Elle travaille depuis des mois sur ce projet visant à proposer une solution open source pour décompresser les flux vidéo AV1 de manière efficace et multiplateforme.
Dans un billet de blog publié le mois dernier, Jean-Baptiste Kempf évoque pas moins de 140 000 lignes de code rédigées en assembleur pour ce projet, dont la phase d'optimisation touche à sa fin.
Les gains sont observables tant sur les plateformes ARM que x86, notamment sur les contenus prenant en charge une profondeur de couleur sur 10/12 bits. Désormais, le travail va se concentrer sur la gestion des threads.
Aucune date n'a pour le moment été donnée pour une éventuelle version 1.0.
Commentaires (45)
#1
OMFG
#2
Et sinon, les menus DVD en français, ça avance…?
#3
“140 000 lignes de code rédigées en assembleur pour ce projet”.
Je sais que niveau optimisation c’est le nec plus ultra, mais faut vraiment être masochiste pour s’infliger autant d’assembleur !!
Merci à eux en tout cas de faire un aussi bon boulot en open source et gratuit pour les utilisateurs finaux !
#4
Tu as le droit de contribuer, si cette fonctionnalité t’intéresse tant que ça :-) On parle de localisation après tout, pas de code, c’est accessible.
#5
Pour les 140 k lignes en assembleur, le billet précise ceci donc par plateforme c’est heureusement moins (mais ça reste beaucoup avec 25 à 30 k lignes) :
90000 lines for x86 (AVX2, SSSE3-32, SSSE3-64);
50000 lines for ARM (32bit and 64bit).
This is very large for handwritten assembly, and for comparison, this is more assembly than what there is in FFmpeg (for all codecs).
Et il indique ausssi ceci, intéressant car avec la complexité des CPU modernes d’habitude c’est difficile de faire mieux qu’un compilateur :
And yes, this code is faster than what the compilers can generate by themselves. :)
#5.1
Merci du complément d’info, la question qui vient ensuite c’est “mais donc est-ce qu’il n’aurait pas fallu plutôt travailler à l’amélioration du compilateur ?”
Mais si ça se trouve ça aurait été encore plus velu.
#6
Masm et Tasm pour discuter avec une imprimante ligne éditant les relevés de compte des clients géré sous Cobol…. revival.
#7
Du beau travail a été fait, impressionnant !
#8
Hormis sur mobile, sur desktop j’ai définitivement migré sur MPC-HC, l’interface est claire, le client est plus léger et lis parfaitement le format AV1, avec VLC, j’avais des problèmes avec une version récente (la dernière je ne sais pas) qui le rendait presque inutilisable, je n’ai jamais eu de problèmes avec MPC-HC.
#8.1
Ne connaissant pas, je suis aller sur le site du projet.
Voici le message en haut de page “MPC-HC is not under development since 2017. Please switch to something else.”
#8.2
Le développement continue par un membre de l’équipe : https://github.com/clsid2/mpc-hc/
Mais ça reste quand même moins bien que VLC
#8.4
c’est parce qu’on est des vieux de la veille qui veulent rester sur l’interface windows media player de win98
les trads sont pas sur transifex ou une autre plateforme de localisation plutôt?
#8.5
Si t’es pas tenté par VLC, SMPlayer (qui utilise mpv comme backend de lecture qui a remplacé mplayer) est très bien aussi. :)
#8.6
J’utilise VLC sur Windows, Mac OS X et Ubuntu.
Et comme Windows n’est pas mon système personnel quotidien, je ne connais pas les autres outils.
#8.7
Ca tombe bien, SMPlayer n’est pas un soft Windows mais un soft multiplateforme (comme mplayer et mpv qui sont les backend utilisables d’ailleurs).
Ca prenait 20s à vérifier au lieu d’expliquer ne pas connaitre les alternatives Windows (ce que SMPlayer n’es pas).
https://www.smplayer.info/en/downloads
#8.3
Pareil, toujours eu quelques soucis avec VLC qui étaient résolus en lisant ma vidéo avec MPC-HC… mais ma dernière expérience remonte pas mal et ces soucis réguliers ne sont peut-être plus d’actualité.
Du coup aujourd’hui je ne jure plus que par MPC-HC + madVR. Aucun regret. A ce sujet MPC-HC a été repris et je vous recommande chaudement l’installeur ultra complet, maintenu régulièrement et très propre “K-Lite”. Je suis le premier à fuir les packs de codecs en temps normal pour leur côté bordélique et un peu trop envahissant mais là j’ai été séduit.
Je reste néanmoins très respectueux de travail accompli sur VLC, je précise histoire de pas sembler torpiller une news positive sur VLC. D’autant que Jean-Baptiste me lira probablement
#9
Ca aurait été bien de mettre un graphique pour voir les progrès réalisés.
#9.1
J’ai peut-être mal compris ta remarque, mais il y en a bien un et il est parlant : http://www.jbkempf.com/blog/public/VideoLAN/dav1d/dav1d_090_10b.png
#9.2
C’est l’article de NXI qui manque de graphes.
#9.3
Il n’y a pas d’images dans le brief mais effectivement, un lien vers le billet de blog qui donne des détails (en images) sur le sujet.
#9.4
Normal, c’est pas un article c’est une brève.
Il n’y a jamais d’images (en dehors de l’illustration) dans une brève.
(Edit : arf, grillé le temps de lire et répondre sur un autre article…
)
#10
https://github.com/clsid2/mpc-hc/releases
Sur desktop, je préfère MPC-HC, j’ai eu des problèmes/bugs à plusieurs reprises avec VLC, client plus lourd, je n’ai jamais eu de soucis avec MPC-HC, mais je ne suis pas une généralité et tout dépends des préférences de chacun, en soit, quand VLC fonctionne correctement il est très bon.
#10.1
Je ne peux pas parler pour aujourd’hui, mais du temps où j’utilisais VLC et MPC-HC (sous Windows), je trouvais que le soucis majeur de VLC c’était la navigation dans la vidéo. MPC-HC était nettement plus réactif à ce niveau, c’était incomparable. Sur VLC ça n’était pas purement instantané et m’amenait quelques soucis de sync son ou st.
Bon on s’écarte un peu du sujet de la news là.
#11
Localisation? Les menus sont déjà disponibles en français sur les DVD (la preuve en est qu’avec MPC-HC ou PowerDVD ils s’affichent correctement), donc il y a bien une ligne de code à écrire quelque part pour qu’ils s’affichent dans la langue de son choix sur VLC, non?
#12
J’ai aussi eu durant un temps des problèmes de navigation dans la vidéo, plus la vidéo qui freeze, le son qui plante ce genre de chose.
#12.1
Pour être honnête madVR c’est vraiment un plus optionnel. Là où je vois une différence non négligeable c’est sur la lecture du contenu HDR converti en SDR via tone mapping. VLC le fait nativement avec son propre renderer mais si on met les images côte à côte on s’aperçoit sans trop de mal que le rendu est meilleur sur madVR. Mais ce n’est peut-être qu’une question de goût ? Pour ma part je trouve le rendu VLC trop fade.
#13
C’est vrai que j’ai souvent des trucs bizarres avec VLC. Le dernier était l’absence des voies des personnes dans un film, film qui passait sans soucis avec mplayer (juste les voies, il y avait la musique).
#14
Tu n’as pas ouvert de ticket pour ça ? Apparemment tu connais le sujet, tu pourrais les aider :p
#14.1
Franchement, la flemme de créer un énième compte sur un énième site pour ça. Surtout que le problème est connu depuis longtemps, ça m’étonnerait que l’équipe ne soit pas au courant.
#15
J’ai rencontré ce genre de problème avec des films au format Dolby 6 canaux : VLC ne configurait pas automatiquement le mélangeur audio en stéréo sur mon PC équipé d’une sortie configurée en stéréo dans Windows, et donc seules les pistes audio arrières gauche et droite étaient audibles. Dans le menu Audio, faire passer le son en Mode Stéréo > Stéréo corrigeait le problème.
#16
Bande de has-been, portez-moi tout ça sur Electron.
#17
Pourquoi ya toujours des gens pour parler de MPC-HC qui est mort sur les news de VLC ??
VLC > tous les player
#18
https://github.com/clsid2/mpc-hc/releases
Non.
#19
“pas moins de 140 000 lignes de code rédigées en assembleur pour ce projet”
Engagez-vous qu’ils disaient, rengagez-vous !
#20
Je demandais pas forcément un graphe mais “Les gains sont observables” ça laisse un peu sur sa faim (x2 ? x10 ? +30%?)
#21
Ha bah tampis pour toi alors ^_^. Tu sais, sur ce genre de projets, les contributeurs se focalisent sur ce qu’ils jugent nécessaire (bcp font ça sur leur temps libre, sans aucune contrepartie). Les petits bugs ou manques qui n’intéressent (ou n’impactent) plus personne, ils restent dans le backlog jusqu’au moment où qqun décide de le classer en wontfix, histoire de nettoyer un peu. Pourquoi se donner du mal pour rien ?
Peut être qu’on montrant que ça t’impacte, et en aidant un peu, ça serait résolu.
Nota : VLC utilise Gitlab pour le bugtracking. Tu n’as pas un compte dessus ? Tu peux même t’enregistrer avec Google/Twitter etc, franchement ça va.
#21.1
Non je n’ai pas de compte Gitlab.
Du coup j’utilise autre chose que VLC, alors pour le coup j’ai envie de dire tant pis pour eux. Bon, façon de parler, que j’utilise ou pas VLC, ça ne leur génère ni revenu ni perte.
Par contre, je ne suis pas le seul que ça embête, il existe de nombreux sujets sur les forums à propos de ça.
Faut dire quand même que c’est une fonction basique de tout lecteur multimédia qui se respecte.
#22
140’000 lignes d’assembleur avec une moyenne d’un bug tous les 1000 lignes… ca promet
#23
Sous Linux VLC fonctionne très bien, sous Windows (portable du bureau) je m’en sers de temps à autre depuis des années et je n’ai pas eu de souci.
madVR ça sert à quoi en plus du lecteur MPC-HC ?
Dans le temps j’ai fait remarquer à J-B Kempf que le saut (de 5 ou 10 s) dans VLC était nettement plus lent que sous mplayer (sous lequel c’était comme instantané), et depuis ça a été réglé. Il y a aussi une question de format, le saut est instantané en MKV mais un peu moins sur des fichiers “.m2t” (fichiers MPEG-TS issus de la TNT), cela dit c’est pas bien gênant.
#23.1
madVR c’est tout simplement un moteur de rendu (renderer) tiers, qui propose des réglages un peu plus fins et de base meilleurs que celui de MPC. Enfin, c’est mon avis et celui de beaucoup de monde dans la communauté du PCHT (PC dédié à la diffusion vidéo). Mais je veux bien avouer que par défaut VLC et MPC font déjà du bon travail.
#24
Avec 140 000 lignes d’assembleur, j’ai peur pour la maintenabilité du projet. Les lignes en assembleur, c’est précisément ce que les devs du kernel Linux ont chassés car avec le temps les lignes devenaient désuètes (les compilateurs arrivant à faire bien mieux, et les CPU ayant des extensions de plus en plus poussées)
#25
Si tu avais consacré 50% de ton énergie à aider les devs de VLC plutôt qu’à te plaindre / te trouver des excuses, ça serait peut être déjà corrigé ^^. Mais non, c’est mieux de se plaindre, qui plus est sur un site que les devs ne consulteront pas.
Les ouin-ouin sur les forums c’est pareil : c’est sur le bugtracker qu’il faut mettre des infos, et relancer si besoin.
#26
L’amélioration des compilateurs est un travail continu, mais le compilateur ne peut pas toujours “deviner” ce qui est désiré par le programmeur, ce qui fait qu’on peut dans certains cas optimiser en assembleur, typiquement pour l’utilisation des instructions spécialisées SSE/AVX.
La compilation c’est un problème de traduction au sens large, et la traduction fidèle entre 2 langues n’est pas chose aisée, sauf si le texte est relativement simple.
#27
Personnellement j’utilise MPC-BE avec madVR, mais si vous avez des solutions plus simple je prends !
Pourquoi ce combo et pas VLC : c’est le seul moyen, que j’ai trouvé pour envoyer les metadata HDR à ma TV pour lire correctement les fichiers 10bits/HDR. J’ai également dit à madVR de changer le framerate de windows quand je lance un fichier vidéo pour qu’il corresponde au framerate de la vidéo. Ceci afin que la TV puisse faire son interpolation “true motion” (surement un autre nom chez les autres marques, en gros créer des images intermédiaires à la volée pour fluidifier la vidéo, comme si elle avait été filmée à 60FPS par exemple ou 48FPS pour les films de Jackson). Comme ça les vidéos sont superbes ET sans saccades, le tout sur un HTPC sans CG avec un core i5 basse conso.
VLC ne fait qu’appliquer un LUT sur une vidéo HDR avant de l’envoyer à l’écran, la différence est flagrante entre les deux pour avoir comparé (visible dans le détail des noirs notamment et sur la chaleur de la chroma). Je n’ai trouvé aucun moyen d’envoyer les metadatas à la TV.
Ah oui ! Et évidemment il faut basculer en HDR dans les paramètres d’affichage de windows avant chaque lecture de fichier de ce type, ce qui n’est pas très pratique vous en conviendrez !
Du coup si jamais un INpactien connait un lecteur qui fait tous ça tout seul je suis grandement intéréssée !
#28
J’aime quand on me fait une remarque désobligeante non justifiée.
Mon premier commentaire #10 (auquel tu as répondu) parlait de MPC-HC. Le premier commentaire qui mentionne SMPlayer est le #26.
De plus, comme j’utilise VLC et que j’en suis content, je n’avais aucune raison de chercher des alternatives.
Alors effectivement, avant de te répondre en #43, j’ai bien vu que SMPlayer était multiplateforme (alors que MPC-HC n’est que Windows).
Tout ça pour te montrer que ta remarque est légèrement déplacée.