Auteur Sujet: Guerre des codecs: qui va l'emporter entre AV1 vs HEVC/H.265 ? Probablement AV1 (Lu 207866 fois)

vivien · « **Réponse #360 le:** **Hier** à 12:16:25 »

Citation de: vivien le 21 août 2025 à 15:02:41

Le Google Pixel 10, annoncé hier, change de codec vidéo pour l'enregistrement de vidéos sur le téléphone : On passe de HEVC (utilisé depuis plusieurs années) à AV1, permettant de réduire la taille des vidéos de 30%.

Le processeur maison Tensor G5 intègre, en plus d'un encodeur H.264 et HEVC comme ces prédécesseurs, un encodeur VP9 et AV1.

Le décodeur matériel d'AV1 était lui arrivé avec le premier Google Tensor G1 de 2021 (Pixel 6). S'il pouvait décoder matériellement AV1, il ne pouvait pas encoder en AV1 et les vidéos étaient enregistrées en HEVC (comme tous les téléphones commercialisés ces dernières années).

Comme j'ai acheté un Pixel 10 Pro, je peux faire un retour : Le codec vidéo par défaut reste HEVC, mais on peut demander à passer en AV1 dans les options.

Le fait d'utiliser AV1 n'engendre aucune incompatibilité avec les applications pour partager la vidéo : elle est ré-encodée en H.264, comme c'est aussi le cas pour les vidéos HEVC.

Voici une vidéo filmée par mon Pixel 10 Pro, en 1080p 30 images/secondes en AV1.

