TV et codecs => Discussion démarrée par: vivien le 03 février 2018 à 16:40:37 TV et codecs => Discussion démarrée par: vivien le 03 février 2018 à 16:40:37Y'a d'autres gens que Google qui utilisent ça ?Ceux qui, comme moi, ont une TV compatible. (https://lafibre.info/images/smileys/@GregLand/en.gif)
...Je pense que le VP9 ne sera presque plus du tout utilisé dans 4 ans, à moins que un périphérique AV1 soit obligatoirement compatible VP9. Le VP9 serait alors propulsé par sa compatibilité avec tous les navigateurs et bénéficiant d'une accélération matérielle dans bien plus de cas que l'AV1Le ciel t'entende ! Sinon, il va falloir rénover son matériel tous les ans. (https://lafibre.info/images/smileys/@GregLand/aq.gif)
A noter que AV1 est déjà implèmenté dans Firefox Nightly.Je n'ai pas dû libérer les bons scripts dans NoScript: illisible. (https://lafibre.info/images/smileys/@GregLand/bl.gif)
Un test de lecture vidéo : https://demo.bitmovin.com/public/firefox/av1/ ...
Je ne suis pas étonné qu'il ne soit pas du tout prévu dans les specs de diffusion.
ça parait très compliqué de sortir de la famille MPEG/Hxxx, vu les enjeux politiques et financiersEn même temps, pas besoin pour les acteurs du streaming internet de rechercher une convergence avec la diffusion TV traditionnelle : les rythmes d'évolution (technologique et commerciale) sont très différents, et de toute façon le secteur est suffisamment mature pour faire sa R&D tout seul.
En même temps, pas besoin pour les acteurs du streaming internet de rechercher une convergence avec la diffusion TV traditionnelle : les rythmes d'évolution (technologique et commerciale) sont très différents, et de toute façon le secteur est suffisamment mature pour faire sa R&D tout seul.
Si les acteurs de la TV ne sont pas capables de récupérer la recherche faite par ailleurs, tant pis pour eux !
Tu n'imagines pas l'argent et les luttes d'influences que ça représente, ce business.Effectivement, si les diffuseurs veulent payer des royalties et éviter des économies liées à un meilleur standard, et si les fabricants ne veulent pas profiter d'un renouvellement forcé du matériel, c'est leur choix. Pas illogique puisque dans ce domaine changer coûte très cher !
Enfin, le format bitstream de ce codec n'est pas encore finalisé, donc on a encore un peu de temps avant de voir du matos compatible. (source https://en.wikipedia.org/wiki/AV1)
... mais aussi pour la surveillance (qui jusqu'à présent préférait utiliser des technologies plus anciennes) via la présence de Broadcom.
Pourtant selon la même source : The first version 0.1.0 of the AV1 reference codec was published on 7 April 2016. Soft feature freeze was at the end of October 2017, but a few significant features were decided to continue developing beyond this. The bitstream format was projected to be frozen in January 2018.
Il faut compter 1an et demi à partir du freeze du format bitstream, d'où une sortie mi-2019.
Yep. On doit attendre encore entre 18 et 24 mois avant de voir du matos compatible. On a du temps. Parce que sans le matos compatible, l'encodage est entre 5 et 200 fois plus lent que x265, et le décodage 2 fois plus lent. Du coup, avoir du hardware pour encoder et lire est nécessaire.
Les annonces récentes c'est uniquement marketing pour présenter quelque chose au NAB ...
A mon avis il est trop tôt pour ce faire une idée, il faudra attendre de longs mois/années avant que le codec s'améliore aussi bien coté qualité que vitesse.
De toute façon tant qu'il n'y a pas de décodage matériel ( après 2020 ?), je pense que AV1 restera marginal.
...
curieusement, on constate un plus gros volume qu'avc1 ou vp9 ... 36Mo au lieu de 23 et 21 ...C'est normal, ils précisent dans la description de la playlist que le but est de tester les décodeurs:
At time of writing, these transcodes are encoded at a very high bitrate for decoder performance testing.Par contre, pour Firefox il faut également activer dans about:config les paramètres media.av1.enabled et media.mediasource.experimental.enabled pour que ça fonctionne.
...Par contre, pour Firefox il faut également activer dans about:config les paramètres media.av1.enabled et media.mediasource.experimental.enabled pour que ça fonctionne.Merci pour le tuyau ! (https://lafibre.info/images/smileys/@GregLand/ay.gif)
Je savais pour VLC mais pas pour windows et le format AVIF. Merci ;)
Apparition des premiers décodages matériel pas avant 1 ou 2 ans si on en croît l'article.
Vous trouverez des vidéos de test sur https://www.elecard.com/videosJe n'ai pas réussi à trouver la version 3.0.5 en 64 bit sur le site de VideoLan et lorsque je fais une recherche de mise à jour avec ma version 3.0.4, VLC m'indique que mon logiciel est à jour: aurais-tu un lien afin de télécharger cette dernière version ? (https://lafibre.info/images/smileys/Confus/Confus_83.gif)
Il faut impérativement VLC 3.0.5 ou supérieur...
Windows : La mise à jour 3.0.5 n'est pas encore proposée a ceux qui ont la 3.0.4C'est bien ce que j'ai fait, mais je n'ai trouvé que la version 32 bit ! (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Il faut aller chercher manuellement la version sur https://www.videolan.org/ cliquer sur "Télécharger VLC", enregistrer le fichier et l’exécuter...
Quelle conclusion tirer de ces 3 échecs sur un processeur 4 cœurs 8 threads qui est presque à la même fréquence que le CPU précédents qui n'avait que 2 cœurs ?C'est totalement confirmé puisque dav1d en version 0.1 (la librairie utilisée par VLC) (http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d) ne comporte que très peu d'assembleur optimisé pour autre chose que AVX2 (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#AVX2). Le développement est en cours (https://code.videolan.org/videolan/dav1d/commits/master) pour de l'assembleur SSSE3 (https://en.wikipedia.org/wiki/SSSE3) (à ne pas confondre avec SSE3) et ARMv8.
Je pense que le décodage du flux AV1 utilise massivement les instructions AVX2 (Advanced Vector Extensions 2) qui ont été introduites sur les processeurs de la 4ème génération. Ce Core-i7 est puissant mais reste un processeur de 2ème génération.
C'est totalement confirmé puisque dav1d en version 0.1 (la librairie utilisée par VLC) (http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d) ne comporte que très peu d'assembleur optimisé pour autre chose que AVX2 (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#AVX2). Le développement est en cours (https://code.videolan.org/videolan/dav1d/commits/master) pour de l'assembleur SSSE3 (https://en.wikipedia.org/wiki/SSSE3) (à ne pas confondre avec SSE3) et ARMv8.
Ne fonctionne pas = CPU pas assez puissantPas assez puissant ? un 9900k devrait être suffisant quand même.
J'en déduis que la lecture AV1 est plus optimisée sur Firefox.
Tu utilises quelle version de Firefox ?
La version stable (Firefox 64) ne sais pas lire les flux AV1
Si justement c'est la version stable 64, ça fonctionne maintenant en cochant dans les options about config.Merci pour l'astuce pour Firefox 64.
C'est totalement confirmé puisque dav1d en version 0.1 (la librairie utilisée par VLC) (http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d) ne comporte que très peu d'assembleur optimisé pour autre chose que AVX2 (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#AVX2). Le développement est en cours (https://code.videolan.org/videolan/dav1d/commits/master) pour de l'assembleur SSSE3 (https://en.wikipedia.org/wiki/SSSE3) (à ne pas confondre avec SSE3) et ARMv8.Il y a des bugs qui indiquent la progression des optimisations assembleur : AVX2 : https://code.videolan.org/videolan/dav1d/issues/78 (https://code.videolan.org/videolan/dav1d/issues/78), SSSE3 : https://code.videolan.org/videolan/dav1d/issues/216 (https://code.videolan.org/videolan/dav1d/issues/216), ARM NEON (https://code.videolan.org/videolan/dav1d/issues/215).
Youtube a commencé à déployer l'AV1 sur les autres vidéos, par contre elles sont limitées au 480pAs-tu une liste des vidéos concernées pour l'instant ?
As-tu une liste des vidéos concernées pour l'instant ?Oui mais l'av1 il faut l'activer à la main sur la page de test youtube, donc on le fais de notre plein grès, si ça fonctionne mal on peut le désactiver ou au pire baisser la résolution.
Par contre pour la définition, c'est assez logique vu l'état du déploiement des décodeurs, le risque de saturer le CPU en 4k serait beaucoup trop élevé
j'ai regardé pour produire en AV1, il n'existe apparemment pas d'encodeur temps réel pour l'instant3 mois plus tard, il existe désormais SVT-AV1, un encodeur qui a pour but de fournir une solution temps-réel. Un commit récent (https://github.com/OpenVisualCloud/SVT-AV1/commit/47af208baf2c4bde185f437b9269f09e8fe3fbfb) fait état de 60 fps 1080p sur un Xeon 8180 (28 cœurs tout de même).
$ youtube-dl -F https://www.youtube.com/watch?v=oAbB4dQOz4I | grep 1080p
Intel a ouvert https://github.com/OpenVisualCloud/SVT-AV1 depuis le 31/1/2019 ; c'est curieux le timing de MacbidouilleIl y a eu une annonce (https://newsroom.intel.com/news/intel-netflix-deliver-av1-scalable-codec-power-next-gen-compression-tech-visual-workloads/) récemment sur le sujet.
Actuellement il faut quel budget pour encoder un 1080i/25 en temps réel en av1 ?On trouve pas trop de benchmark à part chez phoronix : http://linuxbenchmarking.com/?video-benchmarks#r-fed01dc174a1644e221804114a752b84c4f18119
Dans les coulisses du support d'AV1 sur la plateforme Vimeo :Des informations plus techniques, de ATEME, OPENHEADEND, et de Videolan
=> https://medium.com/vimeo-engineering-blog/behind-the-scenes-of-av1-at-vimeo-a2115973314b
$ ffmpeg -i 1.mp4 -vf scale=1280:-1 -c:v libaom-av1 -crf 44 -b:v 0 -row-mt 1 -tiles 4x1 -strict experimental -c:a libopus -b:a 64k -f webm 1.webm
ffmpeg version n4.1.4 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
configuration: --prefix= --prefix=/usr --disable-debug --disable-doc --disable-static --enable-avisynth --enable-cuda --enable-cuvid --enable-libdrm --enable-ffplay --enable-gnutls --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopus --enable-libpulse --enable-sdl2 --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-nonfree --enable-nvenc --enable-omx --enable-openal --enable-opencl --enable-runtime-cpudetect --enable-shared --enable-vaapi --enable-vdpau --enable-version3 --enable-xlib
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Unrecognized option 'tiles'.
Error splitting the argument list: Option not foundffmpeg -h encoder=libaom-av1Cette commande me montre que le snap n'est pas compilé avec libaom-av1.Les sources sont publiques pour encoder :Rien à voir, on parle de paquets précompilés délivrés via apt et snap, de plus libaom-av1 != svt-av1
https://github.com/OpenVisualCloud/SVT-AV1
(si vous savez faire pour que les cœurs 5 à 8 ne soient pas en rouge, je suis preneur)On peut changer la couleur en cliquant sur les carrés.
AH bah de toute façon oui, l'encodage vidéo est bien LE domaine qui bénéficie au maximum des jeux d'instructions CPU.Il bénéficie aussi beaucoup du code assembleur écrit à la main, c'est surtout là que se joue la bataille pour les performances actuellement.
Il y a même AVX-512 maintenant chez Intel :-)
Dans un tel cas il est mieux de l'écrire à la main car le compilo ne peut pas générer un code spécialisé efficace, ni même les intrinsicsÇa dépend quand même, les compilos ont fait des gros progrès sur la vectorisation automatique (même si clairement un code assembleur écrit par un humain reste meilleur, voir bien meilleur s'il faut vraiment être astucieux).
Je ne sais pas si c'est du code en assembleur ou le compilateur qui s'est amélioréÇa vient probablement principalement d'ajout de code en assembleur, ça reste crucial dans les encodeurs/décodeurs vidéo.
Voila, c'est (enfin) officiel : AV1 : le nouveau standard vidéo adopté à l'unanimité par Amazon, ARM, Facebook, Google, Intel, Nvidia, Mozilla, Netflix, Microsoft, Adobe, Netflix, VLC, Twitch et même Apple. Par ailleurs, l'AV1 devrait rendre possible la transmission de contenus Ultra HD avec une simple connexion ADSL d'une dizaine de mégabits (10 Mb/s).
(https://lafibre.info/images/tv/201804_codec_av1_calendrier_previsionnel.jpg)
A quelques noms près c'est une guerre de générations ;D
Ah !
Donc premiers encodeurs alpha dans un an au mieux pour le H266/VVC? et de l'ordre de 3/4 ans pour du soft/hard broadcast, en première version ?
On a largement le temps de voir ça arriver sur du consumer/consommateur moyen.
pour réduire le débit nécessaire entre les deux...
et le volume de stockage aussi.
Même si le prix par octet stocké ne cesse de baisser , la production de contenus vidéos croit encore plus vite.
exemple: en 2020 c'est 500 heures de vidéos envoyées (upload) sur Youtube par minute.
Et quel volume de chose intéressante là dedans ?
Ça ne m'étonnerait pas qu'un jour YouTube nettoie les vidéos très peut regardé
Et quel volume de chose intéressante là dedans ?Je ne pense pas que Youtube supprime des vidéos, mais ce qui est sûr c'est qu'il dégrade très nettement la qualité des vidéos qui ne l'intéresse pas/plus.
Ça ne m'étonnerait pas qu'un jour YouTube nettoie les vidéos très peut regardé
Certaines vidéos que j'ai en favori, seul le 144p reste dispo (alors qu'elles étaient au moins en 480p), ou 240p dans le meilleur des cas.
youtube-dl -F <url de la video>n'affiche que 144p ?curieux ca ? t'as un exemple public ?Oui, j'ai un exemple ci-dessous (vidéo avec + d'un million de vue, 2018).
sinon ( https://github.com/ytdl-org/youtube-dl/releases ):Code: [Sélectionner]youtube-dl -F <url de la video>n'affiche que 144p ?
y'a bien toutes les résolutions chez Youtube. chez moi c'est en 1080p.merci pour l'info! j'avais constaté la meme limitation en 144p et j'étais aussi forcé en AV1! réglage qui doit dater d'un autre temps :x
Le problème est de ton coté. c'est quel navigateur et OS ?
ou alors t'as forcé le mode AV1 ("toujours") dans les reglages youtube ( https://www.youtube.com/account_playback ) ? car la effectivement en "av01" youtube-dl ne montre que du 144p pour cette vidéo (mode principalement pour jouer de la musique en tache de fond).
Il y a un moyen de voir si le GPU est utilisé pour le décodage AV1 ?
sous Chrome , chrome://gpu puis chercher 'Video Acceleration Information' (avec ctrl-f ou en scrollant vers le bas)Merci pour l'info détaillée.
Sinon quand une vidéo est en lecture il y'a un nouvel outil 'media':
F12 puis CTRL+Maj+P, saisir 'media' puis sélectionner "Panel Show Media" (ou via le menu trois petit points dans le coin a droite, 'more tools', 'media').
Dans la zone media, a gauche choisir le player actif et clicker dessus pour voir a droite le nom du décodeur et son accélération matérielle.
(https://i.imgur.com/QDnJkkc.png)
Salut kgersen,Il y a un moyen de voir si le GPU est utilisé pour le décodage AV1 ?sous Chrome , chrome://gpu puis chercher 'Video Acceleration Information' (avec ctrl-f ou en scrollant vers le bas)
Sinon quand une vidéo est en lecture il y'a un nouvel outil 'media':
F12 puis CTRL+Maj+P, saisir 'media' puis sélectionner "Panel Show Media" (ou via le menu trois petit points dans le coin a droite, 'more tools', 'media').
Dans la zone media, a gauche choisir le player actif et clicker dessus pour voir a droite le nom du décodeur et son accélération matérielle.
(https://i.imgur.com/QDnJkkc.png)
Mkv n'a rien d'officiel dans l'industrie AV non ?
Enfin il y a un support des vendeurs qui ne pourraient pas vendre à ceux qui veulent regarder leurs films de vacances....
L'industrie AV n'aime pas trop le libre qui empêche les bénéfices...
Donc mp4 aurait l'avantage dans ma vision..
Mkv n'a rien d'officiel dans l'industrie AV non ?Oui on l'a bien vu avec le MP3 alors que l'OGG est de meilleure qualité
Enfin il y a un support des vendeurs qui ne pourraient pas vendre à ceux qui veulent regarder leurs films de vacances....
L'industrie AV n'aime pas trop le libre qui empêche les bénéfices...
Donc mp4 aurait l'avantage dans ma vision..
le HEVC a encore un bel avenir et VVC prendra le relais ensuiteCrois-tu que ce pourrait être une évolution pour un DVB-T2 encore plus performant ou efficace? Ma pensée est peut-être complétement débile...
Voila, c'est (enfin) officiel : AV1 : le nouveau standard vidéo adopté à l'unanimité par Amazon, ARM, Facebook, Google, Intel, Nvidia, Mozilla, Netflix, Microsoft, Adobe, Netflix, VLC, Twitch et même Apple. Par ailleurs, l'AV1 devrait rendre possible la transmission de contenus Ultra HD avec une simple connexion ADSL d'une dizaine de mégabits (10 Mb/s).
(https://lafibre.info/images/tv/201804_codec_av1_calendrier_previsionnel.jpg)
Crois-tu que ce pourrait être une évolution pour un DVB-T2 encore plus performant ou efficace? Ma pensée est peut-être complétement débile...
Le MUX "Test UHD" est sur un multiplex à part (celui de l'expérimentation de diffusion UHD à Paris en 2014 qui est pérennisé) ?
Ou c'est une réorganisation des MUX actuels pour serrer les chaines sur 5 MUX (1 chaines de plus par MUX) afin de libérer un MUX qui passera en DVB-T2 (mux précurseur pour initier la transition en attendant que l'équipement soi suffisant pour faire une bascule, comme celle du MPEG-2 vers le MPEG-4 du 5 avril 2016).
Cà fait plusieurs années que toutes les "vraies" télés savent le faire.DVB-T2 + HEVC oui, depuis 2015-2016 pour certains modèles il me semble.
C'est pas le CSA qui fixe les normes non plus hein.
DGMIC?
Le CSA ne fait qu'appliquer la loi.... comme l'ARCEP
Puisque tu es si sachant je t'invite à consulter le JO.
Petite piste pour, par exemple, la radio numérique et le choix des normes t-dmb, dab+, suppression t-dmb.
Tu devrais systématiquement tomber sur des décrets gouvernementaux...
Déjà tu ne dis plus que c'est le seul csa qui décide de tout....
Pour le tdmb, simple, les editeurs.
Les éditeurs ont le choix les profils entre dab+ et tdmbLe tdmb n'est plus possible, de mémoire. Ce sont les éditeurs qui l'ont imposé en 2007. Le CSA n'a fait que suivre leur demande... Le gouvernement (DGMIC) a décidé.
Qui a fait ces profils ?
avx-512 dans les skylake-s est encore très mauvaix et génère dans un grand nombre de cas des performances inférieures à avx2. Il va falloir encore attendre quelques années avant de voir avx-512 devant avx2.
I hope AVX512 dies a painful death, and that Intel starts fixing real problems instead of trying to create magic instructions to then create benchmarks that they can look good on.
...
And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance, but without the garbage like AVX512) like AMD did.
What kind of precedent does this new system set for the future of video infrastructure? What’s next for you?https://blog.youtube/inside-youtube/new-era-video-infrastructure/
Jeff: One of the things about this is that it wasn't a one-off program. It was always intended to have multiple generations of the chip with tuning of the systems in between. And one of the key things that we're doing in the next-generation chip is adding in AV1, a new advanced coding standard that compresses more efficiently than VP9, and has an even higher computation load to encode.
As for me, I’ll be continuing my work on this project, developing future generations, which will keep me busy for a while.
H265 absent, dommage ...
Mais AV1 fait mieux il me semble.
$ youtube-dl -f 399+251 https://youtu.be/[...]
[youtube] JR49dyo-y0E: Downloading webpage
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[download] Destination: [...].f399.mp4
[download] 100% of 46.27MiB in 17:19
[download] Destination: [...].webm
[download] 100% of 3.83MiB in 01:25
[ffmpeg] Merging formats into "[...].mkv"
Deleting original file [...].mp4 (pass -k to keep)
Deleting original file [...].webm (pass -k to keep)$ youtube-dl --merge-output-format mp4 -f 399+251 https://youtu.be/[...]
[youtube] JR49dyo-y0E: Downloading webpage
[download] Destination: [...].mp4
[download] 100% of 46.27MiB in 17:19
[download] Destination: [...].webm
[download] 100% of 3.83MiB in 01:25
[ffmpeg] Merging formats into "[...].mp4"
Deleting original file [...].mp4 (pass -k to keep)
Deleting original file [...].webm (pass -k to keep)Il paraîtrait que youtube-dl est un peu en perte de vitesse et que le « successeur » est https://github.com/yt-dlp/yt-dlp (https://github.com/yt-dlp/yt-dlp) ?
Je ne connais pas le sujet, je « balance » ceci à tout hasard. ;)
Le HLG (Hybrid Log-Gamma) permet normalement une lecture universelle (client compatible ou pas HDR). Pourquoi il n'est pas utilisé sur navigateur ? Pourquoi proposer un autre encodage HDR ?J'ai vérifié les deux fichiers de 2.85 et 5.45Go, et sont tous les deux HLG d'après VLC.
Autre point, sur PC, que ce soit sur Firefox, Chrome, Windows, Linux, avec ou sans bloqueur de publicité, je n'arrive à avoir accès qu'aux flux VP9 de cette vidéo alors que traditionnellement si une vidéo est encodée en VP9 et AV1, c'est le flux AV1 qui est prioritaire (et c'est le cas, toutes les autres vidéos avec de l'AV1, c'est ce flux qui est utilisé).
J’imagine que c'est à cause du HDR : Aucun navigateur ne peut lire de flux HDR sur Youtube ?
Le HDR est présent sur tous les flux AV1 de cette vidéo, même en 144p (pas sur que cela soit utile sur cette résolution avec un encodage qui privilégie le faible débit contre une qualité bien dégradée sans parler même de la résolution). Ah aussi le truc fou : proposer du 60 images par seconde dans la résolution 144p !
Je me demande pourquoi la vidéo 4K HDR suivante a systématiquement deux encodages AV1, avec HDR et 60 images par seconde à un débit bien différent (du simple au double).Si j'en crois https://gist.github.com/AgentOak/34d47c65b1d28829bb17c24c04a0096f, ce n'est pas nouveau, et le rapport entre les débits peut être encore plus important.
Comment voir sur mobile le N° du flux utilisé dans l'application Youtube ?
(j'ai moi aussi un Pixel 6)
Sous Windows 10 avec un GPU UHD Graphics 620 (CPU Intel Core i5-8265U) :
- Edge : VP9 pour les deux vidéos >:(
- Firefox : VP9 pour celle en HDR et AV1 pour la vidéo sans HDR
- Chrome : VP9 pour celle en HDR et AV1 pour la vidéo sans HDR
(je parle des deux vidéos Youtube que j'ai indiqué deux messages plus haut)
Sur MacOS 12 (MacBook Air M1) avec Safari, VP9 pour les deux vidéos et avec Chrome VP9 pour la vidéo HDR et AV1 pour la vidéo sans HDR.
[info] Available formats for zCLOJ9j1k2Y:
ID EXT RESOLUTION FPS │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
...
401 mp4 3840x2160 60 │ 458.57MiB 11841k https │ av01.0.13M.08 11841k video only 2160p60, mp4_dash
...
402 mp4 7680x4320 60 │ 625.04MiB 16140k https │ av01.0.17M.08 16140k video only 4320p60, mp4_dash
571 mp4 7680x4320 60 │ 978.30MiB 25262k https │ av01.0.17M.08 25262k video only 4320p60, mp4_dashl'espace de couleurs est le bt.709
Et à cette résolution, l'AV1 est le seul codec disponible : (donc pas de 8k sur Safari)je viens d'en tester une autre
[info] Available formats for linlz7-Pnvw:
ID EXT RESOLUTION FPS HDR │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
...
272 webm 7680x4320 60 │ 2.86GiB 20249k https │ vp9 20249k video only 4320p60, webm_dash
702 mp4 7680x4320 60 10 │ 7.13GiB 50463k https │ av01.0.17M.10 50463k video only 4320p60 HDR, mp4_dash
la version av1 est en HDR alors que la version vp9 est en SDR
Il faut telecharger l'extension AV1 pour Edge sur le Microsoft Store j'avais oublié (l'AV1 n'est pas "inclus" de base dans Edge il faut l'activer avec ca) --> https://www.microsoft.com/store/productId/9MVZQVXJBQ9V
je viens d'en tester une autre
https://www.youtube.com/watch?v=linlz7-PnvwCode: [Sélectionner][info] Available formats for linlz7-Pnvw:la version av1 est en HDR alors que la version vp9 est en SDR
ID EXT RESOLUTION FPS HDR │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
...
272 webm 7680x4320 60 │ 2.86GiB 20249k https │ vp9 20249k video only 4320p60, webm_dash
702 mp4 7680x4320 60 10 │ 7.13GiB 50463k https │ av01.0.17M.10 50463k video only 4320p60 HDR, mp4_dash
Et à cette résolution, l'AV1 est le seul codec disponible : (donc pas de 8k sur Safari)
Perso, voici les codecs utilisé dans un navigateur (quel que soit le navigateur), c'est la même chose pour vous ?
- 144p : AV1
- 240p : AV1
- 360p : AV1
- 480p : AV1
- 720p60 : AV1
- 1080p60 : AV1
- 1440p60 : VP9
- 2160p60 : VP9
- 4320p60 : AV1
Etrange alors car j'ai Edge 98 et l'AV1 fonctionne bien sur toutes les videos et/ou résolutions ou j'ai testé
Edit: je viens de tester sur un autre pc et ca ne fonctionne pas avec edge
1ere config
Win 10 21H2
i7 11700KF
RTX 3070 Ti
32GB RAM
2eme config :
Win 10 21H2
i7 7700HQ
GTX 1070
16GB RAM
Cela fonctionne sur la configuration 1 (avec support du AV1 en hardware, non ?) et pas la configuraiton 2 où l'AV1 est pas accéléré par le GPU ?
mediaConfig = {
type : 'media-source',
video : {
contentType: "video/mp4;codecs=av01.0.17M.10",
width: 7680,
height: 4320,
bitrate: 50463000,
framerate: 60,
},
};
navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
console.log('This configuration is ' +
(result.supported ? '' : 'not ') + 'supported, ' +
(result.smooth ? '' : 'not ') + 'smooth, and ' +
(result.powerEfficient ? '' : 'not ') + 'power efficient.')
});
=> "This configuration is supported, smooth, and not power efficient" (Chrome et Firefox)- LG rejoint l'Alliance for Open Media. Les prochaines TV LG devraient supporter le codec vidéo AV1.C'est déjà le cas à partir de certains modèles 2020 (probablement un SoC Mediatek).
- Qualcomm devrait supporter AV1 sur les Snapdragon 8 Gen 2 (lancement attendu fin 2022 ou début 2023).Ils ont pris le temps, c'est 3 ans après Mediatek (Dimensity 1000), qui a pourtant un positionnement moins haut de gamme.
On reste toujours sans nouvelle d'implémentation de l'AV1 par Apple. C'est le point noir.Pourtant ils sont membres fondateurs de l'alliance AV1...
On reste toujours sans nouvelle d'implémentation de l'AV1 par Apple. C'est le point noir.
Grande nouvelle : Apple est en train de préparer la prise en charge du décodeur AV1 dans Safari (plus précisément dans WebKit, le moteur de rendu de Safari).
Deux ajouts ont été fait a WebKit :
- dav1d, le décodeur AV1 conçu par les équipes de VideoLAN et ffmpeg, et dévoilée en octobre 2018. Il est performant et Firefox 67 est passé de libaom à dav1d en mai 2019.
- libavif, une bibliothèque qui permet de décoder (et d'encoder) les fichiers AV1 Image File Format (.avif), utilisé pour les images clés de l'AV1. La compression AVIF est plus performante que le viuex jpeg ou que le webp (qui est basé sur le VP8 de Google).
Sur ses puces M2, Apple semble pourtant préférer son propre format Apple ProRes au détriment du codec AV1 et des avantages qu’il permet, notamment en termes de qualité de compression.C'est n'importe quoi, l'AV1 est un codec pour distribuer des contenus (comme VP9 et HEVC), alors que Apple ProRes est un codec dédié au montage vidéo.
J'espère que cela n'ira pas plus loin.
Qui a donné les infos à la Commission ?
Je comprends que c'est une société qui dispose brevets et "qui ne faisaient pas partie d'AOM au moment de la création de la technique AV1" et donc qui a rejoint AOM plus tard.
Je ne peux m'empêcher de penser à un membre tardif d'AOM qui touche des royalties de H.265 et qui n'a toujours pas implémenté AV1 dans son navigateur ou son système d'exploitation (même si je note du progrès pour AVIF qui sera supporté dans les prochaines versions cet automne)...
Annexe extraite du rapport 2022 sur l'état de d'internet en France, page 96Je n'avais pas relevé, il est question de support de l'AV1 sur les smartphones conçus en 2021.
Mauvaise nouvelle : Sisvel annonce un "pool de brevets AV1", qui revendique détenir des brevets sur les codecs VP9 et AV1
Certaines actions en justice se préparent pour contester l'AV1. En cas de victoire, AOMedia serait contrait de retirer les brevets pour faire un AV2 libre.
(https://lafibre.info/images/tv/202006_sisvel_site_web.webp)
Sisvel International a annoncé l'élargissement de ses membres à sa plate forme de licence de codage vidéo, qui offre des programmes de licence pour la propriété intellectuelle liée aux formats vidéo OTT VP9 et AV1 .
Après avoir mis en place le pool d'origine avec JVC Kenwood, NTT, Orange, Philips et Toshiba, qui concédaient tous des licences de brevets à MPEG-LA pour les pools de brevets AVC, DASH ou HEVC, Sisvel a été approché par d'autres sociétés et a défini d'enquêter sur leurs revendications de propriété intellectuelle connexes.
Le résultat est l'ajout de neuf nouveaux membres: Dolby, Ericsson, GE, SK Telecom, la maison de recherche financée par l'État sud-coréen ETRI, InterDigital (qui a acquis les brevets hérités de Technicolor), IP Bridge (administrateur de brevets japonais qui prétend être le plus grand concédant de licence du pool de brevets MPEG-LA AVC / H.264), NTT Docomo (la branche mobile de la société de télécommunications japonaise NTT) et Xylene (titulaire de brevets précédemment détenus par Mitsubishi Electric).
Selon Sisvel, dont le siège est à Luxembourg, des centaines d'autres brevets sont en cours d'évaluation. Le groupe prévoit d'atteindre un portefeuille total proposé en licence d'environ 1 000 brevets pour VP9 et près de 2 000 pour AV1. Les détails de certains d'entre eux sont maintenant publiés sur le site Web de Sisvel, avec des mises à jour régulières.
"L'AOMedia a poursuivi quelque chose qui est honnêtement difficile à réaliser", a déclaré Mattia Fogliacco, PDG de Sisvel, au sujet de l'objectif libre de redevances d'AOMedia. Toutes les technologies de codage vidéo importantes des 30 dernières années sont le résultat de la collaboration entre entreprises et des investissements de ces entreprises."
"Il est difficile de croire qu'un groupe, même de la taille d'AOMedia, pourrait développer toute la technologie qui entre dans un codec vidéo."
AOMedia est soutenu par des sociétés contrôlant d'énormes écosystèmes ou développant des puces utilisées par des centaines de millions de clients dans le monde. Ils comprennent Amazon, Cisco, Intel, Mozilla, Samsung, Apple, Facebook, IBM, ARM, Nvidia, Tencent, Bitmovin, ATEME, Broadcom, Alibaba, Vimeo, Adobe, CableLabs et Hulu.
"Les entreprises membres d'AOMedia ont une bonne raison d'offrir gratuitement leur technologie en AV1", fait valoir Fogliacco. "Ils vendent des puces, des cartes vidéo ou des appareils afin de gagner de l'argent pour financer leurs techniques de R&D par d'autres moyens.
"Les personnes que nous représentons n'ont pas ce débouché pour leur contribution à la technologie de codage vidéo et cherchent à obtenir [une récompense] sous forme de licence et de redevance."
"Cela se résume au fait que de nombreux détenteurs de brevets pour VP9 et AV1 ne sont pas membres d'AOMedia et n'ont donc pris aucun engagement de rendre cette technologie libre de droits."
Il pense que les membres de l'Alliance ne rejetteront plus d'emblée les prétentions de Sisvel.
"Lorsque AOMedia examinera la liste des membres que nous représentons, ils se rendront compte que la réalité est un peu différente de ce qu’ils imaginent. Ils réaliseront que les prix sont équitables et que nous avons fait un travail approfondi d’interne filtrage avec des tiers accrédités et par nos propres experts du domaine technique pour établir une base technique pour les brevets."
Les taux de redevance, qui ont été fixés l'année dernière, n'ont pas changé. Ils exigent que les implémenteurs paient 0,32 € pour les appareils d'affichage grand public (y compris les smartphones, les téléviseurs, les appareils VR, les caméras vidéo et les ordinateurs) et 0,11 € pour les appareils sans écran (y compris les décodeurs, les consoles de jeux, les lecteurs multimédias en streaming et les cartes graphiques ) en utilisant AV1.
Pour un preneur de licence qui respecte pleinement ses obligations, il existe une incitation à un taux inférieur de 0,24 € et 0,08 € pour les appareils AV1 affichés et non affichés. "Le pool est l'option la moins chère et la plus efficace pour effacer" l'option de licence", déclare Sisvel.
Les entreprises qui mettent déjà en œuvre la technologie VP9 ont été informées du coût de la technologie, dit Sisvel, tandis que celles qui envisagent d'adopter AV1 sauraient que des redevances s'appliqueront.
Fogliacco explique que Sisvel a délibérément pris l'année depuis l'annonce de la création du pool de brevets pour enquêter sur d'autres revendications de brevet pour AV1 et VP9.
"Nous n'avons pas immédiatement lancé d'activités de licence. Nous savions qu'il était essentiel de créer un guichet unique pour examiner et valider, ou rejeter, les brevets de toutes les autres sociétés qui nous ont contactés. Nous sommes maintenant en mesure de garantir que le pool de brevets est aussi inclusif que possible pour les IP sous licence."
Sisvel ne demandera pas de redevances pour le contenu encodé et actuellement seules les implémentations matérielles sont sous licence - mais cela pourrait changer.
"Nous laissons la porte ouverte pour voir comment le marché se développe", explique Fogliacco. "Il se pourrait que les appareils soient vendus avec une capacité de décodage AV1 qui n'ont cette capacité qu'en raison de téléchargements de micrologiciels ou de mises à jour logicielles, nous gardons donc nos options ouvertes."
Dans le cadre du programme AOMedia, les sociétés titulaires de brevets qui mettent en œuvre AV1 renoncent à leur droit à la propriété intellectuelle sous licence (payante). Sony, fabricant de smartphones fonctionnant sous Android 10, est cité par Sisvel à titre d'exemple.
En excluant ces sociétés, Sisvel affirme avoir regroupé la grande majorité des autres sociétés possédant des IP AV1 et VP9 sous licence.
«Nous pensons que les pools créent de l'efficacité en permettant aux réalisateurs potentiels de signer un accord autorisant plusieurs portefeuilles de brevets en une seule transaction à un coût raisonnable et transparent», dit-il.
AOMedia a critiqué le lancement du pool de brevets AV1 comme contraire à ses objectifs. Sans nommer explicitement Sisvel, il a déclaré que l'annonce de mars dernier "approuve un environnement d'exigences élevées en matière de redevances de brevets et d'incertitude en matière de licences" qui, comme les pools MPEG-2 et H.264 administrés par MPEG LA "limiterait le potentiel de la vidéo en ligne gratuite et ouverte La technologie."
En revanche, AOMedia a l'intention de régler les conditions de licence de brevet avec la licence de licence AOMedia 1.0 libre de droits.
AOMedia doit détenir les droits de propriété intellectuelle pour toutes les techniques fondamentales dans AV1 / VP9 "pour éviter de porter atteinte à la propriété intellectuelle de tiers", déclare Sisvel.
AV1 partage la même architecture de codec hybride que H.264 et HEVC. Ces éléments constitutifs comprennent la transformation / mise à l'échelle / quantification, l'intra et l'interprédiction, le filtrage en boucle, le décodeur dans la boucle (y compris la quantification et la transformation inverses) et le codage entropique.
En 2018, Netflix et Intel ont décidé de développer un encodeur AV1 de qualité production qui offre performances et évolutivité.
Netflix estime que SVT-AV1 peut être utilisé comme plate-forme pour la R&D d'un futur codec AV2. Sisvel a refusé de dire si les membres de son pool de brevets revendiqueraient la propriété intellectuelle sur ce développement.
Sisvel, qui décrit son rôle de "facilitateur des transactions sur le marché", a été constituée en 1982 en tant qu'entreprise commune entre les principaux fabricants italiens de téléviseurs. Sisvel était l'administrateur de la télévision numérique terrestre (DVB-T) et de ses évolutions (DVB-T2 et DVB-S2X). Elle exploite actuellement des pools de brevets et des programmes de licence conjoints dans les domaines de la communication mobile, des réseaux locaux sans fil 802.11, du codage vidéo , des technologies d'affichage et de vidéo numériques, des moteurs de recommandation et de l'accès large bande aux réseaux de données.
Source : streamingmedia.com (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=139636), le 10 mars 2020 Par Adrian Pennington. Traduction Google.
J'ai remonté le problème à "Can I Use" et ils ont corrigés, en mentionnant l'absence de support d'AV1 activé par défaut pour Edge : https://caniuse.com/?search=av1
Googe Chrome 113, disponible depuis le 2 mai 2023 intègre libaom v3.6.0 pour encoder et décoder des vidéos avec le codec vidéo AV1.A priori c'est uniquement l'encodage, le décodage étant normalement fait avec dav1d.
A priori c'est uniquement l'encodage, le décodage étant normalement fait avec dav1d.dav1d est probablement toujours plus rapide que libaom pour le décodage.
À noter que Tiktok propose de nombreux encodages en HEVC :c'est marrant j'avais essayé cet outil pour télécharger des vidéos de canal+ et autres daily/YT, ca n'avait jamais marché..
Le support du codec HEVC est indispensable pour les définitions 720p et 1080p.
Sur les codecs , on a une idée pourquoi les flux Hd multicast des opérateurs, et DVB-S chez canal ne passent pas en HEVC ? Au moins en partie ? Ça ferait un sacrée gain de place.
Les deux raisons les plus probables à mon humble avis :
1) prise en charge matérielle qui n'est pas assez proche de l'universalité
2) le consortium qui va venir frapper à la porte des diffuseurs pour demander des millions en coûts de licence
2) Si les décodeurs sont déjà là , cela veut dire aussi que les licences ont déjà été payées, non ?
Il y a d'une part les droits à payer pour que le terminal puisse lires les flux HEVC, mais égarements les droits, beaucoup plus importants, pour diffuser (ou encoder) en HEVC.
Il y avait même un pourcentage de 0,5% du chiffre d'affaires sur les flux HEVC à payer (de l'abonnement vidéo), mais cela a été supprimé.
L'AV1 est en passe de devenir au fur et à mesure le standard de-facto,
L'AV1 est en passe de devenir au fur et à mesure le standard de-facto, VVC semble prometteur, mais est sans doute bien moins soutenu/implémenté et fait probablement du licensing, j'avoue ne pas m'être renseigné outre-mesure.
En effet, même si rien n’empêche une future évolution de la méthode de compression, hormis le support materiel, la norme DVBT-2 ne comprenant pas spécifiquement de codec en soi.
Selon toi, on s’oriente donc vers une cohabitation de standard?
Avec la disparition progressive des médias physiques, à mon sens, la situation pourrait évoluer dans les années à venir, tout dépendra du rapport entre la performance, le coût, etc., même si une grande part découle également du poids des acteurs qui soutiennent ces technos.
Sympa en tout cas, j'imagine que tu utilises du DVB-T pour avoir un plus large public couvert?
Si je prends le cas de mon téléviseur, il est récent et les deux normes sont couvertes.
En termes de bitrate a/v, cela représente combien en moyenne?
Tu paies donc du licencing pour la diffusion de HEVC?
https://accessadvance.com/hevc-advance-patent-pool-detailed-royalty-rates/
Concernant l'AV1, c'est possible!
https://aomediacodec.github.io/av1-mpeg2-ts/
Bref, se méfier des benchmark vidéo (car l'AV1 réencode du H264 déjà encodé, donc il va recompresser encore plus)
Car du H264 à 10 mégas, ça donne pas une bouille pareille.
10 Mbps avec 4K et 120 images/secondes... sur un encodeur hardware « grand public » en temps réel et pertes de performance minime... si !
Forcément, il va volontairement exagérer le trait en dégradant volontairement la qualité des autres codecs pour que les gens se disent "olala oui, on voit vraiment la différence".
Il aurait été intéressant de faire une comparaison avec VP9 ou HEVC.
Oui, le biais est clairement fait en choisissant de faire du 4K@120 avec H.264 avec un débit aussi ridicule. La comparaison serait en effet plus pertinente avec 4K@30 au même débit, et encore... ça resterait très exagéré. Une comparaison honnête, à mon humble avis, se serait portée sur du 4K60 avec 50 Mbps.Autre point a garder en tête, on est sur de l'UHD.
J'ai un peu de mal à comprendre pourquoi elle ne peut pas encoder du SDR.
J'ai un peu de mal à comprendre pourquoi elle ne peut pas encoder du SDR.
Autre point a garder en tête, on est sur de l'UHD.
Les vieux codecs sont moins efficaces en haute définition.
Une comparaison H.264 vs AV1 sur un flux 480p donnerait moins d'écart entre les deux.
Récemment j'ai dû faire de l'encodage MPEG2, c'est impressionnant : quand on double le nombre de pixels, on doit doubler le débit.
Pour moi, il faut soit faire des demandes pour être intégrées dans le véritable Handbrake
Sur l'URL proposée, les différentes compilations sont en échec.
Ils ont catégoriquement refusé, d'où ce forkTu sais pourquoi ?
Tu sais pourquoi ?
Personnellement, j'ai été étonné que Handbrake qui propose une centaine de préréglages (presque tous en H.264, un petit peu de HEVC) et ne propose rien pour VP9 dans un conteneur WebM (le seul permettant de diffuser sur internet). Le seul pré-réglage VP9 qui existe, il est caché dans "Mastroka" et il n'est donc pas utilisable sur internet).
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%.Une personne aurait acheté un Pixel 10 et pourrait vérifier si les vidéos prises par le téléphone ne sont plus en HEVC, mais en AV1 ?
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.
Tu utilises quoi pour encoder tes vidéos ? ffmpeg directement ou un outil graphique.
- CRF 50 en 1080p, 55-60 en 4K, 40-45 en 720pC'est osé CRF 50 et > 50, tu perds quand même pas mal de détails.
- Toujours en 10-bit (la prise en charge du décodage matériel l'a rendu obligatoire ; c'est contre-intuitif mais ça améliore la compression et surtout ça aide énormément vis-à-vis du banding (https://en.wikipedia.org/wiki/Colour_banding))Tu es sûr que le 10-bit améliore la qualité pour une même taille ?
Ces SVG ne devraient pas, en soi, mettre le banding en évidence. C'est surtout le deuxième qui permettra de le distinguer. Mais in fine ça va dépendre du moteur de rendu et de l'affichage derrière. Je ne suis pas sur mon écran principal OLED qui sait afficher du 10-bit actuellement (je suis sur une tablette "normale") donc je vois un peu de banding. Mais ça va... un peu de dithering (diffusion d'erreur avec "bruit bleu" (https://blog.demofox.org/2018/01/30/what-the-heck-is-blue-noise/) et ça serait très propre.Je pense que Vivien parle de générer des AVIF 8/10 bits à partir des SVG, pour comparer les deux, avec le SVG en référence.
Moi, je serais plus curieux de comprendre comment font VLC ou les distributions Linux pour prendre en charge HEVC sans payer la licence.
comment DELL et HP font ils pour desactiver HEVC si le gpu embarqué le prend en charge ? ils le font avec leurs drivers ?Apparemment, le fabricant modifie les blocs GUID servant à identifier la capacité de décodage vidéo HEVC sur le CPU pour que le driver ne les reconnaisse plus.
Apparemment, le fabricant modifie les blocs GUID servant à identifier la capacité de décodage vidéo HEVC sur le CPU pour que le driver ne les reconnaisse plus.Donc le décodage matériel HEVC ne devrait pas non plus fonctionner sous Linux, si la modification est au niveau du CPU.
HEVC_VLD_Main, HEVC_VLD_Main10, etc... ne sont plus exposés par le processeur donc le driver croit qu'il pas la capacité de décodage matériel.
source : https://github.com/intel/media-driver/issues/1956
Apparemment, le fabricant modifie les blocs GUID servant à identifier la capacité de décodage vidéo HEVC sur le CPU pour que le driver ne les reconnaisse plus.J'ai cherché quelques éléments de la liste, et j'ai trouvé des référence de 2015, 2022, ...
HEVC_VLD_Main, HEVC_VLD_Main10, etc... ne sont plus exposés par le processeur donc le driver croit qu'il pas la capacité de décodage matériel.
source : https://github.com/intel/media-driver/issues/1956
#!/bin/bash
time ffmpeg -i source.mkv \
-vf "scale=1920:-1" \
-c:v libsvtav1 -preset 4 -crf 32 \
-svtav1-params keyint=10s:scd=1:lookahead=64:tune=0:enable-variance-boost=1 \
-pix_fmt yuv420p10le \
-c:a libopus -b:a 96k \
-metadata title="Super Coaster - Luge sur rails à Super-Besse" \
-metadata license="CC BY-SA 4.0" \
-metadata description="Test de Super Coaster" \
-metadata copyright="CC BY-SA 4.0 Vivien GUEANT" \
-metadata genre="Montagne" \
-metadata date_released="2026" \
-metadata url="https://lafibre.info" \
-metadata artist="Vivien GUEANT"\
-metadata publisher="LaFibre.info" \
-metadata:s:a:0 language="fre" \
destination.mp4
J'ai une version récente de ffmpeg (7.1.1), qui encode avec SVT-AV1 via /usr/lib/x86_64-linux-gnu/libSvtAv1Enc.so.2.3.0Si la librairie suit les conventions, la compatibilité n'est pas garantie parce que la version majeure est différente (libX.so.2 et libX.so.4).
Est-il possible de lui demander à utiliser la bibliothèque /usr/local/lib/libSvtAv1Enc.so.4.0.1 à la place, sans recompiler ffmpeg ?
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).
#!/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
| Preset | Taille du fichier (Mo) | Vitesse d'encodage (i/s) | Débit moyen (Kb/s) |
| -1 | 3,41 | 0,46 | 1640,55 |
| 0 | 3,36 | 2,87 | 1617,14 |
| 1 | 3,42 | 8,08 | 1648,67 |
| 2 | 3,48 | 15,30 | 1676,90 |
| 3 | 3,54 | 25,25 | 1705,51 |
| 4 | 3,60 | 44,33 | 1737,95 |
| 5 | 3,64 | 60,20 | 1757,74 |
| 6 | 3,89 | 66,99 | 1887,08 |
| 7 | 4,04 | 68,81 | 1960,42 |
| 8 | 4,35 | 68,95 | 2119,15 |
| 9 | 4,36 | 71,34 | 2125,60 |
| 10 | 4,09 | 74,45 | 1988,09 |
Il y a quelque chose qui coince chez toi, alors, puisque j'obtiens bien le résultat attendu : à CRF équivalent mais preset changeant, la taille diminue suivant l'augmentation de la complexité du preset.Cela s'explique peut-être par ma version de SVT-AV1, la version 2.3.0 ?
Cela s'explique peut-être par ma version de SVT-AV1, la version 2.3.0 ?
| Preset | Taille du fichier (Mo) | Vitesse d'encodage (i/s) | Débit vidéo (Kb/s) |
| 0 | 26,10 | 1,43 | 2275,86 |
| 2 | 26,88 | 7,74 | 2346,50 |
| 4 | 27,25 | 34,78 | 2379,90 |
| 5 | 27,79 | 55,03 | 2429,05 |
| 6 | 29,75 | 74,84 | 2607,64 |
| 8 | 32,37 | 111,62 | 2846,75 |
| 10 | 28,69 | 128,50 | 2511,70 |
| Preset | Taille du fichier (Mo) | Vitesse d'encodage (i/s) | Débit vidéo (Kb/s) |
| 0 | 14,74 | 3,19 | 941,36 |
| 1 | 14,81 | 8,64 | 945,56 |
| 2 | 14,83 | 18,09 | 947,43 |
| 3 | 14,24 | 31,71 | 906,78 |
| 4 | 14,20 | 53,32 | 903,69 |
| 5 | 14,16 | 77,61 | 901,43 |
| 6 | 14,26 | 107,92 | 907,89 |
| 7 | 14,95 | 145,59 | 955,30 |
| 8 | 15,60 | 215,42 | 1000,35 |
| 9 | 14,23 | 298,90 | 905,86 |
| 10 | 13,07 | 331,70 | 826,32 |
$baseName = "202603_arte_info_meta_et_google_condamne_pour_mise_en_danger_de_mineurs"
$presets = @("0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10")
foreach ($p in $presets) {
$filename = "$baseName$p.mp4"
if (Test-Path $filename) {
Write-Host "Extracting frame data for Preset $p..." -ForegroundColor Cyan
& "$ffmpegDir\ffprobe.exe" -v error -select_streams v:0 -show_entries frame=pkt_size,pkt_pts_time -of csv=p=0 $filename > "trace_p$p.csv"
}
}J'ai créé un bug pour que SVT-AV1 soit mis à jour pour Ubuntu 26.04 : https://bugs.launchpad.net/ubuntu/+source/svt-av1/+bug/2140560
Actuellement, c'est encore la version 2.3.0 dans les versions bêta...
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).
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 ?
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
| 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. |
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.
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
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é.