S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Dav2d : VideoLAN publie son décodeur AV2 open source

Presque huit ans après Dav1d, VideoLAN remet le couvert avec Dav2d. Comme son nom l’indique, c’est une implémentation logicielle pour décompresser des vidéos AV2, le codec en cours de développement par l’Alliance for Open Media. Il prend donc la suite de Dav1d – qui est l’acronyme récursif de Dav1d is an AV1 decoder – pensé pour le codec AV1.

Dans la foire aux questions, il est précisé que Dav2d est toujours récursif, « mais c’est moins drôle que dav1d », reconnait l’équipe. Quoi qu’il en soit, Dav2d est proposé sous une licence très permissive : BSD 2-Clause ou « Simplified BSD License ».

Illustration : Flock

Sur le GitLab dédié de VideoLAN, il est indiqué que « dav2d est un décodeur AV2 multiplateforme, open source, axé sur la vitesse et la précision. Il est basé sur notre décodeur dav1d, très populaire. Il s’agit d’un projet encore préliminaire, qui ne devrait pas être utilisé en production, notamment parce que la spécification AV2 n’est pas définitive ». Ce projet de VideoLAN est réalisé dans « le cadre de son adhésion à l’Alliance for Open Media/AOM », en charge d’AV1 et AV2.

Les travaux ont débuté il y a quelques mois déjà, mais c’est encore une version très préliminaire en 0.0.1 (alias Merbanan). L’équipe cherche de l’aide, notamment des développeurs C et assembleur, ainsi que des testeurs… La FAQ se termine par un trait d’humour sur ce sujet : « Vous soucierez-vous de <mon architecture > ? De < mon OS > ? ». Réponse : « Oui, mais nous n’avons ni le temps ni les connaissances nécessaires. C’est pourquoi les correctifs et les contributions sont les bienvenus ».

AV1, pour rappel, a été lancé en 2018 et son adoption a pris du temps, notamment pour le navigateur Edge de Microsoft (version 121 en 2024) et les terminaux Apple (Mac avec puce M3, iPhone 15Pro et 16), comme le rappelle Lafibre.info dans son grand tableau récapitulatif des codecs populaires.

L’avantage d’AV1 est sa gratuité (pas de redevance, comme AV2), il peut être encapsulé dans des conteneurs tels que MP4, MKV ou même WebM. Il a donné naissance à AVIF pour AV1 Image File Format (un mélange entre les algorithmes de compression AV1 et du High Efficiency Image File Format ou HEIF).

Commentaires (30)

votre avatar
0.0.1 ? C'est pas SemVer-compliant ça XD

(Ça devrait être 0.1.0)
votre avatar
L’équipe cherche de l’aide, notamment des développeurs C et assembleur,
Assembleur? X86 ?

Ce n'est pas très portable d'une machine à l'autre. Car il faut tout simplement faire en double. Même avec des outils dédiés c'est pas super top en termes d'exploitabilité. Tu changes un truc et il faut reporter partout les modifs.

C'est l'avantage des compilateurs sur ça.

Rien d'impossible cependant, mais cela me fait tiquer de le lire. Je viens du monde des ordinateurs ou le C était vu comme lent et gourmand. Le PC avec le C/C++ a renversé la vapeur. Et aujourd'hui on demande du dev ASM à nouveau ??? hmm ???
votre avatar
Comme pour dav1d, malgré les défaut de l'assembleur que tu pointes, ce langage permet une efficacité extraordinaire.
votre avatar
@pamputt , @doctorrock

Comme le dit @alex.d. il a eu de l'eau qui a coulé sous les ponts. Je dirai même que les différences architecturales des x86 en passant de la génération 4 à Pentium ont obligé ces compilateurs à commencer a s'y mettre sérieusement et effecacement.

Et c'est même là que le compilateur a supplanté l'humain. Avec par exemple l'exécution en parallèle d'instructions (gravement vulgarisé/schématisé - mais avec une bonne réponse ici) qu'il fallait grouper par paquet de X et pas n'importe comment, etc. Le compilateur permettra d'exploiter la chose et de garder un source flexible. Le faire en ASM, tu changes un truc c'est reprendre depuis zéro le ou les bouts de code.

