Difference between pages "Boot Methods" and "FLOP:FFmpeg"

(Difference between pages)
(BIOS + GRUB (MBR))
 
 
Line 1: Line 1:
It used to be that booting a PC-compatible system didn't involve very many choices -- there was only one way to do it. All of our desktops and servers had a standard BIOS, all our hard drives used Master Boot Records, and were partitioned using the MBR partition scheme. Then, along came EFI and UEFI, which are new-style firmware designed to boot systems, along with GPT partition tables to support disks larger than 2.2TB. All of the sudden, we then had a variety of options to boot Linux systems, turning what once was a one-method-fits-all approach into something a lot more complex.
+
{{FLOP
 +
|Created on=2015/01/31
 +
|Summary=Funtoo Linux prefers FFmpeg. Some enlightenment about our choice and why we prefer this  or could switch to alternative in future.
 +
|Author=Oleg, Mgorny
 +
|Maintainer=Oleg
 +
|Reference Bug=FL-844
 +
}}
 +
== Introduction ==
 +
FFmpeg and Libav are library sets for multimedia decoding (and more). Both libraries expose similar API and features.
  
=== BIOS + GRUB (MBR) ===
+
Both project have common origins and diverged only recently. The developers share the same bad coding practices causing permanent lack of API and ABI stability, therefore requiring frequent rebuilds of reverse dependencies.
  
