Je ne parlais pas de différence, mais de compatibilité au niveau des arguments en ligne de commande, voire de l'API (pouvoir remplacer ffmpeg par libav et inversement sans que ton script/programme se retrouve cassé. Ce qui compte quand on remplace ffmpeg par libav dans une distrib')
J'avais bien compris, et je dis justement que c'est pas suffisant. L'API peut être similaire, mais avec les mêmes arguments justement, un programme se retrouvera cassé selon l'implémentation. C'est le cas dans le bug que j'ai corrigé sur blender où on se retrouvait avec diverses implémentations d'un même codec selon le projet (à l'époque où j'ai patché, j'utilisais l'implémentation libav de ffmpeg!), et on doit tester à l'exécution. Avec les mêmes arguments justement, c'était pas portable de l'un à l'autre, ni réciproquement.
Morceaux choisis :
Je donnais des cas réels avec patchs à l'appui. Pas des "morceaux choisis" extraits de doc ou de beaux discours.
Maintenant soyons clair. Je ne dis pas que l'un est mieux que l'autre et je ne jette sûrement pas la pierre à l'équipe de ffmpeg sur le coup. Vu de l'extérieur (de loin, car je ne suis pas vraiment cette histoire, en gros les commentaires dans ton genre ou les blog posts dont les liens sont donnés plus haut sont informatifs pour moi), il semblerait que l'équipe de ffmpeg a en effet un comportement plus sain que ceux de libav, ou du moins font plus d'efforts. Peut-être que le problème que j'avais patché à l'époque n'était qu'une erreur passagère, un oubli, et que depuis l'équipe de ffmpeg a amélioré la compatibilité des codecs avec libav.
Néanmoins je dis juste que tout n'est pas aussi bien et bon avec l'implémentation de ffmpeg qu'ils le prétendent. Probablement pas de leur faute s'ils doivent constamment faire avec une équipe hostile chez libav, mais c'est un fait, appuyé par des patchs ici et là de divers dév, et des logiciels qui cassent, etc.
Pour moi, c'est une situation qui ne peut pas tenir. C'est pas sain. On ne peut pas avoir deux équipes hostiles dont l'une refuse catégoriquement de collaborer avec l'autre, et qui travaillent sur une API de même nom. Même si la première fait énormément d'efforts dans ce sens, les efforts doivent être dans les 2 sens, sinon ça ne peut être que bancal!
Il faut que l'une accepte de renommer ou alors que les deux équipes se mettent finalement d'accord pour collaborer. Et je suis d'accord que ce serait bien plus justifié si le fork (donc le projet libav) était celui qui renomme, car après tout... ben ils sont un fork du premier! Mais de manière évidente (ne serait-ce que par le nom de projet qu'ils ont choisi: libav), il semblerait qu'ils ne veulent vraiment pas et qu'ils sont bornés. Donc je vois pas de solution, mais tout ce que je constate, c'est que la situation est devenue un véritable enfer pour les utilisateurs comme pour les développeurs tiers. Et ce, quelque soit la bonne volonté de l'équipe ffmpeg. Là n'est pas la question.
Les faits sont dans les patchs et les commits des projets, dans les tentatives de compilation, et dans les logiciels qui cassent à l'usage (même en utilisant ffmpeg!), pas dans des "morceaux choisis" sur des sites web.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche FFmpeg 2.1. Évalué à 1.
Salut,
J'avais bien compris, et je dis justement que c'est pas suffisant. L'API peut être similaire, mais avec les mêmes arguments justement, un programme se retrouvera cassé selon l'implémentation. C'est le cas dans le bug que j'ai corrigé sur blender où on se retrouvait avec diverses implémentations d'un même codec selon le projet (à l'époque où j'ai patché, j'utilisais l'implémentation libav de ffmpeg!), et on doit tester à l'exécution. Avec les mêmes arguments justement, c'était pas portable de l'un à l'autre, ni réciproquement.
Je donnais des cas réels avec patchs à l'appui. Pas des "morceaux choisis" extraits de doc ou de beaux discours.
Maintenant soyons clair. Je ne dis pas que l'un est mieux que l'autre et je ne jette sûrement pas la pierre à l'équipe de ffmpeg sur le coup. Vu de l'extérieur (de loin, car je ne suis pas vraiment cette histoire, en gros les commentaires dans ton genre ou les blog posts dont les liens sont donnés plus haut sont informatifs pour moi), il semblerait que l'équipe de ffmpeg a en effet un comportement plus sain que ceux de libav, ou du moins font plus d'efforts. Peut-être que le problème que j'avais patché à l'époque n'était qu'une erreur passagère, un oubli, et que depuis l'équipe de ffmpeg a amélioré la compatibilité des codecs avec libav.
Néanmoins je dis juste que tout n'est pas aussi bien et bon avec l'implémentation de ffmpeg qu'ils le prétendent. Probablement pas de leur faute s'ils doivent constamment faire avec une équipe hostile chez libav, mais c'est un fait, appuyé par des patchs ici et là de divers dév, et des logiciels qui cassent, etc.
Pour moi, c'est une situation qui ne peut pas tenir. C'est pas sain. On ne peut pas avoir deux équipes hostiles dont l'une refuse catégoriquement de collaborer avec l'autre, et qui travaillent sur une API de même nom. Même si la première fait énormément d'efforts dans ce sens, les efforts doivent être dans les 2 sens, sinon ça ne peut être que bancal!
Il faut que l'une accepte de renommer ou alors que les deux équipes se mettent finalement d'accord pour collaborer. Et je suis d'accord que ce serait bien plus justifié si le fork (donc le projet libav) était celui qui renomme, car après tout... ben ils sont un fork du premier! Mais de manière évidente (ne serait-ce que par le nom de projet qu'ils ont choisi: libav), il semblerait qu'ils ne veulent vraiment pas et qu'ils sont bornés. Donc je vois pas de solution, mais tout ce que je constate, c'est que la situation est devenue un véritable enfer pour les utilisateurs comme pour les développeurs tiers. Et ce, quelque soit la bonne volonté de l'équipe ffmpeg. Là n'est pas la question.
Les faits sont dans les patchs et les commits des projets, dans les tentatives de compilation, et dans les logiciels qui cassent à l'usage (même en utilisant ffmpeg!), pas dans des "morceaux choisis" sur des sites web.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]