Je pense aussi à :


  • l'utilisation des caches qui sont bien différents suivant les générations de CPU mais aussi d'un type d'un CPU à l'autre. Il y a quelques CPU RISC-V (SBC de dev) qui lorsque l'on utilise les caches comme il faut, font des merveilles de parallélisme (Ça tombe bien... la vidéo, l'audio...).




  • la spécialisation plus ou moins profonde des cœurs qu'on a vu arriver récemment.



Bref, ç'est du sport.

Je ne dis pas que c'est impossible. Mais faire de l'ASM en restant efficace sans une aide par des outils dignes de ce nom comme on voit dans les autres langages... bin on va y laisser une goutte ou deux.
votre avatar
Je ne dis pas que c'est impossible. Mais faire de l'ASM en restant efficace sans une aide par des outils dignes de ce nom comme on voit dans les autres langages... bin on va y laisser une goutte ou deux.
Ca dépend beaucoup des instructions utilisés. Réécrire en assembleur un programme écrit en C, n'a que peut de sens aujourd'hui, tant les compilateurs sont efficaces.

Par contre, écrire en assembleur pour utiliser pleinement les jeux d'instructions du CPU disponibles, là, c'est déjà beaucoup plus efficace.
votre avatar
Exactement: Même en faisant 99.9% du boulot en langage généraliste (y compris un "assembleur de haut niveau" comme le C), on ne pourra y utiliser des instructions/accélérateurs HW très spécifiques. Là, qq routines optimisées (en assembleur et/ou compilées pour un matériel spécifique) s'imposeront toujours avec même la possibilité de les caser dans des librairies spécifiques et de tirer, au load, celle adaptée spécifiquement aux possibilités offertes par le matériel sur lequel on tourne (utilisation des flags cpuid sur x86 par exemple), au milieu de tout le reste qui est généré de manière largement compatible pour tourner sur une grande variété de matériels.
Cela permet d'avoir le meilleur des 2 mondes entre compatibilité et performance (là ou cela apporte vraiment un bénéfice).
votre avatar
Alors oui et non. Tout dépend de ce que l'on fait. Bon, ça, facile.

Écrire de l'ASM pour mieux aller chercher les cycles se fait au prix de la spécialisation. Si c'est pour recopier une ligne de pixel... Bon ça va pas chercher loin. D'où les SIMD et autres accélérations matérielles. Et je ne parle même pas de code auto modifié, généré et généré auto modifiant (ouais c'est freestyle parfois).

Donc, il y a un problème. Il faut penser sur plusieurs architectures. Aujourd'hui X86-64/ARM, et bientôt RISC-V. Sinon c'est une version ok sur un type de CPU et le reste, ouais bof...

Dans ce contexte, le besoin d'avoir des outils qui permettent d'embarquer dans le même source toutes les moutures se fait sentir. Gestion de projet oblige. Grosso modo les directives de compilation. Je ne crois pas que ce soit le cas aujourd'hui dans les compilos C/C++. En tout cas pour la partie ASM. On approche la chose en compilant pour une cible et il gueule s'il n'a pas ce qu'il veut.

Et donc de tenir compte de la spécificité de chaque type de CPU. D'ailleurs on ne devrait plus appeler ça CPU mais plateforme d'exécution tellement cela a changé d'approche à ce niveau. D'où les jeux d'instruction à gogo partout.

Il faudrait passer de :


int main()
{
    __asm__("movl $4, %eax; 
             movl $2, %ebx; 
             addl %eax, %ebx"
          ::: "eax", "ebx");
}