{{Note|This option is the "old school" way to boot Funtoo Linux, as documented in our [[Install|Install Guide]]. This method uses traditional MBR partitions, which have existed since the origin of the PC. }}
+
Worse than that, after the split projects use colliding SONAMEs for libraries with potentially different ABI. This means that after switching from one implementation to another, the reverse dependencies may become broken instantly (preserved-libs doesn't help) and need to be rebuilt ASAP.
  
Here is the typical disk layout:
+
Many packages for video decoding, are done via FFmpeg or Libav.  Differences between FFmpeg and Libav can have a major impact on its behavior: the number of files it can decode, whether it decodes correctly, what video and audio filters are provided, network behavior, and more.
  
* MBR (master boot record) at beginning of boot disk
+
== Current status ==
* MBR partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (typically ext2)
+
=== Funtoo ===
* MBR partition 2, <tt>/dev/sda2</tt> is ''swap''.
+
Funtoo supports only FFmpeg. It is forced by Funtoo version of virtual/ffmpeg. This provides the ability to avoid the Gentoo issues, as explained below.
* MBR partition 3, <tt>/dev/sda3</tt> is the <tt>/</tt> (root) filesystem.
+
  
Here's how the boot process works:
+
Decision made by Oleg, forced by #funtoo community and bugtracker reports.
  
# The system BIOS loads the MBR from your boot disk (containing stage1 of the GRUB boot loader) and runs it.
+
=== Gentoo ===
# Extra boot-related code is loaded by the GRUB stage1 from the <tt>/boot</tt> filesystem on the disk.
+
Gentoo supports both ffmpeg and libav, with a preference towards libav. The preference is caused by package order in virtual/ffmpeg — when no other circumstance affects the package choice, Portage will prefer libav. However, if ffmpeg is already installed or a package incompatible with libav is requested, Portage will use ffmpeg instead.
  
Now, the boot loader is able to run and load the Linux kernel and initramfs, and start Funtoo Linux.
+
There are two major technical issues with this design:
 +
# there is no technically correct way of forcing rebuilds on ABI changes — subslot dependencies do not work with virtuals or || () deps,
 +
# there is no way of forcing rebuilds when switching from libav to ffmpeg, and the other way around.
  
=== BIOS + GRUB (GPT) ===
+
== Future status ==
 +
=== Funtoo ===
 +
Funtoo has no plan to change default FFmpeg, it only needs to mask libav in the profiles. Then dependencies on updated packages will unconditionally use FFmpeg. Eventually Funtoo will want to remove virtual/ffmpeg and depend on media-video/ffmpeg:0= directly in forked packages.
  
This is a more modern way to boot Linux. It uses MBR for booting but uses the more modern GPT partition scheme. Here's the disk layout:
+
=== Gentoo ===
 +
There is a planned Gentoo change which will eventually replace virtual/ffmpeg and explicit || () deps with 'libav' USE flag. The flag will be added to all packages that support both FFmpeg and libav. When the flag is enabled, the package will use libav; otherwise it will use FFmpeg. The choice of flag name is forced by the fact that USE=ffmpeg is already used as generic ffmpeg-or-libav flag.
  
* The protective MBR is used for booting.
+
This change fixes both Gentoo issues:
* GPT partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (typically ext2)
+
# USE-conditional dependencies allow subslot dependencies to force rebuilds on ABI changes,
* GPT partition 2 type 0xEF02, <tt>/dev/sda2</tt> is the ''boot loader partition'' (this contains a fake MBR).
+
# provider change will force rebuild because of USE flag change.
* GPT partition 3, <tt>/dev/sda3</tt> is ''swap''.
+
* GPT partition 4, <tt>/dev/sda4</tt> is the <tt>/</tt> (root) filesystem.
+
  
Here's how this hybrid scheme works:
+
The change may also eventually make it possible to install FFmpeg and libav side-by-side. Until then, the flag state would involve 'strong' preference of one implementation over the other, and user will have to change USE=libav as a global flag. '''Installing a package that supports only one of the two implementations will result in blocker that needs to be handled manually'''.
  
# The system BIOS loads the fake MBR from your boot disk(/dev/sda2) (containing stage1 of the GRUB boot loader) and runs it.
 
# Extra boot-related code is loaded by the GRUB stage1 from a small (a few MB) GPT partition on the disk.
 
  
Now, the boot loader is able to run and load the Linux kernel and initramfs, and start Funtoo Linux.
+
== Detailed information on FFmpeg and libav ==
 +
=== FFmpeg and Libav history ===
 +
In 2011, parts of the FFmpeg developers were unhappy about the FFmpeg leadership, and decided to take over. This didn't quite work out. Apparently Fabrice Bellard, original FFmpeg developer and owner of the ffmpeg.org domain name, decided not to hand over the domain name to the new maintainers. So they followed Plan B, and forked FFmpeg, resulting in Libav. Since then, Libav did its own development, and completely ignored whatever FFmpeg did. FFmpeg, on the other hand, started to merge literally everything Libav did.
  
=== UEFI + GRUB ===
+
The reason for the fork is most likely that the developers hate each other. While this formulation seems somewhat sloppy, it is most likely the truth. To this date, the #libav-devel IRC channel still has Michael Niedermayer (the FFmpeg maintainer since 2004 according to Wikipedia) on their ban list (similar misbehavior is exhibited by some FFmpeg developers). There is little to no cooperation between the two projects.
  
{{Note|This method is documented in our [[Install|Install Guide]] as the "new school" UEFI boot method.}}
+
More about FFmpeg's history and the fork incident can be found on Wikipedia
  
UEFI is a new-style firmware that is used for booting. It is generally available on all new PCs (2012 and newer) and may be available on older systems as well. Here's the disk layout:
+
=== Situation today ===
 +
FFmpeg has more features and slightly more active development than Libav, going by mailing list and commit volume. In particular, FFmpeg's features are a superset of Libav's features. This is because FFmpeg merges Libav's git master on a daily basis. Libav on the other hand seems to prefer to ignore FFmpeg development (with occasional cherry-picking of bug fixes and features).
  
* ''no MBR is installed or required''
+
Some Linux distributions, especially those that had Libav developers as FFmpeg package maintainers, replaced FFmpeg with Libav, while other distributions stick with FFmpeg. Application developers typically have to make sure their code works with both libraries. This can be trivial to hard, depending on the details. One larger problem is that the difference between the libraries makes it hard to keep up a consistent level of the user experience, since either library might silently or blatantly be not up to the task. It also encourages library users to implement some features themselves, rather than dealing with the library differences, or the question to which project to contribute.
* GPT partition 1, <tt>/dev/sda1</tt> is the <tt>/boot</tt> filesystem (<tt>vfat</tt> aka "FAT32").
+
* GPT partition 2, <tt>/dev/sda2</tt> is ''swap''.
+
* GPT partition 3, <tt>/dev/sda3</tt> is the <tt>/</tt> (root) filesystem.
+
  
Here's how this boot scheme works:
+
FFmpeg and Libav developers also seem to have the tendency to ignore the damage their rivalry is causing. Apparently fighting out these issues on the users' backs is better than reconciling. This means everyone using these libraries either has to suffer from the differences, or reimplement functionality that is not the same between FFmpeg and Libav.
 
+
{{FLOPFooter}}
# UEFI (contained in your motherboard's firmware) loads the Bootmanager entry from the RW NVRAM inside your motherboard.  
+
# If there's a valid entry that contains Grub, then the GRUB boot loader code from your <tt>/boot</tt> filesystem will be loaded.
+
# UEFI can read from <tt>vfat</tt> partitions directly, which is why we use <tt>vfat</tt> instead of the normal <tt>ext2</tt> for <tt>/boot</tt>.
+
 
+
Now, the boot loader is able to run and load the Linux kernel and initramfs from the <tt>vfat</tt> <tt>/boot</tt> filesystem, and start Funtoo Linux.
+
 
+
=== Pure UEFI ===
+
 
+
A Pure UEFI boot is also possible. The partitioning scheme is the same as the UEFI + GRUB scheme, above.
+
 
+
Here's how this boot scheme works:
+
 
+
# UEFI (contained in your motherboard's firmware) loads the Bootmanager entry from the RW NVRAM inside your motherboard.
+
#  UEFI loads the Linux kernel STUB and initramfs directly, and runs the Linux kernel to start Funtoo Linux.
+

Latest revision as of 07:44, February 1, 2015

Created on
2015/01/31
Original Author(s)
{{#set:Author={{ #show: User:Oleg | ?Full name }}}}{{ #show: User:Oleg | ?Full name }},{{#set:Author={{ #show: User:Mgorny | ?Full name }}}}{{ #show: User:Mgorny | ?Full name }}
Current Maintainer(s)
Oleg Vinichenko
Status
Reference Bug
FL-844

Funtoo Linux Optimization Proposal: FFmpeg

Funtoo Linux prefers FFmpeg. Some enlightenment about our choice and why we prefer this or could switch to alternative in future.

Introduction

FFmpeg and Libav are library sets for multimedia decoding (and more). Both libraries expose similar API and features.

Both project have common origins and diverged only recently. The developers share the same bad coding practices causing permanent lack of API and ABI stability, therefore requiring frequent rebuilds of reverse dependencies.

Worse than that, after the split projects use colliding SONAMEs for libraries with potentially different ABI. This means that after switching from one implementation to another, the reverse dependencies may become broken instantly (preserved-libs doesn't help) and need to be rebuilt ASAP.

Many packages for video decoding, are done via FFmpeg or Libav. Differences between FFmpeg and Libav can have a major impact on its behavior: the number of files it can decode, whether it decodes correctly, what video and audio filters are provided, network behavior, and more.

Current status

Funtoo

Funtoo supports only FFmpeg. It is forced by Funtoo version of virtual/ffmpeg. This provides the ability to avoid the Gentoo issues, as explained below.

Decision made by Oleg, forced by #funtoo community and bugtracker reports.

Gentoo

Gentoo supports both ffmpeg and libav, with a preference towards libav. The preference is caused by package order in virtual/ffmpeg — when no other circumstance affects the package choice, Portage will prefer libav. However, if ffmpeg is already installed or a package incompatible with libav is requested, Portage will use ffmpeg instead.

There are two major technical issues with this design:

  1. there is no technically correct way of forcing rebuilds on ABI changes — subslot dependencies do not work with virtuals or || () deps,
  2. there is no way of forcing rebuilds when switching from libav to ffmpeg, and the other way around.

Future status

Funtoo

Funtoo has no plan to change default FFmpeg, it only needs to mask libav in the profiles. Then dependencies on updated packages will unconditionally use FFmpeg. Eventually Funtoo will want to remove virtual/ffmpeg and depend on media-video/ffmpeg:0= directly in forked packages.

Gentoo

There is a planned Gentoo change which will eventually replace virtual/ffmpeg and explicit || () deps with 'libav' USE flag. The flag will be added to all packages that support both FFmpeg and libav. When the flag is enabled, the package will use libav; otherwise it will use FFmpeg. The choice of flag name is forced by the fact that USE=ffmpeg is already used as generic ffmpeg-or-libav flag.

This change fixes both Gentoo issues:

  1. USE-conditional dependencies allow subslot dependencies to force rebuilds on ABI changes,
  2. provider change will force rebuild because of USE flag change.

The change may also eventually make it possible to install FFmpeg and libav side-by-side. Until then, the flag state would involve 'strong' preference of one implementation over the other, and user will have to change USE=libav as a global flag. Installing a package that supports only one of the two implementations will result in blocker that needs to be handled manually.


Detailed information on FFmpeg and libav

FFmpeg and Libav history

In 2011, parts of the FFmpeg developers were unhappy about the FFmpeg leadership, and decided to take over. This didn't quite work out. Apparently Fabrice Bellard, original FFmpeg developer and owner of the ffmpeg.org domain name, decided not to hand over the domain name to the new maintainers. So they followed Plan B, and forked FFmpeg, resulting in Libav. Since then, Libav did its own development, and completely ignored whatever FFmpeg did. FFmpeg, on the other hand, started to merge literally everything Libav did.

The reason for the fork is most likely that the developers hate each other. While this formulation seems somewhat sloppy, it is most likely the truth. To this date, the #libav-devel IRC channel still has Michael Niedermayer (the FFmpeg maintainer since 2004 according to Wikipedia) on their ban list (similar misbehavior is exhibited by some FFmpeg developers). There is little to no cooperation between the two projects.

More about FFmpeg's history and the fork incident can be found on Wikipedia

Situation today

FFmpeg has more features and slightly more active development than Libav, going by mailing list and commit volume. In particular, FFmpeg's features are a superset of Libav's features. This is because FFmpeg merges Libav's git master on a daily basis. Libav on the other hand seems to prefer to ignore FFmpeg development (with occasional cherry-picking of bug fixes and features).

Some Linux distributions, especially those that had Libav developers as FFmpeg package maintainers, replaced FFmpeg with Libav, while other distributions stick with FFmpeg. Application developers typically have to make sure their code works with both libraries. This can be trivial to hard, depending on the details. One larger problem is that the difference between the libraries makes it hard to keep up a consistent level of the user experience, since either library might silently or blatantly be not up to the task. It also encourages library users to implement some features themselves, rather than dealing with the library differences, or the question to which project to contribute.

FFmpeg and Libav developers also seem to have the tendency to ignore the damage their rivalry is causing. Apparently fighting out these issues on the users' backs is better than reconciling. This means everyone using these libraries either has to suffer from the differences, or reimplement functionality that is not the same between FFmpeg and Libav.

blog comments powered by Disqus