Sommaire
Bonjour à tous !
La dernière fois, je vous ai vanté les mérites du futur codec vidéo HEVC contre son prédécesseur H.264.
Ce qui nous intéresse aujourd'hui, c'est comment HEVC se compare face à son concurrent VP9, qui a été racheté par google il y a cinq ans.
L'écriture de ce journal m'est venue car j'ai récemment remarqué que mes vidéos youtube se jouaient toutes en VP9 depuis quelques mois (avec le lecteur HTML5 sous chrome).
Google essaie de pousser son nouveau codec en forçant son utilisation sur la plateforme de vidéo la plus populaire au monde.
La question est donc : VP9, ça vaut quoi ?
Je vous propose donc un petit face-à-face entre VP9 et HEVC, mais également une comparaison avec l'ancien H.264.
Les encodeurs
x265
X265 est un encodeur HEVC nommé après le très célèbre x264 pour H.264. Il est open-source et développé par la société multicoreware.
J'utiliserai la version 1.4 sortie le 3 novembre 2014, et je mux le résultat dans des fichiers MKV.
Je me suis fourni sur le repo mercurial disponible sur bitbucket.
libvpx
La libvpx, c'est le projet de google qui rassemble des bibliothèques de décodage/codage pour VP8 et VP9. C'est la seule implémentation logicielle pour VP9 qui existe.
J'utiliserai la dernière révision git, tout simplement parce que la dernière version (1.3.0) date de novembre 2013 et est indiquée comme "expérimentale pour VP9".
Je mux le résultat dans des fichiers WebM.
Je me suis fourni sur le repo git disponible ici.
x264
On ne le présente plus, j'utiliserai l'encodeur x264 build 142 pour les échantillons H.264.
Lecture
Pour la lecture, j'ai utilisé Media Player Classic HC sous windows. J'aurais bien voulu utiliser VLC, mais même en 2.2.0-rc1 j'ai rencontré de gros problèmes de performances en lecture de flux HEVC, et la moitié des vidéos VP9 étaient corrompues.
Sous linux, on doit pouvoir les regarder avec mplayer ou ffplay/avplay.
Paramètres d'encodage
Comme comparer deux codecs vidéo ne peut se faire qu'à bitrate égal, j'utilise des encodages en deux passes pour avoir un bitrate moyen égal.
J'ai téléchargé les échantillons au format brut YUV420 sur http://media.xiph.org/video/derf/.
x265
J'utilise un encodage en deux passes avec un preset "slower". Niveau ligne de commande ça ressemble à ça :
x265 --input <input> --pass 1 --bitrate <bitrate> --preset slower --stats <input>.stats /dev/null
x265 --input <input> --pass 2 --bitrate <bitrate> --preset slower --stats <input>.stats out.hevcJe me permets l'utilisation de ce preset car la libvpx-vp9 est, on le verra, très lente. Ca serait un désavantage de ne pas pousser les réglages de x265 car, avec ceux par défaut, il compresse 8x plus rapidement que la libvpx.
x264
Tout pareil :
ffmpeg -y -i <input> -vcodec libx264 -b:v <bitrate>k -pass 1 -p slower -f h264 /dev/null
ffmpeg -y -i <input> -vcodec libx264 -b:v <bitrate>k -pass 2 -p slower out.mkvlibvpx
Idem, excepté qu'il n'y a pas de notion de preset. Au niveau ligne de commande :
ffmpeg -y -i <input> -c:v libvpx-vp9 -b:v <bitrate>k -pass 1 -f webm /dev/null
ffmpeg -y -i <input> -c:v libvpx-vp9 -b:v <bitrate>k -pass 2 -f webm out.webmSide-by-side
Nouveauté dans ce journal, je vous propose aussi des vues "side-by-side" des deux vidéos, avec à gauche une moitié VP9 et à droite une moitié HEVC. Les deux moitiés sont séparées par une barre noire.
Du coup, je dois réencoder les deux vidéos précédentes. Pour éviter de gommer les différences entre les deux, j'ai choisi d'encoder le résultat en H.264 avec un CRF à 19, réputé pour être "quasi lossless" visuellement parlant.
Les fichiers side-by-side sont donc beaucoup plus gros que les deux autres.
Les tests
Crowd run (3840x2160@50, 10s)
On commence avec un sample 4K (3840x2160) de 10 secondes où l'on voit un marathon au premier plan.
Le bitrate est de 7'150 kbps. Ce n'est pas tout à fait suffisant pour un tel flux, mais ça permettra de mieux exposer les différences entre les deux codecs.
- crowd_run_2160p50-x265.mkv
- crowd_run_2160p50-vp9.webm
- crowd_run_2160p50-x264.mkv
- crowd_run_2160p50-side.mkv
Je m'excuse d'avance pour les propriétaires de grille-pains qui auront du mal à lire du 4K@50fps de façon fluide.
Analyse :
Pour moi, HEVC est vainqueur de cette comparaison. Les coureurs au premier plan sont plus nets, mais ce qui choque c'est surtout ce qui se passe dans le fond.
Avec VP9, tous les coureurs en arrière-plan apparaissent saccadés, alors qu'ils sont très fluides sur la vidéo HEVC.
Je trouve également que la qualité de l'herbe sur laquelle les gens courent est plus agréable côté HEVC.
Sans surprise, la vidéo H.264 fait pâle figure face aux deux nouveaux codecs.
Au niveau des performances :
- x265 a encodé la vidéo à 0.4fps, MPC-HC consomme 40% du CPU à la lecture.
- libvpx-vp9 a encodé la vidéo à 0.5fps, MPC-HC consomme 30% du CPU à la lecture.
Pedestrian area (1920x1080@25, 15s)
On retourne à une résolution Full HD sur une scène où des piétons traversent une zone piétonne.
Bitrate demandé : 1'050 kbps.
- pedestrian_area_1080p25-x265.mkv
- pedestrian_area_1080p25-vp9.webm
- pedestrian_area_1080p25-x264.mkv
- pedestrian_area_1080p25-side.mkv
Analyse :
Il est plus difficile d'établir un vainqueur pour cette vidéo.
J'aurais tendance à dire que HEVC l'emporte. De peu certes, les deux vidéos sont dans l'ensemble de très bonne qualité, mais l'image est légèrement plus lisse côté x265 :
La vidéo H.264, quant à elle, souffre beaucoup de ce bitrate bien trop bas pour elle et l'image est très bruitée, même les éléments statiques :
Au niveau des performances :
- x265 a encodé la vidéo à 2.25fps, MPC-HC consomme 5% du CPU à la lecture.
- libvpx-vp9 a encodé la vidéo à 1.2fps, MPC-HC consomme 4% du CPU à la lecture.
Old Town (1280x720@50, 10s)
Un plan HD qui consiste en un travelling vu du ciel d'une ville.
Bitrate demandé : 800 kbps.
- old_town_cross_420_720p50-x265.mkv
- old_town_cross_420_720p50-vp9.webm
- old_town_cross_420_720p50-x264.mkv
- old_town_cross_420_720p50-side.mkv
Analyse :
Encore une fois, il est difficile de juger les deux codecs tant les vidéos sont similaires.
De mon point de vue, HEVC a un léger avantage d'ensemble puisqu'on peut remarquer que l'image VP9 "tremble" légèerment, et il y légèrement plus de flou autour des bâtiments en hauteur. Rien de flagrant en tout cas..
Au niveau des performances :
- x265 a encodé la vidéo à 5fps, MPC-HC consomme 4% du CPU à la lecture.
- libvpx-vp9 a encodé la vidéo à 4fps, MPC-HC consomme 2,5% du CPU à la lecture.
Bilan
Je dois dire que lorsque j'ai pensé à faire ces tests, j'avais de gros aprioris et dans ma tête, HEVC/x265 allait sortir grand vainqueur.
Pourtant, force est de constater que l'équipe derrière VP9 et son implémentation dans la libvpx ont fait un très bon boulot puisque le codec rivalise quasiment (selon moi) avec HEVC, et surtout est 25% moins demandant sur les décodeurs.
Seule la vitesse de compression très faiblarde de la libvpx fait défaut, mais ses développeurs promettent des améliorations non négligeables à venir. Notamment, la libvpx n'est pas multi-coeur pour le moment..
On sent que VP9 a bien mûri et on comprend pourquoi google commence à transcoder toutes ses vidéos youtube en vp9.
On commence à apercevoir le départ en retraite du vénérable H.264, même si ce n'est pas pour maintenant :-) . En tout cas, les releases LOL-x265 commencent à arriver dans la baie des pirates..
# de ton analyse, pas la même conclusion
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 19 novembre 2014 à 21:00.
Je ne vais pas rentrer dans les détails (je n'ai pas assez d'arguments précis pour défendre chaque point, et il me faudrait en premier regarder le bitstream de chaque fichier pour voir si il n'y a pas des différences, genre ça m'avait bien fait rire Theora contre H264 avec H264 ayant des keyframes toutes les 12 frames et Theora toutes les 300 frames, ça faussait la comparaison mais le gens étaient fiers de Theora. Ici, on ne sait pas la distance maximum et la répartition moyenne des key frames de chaque fichier et vu que ce sont des encodeurs différents, je dirai juste que tu n'es pas assez précis niveau contraintes dans tes tests pour pouvoir comparer équitablement, sans savoir de quel côté tu donnes l'avantage sur ce point), mais je me concentre sur un point :
Voila, c'est bien le soucis : ça, ça va être la norme même sur le smartphones dans le prochaines années (à la vitesse où ils augmentent les pixels sur les smartphones…), et HEVC est justement taillé pour.
Du coup, j'aurai plutôt tendance à conclure que HEVC est vainqueur de ta comparaison, du moins pour le futur pas bien éloigné (et c'est ce qui compte, plus de monde qui aime le futur que le passé).
Ca ajouté au fait que tu compares "que" x265 qui est réputé certes mais n'est pas le seul encodeur H265 et que certains poutrent il parait (je n'ai toutefois pas encore pu tester, ça viendra)…
PS : mais à part Google et quelques geeks, qui fournit du contenu en VP9? H265 décolle niveau monde qui déploit et la différence va jouer dans le puissance financière pour la R&D…
[^] # Lapin compris ?
Posté par Ely . Évalué à 10.
Tu me cites disant "Pour moi, HEVC est vainqueur de cette comparaison.", puis tu rajoutes "Du coup, j'aurai plutôt tendance à conclure que HEVC est vainqueur de ta comparaison".
J'ai pas bien compris où tu voulais en venir.
Dans toutes mes comparaisons, je classe HEVC en tête, et même si ma conclusion parle un peu trop de VP9, ce n'est que pour féliciter les gens derrière VP9 parce qu'ils ont sorti un truc somme toute pas trop mal.
Je te concède le point sur les I-frames, en effet j'ai pas mis la distance entre chaque à égalité.. Et pour les autres encodeurs, j'aurais pu, oui, comparer avec f265, DivX265, etc.. Mais ça ne s'est pas fait par manque de temps notamment. L'encodage de tous les fichiers, la mise à dispo sur un serveur, les dizaines de visualisations de chaque échantillon et l'écriture de l'article m'ont pris pas mal de temps mine de rien.
[^] # Re: Lapin compris ?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 19 novembre 2014 à 23:19.
J'essaye d'être plus précis :
- tu as fais 3 tests.
- 1 test "HEVC est vainqueur de cette comparaison."
- 2 autres "HEVC fait un peu mieux"
tu en conclues "HEVC fait un peu mieux" (pour résumer, oui, bref tu trouve VP9 pas mal), je conclue de tes tests "HEVC est vainqueur de cette comparaison.", car un seul test est utile en fait (les autres sont le passé ou présent à court terme, peu utile pour l'étude de codec qui s'interesse au futur, en général on s'interesse au futur quand on parle d'un outsider, sinon quel interêt?)
C'est le seul point où je voulais en venir, ne souhaitant pas démonter le reste du journal plus que ça et voulant juste me baser sur tes tests et rien d'autre.
Bon, si il faut être plus clair (et un peu plus méchant, j'ai bien essayé de ne pas l'être trop mais tu insiste) : le temps que tu passes à le faire n'est pas une caution sur la qualité du résultat : tu peux passer 2 heures à calculer 1+1, si c'est faux (tu donnes 10 comme résultat mais qu'on a demandé en base 10 : ton réultat est juste sous conditions diveres, mais faux sur ce qui est testé), ça reste faux.
Le problème dans les tests de gens certes passionnés mais pas assez sérieux dans le tests, c'est qu'ils testent des pommes et des poires.
Ici, tu as testé les configs par défaut (à quelques paramètres près) d'encodeurs, ça ne dit pas grand chose sur les performances des encodeurs.
Tu peux passer 1000000 heures sur un protocole de test, si le protocole est faux le résultat sera juste du vent, même si ça peut te faire mal au coeur.
Ici, tu n'as pas testé des formats, mais 2 logiciels avec leurs paramètres par défaut.
Je n'ai pas de chiffres précis à te donner (oui, j'ai dit dans mon premier message que je ne prendrait pas le temps), mais pour info les scientifiques du domaine qui se sont amusés à tester VP9 en concluent plutôt que c'est mieux que AVC Main et moins que AVC High, et n'osent pas comparer à HEVC (vu que HEVC est nettement meilleur que AVC High, la conclusion…), alors que tu veux démontrer que VP9 n'est pas mauvais face à H265, il vaut quand même mieux venir blindé avec un protocole de test qui ne soit pas faux.
Désolé d'être plus méchant sur ce commentaire, mais tu as insisté en parlant de temps de travail là où cette donnée n'est absolument pas pertinente (et montre au contraire qu'il n'y a pas eu de tentative de démarche scientifique, car toute personne faisant une démarche scientifique sait que le temps passé sur un test ne dit absolument rien sur la qualité d'un test) tout en voulant aller à l'opposé de l'industrie dans tes conclusions (donc bon, ça devrait dire que tu as bien étudié, donc ton protocole est blindé). Parler de temps passé pour cautionner un résultat est le meilleur moyen de décrédibiliser un résultat.
PS : pourquoi donc tous ceux à part le promoteur du codec qui payent pour stocker et diffuser ne passent donc pas à VP9 mais passent à HEVC? Sont-ils tous idiots au point de ne pas calculer le gain financier pour leurs actionnaires à passer à VP9 pour ne pas payer la licence H265?
[^] # Re: Lapin compris ?
Posté par Ely . Évalué à 10.
Wow, je pense que tu t'emportes beaucoup trop pour un journal sur linuxfr. D'ailleurs, c'est bien de ça dont il s'agit ? Je suis plus sûr, j'ai l'impression d'avoir soumis un article en lateX à un journal scientifique.
Comme beaucoup de journaux, celui-ci a vocation de parler à ceux qui ne connaissent pas de HEVC et de VP9, de leur montrer ce qu'on peut faire avec des logiciels open-source, leurs avantages par rapport aux outils précédents, et bien sûr une comparaison modeste. Je n'ai jamais eu comme but d'en faire un test rigoureux au possible, mais cependant je ne voulais pas non plus tomber dans la désinformation en racontant n'importe quoi. Je trouve que le compromis que présente ce journal est loin d'être mauvais.
Pourtant, les vidéos AVC que je présente dans ce journal sont en High et sont bien fades par rapport à ce que propose VP9. x264 est reconnu dans le monde professionnel comme un excellent encodeur, et même si j'aurais pu obtenir 3% de qualité en plus en preset placebo, cela n'aurait pas suffi.
De plus, si tu n'as pas de chiffres précis à me donner, c'est aussi parce que des comparaisons entre VP9 et le reste, ça ne court par les rues. (et pitié, ne me parle pas de ce vieil article qui date beaucoup trop pour que ça reste vrai aujourd'hui)
J'ai toujours vu les développeurs de x264 et x265 prôner l'utilisation de presets, et qu'il n'était pas nécessaire d'essayer de "tuner" les options. Celles qui sont misent par défaut ont été bien pensées et il est souvent inutile d'aller chercher plus loin.
[^] # Re: Lapin compris ?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 20 novembre 2014 à 07:46.
OK, donc je vais faire un journal ici pour dire que Windows et 100x meilleur avec une démonstration fausse, et personne ne réagira pour dire "tu te trompes", ça sera normal et on dira juste qu'il vaut mieux parler de Linux qui est moins bien mais c'est pa grave. Oups, pardon, ça marche que dans un seul sens "pas grave", c'est quand le "libre" (sic, VP9 est aussi libre que H265) est mieux.
OK. Mais en fait, ça te dérange pas de dire des choses fausses? Ah oui, du moment où ça va dans le sens que tu aimes… Désolé, je ne gobe pas le "je croyais que".
Oui, et les comparaisons sont souvent faite avec x264, pas de soucis. Bizarrement, tu es le seul à dire que VP9 s'approche de H264 High, mais bin, tu dois avoir raison, les gens qui s'en foutent du libre et comparent techniquement, les gens passionnés (Doom9…) ou pro riolent de VP9, mais toi tu as raison.
Ceux qui s'interessent vraiment à la qualité d'encodage ont passé leur chemin comme ils l'ont fait pour Theora.
Pourquoi d'après toi? Je t'ai répondu déjà, mais si il faut être clair : car VP9 est nul. Tu veux montrer l'inverse? Vaut mieux une démarche scientifique, sinon c'est juste faire croire que.
C'est ce qui avait aussi été fait avec Theora. Sauf que Theora, ils avaient laissé aussil es presets, et il y avait des key frames à 300.
OK, j'ai compris : en fait, c'est le même mensonge que pour Theora.
PS : le pire, c'est qu'à la base, j'essayais vraiment de rester sur *tes dires pour te montrer que ton approche merdait déjà un peu, mais tu essayes quand même de te rattraper car tu y as passé du temps…
Ben… Voila, tu fais exactement de la désinformation en disant que VP9 est mieux que H264 et proche de H265, sans le prouver (tu dis maintenant que ce n'était pas le but) et sans que d'autres independants ne le prouvent ou simplement le valident.
Je peux te faire exactement le même journal avec Theora contre H265 et "montrer" que Theora s'en sort pas mal (en fait, il suffit de reprendre des jounaux LinuxFr).
Je ne comprend pas la démarche, à part y voir de la désinformation :
- Si les outils te plaisent, parler des outils (ne pas comparer les résulats)
- Si les formats te plaisent, comparer scientifiquement et faire valider par ses pairs.
Perso, je note juste que ça ne te dérange pas d'essayer de tromper les lecteurs sur les qualités supposées mais non prouvées (tu dis finalement entre les lignes toi-même que tu as rien à foutre de prouver que VP9 est bon, juste essayer de faire passer VP9 comme "pas mauvais"), et te fous de savoir si c'est pertinent. On comprend mieux pourquoi les gens pensaient que la terre était plate (note : je suis moinssé, c'est mieux que d'être au bucher comme les gens qui pensaient à l'époque que la terre était ronde).
encore une fois, je n'étais pas parti sur attaquer, juste déjà me baser sur tes dires pour expliquer qu'en 2014 regarder du 720p c'est pas vraiment ça (j'ai expliqué pourquoi), mais ensuite tu as essayé de noyer le poisson à coup de "j'ai passé du temps" qui est quand même fort comme argument quand on parle de qualité.
Sur ce, je crois que je vais passer, il y a des fois où il faut savoir abandonner quand les gens sont dans leur monde. Triste monde. des fois les librites tombent dans un délire "si, c'est bien" car d'autres se sont trompé dans leurs tests et leur ont dit "si, c'est bien", et ça ne fait que rendre ces personnes ridicules. Beaucoup on cru en VP9 à sa sortie, quasi tous ont sauté de joie pendant 3 jours, puis sont passé à autre chose quand ils ont regardé un peu plus, et depuis pas de grandes nouveautés.
[^] # Re: Lapin compris ?
Posté par patrick_g (site web personnel) . Évalué à 10.
J'ai comme l'impression que c'est plutôt toi qui part dans un délire et monte sur tes grands chevaux à propos de ce journal. Ely a clairement indiqué sa méthodologie donc il n'y a aucune raison de crier à la tentative de tromperie comme tu le fais. Que tu fasses un ou même plusieurs commentaires pour expliquer en quoi cette méthodologie ne permet pas de conclure est une chose. En revanche accuser l'auteur de désinformation volontaire, crier au complot des libristes et invoquer les bûchers moyenâgeux c'est…comment dire…un peu too much ?
[^] # Re: Lapin compris ?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 20 novembre 2014 à 08:24.
Il est très amusant de constater la différence de réaction :
- Une conclusion qui plait : les détracteurs montent sur leurs grands cheveaux, ils sont lourds, qu'ils se calment pfff
- Une conclusion qui déplait : l'auteur de l'article dit des conneries, quel idiot! Il fait de la désinformation! (pour LinuxFr, voir tous les journaux qui critiquent les articles qui disnet du mal de Linux et autres logiciels libres)
L'exemple du bucher est juste pour démontrer que sous couvert de tests "j'ai passé du temps dessus", on peut toujour sarriver à la conclusion qui nous plait, qu'importe la réalité.
Bref, encore une démonstration de belle objectivité… Je suis pressé de te lire répondre ce que tu me réponds quand ce sera un de tes poulains qui sera mis à égalité avec ce que tu considères comme mauvais.
[^] # Re: Lapin compris ?
Posté par flagos . Évalué à 4.
Et donc, l'article qui conclut qu'h265 est mieux, il rentre dans quelle catégorie ZeniFreud ?
[^] # Re: Lapin compris ?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 20 novembre 2014 à 08:38.
Tu peux pas imaginer comment je me fous complet de qui gagne.
Je suis un scientifique, la science m'interesse, uniquement elle. Et du coup les comparaisons honnêtes, objectives, sont mes critères.
Maintenant, je constate qu'ici il suffit de faire un test à l'arrache faux pour faire plaisir (du moment qu'il va vers le libre, pardon vers un semblant de libre VP9 étant aussi libre que H265 mais on ne sait pouruqoi les libristes aiment), je n'ai peut-être effectivement pas ma place ici.
Note qu'au passage j'ai répondu bien plus posément dans mon 1er commentaire, sur un sujet bien précis, mais bizarrement il a été "oublié" pour aller défendre le pauvre petit VP9 en masse. "Etonnant"…
PS : pour information, j'ai été dans les premiers à m'exctasiser d'avoir Google qui sort un codec bon et libre. Juste que comme tous les autres, après j'ai vu qu'il n'était ni bon ni libre, c'est tout. C'est dommage, mais je sais que tu ne vas pas me croire quand je dis que c'est dommage, car si j'explique en quoi le test du journal est faux, c'est que je suis anti-VP9. Si tu n'es pas avec moi, tu es contre moi, j'avias oublié, désolé.
[^] # Re: Lapin compris ?
Posté par flagos . Évalué à 9.
Au sujet des key frame, ce n'est une réponse précise, tu émet juste un doute sans fournir aucune preuve. Autant, le réglage des key frame est en défaveur de VP9, bref on en sait rien.
Et a ce sujet, il t'a été répondu que ce sont les presets qui ont été utilisés, et que c'est la méthode recommandé par le comité car elle est censée être optimale, y compris sur le réglage des key frame. Ce à quoi on attend toujours une réponse de ta part.
[^] # Re: Lapin compris ?
Posté par benoar . Évalué à 10.
Et au lieu de troller méchamment, tu pourrais pas lui suggérer plutôt un ou deux flags en ligne de commande à modifier/ajouter ? Je suis sûr que ça ne te prendrait pas beaucoup plus de temps que d'écrire tes commentaires… (tu peux même lui conseiller d'aller vérifier des infos avec ton soft, ça te fera de la pub et tout le monde sera content !)
[^] # Re: Lapin compris ?
Posté par flagos . Évalué à 10. Dernière modification le 20 novembre 2014 à 08:30.
Et pour revenir sur le sujet, tu penses quoi de l'utilisation des presets par le comité pour annoncer qu'h265 est 2fois plus performant qu'h264 ?
Je pose la question parce que manifestement, ça te gêne qu'on utilise les presets aujourd'hui.
[^] # Re: Lapin compris ?
Posté par flagos . Évalué à 10.
Mec, t'es lourd. Tu pourrais être un peu constructif ? Quel que soit le sujet que tu abordes, tu es inutilement agressif. Et pas que sur ce sujet, c'est quasiment tous les threads qui sont pollués par tes commentaires haineux.
Tu pourrais simplement objecter les ponts de sa comparaison qui ne sont pas juste plutôt que pourrir un mec qui nous partage ses resultats de manière intéressante et reproductible.
[^] # Re: Lapin compris ?
Posté par Larry Cow . Évalué à 4.
C'est un peu ce qu'il a commencé par faire, non? Ce à quoi le
nous explique que sa méthode n'avait pas vocation à nous fournir des résultats pertinents (ce qu'il aurait pu mentionner dès le journal pour couper court à toute critique).
[^] # Re: Lapin compris ?
Posté par flagos . Évalué à 7.
Les resultats ne sont pas pertinents si on cherche a faire une publication dans une revue scientifique. Oui je suis d'accord. Mais l'auteur précise que ce test n'est pas non plus malhonnête car il se base sur les recommandations du comité.
Et sur cette réponse, à mon sens plutôt juste et réfléchie, que Zenitram s’énerve et met a le pourrir au delà du raisonnable. Non désolé, j'ai beau relire, c'est du grand n'importe quoi cette réaction, ca n'est pas justifié.
[^] # Re: Lapin compris ?
Posté par Albert_ . Évalué à 10. Dernière modification le 20 novembre 2014 à 10:17.
Je n'ai pas de chiffres précis à te donner
A partir du moment ou il critique tout et n'importe quoi en rajoutant en plus la phrase du dessus. Tu m'excuseras mais oui il perd son droit a la critique et obtient son droit au moinssage.
Des le premier message il est, inutilement, agressif et desagreable. Il y a des facon de faire et d'ecrire plus ou moins aimable (correcte) et Zenitram ne comprend pas cela. Je trouve l'auteur du journal tres calme dans ses reponses. Comme il le dit lui meme cet article dans un journal linuxfr n'a pas vocation a etre scientifique. Si Zenitram veut prouver la meme chose (l'auteur de ce journal ne met pas vp9 en tant que vainqueur) il peut le faire de facon scientifique avec un journal aussi detaille et decrivant la methode et pas uniquement en venant et disant "tu dis de la merde moi j'ai raison mais j'ai pas de chiffre mais j'ai raison et tu dois me croire!".
[^] # Re: Lapin compris ?
Posté par NumOpen . Évalué à 6.
Zenitram a encore frappé ! Ça devient systématique sur tous les posts.
[^] # Re: Lapin compris ?
Posté par FantastIX . Évalué à 2.
Re-devient.
-->[]
[^] # Re: Lapin compris ?
Posté par Ely . Évalué à 10.
Bon c'est la dernière fois que je te répondrai puisque tu es trop buté, et que malgré toute ta prose, je ne vois pas un seul lien bleu dans tes commentaires pour appuyer tes dires.
Tes seules preuves, c'est "je suis un scientifique" et tu parles au nom de tous les scientifiques en disant des trucs du style "les scientifiques du domaine qui se sont amusés à tester VP9 en concluent plutôt que c'est mieux que AVC Main et moins que AVC High".
Bein désolé mais non, ça passe pas, pas sans une source. Tu justifies ça par "je ne prendrai pas le temps de trouver des sources", dans ce cas ne prends pas le temps de faire un commentaire et passe direct ton chemin.
Tu as une haine pour VP9 et rien ne semble pouvoir te faire changer d'avis. D'ailleurs, je ne sais même pas si tu as pris la peine de regarder les vidéos. C'est une opinion que tu t'es forgée il y a plusieurs années et tu n'as pas regardé comment ça a évolué depuis.
Malgré les paragraphes de textes qui visent le manque de rigueur de l'encodage de mes vidéos, tout ce que j'ai retenu c'est que "j'ai pas mis un interval régulier entre les I-frames".
Alors je suis allé regarder dans les vidéos crowd_run :
Pour finir, je te retourne ta citation d'un message plus loin :
Car en attendant, moi j'ai des vidéos valides à te montrer où VP9 bat clairement AVC, et toi tu ne prends même pas la peine de regarder et tu me sors des arguments vieillos que tu refuses de remettre en question.
[^] # Re: Lapin compris ?
Posté par barmic . Évalué à 10.
Tu dérive complètement. T'es passé de "j'aimerais bien avoir plus d'info sur ton protocole de test" à "t'es qu'un gros connard de libriste communiste communautaire barbu lancé dans une fatoua".
Tu peut dire des choses intéressantes, mais ça pourrait être sympa que tu fasse la part des choses de temps en temps et que tu défoule avec un peu de sport plutôt qu'à faire le rageu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lapin compris ?
Posté par reynum (site web personnel) . Évalué à 4.
J'en connais d'autres qui ont fait de cette phrase leur naturel quotidien.
kentoc'h mervel eget bezan saotred
[^] # Re: Lapin compris ?
Posté par eingousef . Évalué à 10.
Salut Ely, je te présente Zenitram o_
Aujourd'hui, il n'est pas content parce que ce joli journal sur les formats vidéo, c'est pas lui qui l'a écrit.
Alors il râle. Du coup il se fait moinsser. Alors il râle encore plus. Tu vas apprendre à le connaître.
En tout cas merci pour ton chouette travail ! \o_
*splash!*
[^] # Re: Lapin compris ?
Posté par reynum (site web personnel) . Évalué à 6.
Comme tu es un spécialiste :
Y a t il un ou plusieurs points communs entre ce comportement et celui d'un Putain d'ornithorynque ? :-D
kentoc'h mervel eget bezan saotred
# Inadmissible
Posté par dwd . Évalué à 8.
Inadmissible d'avoir feint d'oublier le codec qui les enterrera tous : I2BP !
[^] # Re: Inadmissible
Posté par BAud (site web personnel) . Évalué à 3.
mieux vaut redonner un historique sur cette histoire d'i2bp qui ne parlerait que peu à ceux n'étant pas là au début du siècle :)
même la poudre verte est plus connue (à raison).
[^] # Re: Inadmissible
Posté par cosmocat . Évalué à 5.
Ben c'est un peu normal car la poudre verte était là avant i2bp et comme la poudre verte résoudre tous les problèmes de réseau, il n'y a donc plus besoin d'avoir un codec performant ! CQFD.
# Première image
Posté par Naha (site web personnel) . Évalué à 4.
Je n'ai pas regardé les vidéos, mais sur la première image mon impression est opposée à ta conclusion : juste à droite de la ligne de démarcation entre les deux codecs, côté HEVC donc, on voit de gros applats de couleur moches dans l'arbre (et sous l'arbre, au-dessus des gens). L'herbe en arrière plan semble aussi moins détaillée à droite qu'à gauche, mais c'est moins comparable.
[^] # Re: Première image
Posté par Ely . Évalué à 2.
En effet, le screenshot n'est pas des plus flatteurs pour HEVC. Je t'invite cependant à regarder les deux vidéos - voire le side-by-side si tu peux télécharger 70mo -, là tu saisiras mieux la différence, notamment au niveau des coureurs mais aussi de l'arrière-plan.
[^] # Re: Première image
Posté par Naha (site web personnel) . Évalué à 2.
J'ai regardé le « side-by-side » (côte à côte ?), mais ce n'est pas évident de voir de différence sur ma babasse (un poil trop lente pour lire la vidéo de manière fluide). Par contre on voit bien que l'applat moche dans l'arbre apparaît aussi du côté VP9 au début de la vidéo, donc la capture d'écran est effectivement trompeuse.
[^] # Re: Première image
Posté par Sufflope (site web personnel) . Évalué à 2.
Ce que je vois surtout c'est que même sur mon écran pourtant seulement Full HD (et comme dirait Zenitram, ça c'est le passé/présent seulement) les deux sont sacrément dégueulasses. Alors que VP9 "gagne" en sentant juste un peu moins la fiente, ça me fait une belle jambe.
[^] # Re: Première image
Posté par Ely . Évalué à 1.
Les bitrates choisis sont volontairement "trop bas" pour exposer les faiblesses des deux formats. Pour du 4K@50 sur un exemple aussi difficile que crowd run, il aurait fallu facile 13-15k.
# Cadeau
Posté par Rolinh (site web personnel) . Évalué à 8.
Je m'étonne que ton seul moyen de comparaison soit de type visuel. L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.
Bref, cela aurait été pertinent d'utiliser quelques métriques tels que le PSNR ou SSIM bien que ces méthodes aient aussi leurs défauts. VQMT te permet de les calculer, ainsi que d'autres, et fournit les résultats dans des fichiers CSV. Il prend en paramètre la vidéo original en YUV et comme deuxième paramètre, la vidéo que tu auras encodé puis re-décodé.
Sinon, comme cela a déjà été relevé, il y a beaucoup de paramètres à prendre en compte pour que la comparaison vaille la peine. Je veux dire par là que cela devient extrêmement complexe étant donné le nombre de paramètres et configurations possibles, trop complexe sans doute pour un simple journal LinuxFR. Par exemple, avoir le même intervalle entre les I-frames semble essentiel mais cela ne suffit pas. Il faudrait faire des tests avec différents GOP (Group Of Pictures) (tout en sachant que plus tu as d'I-frames, plus tu fais tomber le bitrate car une I-frame requière plus de ressources pour l'encodage qu'une P-frame ou B-frame). Mais encore, jouer sur les I-frames n'est vraiment utile que si tu veux tester le random access de tes vidéos.
D'autres aspects sont à considérer. Par exemple, la valeur du QP (Quality Parameter). C'est le jour et la nuit entre une valeur de 0 (lossless) ou une valeur élevée (40 et plus) (le range habituellement utilisé se situe ente 18 et 28 en général, 18 étant considéré visuellement lossless). Tu peux aussi jouer sur l'encoder level, l'encoding profile, l'utilisation ou non de B-frames, l'ordre de placement de tes frames dans un GOP, etc. C'est tout un sujet :)
Bref, ma conclusion est que ton journal est intéressant mais que d'après ton protocole de test, il est impossible de désigner un vainqueur de manière objective.
[^] # Re: Cadeau
Posté par flagos . Évalué à 8.
Au contraire. On ne développe plus les codecs en se basant sur de telles métriques car elles conduisent a de mauvais algos. Une image avec un bon résultat en PSNR pourra être ressentie comme moche pour l'oeil humain alors qu'une image avec un PSNR plus éloignée pourra etre percue comme plus agréable. Cela vient de l'utilisation d'algos de filtrage qui plutot que de se rapprocher du yuv initial cherche plutot a gommer les efets de la compression et rendre l'image plus naturelle.
Il a targette un bitrate. C'est ce qu'on utilise aujourd'hui pour définir implicitement le QP. La comparaison est plutot honnete sur ce point.
Tout a fait. C'est pour ca qu'il est parti des encodeurs de référence et qu'il a utilisé les presets. On peut lui reprocher de ne pas creuser (Zenitroll a foncé dedans) mais comme tu dis, c'est tout un sujet. Et si les presets ne sont pas pertinents, c'est quand même aux comités respectifs de se remettre en cause.
On peut effectivement trouver parcellaire cette comparaison, je trouve qu'il est quand même pertinent d'utiliser les paramètres par défauts de l'encodeur (sans passer 10 ans à tout optimiser) et voir lequel se comporte le mieux. Ca donne une idée générale de la qualité algorithmique de chacun des encodeurs.
[^] # Re: Cadeau
Posté par Anonyme . Évalué à 6.
Il a ciblé ?
[^] # Re: Cadeau
Posté par TImaniac (site web personnel) . Évalué à 10.
En même temps c'est le but d'une vidéo non ? Donner une illusion de réel en mouvement à ta rétine.
[^] # Re: Cadeau
Posté par Frank-N-Furter . Évalué à 10.
Ce qui compte c'est que ça satisfasse des algorithmes, comme ça quand les IA contrôleront le monde et que les humains auront disparu, elles auront des vidéos correctement encodées à regarder.
Depending on the time of day, the French go either way.
[^] # Re: Cadeau
Posté par Albert_ . Évalué à 5.
Je m'étonne que ton seul moyen de comparaison soit de type visuel. L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.
Enfin on a pas encore reussi a faire un systeme de mesure aussi performant que l'oeil et je ne sais pas mais moi j'utilise mes yeux pour voir une video donc utiliser cela comme comparaison c'est pas si mal que cela. L'empirisme n'est pas a jete a la poubelle loin de la!
[^] # Re: Cadeau
Posté par Larry Cow . Évalué à 3.
Oui, enfin dans ces cas-là faut pas se limiter à une paire d'yeux. Parce que la vidéo, elle va surement être encodée pour un nombre relativement élevé d'humains, et ça vaudrait le coup d'avoir une idée de sa perception moyenne sur un échantillon représentatif.
Ou alors de se baser sur un modèle mathématique, qui est finalement un meilleur compromis.
[^] # Re: Cadeau
Posté par Albert_ . Évalué à 3. Dernière modification le 20 novembre 2014 à 17:03.
Je ne suis pas d'accord avec toi. Un modele mathematique n'arrive pas, aujourd'hui, a faire ce que l'on fait avec l'oeil. Il suffit de regarder les projets tel que galaxy zoo pour s'apercevoir que au final on est encore obliger de passer par l'humain car cela marche mieux. Je ne dis pas que des logiciels ne peuvent pas aider ni faire certains trucs automatiquement mais l'oeil humain est encore tres tres superieur. Cela peut choquer mais pourtant c'est la realite.
[^] # Re: Cadeau
Posté par Larry Cow . Évalué à 4.
Je n'ai pas dit que l’œil ne faisait pas mieux (au contraire, il me semble), mais simplement que la disparité des paires d'yeux rendait extrêmement coûteux et complexe une approche purement oculaire pour discuter des qualités comparés de traitements automatique d'image.
Si tu veux faire un algo de compression d'image (qui bouge ou pas) pour une paire d'yeux, c'est relativement facile : tu fais un bon stock d'images de test, tu mets côte-côte des versions différentes, et tu laisse l'humain choisir. Bon, c'est pas non plus de la tarte, sauf si en plus de n'avoir qu'une cible tu n'as qu'une image à compresser. Mais si tu es prêt à passer un peu de temps avec tes échantillons ça peut le faire.
Dès lors que tu veux - et c'est un tout petit peu le propos des algos dont on parle dans ce journal - faire ça pour des algos qui vont compresser des vidéos quelconques, à destination d'à peu près tout le monde, ça devient tout simplement ingérable. Dans ces cas-là, l'approche mathématique donnera peut-être de moins bons résultats particuliers, mais de meilleurs résultats moyens.
D'autant que les modèles ne sont pas complètement décorrélés des résultats humains, ce qui est probablement la raison pour laquelle on ne s'est pas contenté de PSNR et qu'on a développé SSIM.
[^] # Re: Cadeau
Posté par Albert_ . Évalué à 4. Dernière modification le 21 novembre 2014 à 11:12.
Je ne sais pas pourquoi mais je suis pret a parier que le premier test que fait quelqu'un sur un algo de compression d'image/video sera avec son oeil car c'est hyper rapide et ca marche! Apres si tu veux publier et tenter de convaincre il va falloir sortir des chiffres et donc mettre au point des tests qui sont (au moins pour le moment) tres incomplet par rapport a la masse d'information et d'analyse que te donne ton oeil et ton cerveau.
De plus comparer a galaxy zoo faire des statistiques sur un algo de compression c'est … facile. Prendre un echantillon representatif de personne et leur faire regarder plusieurs videos c'est pas bien difficile et au final ce que ressent l'humain sera toujours plus important que ceux que va te donner ton test automatique qui sera biaise car fait en fonction des gouts ou des pre-conception de son concepteur.
Que les modeles soient correles avec l'oeil je te dirais heureusement car ils ont ete fait pour et si ils ne l'etaient pas cela serait de joli jouet inutile.
[^] # Re: Cadeau
Posté par fearan . Évalué à 3.
Et surtout comme tout mécanisme de notation mis en place sur un sujet aussi complexe, il se périme vite, un peu comme lorsque l'URSS calculait le rendement d'une usine de lustre par le poids en sorti d'usine.
Lorsque la mesure a été mise en place, c'était un bon indicateur, ou du moins il y'avait une bonne corrélation.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Cadeau
Posté par Ely . Évalué à 5.
Pourtant, je ne trouve pas les paramètres d'encodage de mes vidéos si nazes que ça.
J'ai regardé pour la vidéo crowd_run, voici les résultats :
Lors d'un encodage en 2 passes, le QP est recalculé de façon optimale pour chaque frame selon ce qu'elle a besoin, afin de satisfaire le bitrate moyen. Pas de problème là-dessus donc.
Les "level", c'est juste des contraintes en dimension et en bitrate qui permettent de certifier les décodeurs. On ne peut pas "changer" le level depuis un encodeur, puisque tout dépend de la résolution et du framerate du contenu.
HEVC n'a que Main pour le moment, et j'ai utilisé High pour H.264. Bref, les paramètres optimaux.
Mon but n'étant pas de tester la low-latency, je n'ai pas vu d'utilité à désactiver les B-frames.
Je te concède ce point, même s'il faudrait regarder ce qui a été produit dans les vidéos..
[^] # Re: Cadeau
Posté par moi1392 . Évalué à 9.
N'est-ce pas un des objectifs d'un codec de compression ? Tromper au maximum l'œil (ou l'ouie) pour pouvoir éliminer le plus possible de détails tout en restant subjectivement le plus agréable possible à regarder ?
[^] # Re: Cadeau
Posté par xcomcmdr . Évalué à 2.
Ben oui c'est ce qu'on fait depuis longtemps (améliorations psychovisuelles - Adaptive Quantization/Lumi masking -, http://www.gromkov.com/faq/conversion/xvid_options.html…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Re-
Posté par Kurtnoise . Évalué à 3. Dernière modification le 20 novembre 2014 à 11:53.
Alors, je t'invites a refaire cette partie de ton journal car l'encodeur x264 a un mode lossless :
x264 --qp 0 --preset slower input -o output
CRF@19 n'est pas sans perte, malheureusement. Donc, les aperçus visuels ne servent pas a grand chose, ici.
[^] # Re: Re-
Posté par Ely . Évalué à 3.
Le problème c'est que le mode lossless va générer des fichiers énormes. CRF 19 était un bon compromis pour avoir un mode "quasi sans pertes visuelles".
Ceux qui ont ffmpeg peuvent cependant faire la manip manuellement pour avoir du true lossless. Exemple avec old_town :
Je garantis rien, mais ça devrait fonctionner avec avconv/avplay.
# Bitrate Derivation
Posté par Kurtnoise . Évalué à 2.
Un autre point intéressant…tu utilises le mode en 2 passes. Il est donc judicieux de voir le débit moyen obtenu pour chaque compresseurs afin de voir si le débit choisi est bien respecté (modulo, le fait du choix des samples encodés).
Pour Crowd Run / Débit demandé = 7150 Kbps :
Pour Pedestrian / Débit demandé = 1050 Kbps :
Pour Old Town Cross / Débit demandé = 800 Kbps
Donc, je vous laisse conclure…:-)
# libde265 pour VLC
Posté par Minux13 . Évalué à 2.
Pour celles et ceux qui veulent voir les vidéos encodées en H265 sur Ubuntu (ou Debian) avec VLC (ou GStreamer) il existe un dépôt PPA avec les plugins adéquats :
https://launchpad.net/~strukturag/+archive/ubuntu/libde265
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.