Le débit binaire est toujours le même (CBR) quel que soit la scéne filmée : 18,0 Mb/s pour la vidéo et 192 Kb/s pour l'audio.
Le profil est vidéo est le Main et le Level 4.1 (le 4.0 semblait possible, je ne sais pas pourquoi c'est du 4.1 à 30 fps).
Si le codec vidéo est AV1, le codec audio reste AAC (et non Opus qui est souvent associé à AV1), ce qui fait que certains lecteurs vidéos refusent de lire la vidéo.
Le conteneur est MP4 et non Webm (Webm ne supporte pas le codec audio AAC, seullement Vorbis et Opus).

Voici la vidéo directement extraite de mon téléphone, sans aucun traitement :

La vidéo est normalement lisible sur les navigateurs récents. Pour Safari, je suis intéressé de savoir si la combinaison MP4 + AV1 + AAC lui convient.

Le train sur la vidéo est un Régiolis z54500 en configuration 2x 6 caisses (220 mètres de long) qui circule à 160 Km/h. La vitesse relative est de 135 Km/h, ce qui rend l'encodage vidéo particulièrement complexe (cela reste plutôt net).
C'est une livraison Mobigo (TER de la région Bourgogne-Franche-Comté). La caténaire est en 1500 volts, on est à la limite des communes de Combre-la-Ville et Lieusaint, en direction de Lyon. Le TER circule voie 1, mais un train de marchandise est en panne un peu plus loin devant sur la voie 1 et le TER approche d'une aiguille qui va l'envoyer voie 1bis.

guiest63 · « **Réponse #361 le:** **Hier** à 12:35:00 »

Sur Safari pour iOS sous iOS 27, la vidéo et le son fonctionnent

MaxLebled · « **Réponse #362 le:** **Hier** à 13:59:38 »

J'ai l'impression de voir le défaut sempiternel d'AV1, sa tendance à sur-comprimer tout ce qui est suffisamment plat et/ou sombre... ce serait intéressant d'avoir deux fichiers pour comparer, un HEVC, un AV1, si le téléphone te donne le choix. Si une option « haut débit » existe (c'est le cas chez Samsung) ces variantes seraient également les bienvenues.

vivien · « **Réponse #363 le:** **Hier** à 14:22:51 »

Pour la vidéo, pas d'option "haut débit" chez Google.

Réaliser une même vidéo dans différents codecs, ce n'est pas simple. Si le sujet bouge, cela sera différent et si le sujet est immobile, la compression ne va pas avoir de défault, non ?

Pour info, voici les paramètres avec mon Pixel 10 Pro :

Quand on clique sur les trois petits points, on a d'autres options :

MaxLebled · « **Réponse #364 le:** **Hier** à 14:25:49 »

Citation de: vivien le Hier à 14:22:51

Pour la vidéo, pas d'option "haut débit" chez Google.

Réaliser une même vidéo dans différents codecs, ce n'est pas simple. Si le sujet bouge, cela sera différent et si le sujet est immobile, la compression ne va pas avoir de défault, non ?

Si, mais disons que le long de la même voie, si tu es rapide pour le changement de codec, le décor devrait être suffisamment comparable

Sinon, de mon côté, pour l'encodage logiciel, et l'archivage de mes vidéos smartphone, je suis passé sur svt-av1-tritium, le fork communautaire le plus avancé à ce jour, qui est une surcouche d'un autre fork, svt-av1-hdr.

Code: [Sélectionner]

ffmpeg -i fichierEntrée.mp4 \
  -vf "setparams=color_primaries=9:color_trc=18:colorspace=9" \
  -map 0:v:0 -an -sn -dn \
  -fps_mode passthrough -enc_time_base demux \
  -c:v libsvtav1 -crf 57 -preset 1 -pix_fmt yuv420p10le -g 300 \
  -color_primaries 9 -color_trc 18 -colorspace 9 \
  -svtav1-params "color-primaries=9:transfer-characteristics=18:matrix-coefficients=9:tune=0:ac-bias=2.50:enable-tf=2:complex-hvs=1:enable-dlf=3:hbd-mds=1:enable-variance-boost=1:variance-boost-strength=3:variance-octile=4:scd=1" \
  -err_detect explode \
  fichierSortie.mp4

Je précise dans le tableau ci-dessous que QP = qualité d'un bloc. Plus c'est bas, plus la qualité est bonne (comme le CRF).

Paramètre	Ma valeur	Par défaut	Effet
preset	0 (1 si la définition dépasse 1920 sur les deux axes)	/	Vitesse de l'encodeur. Plus lent = plus de calculs = fichiers plus petits pour le même CRF.
crf	60-50 en 4K, 50-40 en 1080p	/	Qualité visée.
pix_fmt	yuv420p10le	/	10 bits 4:2:0. Meilleure compression, compatibilité HDR, obligatoire avec hbd-mds=1.
tune	0 (VQ)	1 (PSNR)	Ce que l'encodeur cherche à optimiser. 1 vise les indicateurs (PSNR, SSIM, VMAF), qui favorisent une image lisse. 0 vise la percetion humaine : il rend plus nets le filtre temporel, l'interpolation, le CDEF, la restauration, la quantification, et le deblocking des images-clés.
ac-bias	2.5	1.0	Garde plus de texture et de détails fins. (2.5 est déjà un peu agressif, 1.5 sûrement mieux par défaut ?)
tx-bias	1.0	0	En mode 1, défavorise le lissage (moyenne de deux références, mélange inter-intra, grands blocs intra) et favorise une interpolation plus nette = garde plus de détails sur les sujets en mouvement.
enable-tf	2 (adaptatif)	1 (activé)	Force du filtre temporel par bloc de 64x64.
complex-hvs	1	0	]Applique le critère psychovisuel d'ac-bias dès le premier tri des prédictions, au lieu d'une simple variance. Les candidats qui gardent la texture ne sont pas éliminés trop tôt.
enable-dlf	3	1	Deblocking à précision maximale. (Aucun effet aux presets 0 à 2 mais bon j'ai mis quand même.)
hbd-mds	1	0	Compare les prédictions en 10 bits au lieu de 8 bits. Plus précis dans les dégradés et les zones sombres. Aucun effet aux presets 0 à 5 (mais j'ai mis quand même).
enable-variance-boost	1	1	Baisse le QP dans les zones plates et peu contrastées.
variance-boost-strength	3 (moyen)	2 (doux)	De combien le QP baisse dans les blocs plats.
variance-octile	4	5	Renforce aussi les blocs qui ne sont que partiellement plats.
scd	1	1	Détection des changements de scène, colle une image-clé aux changements de plan (SVT-AV1 n'a pas ça)
intervalle (max) d'images clés	10 s	-2 (environ 10 s)	Réglé avec -g dans ffmpeg.
CICP	selon la source	/	9/18/9 HLG, 9/16/9 PQ, 1/1/1 SDR. À mettre aussi dans svtav1-params.

hwti · « **Réponse #365 le:** **Hier** à 14:56:36 »

Citation de: vivien le Hier à 12:16:25

Le fait d'utiliser AV1 n'engendre aucune incompatibilité avec les applications pour partager la vidéo : elle est ré-encodée en H.264, comme c'est aussi le cas pour les vidéos HEVC.

Je suppose que le H264 est en SDR, donc il y a un peu plus qu'un ré-encodage.

D'ailleurs, je vois des différences entre navigateurs, dans la manière dont ils affichent cette vidéo HDR sur une sortie SDR :
- Firefox (Windows, Linux, Android) produit un résultat assez terne
- Chrome (Windows, Linux) produit un résultat plus proche de l'original
Chrome Android (sur mon Pixel 8a) bascule en HDR : la vidéo est plus lumineuse, mais la page à côté est un peu terne.

vivien · « **Réponse #366 le:** **Hier** à 15:28:05 »

Le lecteur vidéo de Gnome (celui qui est de base sous Ubuntu) n'arrive pas à lire la vidéo, alors qu'il lit bien les vidéos AV1 et et les vidéos avec de l'AAC.

Je me demande si ce n'est pas le HDR qui le bloque.

Si on clique sur "Ontaller le greffon" il ne trouve rien.
Si on clique sur "Essayer quand même" la vidéo se lance, mais est très saccadée (sur un Core i7-12700, alors qu'il ne devrait y avoir aucun problème pour le décodage logiciel avec ce CPU)

hwti · « **Réponse #367 le:** **Aujourd'hui** à 18:30:05 »

Pour le lecteur de GNOME (Totem), le bug a été remonté mais les discussions ne sont pas très claires : https://gitlab.gnome.org/GNOME/totem/-/work_items/641.

Il se plaint parce qu'il ne sait pas decoder les flux de méta-données.
mediainfo donne :

Code: [Sélectionner]

Video
ID                                       : 1
Format                                   : AV1
Format/Info                              : AOMedia Video 1
Format profile                           : Main@L4.1
Codec ID                                 : av01
Duration                                 : 8 s 866 ms
Bit rate                                 : 18.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 30.000 FPS
Minimum frame rate                       : 29.821 FPS
Maximum frame rate                       : 30.201 FPS
Real frame rate                          : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.289
Stream size                              : 19.0 MiB (98%)
Title                                    : VideoHandle
Language                                 : English
Encoded date                             : 2026-09-16 17:24:42 UTC
Tagged date                              : 2026-09-16 17:24:42 UTC
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : HLG
Matrix coefficients                      : BT.2020 non-constant
Codec configuration box                  : av1C

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 8 s 822 ms
Bit rate mode                            : Constant
Bit rate                                 : 192 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 206 KiB (1%)
Title                                    : SoundHandle
Language                                 : English
Encoded date                             : 2026-09-16 17:24:42 UTC
Tagged date                              : 2026-09-16 17:24:42 UTC

Other
ID                                       : 3
Type                                     : meta
Format                                   : mett
Codec ID                                 : mett
Duration                                 : 8 s 866 ms
Bit rate mode                            : Variable
Stream size                              : 54.3 KiB (0%)
Title                                    : MetaHandle
Language                                 : English
Encoded date                             : 2026-09-16 17:24:42 UTC
Tagged date                              : 2026-09-16 17:24:42 UTC

Ils disent que le flatpak officiel n'est pas affecté, mais c'est parce qu'ils ont désactivé la boîte de dialogue d'installation de plugin.

En ignorant, la lecture devrait fonctionner, c'est étrange que ça rame.

Qu'est-ce que ça donne avec gst-play-1.,0 (paquet gstreamer1.0-plugins-base-apps) ?

Code: [Sélectionner]

GST_DEBUG_DUMP_DOT_DIR=/tmp gst-play-1.0 202609_pixel10pro_av1_sncf_regiolis_z54500_12caisses.mp4Ca crée des graphes /tmp/*.dot, lisibles par exemple avec xdot, qui permettent de voir comment tout est décodé / affiché.
Par exemple dans mon cas, il y a un GstVaAV1Dec (décodeur HW, via vaapi) qui sort en P010_LE (10 bits), et beaucoup plus loin un GstVideoConvert (transformation sur le CPU) qui convertit en YV12 (donc 8 bits), et c'est affiché par GstXvImageSink.
Normalement le plus optimisé serait de rester sur le GPU, avec soit un sink vaapi, soit un passage en OpenGL ou Vulkan.

vivien · « **Réponse #368 le:** **Aujourd'hui** à 21:52:01 »

Totem n'est plus le lecteur par défaut d'Ubuntu 26.04

C'est Showtime qui remplace officiellement Totem (intégré en amont à partir de GNOME 49). Il intègre un support plus fluide de l'accélération matérielle (VA-API / NVDEC via GStreamer), il intègre aussi la mémorisation automatique de la position de lecture (qui manque bien à VLC 3), ajustement rapide de la vitesse et navigation au clavier optimisée.

Tout comme Totem, Showtime s'appuie sur le framework GStreamer et le problème de demande de plugin pour la vidéo AV1 issue de mon Pixel 10 et de lenteur est présent sur les deux lecteurs. VLC 3 n'a aucun problème pour lire le fichier (comme souvent pour des fichiers exotiques, VLC est la solution).

Voici le fichier .dot généré (après installation de Totem) :

hwti · « **Réponse #369 le:** **Aujourd'hui** à 22:29:33 »

Là c'est av1dec (dans gstreamer1.0-plugins-bad), qui utilise libaom, donc c'est logiciel et pas la meilleure implémentation.
Donc comme meilleures options, il y a :
- le paquet gstreamer1.0-plugins-extra (avant c'était gstreamer1.0-vaapi, mais maintenant c'est dans gst-plugins-bad upstream), qui contient les codecs accélérés avec va-api (ici ce serait vaav1dec)
- le paquet gstreamer1.0-libav, qui utilise ffmpeg (et libavcodec62 dépend bien de libdav1d, donc le décodeur est activé)
- à partir d'Ubuntu 26.10, le paquet gstreamer1.0-dav1d

Dans le graphe, les buffers (en I420_10LE, donc toujours 10 bits) sont copiés dans des textures OpenGL (élement glupload), puis convertis en RGBA avec le GPU (élément glcolorconvert), voient éventuellement leur couleurs corrigées (glcolorbalance), et arrivent dans un gtkglsink (conçu pour afficher en OpenGL dans une application GTK).
Le glupload peut couter un peu, la suite ne devrait pas gêner si l'OpenGL fonctionne bien (mais ça semble fonctionner par transformations successives, ce qui est moins efficace que d'avoir un moteur de rendu qui puisse afficher directement les textures avec toutes les transformations combinées dans un unique shader).
Le pire serait en cas d'une configuration avec un driver manquant, qui ferait de l'OpenGL logiciel (llvmpipe).

Paul · « **Réponse #370 le:** **Aujourd'hui** à 22:50:56 »

Ça fonctionne avec Firefox et Dragon Player sur Fedora.