À un genre comme ça (et encore c'est light).


int main()
{
    __asm_X64_("movl $4, %eax; 
             movl $2, %ebx; 
             addl %eax, %ebx"
          ::: "eax", "ebx");
    __asm_ARM_([...]);
    __asm_RISCV_([...]);

}


Cela veut dire qu'on passe d'outils très atomiques (c'est pas comme si tout allait bien dans le domaine) à des IDE complets et capables d’accueillir tout ça. Et d'accompagner le dev sur cette partie.

Il y a bien quelques gars qui font des trucs. Comme ça : https://x64dbg.com/
Mais bon l'ASM sur PC, ou autre plateforme d'ailleurs... C'est très souvent le couteau entre les dent.

La seule résolution de ce genre de problématique c'est avoir une sorte d'assembleur universel. Mais il faut mettre tout le monde d'accord... aïe... Ha nan mais c'est tout moi ça... le bon sens... nan mais je sais... pas dans ce monde... désolé.
votre avatar
Le jeu d'instruction PowerPC était plutôt bien foutu, y compris un passage 32 vers 64 bits qui n'y a pas changé grand chose (à part la taille des registres généraux)... ce qui ne fut pas le cas ailleurs (coucou ARM).
Maintenant, s'il a eu une belle vie de 20 ans dans l'embarqué et qu'IBM continue à faire ses processeurs sur cette base, c'est pas toujours le meilleur qui gagne!
Niveau universalité, ARM a bien tenté le coup du "processeur Java" avec Jazelle mais c'est tombé en désuétude: Google en particulier n'a pas voulu utiliser un truc qui l'aurait lié pieds et poings avec ARM et en est resté à sa machine virtuelle a dérouler du bytecode purement logicielle (et qui se cross-compile ailleurs si on se fâche avec ARM).
Puis faire "universel" c'est aussi un probable frein aux progrès futurs... Ou alors il faudrait la jouer à la Intel avec depuis longtemps à la base une machine RISC, mais que l'on utilise via le jeu d'instruction CISC "historique" qui est devenu une sorte de couche wrapper matérielle.
votre avatar
Oui. D'un autre coté un CPU Java c'est un peu le grand écart.

Je prône pour l'usage d'une base assembleur commune au moins. Les copies, 4 opérations de base, etc. Tout ça décliné avec la taxonomie de Flynn et ça roule.

Et d'arrêter les bêtises avec les registres. Le nombre réduit de registre à forcé les codeurs à utiliser les jeux d'instructions supplémentaires pour utiliser ces registres dédiés comme du stockage (quand c'est possible).

Tu mets 32 registres de données, et 32 d'adresses bindés dans du cache local (qui se compte en mégas quand même) et c'est réglé. Aujourd'hui à part de se trimbaler la rétro compatibilité (qui ne fait plus vraiment sens aujourd'hui), je ne vois pas trop ce qui bloque.
votre avatar
Dans les années 80, l'assembleur était encore roi et les cpu regorgeaient d'instructions. Le C a accéleré le dev, en perdant l'accès aux soécificités (un opérateur qui fait la division et récupère le reste, comme la plupart des CPU font en une fois, manque par exemple).
Quand cuda est sorti, je n'ai pas compris: oui, la syntaxe c est connue, mais elle est nulle pour ce type de traitement. Fortran était bien mieux.
Bref, c'est bien pour un programme ordonnancant quelques opérations basiques, pour les algo plus complexes, il faut un langage de plus haut niveau car les implémentation spécifiques divergent trop.
L'équipe videolan a déjà prouvé qu'en écrivant des chemins d'exécution dédiés en assembleur, ils dêpassaient les perfs du c même avec les extensions/inteinsics simd.

Une compilation intermédiaire via les instructions intermédiaire de clang pourraient faire l'affaire. Mais bon, tu as vécu comme moi la période des compilo pour risc...
votre avatar
L'idée quand on fait de l'optimisation en réécrivant en assembleur, c'est quand même d'avoir une implémentation générique (en C, portable) et à côté, des implémentations spécifiques, en assembleur, pour tirer le maximum du processeur, en utilisant les jeux d'instructions non disponibles directement. Et perso, le code assembleur directement dans le code C, j'ai jamais supporté ! Surtout que les __asm et consort ne sont pas dans la spécification de base du langage mais des extensions facultatives et liées au compilateur, et que le format attendu dépend aussi de ce dernier.

Il vaut mieux faire une bonne fonction externe qui sera référencée ensuite, dans un fichier à part ;)

Quand on veut tirer parti d'instructions "étendues", comme les instructions AES, SIMD, etc. alors là oui, écrire à la mano en assembleur permet encore d'avoir des gains plus ou moins sensibles ;)

