Auteur Sujet: Codec vidéo FFV1 : Compression vidéo sans perte (Lu 2245 fois)

vivien · « **le:** 02 novembre 2024 à 20:11:07 »

Codec vidéo FFV1 : Compression vidéo sans perte

C'est un codec un peu particulier que je vous présente, il n'est pas fait pour être lu par un lecteur vidéo, bien que VLC le prenne en charge. Sa vocation est d'archiver une vidéo sans perdre de la qualité.

Quand vous re-encodez une vidéo dans un codec type H.264, VP9, HEVC ou AV1, à chaque nouvel encodage le flux se dégrade.

Une vidéo AV1 qui prend pour source une vidéo H.264 sera un peu plus lourde et peu moins bonne qualité que si la compression avait été relaissée avec le flux source : AV1 va devoir encoder les dégradations générées par l'encodeur H.264. Dans 10 ans, quand vous allez vouloir reprendre la vidéo AV1 pour la mettre en AV2, de nouveau, il y aura une légère dégradation.

Pour archiver une vidée pendant de nombreuses années, comme le format de sortie aura changé, il est conseillé de le stocker sans perte de qualité.

C'est là que rentre en jeu FFV1.

FFV1 pour la compression de la vidéo

Ce codec vidéo libre et sans perte a été standardisé par l'Internet Engineering Task Force (IETF): https://www.rfc-editor.org/info/rfc9043
Il est utilisé pour de l'archivage, par exemple, par la Bibliothèque nationale de France.

Attention, compresser une vidéo avec FFV1, c'est comme compresser des photos avec le format d'image sans perte PNG : Cela génère de très gros fichiers.

Pour donner un exemple, pour un ensemble de vidéos qui pèsent 60,1 Go compressées avec UT Video, un codec vidéo sans perte moins performant que FFV1 (mais plus rapide), FFV1 et FLAC permet de passer à 17,2 Go. Les deux fichiers sont équivalents au pixel près. Si je passe en H.264, avec le -crf 23 (encodage de très bonne qualité), je passe à 184 Mo. Je peux passer facilement à moins de 100 Mo avec un encodage plus efficace.

C'est donc un codec pour un marché de niche.

Si FFV1 compresse peu, il ne bénéficie pas d'accélération du GPU et la quantité d'information à gérer fait qu'il est compliqué à lire. Par exemple, sur un Intel Core i7-12700 de 12 cœurs, je n'arrive pas à lire un flux 4K 50 images par seconde encodé en FFV1 (flux vidéo très dynamique, donc qui se compresse peu, qui nécessite 142 Mo par seconde !).

vivien · « **Réponse #1 le:** 02 novembre 2024 à 20:11:49 »

Le GOP permet de réduire un peu la taille. Pour des vidéos avec des images qui sont en grande partie identiques, je ne passe que de 9,6 Go (GOP 1) à 8,3 Go (GOP 120), donc le gain est limité, mais intéressant.
Pour une vidéo très dynamique, le gain est plus faible : de 43,5 Go (GOP 1) à 42,5 Go (GOP 120).
Attention, la taille du fichier augmente pour les gop trop important, je déconseille donc de dépasser 120 pour le GOP.

Pour les Slices, la documentation dit : Slices -slices 4, 6, 9, 12, 16, 24, 30 Each frame is split into this number of slices. This affects multithreading performance, as well as filesize: Increasing the number of slices might speed up performance, but also increases the filesize.
Mais j'ai testé sur plusieurs vidéos : mettre slices à 30 produit un fichier plus petit que slices à 16.
Vidéo 720p : 915 Mo avec slices à 30 contre 984 Mo avec slices à 16. Vitesse d'encodage : 0,617 pour slices à 30 contre 0,623 pour slices à 16.
C'est donc le contraire de la documentation !

Et pour le son ?

FFV1 est un codec vidéo qui ne traite que la vidéo.

Il est généralement associé à FLAC (Free Lossless Audio Codec), codec audio sans perte de qualité. Il obtient un taux de compression d'environ 50 % par rapport à des données PCM non compressées. Depuis 2017/2018, tous les navigateurs web savent gérer ce codec audio particulier. Ce n'est par contre pas le cas de FFV1, qui n'est géré par aucun navigateur web.

vivien · « **Réponse #2 le:** 02 novembre 2024 à 20:12:02 »

Voici un exemple de compression d'un flux vidéo non compressé en FFV1 + flac.

J'en profite pour faire des traitements sur la vidéo (couper des zones de la vidéo intéressante) et augmenter le volume de la piste audio que je passe en mono, la source étant mono.

Code: [Sélectionner]

