Difference between pages "Install/fr/Stage3" and "FLOP:FFmpeg"

< Install‎ | fr(Difference between pages)
(Installion du Stage 3)
 
(add technical details to the FLOP)
 
Line 1: Line 1:
<noinclude>
+
{{FLOP
{{InstallPart|installation de l'archive du Stage 3}}
+
|Created on=2015/01/31
</noinclude>
+
|Summary=Funtoo Linux prefers FFmpeg. Some enlightenment about our choice and why we prefer this  or could switch to alternative in future.
=== Installion du Stage 3 ===
+
|Author=Oleg, Mgorny
 +
|Maintainer=Oleg, Mgorny
 +
|Reference Bug=FL-844
 +
}}
 +
== Introduction ==
 +
FFmpeg and Libav are library sets for multimedia decoding (and more). Both libraries expose similar API and features.
  
La prochaine étape dans la mise en place de Funtoo Linux consiste à télécharger et à installer le Stage 3. Le Stage 3 fournit un système pré-compilé qui sert de point de départ à l'installation du système d'exploitation Funtoo Linux. Ouvrez une nouvelle fenêtre dans votre navigateur Web en allant à l'une de ces adresses: 
+
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.
{{MirrorList}}
+
  
Navigons dans les répertoires des miroirs afin de trouver l'archive qui convient à notre installation.
+
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.
  
==== Quelle version choisir? ====
+
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.
  
'''En cas d'incertitude, sélectionnez <code>funtoo-current</code>.'''
+
== Current status ==
 +
=== Gentoo ===
 +
Gentoo supports both ffmpeg and libav, with a weak 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.
  
Funtoo Linux offre différentes variantes de ses versions pré-compilées. En voici une liste ainsi que leur trait distinctif:
+
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.
  
{{TableStart}}
+
=== Funtoo ===
<tr><th class="info">Version</th><th class="info">Description</th></tr>
+
Funtoo supports only FFmpeg. It is forced by Funtoo version of virtual/ffmpeg. While this provides the ability to avoid the Gentoo issues, virtual still breaks ABI rebuilds.
<tr><td><code>funtoo-current</code></td><td>La version la plus souvent choisie. Les mises à jour sont fréquentes et rapides. C'est le choix de prédilection de la plupart des utilisateurs d'un poste de travail.</td></tr>
+
<tr><td><code>funtoo-current-hardened</code></td><td>Similaire à <code>funtoo-current</code>, mais construite autour d'un toolchain plus robuste.</td></tr>
+
<tr><td><code>funtoo-stable</code></td><td>Version misant sur la fiabilité des paquets, les mises à jour sont moins fréquentes.</td></tr>
+
{{TableEnd}}
+
  
==== Quelle architecture?  ====
+
Decision made by Oleg, forced by #funtoo community and bugtracker reports.
  
'''En cas d'incertitude, optez pour <code>x86-64bit</code>, ou possiblement <code>pure64</code> pour l'installation sur un serveur.'''
+
== Future status ==
 +
=== 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.
  
Choix disponibles pour les ordinateurs compatibles PC:
+
This change fixes both Gentoo issues:
 +
# USE-conditional dependencies allow subslot dependencies to force rebuilds on ABI changes,
 +
# provider change will force rebuild because of USE flag change.
  
{{TableStart}}
+
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'''.
<tr><th class="info">Architecture</th><th class="info">Description</th></tr>
+
<tr><td><code>x86-64bit</code></td><td>Conçu pour les processeurs modernes 64-bit. Utilise un jeu d'instructions et un adressage 64-bit. Demeure compatible avec les applications 32-bit en fournissant le support «multilib».</td></tr>
+
<tr><td><code>pure64</code></td><td>Conception identique au précédent '''sans le support 32-bit'''.</td></tr>
+
<tr><td><code>x86-32bit</code></td><td>Pour les machines 32-bit telles Athlon XP, Pentium 4, ou Atom antérieur.</td></tr>
+
{{TableEnd}}
+
  
==== Moutures 64-bit ====
+
=== Funtoo ===
 +
If Funtoo decides to keep supporting FFmpeg only, 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.
  
À l'intérieur de la section <code>/funtoo-current/x86-64bit/</code> sur l'un de nos miroirs, vous y verrez plusieurs sous-ensembles de Funtoo Linux 64-bit. Ce sont des Stage 3 spécialement conçus pour tourner sur un type de processeur particulier afin d'offir le meilleur rendement possible. Ces versions pré-compilées du système Funtoo Linux vous font profiter du jeu d'instructions spécifique à chaque processeur.  
+
If Funtoo decides to start supporting libav as an option, it may need to add USE="-libav" to profiles if Gentoo decides for libav default. Funtoo will want to progressively update forked packages to match Gentoo dependency specifications.
  
Si votre processeur est du type AMD, téléchargez un stage3 d'un des répertoires <code>generic_64</code>, <code>amd64-k8</code>, <code>amd64-k10</code>, <code>amd64-bulldozer</code>, <code>amd64-piledriver</code>, <code>amd64-steamroller</code> ou <code>amd64-jaguar</code>. Voir [[Subarches#64-bit AMD Processors|notre liste de moutures 64-bit AMD]]
+
== Detailed information on FFmpeg and libav ==
pour obtenir de l'aide sur le choix de la mouture qui vous convient le mieux.
+
=== 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.
  
Si votre processeur est du type Intel, téléchargez un stage3 d'un des répertoires <code>generic_64</code>, <code>atom_64</code>, <code>core2_64</code> ou <code>corei7</code>. La mouture <code>corei7</code> convient parfaitement aux processeurs Intel dernier cri, incluant Core i3 et Core i5 ainsi  que plusieurs Xeons. Voir [[Subarches#64-bit Intel Processors|notre liste de moutures Intel 64-bit]] pour vous aider à faire un choix judicieux.
+
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.
  
Pour les processeurs 32-bit, téléchargez un stage3 d'un des répertoires <code>generic_32</code>, <code>i686</code>, <code>core2_32</code>, <code>atom_32</code> ou <code>athlon-xp</code>.
+
More about FFmpeg's history and the fork incident can be found on Wikipedia
  
==== Réglage de la date ====
+
=== 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).
  
{{Important|Il y a des risques que Portage ne télécharge pas correctement l'archive du fichier d'installation quand la date du système s'éloigne trop de la date courante, voire des mois ou des années. Cela en raison du fait que certains sources sont téléchargés via HTTPS qui utilise des certificats SSL. Ces certificats fournissent une date d'activation et une date d'expiration. Cependant, si l'écart n'est pas trop prononcé, vous pouvez probablement ignorer cette étape pour l'instant.}}
+
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.
  
Vérifions maintenant si l'heure et la date sont conformes aux valeurs UTC. Utilisez la commande <code>date</code> pour vérifier le tout:
+
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}}
<console>
+
# ##i##date
+
lundi 22 décembre 2014, 09:06:06 (UTC-0500)
+
</console>
+
 
+
Si vous devez corriger les date et heure, utilisez cette forme de la commande date: <code>date MMDDhhmmYYYY</code>, en gardant à l'esprit que <code>hhmm</code> représente le format 24 heures.
+
 
+
Une fois le réglage complété, cela constitue une très bonne idée que d'initialiser l'horloge matérielle avec l'heure UTC:
+
 
+
<console>
+
# ##i##hwclock --systohc
+
</console>
+
 
+
==== Téléchargement du Stage3 ====
+
 
+
Une fois à la racine du système Funtoo Linux, utilisez l'utilitaire <code>wget</code> pour télécharger l'archive Stage 3 que vous avez choisie pour votre système Funtoo Linux. Le fichier sera enregistré ainsi dans le dossier <code>/mnt/funtoo</code>:
+
 
+
<console># ##i##cd /mnt/funtoo
+
# ##i##wget http://build.funtoo.org/funtoo-current/x86-64bit/generic_64/stage3-latest.tar.xz
+
</console>
+
 
+
Souvenez-vous qu'un système 64-bit exécute autant les jeux d'instructions 64-bit que 32-bit. Par contre un système 32-bit n'exécute que les jeux d'instructions 32-bit. Assurez-vous également de choisir un Stage 3 conçu spécifiquement pour votre type de processeur. Si vous avez quelque incertitude, misez sur un choix sûr en téléchargeant un Stage 3 <code>generic_64</code> ou <code>generic_32</code> selon le cas.
+
 
+
Extrayez le contenu du fichier d'archive avec la commande suivante:
+
<console>
+
# ##i##tar xpf stage3-latest.tar.xz
+
</console>
+
 
+
{{Important|Il est très important d'utiliser l'option "<code>'''p'''</code>". Elle instruit <code>tar</code> de ''préserver'' les permissions et les droits de propriété qui existent dans l'archive. Autrement les permissions d'accès aux fichiers seront incorrectes.}}
+

Revision as of 23:22, January 31, 2015

Created on
2015/01/31
Original Author(s)
Oleg Vinichenko,Michał Górny
Current Maintainer(s)
Oleg Vinichenko,Michał Górny
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

Gentoo

Gentoo supports both ffmpeg and libav, with a weak 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.

Funtoo

Funtoo supports only FFmpeg. It is forced by Funtoo version of virtual/ffmpeg. While this provides the ability to avoid the Gentoo issues, virtual still breaks ABI rebuilds.

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

Future status

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.

Funtoo

If Funtoo decides to keep supporting FFmpeg only, 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.

If Funtoo decides to start supporting libav as an option, it may need to add USE="-libav" to profiles if Gentoo decides for libav default. Funtoo will want to progressively update forked packages to match Gentoo dependency specifications.

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