FFmpeg vient de sortir en version 2.1, apportant son lot de nouveautés et de nouveaux formats pris en charge. Rappelons que FFmpeg est un outil de traitement vidéo et audio parmi les plus complets et puissants qui existent, avec VLC media player. Pour ne rien gâcher, il est multi‐plate‐forme et libre. D’ailleurs, saviez‐vous qu’en fonction des options de compilation, la licence était soit la GPL v2, soit la LGPL v2 ? En effet, LGPL par défaut, FFmpeg peut être compilé avec des options et des optimisations couvertes par la GPL, qui s’applique alors à tout le code !
Cette version est l’occasion d’ajouter :
- le décodage du WebP et du VP9 en natif ;
- la lecture des méta‐données EXIF des fichiers JPEG ;
- la prise en charge du protocole de transfert sécurisé SFTP (via la libssh) ;
- PulseAudio et le Framebuffer Linux comme périphériques de sortie ;
- la lecture du télétexte DVB(TV TNT) ;
- une nouvelle option
-tpour limiter la durée de lecture de la source (enregistrements partiels) ; - la lecture du format HEVC(H.265) dans des conteneurs Matroska et MP4 ;
- le déplacement dans les flux RTMP(protocole réseau propriétaire d’Adobe pour la diffusion de flux principalement utilisés par Flash).
Notes de révisions plus complètes (mais pas exhaustives) pour cette version 2.1 :
- aecho filter
- perspective filter ported from libmpcodecs
- ffprobe -show_programs option
- compand filter
- RTMP seek support
- when transcoding with ffmpeg (i.e. not streamcopying), -ss is now accurate
even when used as an input option. Previous behavior can be restored with
the -noaccurate_seek option.
- ffmpeg -t option can now be used for inputs, to limit the duration of
data read from an input file
- incomplete Voxware MetaSound decoder
- read EXIF metadata from JPEG
- DVB teletext decoder
- phase filter ported from libmpcodecs
- w3fdif filter
- Opus support in Matroska
- FFV1 version 1.3 is stable and no longer experimental
- FFV1: YUVA(444,422,420) 9, 10 and 16 bit support
- changed DTS stream id in lavf mpeg ps muxer from 0x8a to 0x88, to be
more consistent with other muxers.
- adelay filter
- pullup filter ported from libmpcodecs
- ffprobe -read_intervals option
- Lossless and alpha support for WebP decoder
- Error Resilient AAC syntax (ER AAC LC) decoding
- Low Delay AAC (ER AAC LD) decoding
- mux chapters in ASF files
- SFTP protocol (via libssh)
- libx264: add ability to encode in YUVJ422P and YUVJ444P
- Fraps: use BT.709 colorspace by default for yuv, as reference fraps decoder does
- make decoding alpha optional for prores, ffv1 and vp6 by setting
the skip_alpha flag.
- ladspa wrapper filter
- native VP9 decoder
- dpx parser
- max_error_rate parameter in ffmpeg
- PulseAudio output device
- ReplayGain scanner
- Enhanced Low Delay AAC (ER AAC ELD) decoding (no LD SBR support)
- Linux framebuffer output device
- HEVC decoder, raw HEVC demuxer, HEVC demuxing in TS, Matroska and MP4
- mergeplanes filterAller plus loin
- Site Web de FFmpeg (435 clics)
- Journal des modifications détaillé de FFmpeg (77 clics)
# Troll
Posté par Xinfe (site web personnel) . Évalué à 10.
C'en est où, cette petite guerre ?
[^] # Re: Troll
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 29 octobre 2013 à 14:32.
Pour ceux qui ne connaîtraient pas le mproblème, FFmpeg a été forké par certains de ses contributeurs, sous le nom de Libav. Les deux projets, FFmpeg et Libav, fournissent essentiellement les mêmes bibliothèques, sous les mêmes noms, mais Libav se distingue par le retrait programmé de la commande ffmpeg, remplacée par un outil nommé avconv, avec un message à la limite de la calomnie — c'est à dire que dire que ffmpeg est caduc, c'est faux en général, et vrai uniquement dans le cadre des outils fournis par Libav.
Le mainteneur des paquets relatifs à FFmpeg dans Debian étant un des initiateurs de fork Libav, il est évidemment passé à ce nouveau projet pour ces paquets. Dans Debian, on ne trouve donc pas FFmpeg mais seulement Libav. Quand à l'état de cette guéguerre, à ma connaissance elle continue, mais j'ignore si ça cause de gros problèmes ou non. Si une compatibilité absolue est maintenue, pas de problème à mon avis, mais s'ils s'amusent à jouer avec l'API, le faire sans changer les nom des bibliothèques, ça craint un max.
[^] # Re: Troll
Posté par Debaru . Évalué à 3. Dernière modification le 29 octobre 2013 à 14:48.
Je crois que ça joue dans l'adoption de XBMC par Debian par exemple. Ce dernier utilise FFmpeg et non Libdav.
N'hésitez pas à me dire si je dis une bêtise.
[^] # Re: Troll
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Actuellement, si je comprends bien la situation, aucun projet « n'utilise FFmpeg ou Libav » : ils utilisent des bibliothèques, comme la libavcodec par exemple, qui peut être fournie par FFmpeg ou par Libav. En revanche, s'il commence à y avoir dans ces bibliothèques des fonctions qui n'existent ou qui n'utilisent des options que dans l'une ou l'autre version, là on a un vrai problème.
[^] # Re: Troll
Posté par xcomcmdr . Évalué à 8.
ffmpeg est 100% compatible libav.
L'inverse n'est pas vrai.
Et libav est aussi utilisé par Ubuntu (vu que ça provient des paquets Debian).
Au moins sous Arch on a ffmpeg, le seul, le vrai. ;-)
edit : un lien en plus par rapport à la situation :
http://aballier.wordpress.com/2013/01/18/ffmpeg-vs-libav-a-distribution-maintainer-point-of-view-almost-two-years-after-the-split/
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je sais pas vraiment ce que signifie "l'inverse n'est pas vrai" (j'entends par là: "ça veut rien dire" car si A fait différent de B, alors B est différent de A). Il s'agit "soi-disant" de deux implémentations de libav, et elles sont différentes. Donc c'est juste pénible. J'ai déjà dû corriger un problème avec des patchs dans deux softwares que j'utilise à cause de différences entre les implémentations: blender et DVDStyler. Et c'est des bugs plus subtils que juste une API différente (en gros, des implémentations différentes de même codecs), donc plus difficiles à repérer et corriger (détection à l'exécution), comme on peut le voir dans mes patchs, ce qui fait que ces bugs ont été présents un moment dans la nature et sont probablement encore présents dans divers logiciels.
Aussi j'ai régulièrement des problèmes avec mplayer depuis que je suis passé sous Mint alors que c'était mon logiciel vidéo phare. A priori c'est parce que les paquetages utilisés sont ceux de libav (alors que les dév mplayer utilisent bien sûr la version de ffmpeg).
Et lorsque j'essaie de compiler certains software qui utilisent libav, j'ai régulièrement des problèmes, selon que les dévs utilisent plutôt une version, et moi une autre.
Franchement c'est juste ridicule. C'est une guerre de gamins. La solution est pourtant simple: s'ils veulent réellement faire différent, très bien! Aucun problème pour moi. Mais renommez. Que l'une des équipes trouve un nouveau nom et on peut installer les deux libs côte-à-côte, et ainsi les divers logiciels choisissent la librairie de leur rêve et les blems sont finis. Je comprends bien que le nom est important pour la notoriété et la base utilisateur, mais c'est pas notre problème! Ils ont fait un choix conscient de forker, ils pourraient assumer jusqu'au bout.
Parce que là en tant que simple utilisateur, on se retrouve pris en sandwich/otage dans une guerre absurde où on nous demande de choisir aussi en gros, sauf qu'en vrai, on nous laisse pas le choix (c'est en général notre distrib qui choisit), et on se retrouve avec des blems sur une moitié des logiciels qui utilisent libav.
Et en tant que dév tier neutre, c'est aussi chiant, car on doit constamment corriger des bugs et des changements pour essayer non plus de suivre 1 librairie, mais pour contourner les différences qui apparaissent progressivement entre 2 librairies qui prétendent être la même sans l'être.
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 xcomcmdr . Évalué à 10.
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')
Morceaux choisis :
Bref, ffmpeg s'occupe d'être rétro-compatible (garde les anciens codecs, par exemple), et d'être compatible avec libav.
Du côté de libav, on a le syndrome du NIH et pas grand chose d'autre.
Eh oui:
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . É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 ]
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Petit ajout:
Juste au cas donc où j'étais pas assez clair, le bug que j'avais patché était justement qu'a priori le code marchait avec le libav du projet libav, mais pas le libav de ffmpeg que j'avais sur ma machine. Donc ffmpeg n'était pas compatible avec "l'autre" libav.
Note encore une fois: je ne dis pas que c'est de leur faute, et je suis aussi neutre que possible. Je ne prends pas trop parti. C'est juste une constatation et en tant qu'utilisateur, ben on se retrouve avec des bugs, et dire que le libav de ffmpeg est "compatible avec libav" — juste parce que c'est écrit — n'est pas toujours vrai (même si probablement ils essaient, j'ai pas vérifié, mais c'est apparemment ce qui ressort des dires de gens comme toi, et je veux bien vous croire).
C'est pourquoi je dis que la solution n'est pas tenable, et même en choisissant libav comme base en se disant que ça marchera partout (en partant du principe que ffmpeg se dit compatible avec libav), ben on se retrouve avec des bugs. C'est chiant et intenable comme situation.
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 Zenitram (site web personnel) . Évalué à -10.
"je" donc.
Est-ce que du fait de quelques sites webs qui ne fonctionnent que sous Firefox, ou quelques sites webs qui ne fonctionnent que sous Chrome, on dit que "ce n'est pas suffisant" tout ça?
Non, on dit qu'ils lisent du HTML
Ben la, pareil, la seule chose qui est dite est que FFmpeg essaye de garder la compatibilité. Des bugs, ça arrive, ton exemple ne fait pas une généralité. oui, le code est différent, oui parfois ça ne marche pas, comme certains sites web avec certains navigateurs, et alors, c'est quoi le rapport avec ce qui est dit par xcomcmdr qui est plus général et plus interessant qu'un bug pour discuter?
Si je te trouve un site web qui ne réagit pas pareil suivant les navigateurs, tu répondra aussi à une personne qui dit que "Firefox et Chrome sont des navigateurs web" que ce n'est pas toujours vrai, c'est pas toujours compatible avec les normes du web?
Ou est-ce que tout le monde ne considérera pas que c'est un bug quelque part, mais qu'en général, c'est compatible avec les normes du web?
J'ai pris l'exemple d'un site web, je peux prendre l'exemple de n'importe quel API/Format dont un logiciel essaye de rester compatible avec l'autre, des bugs ça existe, ça n'enlève pas que pour 99% (voir 99.9%) des gens c'est compatible et c'est ça l'important.
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
C'est ce que je dis, apprends à lire.
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 Zenitram (site web personnel) . Évalué à -10. Dernière modification le 30 octobre 2013 à 08:43.
"n'est pas toujours vrai" en enfonçant plus que nécessaire, en agrandissant un petit bug.
"la situation est devenue un véritable enfer pour les utilisateurs comme pour les développeurs tiers", "C'est pourquoi je dis que la solution n'est pas tenable", "C'est chiant et intenable comme situation", clair allez on arrête le HTML commun à tous les navigateurs, chacun sa norme, parce que Jehan a rencontré un bug HTML.
etc… Je dois en citer plus des trucs "horribles ça marche pas il faut arrêter et se séparer"?
Tu empires les choses et dit le contraire total de ma position (je dis qu'au contraire, c'est largmement tenable comme situation), désolé, on ne dit absolument pas la même chose.
Pour reprendre la phrase d'une autre personne : apprends à lire. (je n'aime pas cette phrase, mais bon, toi tu dois l'apprécier vu la personne qui l'a sortie).
[^] # Re: Troll
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Ahahah. Tu aimes bien dialoguer et argumenter tout seul, même lorsqu'on te dit qu'on est d'accord avec toi.
Et oui j'ai été un peu fort dans mon propos, ce que je n'aime pas faire. Mais c'est vraiment parce que c'est toi. :-D Tu aimes tellement troller juste pour troller que j'ai même plus envie de répondre à tes messages. D'ailleurs c'est ma dernière réponse sur le sujet. Comme j'ai dit, je suis d'accord. À toi de pas me croire et de savoir mieux que moi ce que je pense, si ça t'amuse. :-)
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 zebra3 . Évalué à 6.
Je ne sais pas vraiment d'où ça vient, mais j'ai rencontré des problèmes en effet : j'ai encodé des CD en AAC sur une Debian avec les libav* issus de deb-multimedia (donc ffmpeg), et le mpd issu du dépôt officiel Debian (basé sur libav) n'est pas capable d'en lire certains.
Si je le recompile avec les libav*dev de dmo, je n'ai plus le problème. Mais dans le même temps, d'autres logiciels du dépôt d'origine sont parfaitement capables de les lire (comme Totem).
Tout ça pour dire qu'au final ce sont bien les utilisateurs qui sont emm*rdés, en introduisant des bugs qui n'ont aucune raison d'être (ie la cause n'est pas technique).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Troll
Posté par Reihar . Évalué à 8.
Il manque un détail. Le packager debian a décidé de garder ffmpeg pour le nom de paquet de libav.
Cf : http://packages.debian.org/sid/ffmpeg
[^] # Re: Troll
Posté par vv222 (site web personnel) . Évalué à 3.
Le paquet que tu cites n'existe que pour l'architecture hppa.
Sur une machine plus "standard", le paquet ffmpeg n'est plus proposé dans les dépôts de Sid.
[^] # Re: Troll
Posté par Reihar . Évalué à 2.
Au temps pour moi, la clarté du site de Debian m'a troublé. Au moins leur position s'améliore…
[^] # Re: Troll
Posté par Reihar . Évalué à 1.
D'ailleurs, les debianeux, j'avais lu la news à propos du dépot debian-multimedia. Est-ce que vous avez un remplaçant pour pouvoir vous procurer ffmpeg ?
[^] # Re: Troll
Posté par shbrol . Évalué à 3.
http://www.deb-multimedia.org
[^] # Re: Troll
Posté par elboulangero (site web personnel) . Évalué à 0.
Perso je n'utilise pas le dépot deb-multimedia.org, mais pour autant que je sache le dépot est toujours maintenu et fournit ffmpeg.
http://www.ffmpeg.org/download.html, section FFmpeg Linux Builds
[^] # Re: Troll
Posté par Maclag . Évalué à 2.
Pas sûr de comprendre, mais si tu fais référence à la disparition du site debian-multimedia.org, il ne s'agit en fait pas d'une disparition mais d'une migration.
Le nouveau site s'appelle deb-multimedia et Christian Marillat fournit toujours les paquets comme avant:
http://deb-multimedia.org/
Certains chez Debian s'inquiétaient que le nom du site Debian Multimedia prête à confusion et que des donateurs envoient de l'argent au projet en pensant qu'il s'agit d'un projet Debian officiel.
Ils lui ont donc demandé de changer de nom.
J'espère qu'il reçoit autant de dons qu'avant!
Longue vie à deb-multimedia!
[^] # Re: Troll
Posté par Reihar . Évalué à 0.
Au temps pour moi, j'avais gardé un mauvais souvenir de la news. J'utilise très rarement debian mais je préfère savoir que ce dépôt existe au cas où.
[^] # Re: Troll
Posté par vv222 (site web personnel) . Évalué à 1.
Pas d'inquiétude : il existe toujours, et est toujours aussi peu utile ;)
[^] # Re: Troll
Posté par sifu . Évalué à 4.
Bof.
Comme expliqué par Tanguy plus haut, le message indiquant que la commande ffmpeg était obsolète était très limite.
J'espère que le fork va prendre ses responsabilités et renommer son bousin.
Ainsi les développeurs et les utilisateurs pourront choisir.
[^] # Re: Troll
Posté par xcomcmdr . Évalué à 5. Dernière modification le 30 octobre 2013 à 09:17.
J'espère surtout que ce bousin va bouser de Debian.
----> []
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.