ffmpeg -i "200402_france_telecom_atout_reso_1_tele_sur_adsl.avi" \
-vf "crop=1520:1080:192:0" -c:v ffv1 -threads 16 -level 3 -coder 1 -context 1 -g 120 -slices 30 -slicecrc 1 \
-af "volume=3.6dB" -c:a flac -sample_fmt s16 -ac 1 \
-metadata title="Atout Réso France Télécom - La télévision sur ADSL, nouveau mode de diffusion de la TV numérique" \
-metadata description="Animation pédagogique de 2004 qui présente les technologies de la télévision sur ADSL, via le protocole ATM" \
-metadata copyright="France Télécom 2004" \
-metadata genre="Télécom" \
-metadata date_released="2004" \
-metadata url="https://lafibre.info/histoire/animations-atout-reso-france-telecom" \
-metadata publisher="LaFibre.info" \
-metadata:s:a:0 language="fre" \
"200402_france_telecom_atout_reso_1_tele_sur_adsl.mkv"

MaxLebled · « **Réponse #3 le:** 02 novembre 2024 à 20:20:16 »

Personnellement, j'utilise UT Video depuis plus de 10 ans. Il est optimisé pour l'utilisation au sein de logiciels de montage. Il compresse un peu moins bien que FFV1, mais est beaucoup plus rapide en encodage et décodage.

http://umezawa.dyndns.info/archive/utvideo/

Il est également utilisé par OBS pour les enregistrements en mode sans perte.

Si on veut vraiment maximiser la compression pour l'archivage sans perte, x264 et x265 proposent également des modes sans perte, généralement accessibles avec CRF=0. Cependant, le mode sans perte de x264 est meilleur (~5%) que celui de x265. AV1 peut aussi faire du sans perte, mais seulement avec libaom. A priori il peut faire mieux, mais il faut utiliser des presets encore plus lents que 4.

Si on utilise ces codecs pour faire du sans perte, il faut faire bien attention à également utiliser l'espace colorimétrique qui convient.

vivien · « **Réponse #4 le:** 02 novembre 2024 à 20:32:03 »

C'est bien un codec sans perte, mais il ne compresse pas, non ?

Le gain que j'annonçai (ensemble de vidéos qui pèsent 60,1 Go sans perte et sans compression, FLAC permet de passer à 17,2 Go), c'est justement sur le codec UT Video (ce sont des vidéos capturées avec OBS).

vivien · « **Réponse #5 le:** 14 novembre 2024 à 17:43:36 »

La Bibliothèque nationale de France (BnF) publie ses référentiels de numérisation.

Ce sont des documents qui expliquent de façon détaillée les formats et codecs utilisés pour la numérisation. L'objectif est de préserver dans la durée ces documents.

Pour la vidéo, le codec sas perte FFV1 est utilisé pour la numérisation de bandes vidéo sur bobien libre.
Objectif : produire un signal numérique le plus fidèle possible au signal analogique d’origine pour les bandes vidéo, que l’on souhaite manipuler le moins possible en raison
de leur fragilité. La BnF demande alors une livraison d’une version de haute qualité au format Matroska FFV1 FLAC et en complément une version de qualité standard au format MP4 AVC AAC.

(cliquez sur la miniature ci-dessous - le document est au format PDF)

MaxLebled · « **Réponse #6 le:** 15 novembre 2024 à 18:49:14 »

Citation de: vivien le 02 novembre 2024 à 20:32:03

C'est bien un codec sans perte, mais il ne compresse pas, non ?

Si si ! Juste un peu moins bien que FFV1. Mais en contrepartie, il est décodable bien plus vite.

Je l'utilise pour stocker les masters de mes court métrages d'animation, et je l'ai souvent utilisé pour du compositing vidéo. La méthode traditionelle, c'est de stocker chaque trame d'une séquence en fichiers TGA, PNG, TIFF, EXR, etc. — mais ce faisant, on subit une grosse perte de vitesse côté système d'exploitation, et pour décompresser chaque trame ; bref, des surcoûts liés au fait qu'on doit accéder à des fichiers individuels, et stockés avec des formats d'image traditionnels.

UT Video propose beaucoup de sous-formats différents (RGB, variantes de YUV, etc.), et j'ai donc pu stocker des séquences de cache directement sous format I8 (nuances de gris, un seul canal), ce qui a encore plus optimisé la vitesse de décodage et la taille des fichiers AVI impliqués dans mes projets After Effects.

vivien · « **Réponse #7 le:** 15 novembre 2024 à 19:05:14 »

Coté audio par contre, UT Video est associé à de l'audio non compressé (PCM) - 1536 Kbit/s pour de la stéréo.
Le conteneur est AVI.

J'ai corrigé mon premier message :

Citation de: vivien le 02 novembre 2024 à 20:11:07

Pour donner un exemple, pour un ensemble de vidéos qui pèsent 60,1 Go compressées avec UT Video, un codec vidéo sans perte moins performant que FFV1 (mais plus rapide), FFV1 et FLAC permet de passer à 17,2 Go.

Oui, UT Video est très léger. J'arrive à l'utiliser en temps réel pour encoder un flux UHD à 50 images par seconde et cela charge peu mon PC portable (SSD NVMe nécessaire vu le débit en écriture par contre). FFV1 je ne pourrais pas l'utiliser en temps réel que ce soit en encodage ou en décodage.