Mais sur du code "classique", il vaut mieux laisser faire le compilateur, qui saura beaucoup mieux prendre en considération les architectures modernes des processeurs, les pipelines, etc. en réordonnançant parfois les instructions !
votre avatar
Déjà, il y a ~40 ans j'avais fait de l'assembleur en milieu pro parce que le C n'était pas assez rapide... sur les manipulations de bits !

On programmait un algo Lempel & Ziv (celui de Zip) parce qu'à l'époque, impossible de trouver une librairie à acheter. Alors quand le jeu x86 propose des instructions du genre je pousse un bit à droite dans le registre bidule, et il rentre à gauche dans le registre machin... eh bien va-t-en faire la même chose aussi efficacement en C !

D'ailleurs C est toujours notoirement à la ramasse sur les "bitfields", c'est un domaine où il y a eu très peu d'évolutions en 40 ans !

Alors j'imagine qu'utiliser efficacement des instructions "spécialisées vidéo" se fait toujours en assembleur sur un codec, tant pis s'il faut coder en x86 et refaire en ARM!..

Après, sur les choses génériques, les compilateurs ont effectivement bien évolué. Mon assembleur de l'époque plaçait "astucieusement" les instructions pour faire tourner le processeur pendant que le bus mémoire était occupé. On n'a plus besoin de faire ça "à la main", le compilateur le fait très bien, et même le processeur d'ailleurs, si le compilateur n'a pas optimisé la chose.
votre avatar
Pour le calcul décimal, le C est également à la ramasse. Mais les choses vont peut-être changer.
votre avatar
Bah tous les codecs videos ont une grosse partie en ASM, c'est pas nouveau. Même les codecs audios. Si on veut qu'ils soient hyper efficaces, à un moment donné le compilateur est largué et il faut écrire les parties critiques en ASM
votre avatar
C'est de moins en moins le cas. Historiquement, c'est surtout pour exploiter les unités vectorielles que l'assembleur était nécessaire, mais la vectorisation par le compilateur a beaucoup progressé.
votre avatar
Oui elle a progressé, mais elle n'est pas assez performant pour ce genre de cas.
Sans compter que si tu fine-tunes ton code assembleur pour les instructions assembleurs que tu vises, ça devient très vite chiant de faire du C puis de checker en assembleur. Tu passes plus de temps à essayer de tordre le compilateur dans ton sens plus qu'autres choses.
votre avatar
Sur la nécessité de faire de l'assembleur, JB Kempf a déjà expliqué pourquoi s’agissant de dav1d, je pense que c'est la même logique pour dav2d : youtu.be YouTube
votre avatar
Ils demande C et ASM.
Il y a fort à parier que la majeure partie sera en C, et que seules quelques fonctions très spécifiques, celles qui sont appelées massivements avec des calculs où l'optimisation joue énormément, qui seront écrites en assembleur. Il suffit parfois d'une petite optimisation sur des fonctions clefs pour un gain énorme à l'arrivée.
Il y a souvent un arbitrage à faire entre portabilité et efficacité, et dans le cas d'un codec le poids de cette dernière est assez fort pour que ça vaille le coup d'y consacrer du temps et des ressources.

C'est ce qu'ont du mal à comprendre pas mal de chefs de projets actuels qui veulent tout faire en python (par exemple), dans un peu tous les domaines.
votre avatar
Heu... Les Pythonisateurs... doivent mourir... voila.

Oui évidement C majoritaire. Mais c'est un peu toujours le couteau entre les dents dès qu'on taquine un peu l'ASM. En fait quand le PC est arrivé, beaucoup de gens disaient que le PC était fait pour le C/C++. A tort ou à raison peut-être. Pour l'instant je ne leur donne pas tort.
votre avatar
Je me rappelle d'une vieille discussion avec JB ici. Si je me souviens bien, le code est entièrement ecrit en C/C++, mais pour les architectures les plus courantes, ils ont réécrit des parties de ce code en assembleur pour l'optimiser.

