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

0 Membres et 1 Invité sur ce sujet

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 13 315
  • Thoissey (01)
    • Twitter
Y'a des devices en i386 avec assez de CPU pour décoder de l'AV1 ?

vivien

  • Administrateur
  • *
  • Messages: 52 361
    • Bluesky LaFibre.info
Ici, on parle d'encodage AV1, pas du décodage AV1. Encoder en AV1 sur un i386, cela ne peut être que pour un défi tellement, cela sera lent.

Pour revenir à ta question décoder de l'AV1, oui cela fonctionne sur un i386. Par exemple un Pentium dual core i386 est assez puissant pour décoder de l'AV1 en 540p/25 images par seconde.



Ce qui fait que la plateforme i386 est morte, ce n'est pas la puissance, mais la perte de logiciels (sous Windows, comme sous Linux). Filezilla par exemple n'est pas disponible sur cette architecture avec Debian 12 i386. Un autre gros manque, ce sont les DRM indisponibles sur Firefox comme Chromium, cf Pourquoi n'est-il pas possible de lire des vidéos protégées par DRM sur un Firefox 32 bits sous Linux ?

Google a mis fin au support de Widevine pour Linux 32 bits le 31 mai 2021.

Et c'est ce qui a causé des problèmes à la poignée d'utilisateurs qui utilisent encore des ordinateurs plus anciens équipés de distributions Linux 32 bits.

Lorsque le navigateur a été mis à jour, la prise en charge de Widevine a été supprimée. Même s'il indique que le DRM est toujours activé dans le navigateur, le plugin ne fonctionnera pas.


C'est dommage de supprimer si tôt une technologie qui ne peut pas être remplacée par une autre (ex: quand Google supprime le support de Chrome 32bits sous Linux, on peut utiliser d'autres navigateurs web, comme Chromium ou Firefox).

Là, plus de DRM possible (sur aucun navigateur).


hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 904
  • Chambly (60)
L'usage de svt-av1 en 32 bits est probablement anecdotique.
Mais comme le paquet est actuellement présent, il fautdrait qu'il soit enlevé, et que les paquets utilisateurs (gst-plugins-bad1.0, ...) soient modifiés pour enlever la dépendance selon l'architecture.

Côté Debian, ils ont libcpuinfo-dev en i386, ce qui leur permet de compiler svt-av1.

vivien

  • Administrateur
  • *
  • Messages: 52 361
    • Bluesky LaFibre.info
Je ne comprends pas non plus pourquoi crée une version 32bits alors que les dernières versions de Debian et Ubuntu ne sont plus disponibles en 32 bits.

Pour moi le principal usage du 32bits avec les dernières versions de Debian et Ubuntu, c'est pour l'utilisation de certains logiciels propriétaire ou pour Wine.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 904
  • Chambly (60)
Wine utilise gstreamer pour le décodage vidéo, donc il faut bien des versions 32 bits de gst-plugins-bad1.0 et autres.
Mais on pourrait imaginer une config réduite, sans certains plugins d'encodage comme svt-av1.

vivien

  • Administrateur
  • *
  • Messages: 52 361
    • Bluesky LaFibre.info
Quelle qualité de compression utilisez-vous avec le codec AV1 ?

Le CRF (Constant Rate Factor) ajuste la compression selon la complexité des scènes. Les valeurs s'étendent de 0 (compression sans perte) à 70 (très fortement dégradée).

Habituellement, on dit qu'un crf autour de 20 est une qualité "visuellement parfaite" (impossible de distinguer un flux entre crf 0 et crf20 à l'œil).
Un crf autour de 30, c'est une qualité standard, un crf autour de 40 la compression devient agressive avec une perte de qualité.

Toutefois, dans mon cas, j'ai fait des tests sur plusieurs types d'encodage et pour du contenu de bonne qualité, j'utilise habituellement le crf 45 et pour des vidéos source dégradées (ex: visioconférence) le crf 50 et je ne vois presque aucune perte avec l'original.

Voici un flux Arte 1080p haute qualité proposée sur leur site web (il y a deux qualités en 1080p : encodage H.264 à 3 Mb/s et encodage HEVC à 3 Mb/s. HEVC étant pus efficace que H.264, la qualité est meilleure avec le flux HEVC.

Voici ce flux pour Arte journal passé en AV1.
- crf 20 : 3,53 Mb/s
- crf 38 : 1,33 Mb/s
- crf 45 : 0,87 Mb/s
- crf 50 : 0,65 Mb/s

On voit que les différences sont faibles. Seul le flux crf 50 a des dégradations significatives en regardant bien.

Images qui bougent peu : La dégradation la plus importante est au niveau de la ceinture de la présentatrice :


Images qui bougent, la caméra est en traveling pour suivre une personne et les différentes personnes de la vidéo bougent également. La dégradation la plus importante est autour du logo Arte en haut à gauche. On voit également d'autres endroits de l'image ou on perd des détails en crf 50, mais pour moi cela reste acceptable en crf 45.


La ligne de commande utilisée. Je suis en "-preset 3" donc un encodage relativement lent.
#!/bin/bash
ffmpeg -i 202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs.mkv \
  -c:v libsvtav1 -preset 3 -crf 20 \
  -svtav1-params keyint=10s:scd=1:lookahead=64:tune=0:enable-variance-boost=1 \
  -pix_fmt yuv420p10le \
  -filter:a "volume=7.8dB" -ac 1 -c:a libopus -b:a 64k \
  -metadata title="Meta et Google condamnés pour mise en danger de mineurs" \
  -metadata license="Arte" \
  -metadata description="Arte Journal du 25 mars 2026" \
  -metadata copyright="Arte" \
  -metadata genre="Journal" \
  -metadata date_released="2026" \
  -metadata url="https://lafibre.info/techno-du-web/grandir-et-vivre-avec-les-reseaux-sociaux/" \
  -metadata artist="Arte journal"\
  -metadata publisher="LaFibre.info" \
  -metadata:s:a:0 language="fre" \
  202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs_20.mp4