Car oui, un des problèmes de FFV1, c'est que même sur un PC très puissant (PC fixe avec Core i7 de 12eme génération), impossible de lire un flux UHD à 50 images par seconde.
J'ai testé plusieurs lecteurs (VLC, Totem, Avidemux), mais impossible, je dois recompresser mon fichier pour pouvoir le lire.

MaxLebled · « **Réponse #8 le:** 15 novembre 2024 à 20:32:23 »

Citation de: vivien le 15 novembre 2024 à 19:05:14

Coté audio par contre, UT Video est associé à de l'audio non compressé (PCM) - 1536 Kbit/s pour de la stéréo.
Le conteneur est AV1.

C'est de l'AVI, pas AV1

Pour ce qui est de l'audio, ça sera donc MP3, AC3, DTS, AAC, ou PCM. Y a peut-être moyen d'y insérer une piste FLAC mais ça sera non-standardisé. Le format n'est pas étranger à ce genre de détournements : il y a eu des implémentations de H.264/AVC prévues pour aller dans un conteneur AVI, alors que c'est normalement impossible.

F6FLT · « **Réponse #9 le:** 18 novembre 2024 à 16:19:48 »

Le FLAC est le top pour l'audio sans perte. Rapide, ce n'est pas la lourdeur de l'APE, même s'il compresse un peu moins. Ca semble une bonne idée de l'avoir marié à un codec vidéo de même profil.

vivien · « **Réponse #10 le:** 18 novembre 2024 à 17:04:09 »

Je ne sais pas si le fait que le décodage soit très gourmand en ressources CPU soit problématique pour FFV1 qui est un format de stockage (FFV1 est aussi très gourmand en CPU coté vidéo).

Le mariage est surtout fait que les deux codecs sont libres de droits.

Monkey's Audio (plus efficace que FLAC) est passé sous licence open source en août 2023, donc tardivement (20 ans après FLAC qui a rejoint rejoint Xiph.org en janvier 2003).

On voit que les codecs vidéos libres de droits ont des codecs audio libres de droits et que les codecs vidéos propriétaires ont des codecs audio propriétaires.

Codec vidéo => codec audio habituellement associé

Par ordre chronologique :
- MPEG-2 => AC-3 (propriétaire)
- Theora => Vorbis (libre)
- VC-1 => WMA (propriétaire)
- VP8 => Vorbis (libre)
- H.264 => AAC (propriétaire)
- VP9 => Opus (libre)
- HEVC => AAC (propriétaire)
- AV1 => Opus (libre)

vivien · « **Réponse #11 le:** 18 novembre 2024 à 22:51:05 »

Limiter les dégradations lors de la mise à l'échelle d'une vidéo

Dans une vidéo 1080p on peut avoir plusieurs sources : une source 2160p qu'il faut réduire et une source 720p qu'il faut upscaler.

Pour réduire la résolution d'une vidéo avec FFMPEG (suppression de pixels par exemple en passant de 2160p à 1080p) les seuls filtres viables sont lanzcos et bicubic.
Lanzcos est meilleur pour les images "réelles"

Bicubic est meilleur pour les images synthétiques, comme les graphismes de jeux.

Pour utiliser lanczos : -vf scale=1920x1080:flags=lanczos

ffmpeg utilise par défaut bicubic.
Si vous désirez le spéciifer : -vf scale=1920x1080:flags=bicubic

Même chose pour un upscaling (ajout de nouveaux pixels à la vidéo qui n'étaient pas présents dans l'original par exemple en passant de 720p à 1080p).
Pensez à utiliser un filtre de réduction du bruit, car il devient plus visible.

Exemple : -vf "scale=1920x1080:flags=lanczos, noise_reduction=20:2"

⇒ https://trac.ffmpeg.org/wiki/Scaling

Ligne de commande compléte, dans un fichier bash, pour passer une vidéo de UHD 50 images par seconde à 720p 25 images par seconde, avec lanczos et un encodage vidéo FFV1 :

Code: [Sélectionner]

#!/bin/bash
ffmpeg -i "video_reference_dynamique_de_melun_a_paris.mkv" \
-vf "scale=1280:-1:flags=lanczos,fps=25" -c:v ffv1 -threads 16 -level 3 -coder 1 -context 1 -g 120 -slices 30 -slicecrc 1 \
-c:a copy \
-metadata title="Vidéo de référence dynamique « de Melun à Paris en 5 minutes »" \
-metadata license="Licence CC0 1.0 Universel" \
-metadata description="Vidéo de référence pour tester les codecs vidéo et leur consommation d'énergie" \
-metadata copyright="Licence CC0 1.0 Universel" \
-metadata genre="Codecs vidéos" \
-metadata date_released="2024" \
-metadata url="https://lafibre.info/section-vivien/video-ref/" \
-metadata artist="Vivien Guéant" \
-metadata publisher="LaFibre.info" \
-metadata:s:a:0 language="fre" \
"video_reference_dynamique_de_melun_a_paris_720p25.mkv"