Donc normalement, tu pourrais compiler le code sur ton processeur Power-PC préféré, mais il y a des chances qu'il tournera moins bien que sur ton PC x64 récent.
votre avatar
De mémoire, la première version de libdav1d, sans opti asm faisait un x10 de rapidité par rapport à la libaom, qui servait d'exemple d'implémentation pour AV1. Une fois les optis asm faîtent, y'a eu un nouveau x10.

Si tu regardes le git de la bibliothèque, tu vois qu'ils implémentent à la main x86, LoongArch, PowerPC, Aarch64/ARMv8 et RISC-V.
Et même parmi les x86, ils font le distingo entre les version d'AVX présentes ou non (AVX2, AVX512), et les SSSE.

Tout ça pour dire que non seulement c'est pas impossible, mais en plus, ce sont des fous, et ils le font bien :)

Je me souviens qu'à une époque, ils avaient besoin de volontaires, du coup, ils avaient créé des formations à l'ASM pour le tout venant juste pour ce projet. Des vrais fous.
Mais des fous géniaux, puisque maintenant, ils ont la lib la plus rapide du monde pour décoder l'AV1, lib qui fait du meilleur boulot que Google ou Netflix ont pu faire. C'est aussi grace à eux qu'on peut lire des vidéos AV1 sur smartphone aujourd'hui, quand quelques mois après le lancement du format fallait un PC gamer bête de course pour faire tourner du 720p (et j'exagère à peine : je me souviens avoir lancé des samples avec des extraits de Big Buck Bunny, et c'était… dur).

Note que ce sont les même gens qui font FFMpeg, logiciel qui tourne derrière Youtube, Netflix, Amazon Prime…
Cette commu est folle.

EDIT : Je te recommande vivement la lecture des posts de blog de JP Kempf, qui détaille l'avancement de dAV1d https://jbkempf.com/blog/dav1d-toward-the-first-release/ (post au hasard sur le sujet, hésite pas à naviguer)
votre avatar
Cette news est l'occasion de rappeler l'excellent travail réalisé par Videolan. Un grand merci à toute l'équipe pour le travail réalisé jusqu'à présent :iloveyou:.
votre avatar
C'est clair que VLC a longtemps été mon soft vidéo de prédilection... détrôné (sous Linux au moins) depuis 3 ou 4 ans par MPV: Ce dernier ne me fait jamais de gag, bouffe tout ce que je lui donne sans jamais planter (plus encore la version snap essayée un temps à cause du pb RTSP évoqué ci-après, totalement instable)... et Debian n'a pas été obligé de le générer sans RTSP pour d'obscurs pb de licence avec VLC. Et comme c'est le standard des cams IP...
votre avatar
Oh merci pour l'article ! Je découvre l'existence d'AV2 !

Et déjà 8 ans pour Dav1d ... :phibee:
votre avatar
Et sinon, VLC 4? :D
votre avatar
:santa_flock:
votre avatar
Je me suis toujours demandé c'est quoi qui fait l'innovation dans un codec ?
L'AV1 est assez récent, quel est le responsable du bon technologique entre AV1 et AV2, que l'ont pouvait pas déjà normer à l'époque de l'AV1 ?
votre avatar
C'est le hardware qui limite les algo des codecs en fait. À l'époque de AV1 on pouvait pas utiliser les algo trop puissants d'AV2 sur des puces AV1. Maintenant que le gap hardware est passé, on monte en version et en puissance sur les algos, et donc on up les codecs.

C'est le cas pour absolument tous les codecs du genre. Ya surement un arbitrage quelque part, mais on pourrait presque dire que la sortie des codecs est plannifiée, et qu'il n'y aura jamais de codec absolu
votre avatar
L’avantage d’AV1 est sa gratuité (pas de redevance, comme AV2)

L'AV2 à des redevances contrairement à l'AV1 ou alors l'AV2 n'a pas de redevances tout comme l'AV1?

Je bug sur cette tournure de phrase :keskidit:
votre avatar
AV1, tout comme AV2, n’a pas de redevance et ce, contrairement à H.26x.