Suite de mon dernier journal il y a presque un an jour pour jour :
FFmpeg de retour dans Debian
Ce ne sera pas une grande surprise pour beaucoup de monde, mais Debian a décidé de remplacer Libav par FFmepg comme fournisseur des bibliothèques multimédia libav* :
libav and FFmpeg: switch over
L'annonce a été faite le 8 juillet et certains s'interrogeaient déjà de la pertinence de cette décision, avec entre autre l'argument habituel que FFmpeg dépendait trop de Michael Niedermayer (le leader de FFmpeg) et que ce n'était pas une situation pérenne :
Why Debian returned to FFmpeg
Coup de tonnerre le 31 juillet avec l'annonce de la démission en tant que leader (pas forcément en tant que contributeur) de Michael Niedermayer qui cite le travail/stress occasionné par l'intégration des « commits du fork » comme cause principale de sa démission ("Indeed i fully admit the work and pressure caused by the merges is a main reason for my resignation"):
FFmpegs future and resigning as leader
L'histoire de ce fork est remarquable à plus d'un titre :
* FFmpeg/Libav est très largement utilisé, aussi bien directement qu'indirectement
* Réaction de Michael Niedermayer suite au fork : il a apparemment vraiment essayé de corriger ce qu'on lui reprochait
* Intégration de toutes les modifications de Libav dans FFmpeg (alors que d'habitude le fork est plus ou moins ignoré)
* Démission de Michael Niedermayer comme ultime tentative pour réunir les deux communautés
# Réaction
Posté par patrick_g (site web personnel) . Évalué à 10.
Est-ce qu'il y a déjà une réponse de la part des devs de libav ?
Un réunification est-elle envisageable ?
[^] # Re: Réaction
Posté par Christie Poutrelle (site web personnel) . Évalué à -10.
Qui de l'équipe jaune ou de l'équipe rouge va gagner l'épreuve d'immunité ?
# Bonne nouvelle
Posté par reynum (site web personnel) . Évalué à 10.
Je suis personnellement content car il m'est plusieurs fois arrivé d'avoir des impossibilités d'utiliser un logiciel car il nécessitait FFMPEG et ne fonctionnait pas avec libav.
J'ai même une fois essayé le dépot non officiel de deb-multimedia.org mais ça m'a cassé vlc et occasionné des confits ailleurs.
En tout cas quand j'ai fait la mise à jour de ma testing la semaine dernière et que j'ai vu arriver les paquets :
libavcodec-ffmpeg56
libavformat-ffmpeg56
libavutil-ffmpeg54
…
Et bien j'étais heureux.
kentoc'h mervel eget bezan saotred
[^] # Re: Bonne nouvelle
Posté par Ely . Évalué à 10.
Je n'ai jamais compris le passage au projet Libav par les distributions. Peut-être avaient-elles de meilleurs contacts avec les développeurs de Libav plutôt que FFmpeg ?
Depuis ce fork, FFmpeg fait de son mieux pour continuer à faire le meilleur logiciel de traitement vidéo/son en continuant à rajouter des fonctionnalités et en migrant tous les commits de fix de Libav, alors que les devs de Libav ont décidé de bouder et d'ignorer complètement ce qui se passait dans le projet mère.
La plupart des logiciels multimedia construits sur FFmpeg ont du s'adapter et fournir des bridges pour les deux projets, mais la plupart recommandent toujours FFmpeg.
Bref, très content également de ce retour aux sources, mais dommage pour Michael Niedermayer et le travail colossal qu'il abattait chaque jour.
[^] # Re: Bonne nouvelle
Posté par reynum (site web personnel) . Évalué à 10.
En ce qui concerne Debian la raison est toute simple :
Le mainteneur des paquets ffmpeg faisait partie de l'équipe du fork, donc naturellement la migration s'est faite vers libav.
kentoc'h mervel eget bezan saotred
[^] # Re: Bonne nouvelle
Posté par desktop.ready . Évalué à 1.
Ce n'est pas tout à fait toute l'histoire.
La raison donnée (je ne sais pas si c'est vrai, à vous de voir), c'est que Libav essaye de refactoriser et de recoder de manière plus propre. Donc tout patch venant de FFmpeg doit passer le contrôle qualité plus strict, ce qui prend du temps…
[^] # Re: Bonne nouvelle
Posté par Tit'nouille . Évalué à 7.
Parce que les patch venant de Libav ne nécessitent pas le même travail pour être intégrés à FFmpeg?
[^] # Re: Bonne nouvelle
Posté par Sufflope (site web personnel) . Évalué à 2.
Bah si les devs FFmpeg développent comme des gorets (j'en sais rien, c'est ce que le Monsieur dit) non… git merge et pouf on verra bien.
[^] # Re: Bonne nouvelle
Posté par desktop.ready . Évalué à 6.
Cette remarque revient souvent dans les listes de diffusion :
http://lwn.net/Articles/653379/
Pour le coup il donne un exemple justement où le code importé de Libav n'a apparemment pas été fait correctement.
Donc tout n'est pas blanc ou noir dans cette affaire…
[^] # Re: Bonne nouvelle
Posté par tao popus . Évalué à 3.
Je n'arrive pas à remettre la main sur l'article qui était me semble t-il dans l'article précédent linuxfr sur le sujet (ou via plusieurs liens intermédiaires), où un un des devs qui avait participé aux 2 projets expliquaient que les dev de libav n'avaient pas beaucoup avancé et étaient de mauvaise foi, diff des dépôts git respectifs à l'appuie. Il y montrait plusieurs exemples de patchs importants (réparant de gros problèmes reportés dans le tracker de libav), patchés rapidement sur ffmpeg, puis, plusieurs mois après copiés à l'identique dans libav, sans citer l'auteur original dans le git ffmpeg et faignant d'ignorer ffmpeg. L'auteur de ffmpeg à été plus honnête en montrant bien qu'il réintégrait les évolutions de libav, lorsque c'était le cas.
Il expliquait également, que libav avait cassé à plusieurs reprises l'API tandis que l'auteur de ffmpeg s'efforçait de conserver la compatibilité aux anciennes versions de ffmpeg et de libav simultanément via différents moyens.
AAahh, je l'ai retrouvé : http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
# Du coté de Gentoo
Posté par Tonton Benoit . Évalué à 10.
Après avoir passés à libav par défaut ils en sont aussi revenus à ffmpeg :
Gentoo c'est le choix, mais n'ayant aucune connaissance ni besoin particuliers dans ce domaine (je veut juste lire des vidéos) j'ai suivi le choix par défaut, autant pour le passage à la libav que pour le retour à ffmpeg.
Et la seule fois ou j'ai eu besoin de mixer de l'audio/video j'ai eu affaire à un bug de la libav qui me sortait un fichier 10 fois trop gros. Du coup obligé de télécharger un binaire pré-compilé de ffmpeg pour faire le boulot…
[^] # Re: Du coté de Gentoo
Posté par FredBezies . Évalué à 6.
Sur Archlinux, il n'y a que ffmpeg, du moins, je ne me souviens pas d'un switch entre les deux logiciels.
D'ailleurs, en essayant de maintenir sur AUR le
logicielscript avancé Dpluzz, j'ai été confronté à ce duo infernal, Ubuntu proposant libav, et Archlinux ffmpeg.Heureux que la situation s'éclaire et se simplifie pour les Debian based.
Un libriste qui en a sa claque des puristes.
[^] # Re: Du coté de Gentoo
Posté par Reihar . Évalué à -4.
AUR.
[^] # Re: Du coté de Gentoo
Posté par FredBezies . Évalué à 3.
J'aurais du préciser : Archlinux User Repository. Le dépot communautaire dans son acception étymologique.
En clair, on y trouve tout ce que la communauté peut proposer, le meilleur comme le pire. Et souvent le pire, d'ailleurs :D
Un libriste qui en a sa claque des puristes.
# Et pour parler autre chose que de politique
Posté par Stéphane P. . Évalué à 1.
Beaucoup d'améliorations ces derniers temps dans FFmpeg, surtout deux améliorations que je trouve assez génial :
- Le filtre dynaudnorm, si vous récupérez des enregistrement de conférence avec des personnes qui par moment ne parlent pas toujours bien devant le micro, ce filtre va rendre la vidéo beaucoup plus écoutable, on comprend tout sans tendre l'oreille. Tout nouveau depuis juillet.
- La vitesse d'encodage du VP9 (même si c'est plus un progrès de libvpx). Je ne l'ai pas encore beaucoup utilisé mais en 1 an, j'ai l'impression qu'on est passez de "inutilisablement lent à l'encodage" à "un compromis raisonnable", de quoi rendre le codec globalement plus intéressant que VP8.
Manque plus que de l'entrée/sortie WebRTC et ce serait vraiment fou (j'avoue que je n'ai pas trop regardé pour savoir si cela a du sens et si c'est techniquement possible).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.