URL: https://linuxfr.org/news/ffv1-un-format-video-sans-perte-et-libre-normalise-a-l-ietf Title: FFV1, un format vidéo sans perte et libre, normalisé à l'IETF Authors: Zenitram antistress, orfenor, eggman, Stéphane Bortzmeyer, Olivier Jeannet, BAud, yPhil, Benoît Sibaud, Pierre Jarillon, Ltrlg, Yves Bourguignon, Pierre Maziere, Bruno Ethvignot, Julien Jorge, Scoubidouhoua et tisaac Date: 2021-03-10T19:55:35+01:00 Tags: ffmpeg, codec, archivage, standard, ffv1, format_ouvert et flac Score: 3 Si la compression vidéo sans perte est moins tendance que celle avec perte, elle reste utile dans certains domaines (par exemple l’archivage, que ce soit pour son stockage ou sa transmission, qu’il concerne des enregistrements de procès importants pour l’histoire ou le dernier _blockbuster_ à la mode). L’[Internet Engineering Task Force (IETF)](https://fr.wikipedia.org/wiki/Internet_Engineering_Task_Force) avait déjà normalisé des formats de compression avec perte (Opus, pour l'audio), mais pas encore de format sans perte : c'est à présent chose faite, cette fois-ci en matière de vidéo, avec la normalisation de [FFV1](https://en.wikipedia.org/wiki/FFV1) sous le doux nom de [RFC 9043](https://www.rfc-editor.org/rfc/rfc9043). ![logo IETF](https://upload.wikimedia.org/wikipedia/commons/9/98/IETF_Logo.svg) ---- [RFC 9043](https://www.rfc-editor.org/rfc/rfc9043) [Liste des institutions qui utilisent FFV1, sur la Wikipédia en anglais](https://en.wikipedia.org/wiki/FFV1#List_of_institutions_known_to_use_FFV1) [Tout savoir sur FFV1 et les codecs à fin d'archivage, sur Österreichische Mediathek](http://download.das-werkstatt.com/pb/mthk/info/) [Histoire de FFV1 par Peter Bubestinger (diaporama 2015)](https://fr.slideshare.net/OpenLabsOscal/peter-the-ffv1-story) [Paramètres d'encodage en FFV1 avec FFmpeg](https://www.av-rd.com/knowhow/video/ffv1/ffv1_cheatsheet.html) ---- # Un format de compression intra-image, sans perte, à la spécification libre et normalisée FFV1 (« FF video codec 1 ») est un format vidéo sans perte, qui existe depuis 2003 sans avoir été normalisé… jusqu'à aujourd'hui, avec la publication de la [RFC 9043](https://www.rfc-editor.org/rfc/rfc9043). Cette RFC décrit les versions 0, 1 et 3 de ce format (ce n'est pas une faute de frappe, la version 2 a été abandonnée en cours de route au profit de la version 3). Elle est une RFC informelle car elle décrit l’existant (puisque le décodeur de référence a été écrit longtemps avant la spécification). On parle de codec intra-image (ou intra-frame) pour signifier que la compression intervient en analysant les similitudes au sein de chacune des images prises isolément (par opposition aux codecs [inter-frames](https://fr.wikipedia.org/wiki/Inter-trame) qui analysent les similitudes au sein d'images successives). FFV1 prend en charge les images en [niveau de gris](https://fr.wikipedia.org/wiki/Niveau_de_gris), [YUV](https://fr.wikipedia.org/wiki/YUV) ou [RGB](https://fr.wikipedia.org/wiki/Rouge_vert_bleu), avec ou sans [canal alpha (transparence)](https://fr.wikipedia.org/wiki/Canal_alpha), sans limitation du nombre de bits par composante (en pratique [8 à 16 bits par composante](https://twitter.com/JeromeM78/status/964246807734816769) sont utilisés), de n’importe quelle taille (il n’y a pas de notion de « profil » de performance, donc il faut prévoir la machine en conséquence : ne comptez pas faire de la 4K en temps réel avec une machine de bureau même si l'encodage et le décodage [restent nettement plus léger](https://meemoo.be/storage/files/ef9ac152-9176-48f9-aff5-73c11cd5a4f1/rapport-studie-naar-het-herformatteren-van-het-viaa-archief.pdf) que pour du [[JPEG 2000]] tout [en compressant légèrement mieux](http://download.das-werkstatt.com/pb/mthk/info/video/comparison_video_codecs_containers.html#codec_tests)). FFV1 est volontairement basé sur des techniques ayant plus de 20 ans pour ne pas risquer la moindre menace des chasseurs de brevets. Pour avoir un [[format ouvert]] et offrir ce qui est nécessaire pour le garder, tous les auteurs ont pris un engagement formel (voir [les règles  de l'IETF en la matière](https://www.ietf.org/about/note-well/)). # Les usages FFV1 fonctionne sur la majorité des outils libres (merci [[FFmpeg]]) et contient des fonctionnalités comme le découpage en pavés pour faciliter le multi-threading, ou le contrôle d’erreurs de transmission (CRC) pour vérifier que le contenu n’est pas corrompu pendant le stockage ou la transmission. Un exemple d’usage de FFV1 peut être vu dans le projet [RAWcooked](https://mediaarea.net/RAWcooked), qui compresse des DPX, TIFF, EXR, WAV non compressés en Matroska-FFV1-FLAC tout en permettant une réversibilité vers les fichiers d’origine au bit près si besoin, ce qui est très important pour certaines institutions qui ont des engagements légaux à restituer exactement les fichiers qu’on leur a demandé d’archiver. C'est comme un ZIP, mais [plus performant autant en vitesse qu’en taux de compression](https://mediaarea.net/Events/2019-09-16_iPRES_RAWcooked/#/4) tout en étant directement lisible par exemple par VLC. # Un peu d'histoire FFV1 a été créé par Michael Niedermayer en 2003 comme une expérience pour avoir un format vidéo sans perte et libre dans FFmpeg (dont il a été le mainteneur entre 2004 et 2015). - La version 0 ne gérait que du 8 bits par composante. - La version 1 a ajouté la gestion de profondeur de couleur de plus de 8 bits et, en théorie, de moins de 8 bits également. - La version 2 a été abandonnée au profit de la version 3, pour ajouter un principe de version mineure. - La version 3 ajoute la gestion de plusieurs « pavés » par image, chaque « pavé » étant indépendant afin de permettre le décodage multi-thread, ainsi que le contrôle d’erreurs de transmission (CRC) afin de vérifier l'intégrité du flux. La version 3 et la prise en charge en pratique du 16 bits par composante (la spécification le permettait déjà, mais il n'y avait pas d'encodeur ni de décodeur) ont été financées principalement par des organisations nationales d'archivage qui n'ont pas voulu payer pour une boîte noire non libre et non évolutive, en préférant financer, pour moins cher, un développeur pour intégrer leurs demandes dans FFV1 (lequel n'était pas adapté au multi-thread alors que les processeurs multi-cœurs se répandaient). Et puis, ça a profité à d'autres organismes d'archivage en mutualisant les coûts… Utile, le libre ! ;-) Ces organismes d'archivage ont ensuite convaincu l'Union Européenne du besoin d'un format libre pour leur activité. L'UE a commencé à financer une suite de tests de conformité ainsi que l'écriture d'une spécification, en collaboration avec un organisme de normalisation (qui dit archivage dit besoin de pérennité) dans le cadre du projet [PREFORMA](https://linuxfr.org/news/des-formats-ouverts-et-du-foss-pour-la-preservation-du-patrimoine-europeen). [MediaArea](https://mediaarea.net) a été choisi pour faire ces développements (c'est ici que l'auteur de cette dépêche a commencé à s'impliquer dans le processus). C'est alors que MediaArea a milité pour convaincre les représentants de l'Union Européenne de passer par l'IETF, plus ouverte que l'[ISO](https://fr.wikipedia.org/wiki/Organisation_internationale_de_normalisation) – tant sur la spécification que sur le mode de développement. Historiquement et comme son nom l'indique, l'[[IETF]] a pour cible de travail les normes d'Internet. Son objet s'est élargi comme en témoignent [la normalisation du format audio avec perte Opus en 2010-2018](https://datatracker.ietf.org/wg/codec/documents/) et [sa tentative de normalisation d'un codec vidéo avec perte en 2012-2020](https://datatracker.ietf.org/wg/netvc/about/). Et l'IETF a accepté notre demande ! En nous apportant son soutien technique et humain : merci à eux pour cette aventure. Les contraintes administratives étant ce qu'elles sont, le projet PREFORMA s'est arrêté à une date fixe (fin 2017), avant la normalisation — les joies des projets avec des institutions qui ont des budgets très bornés dans le temps. Cependant, MediaArea ainsi que des contributeurs volontaires ont continué le travail jusqu'à la normalisation. ![Logo de FFmpeg](https://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/FFmpeg_Logo_new.svg/250px-FFmpeg_Logo_new.svg.png)![IETF](https://upload.wikimedia.org/wikipedia/commons/thumb/9/98/IETF_Logo.svg/langen-220px-IETF_Logo.svg.png) ![PREFORMA](https://mediaarea.net/images/093f650-c2f0715.png)![European Commission](https://mediaarea.net/images/b7e8ae5-0a679a5.png)![FP7-ICT](https://mediaarea.net/images/b13d456-5f4b5bb.png) ![MediaArea](https://mediaarea.net/images/7eea6c8-3305620.png) # Pourquoi normaliser ? Vous pouvez vous demander pourquoi passer du temps à normaliser. Il s’avère que l’absence de norme est un argument contre l’usage de formats libres dans beaucoup d’institutions, face à MJPEG 2000 ou H.264 en mode sans perte, tous deux non libres mais normalisés. C’est donc une excuse en moins pour les institutions de ne pas choisir du libre. C'est aussi pour l'équipe qui a travaillé sur le format une preuve de maturité de FFV1 et une confirmation de qualité grâce à la relecture par les pairs. Le travail de normalisation a en plus permis de détecter des problèmes dans l'implémentation de référence, avec pour résultat parfois de corriger FFmpeg et parfois de documenter les problèmes qu'on ne peut corriger sans casser la prise en charge des flux déjà créés (ces problèmes pourront être supprimés dans la prochaine version de la spécification). Enfin, on a pu clarifier certaines parties du format afin d'avoir un meilleur support à long terme de celui-ci. Le passage par l'IETF n'a pas été de tout repos (vous pouvez voir [le long historique du brouillon de RFC FFV1](https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/history/)), ses procédures étant complexes (sans être inutilement compliquées : c'est légitimement complexe vu que c'est prévu pour du long terme et qu'il y a une cohérence à avoir entre les RFC), avec des surprises le long de la route genre [la mise en ballotage](https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ballot/) (tout vert aujourd'hui mais ça ne l'était pas au début) ou [cette bévue avec la dépendance bloquante à Matroska alors que ce format n'est pas encore normalisé, vue seulement dans la dernière ligne droite avant d'avoir notre numéro](https://mailarchive.ietf.org/arch/msg/cellar/96r9p4pv_a8cKiR6NIhqUXPAQeU/), mais nous avons été très bien accompagnés avec toujours une explication constructive sur les refus de passer à l'étape suivante. Au final on peut remercier l'IETF pour son soutien. Bien que la version 3 soit aujourd'hui la plus utilisée, la RFC contient aussi la documentation des versions 0 et 1, utilisées par le passé et même aujourd'hui : lorsqu'on a par exemple du 8 bits, il n'est pas toujours utile de faire passer par la version 3, incompatible avec les anciennes versions de FFmpeg. Et puis, le temps à consacrer à la rédaction était bien faible vu les petites différences. En termes d’implémentation, il existe actuellement un seul **en**codeur (FFmpeg) mais plusieurs **dé**codeurs : - FFmpeg (forcément), licence libre gauche d'auteur LGPL2+, - [MediaConch](https://mediaarea.net/MediaConch), licence libre permissive BSD-2-Clause ([après un passage temporaire par du GPL3/MPL2](https://mediaarea.net/blog/2018/03/20/Why-we-changed-MediaConch-license)), comme vérificateur de conformité qui inclut la conformité FFV1, - [go-ffv1](https://github.com/dwbuiten/go-ffv1) licence libre permissive ISC, comme une implémentation en Go fait [pour le fun mais aussi pour tester une implémentation directement à partir de la spécification](https://mediaarea.net/Events/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from%20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf)), # La suite Le groupe IETF dédié, [Codec Encoding for LossLess Archiving and Realtime transmission (CELLAR)](https://datatracker.ietf.org/wg/cellar/about/), ne compte pas en rester là et la normalisation de [Matroska](https://fr.wikipedia.org/wiki/Matroska) (pour la partie conteneur) puis de [FLAC](https://fr.wikipedia.org/wiki/Free_Lossless_Audio_Codec) (pour de l’audio sans perte) est en cours, tout en travaillant à améliorer encore FFV1 dans une prochaine version. IETF oblige, les travaux sont ouverts à tous : vous pouvez les suivre et y participer sur [la liste de diffusion de CELLAR](https://mailarchive.ietf.org/arch/browse/cellar/) ou sur le [GitHub de CELLAR](https://github.com/ietf-wg-cellar/) (exception faite de la partie FFV1 qui est encore sur le [GitHub de FFmpeg](https://github.com/FFmpeg/FFV1)). La prochaine version devrait contenir un nettoyage de la spécification précédente (la RFC est informelle, elle décrit l'existant, y compris les bugs), une gestion des [matrices Bayer](https://fr.wikipedia.org/wiki/Matrice_de_filtres_color%C3%A9s), la possibilité de stocker une version non encodée (parfois la version encodée est plus grosse que le source), et d'autres améliorations suivant la motivation des développeurs. Les idées sont décrites dans le document [ffv1-v4-goals](https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md). Pour l’anecdote, Matroska et FLAC sont maintenant explicitement sous le chapeautage de l’IETF et leurs dépôts de développement transférés au [groupe CELLAR](https://github.com/ietf-wg-cellar/), mais pour FFV1 [ce n’est pas encore le cas](https://github.com/FFmpeg/FFV1/issues/161). Un encodeur/décodeur indépendant pour FFV1 avec accélération CPU (AVX-2/AVX-512) et GPU (CUDA) est en cours de développement par MediaArea, sous licence libre mais sans doute pas en diffusion publique dans un premier temps. Licence du document : [CC-By v2.0](https://creativecommons.org/licenses/by/2.0/deed.fr) PS : l’auteur de cette dépêche va avoir son orgueil encore plus gonflé, étant donné qu’il vient d’avoir son nom dans une RFC :). [^1]: un fichier audio-vidéo se compose d’un conteneur (dans cet exemple : Matroska, abrégé en MKV) assemblant et synchronisant une piste vidéo (ici encodée sans perte en FFV1) avec une ou des pistes audio (ici encodées sans perte en FLAC).