Le topic de l'encodage vidéo, où on aime (s')encoder

[Rocca]

Pas plus que ça hormis que la hype semble justifié de ce que j'ai pu croiser comme info de ci de là, d'après Wiki :


Avec deux tests en sources :

https://datatracker.ietf.org/doc/htm...dec-results-03
http://listening-test.coresv.net/results.htm

Au vu des courbes dans ces papiers, clairement, Opus est bien plus haut que le mp3 et un peu plus haut que le reste. Bref, ça semble être le gagnant du moment pour remplacer le son avec perte.



Sur les animés par exemple, c'est devenus assez courant H265/Opus . Je ne dirais pas que c'est systématique, mais de très anecdotique/curiosité ça s'installe doucement dans le paysage cette dernière année.

Merci pour les infos, même si d'après les infos que j'ai trouvé, le vorbis est supérieur au AAC (pas le cas dans ton test numéro2).

Je vais voir pour ce Opus, j'encodais en Vorbis, mais si c'est mieux pour la même taille, pourquoi pas.

En parlant de cela, quelqu'un a-t-il tenté le AV1 avec HandBrake (version 1.6.0) ? De ce que je vois ça sera avec le CPU, ce qui ne me dérange pas, mais je me demandais si c'est au point. Vu que d'après ton lien plus haut, ça fait au moins deux ans qu'ils ont eu le temps de peaufiner le codec...

[tompalmer]

AAC c'est du mp3 avec du vernis a ongle hein

- - - Mise à jour - - -

En parlant de cela, quelqu'un a-t-il tenté le AV1 avec HandBrake (version 1.6.0) ? De ce que je vois ça sera avec le CPU, ce qui ne me dérange pas, mais je me demandais si c'est au point. Vu que d'après ton lien plus haut, ça fait au moins deux ans qu'ils ont eu le temps de peaufiner le codec...

On en a parlé plus haut, j'ai fait qu'un essai et c'etait moins bien que H265 en taille, temps passé a convertir et meme qualité

[Rocca]

AAC c'est du mp3 avec du vernis a ongle hein

- - - Mise à jour - - -

On en a parlé plus haut, j'ai fait qu'un essai et c'etait moins bien que H265 en taille, temps passé a convertir et meme qualité

J'ai vu. Mais bon un essai sur le coin d'une table c'est loin d'être représentatif

Pour le AAC, c'est pas ce que disent les tests. Le MP3 et à chier, mais le AAC non.

[tompalmer]

Je t'en refait un :

Source = Video Iphone de 12 secondes en 4k, débit de 49 mbps, source H265, framerate variable en passthrough (tout comme l'audio)

Encodage en RF 20, profil Veryslow, avec un 5900x

Source : 70,2 Mo
Av1 : 50,1 Mo 01:18:48
H264 : 62,9 Mo - 01:36
H265 : 49,7 mo - 10:25

A noter que l'AV1 a un setting de pré réglage de l'encodeur qui va de 12 a 0, j'ai mis a 1 je pense que c'est a ne pas faire.

Handbrake a tendance a pas utiliser tout le processeur pour l'AV1, donc il y a de la marge pour optimiser, ca oscille de 17 à 90 %
Par contre je sais pas ce qui fait avec la RAM, il me prend 12,6 Gb pour encoder une chiure du mouche, c'est du grand n'importe quoi.

Du coup pour conserver tes Blue ray, je pense que c'est pas le codec de choix sans Hardware acceleration.

Deuxième experience avec des settings plus standards sur la meme vidéo : Encodage en RF 20, profil Medium (ou 6)

Source : 70,2 Mo
Av1 : 46 Mo 01:23
H264 : 65,5 Mo - 00:22
H265 : 41 mo - 00:42
H265 GPU : 29 mo - 00:10


Voila Voila, donc au mieux ca égale le H265, mais ca peut être moins bien.
Vu les temps de traitements a ce jour, je vois pas l'utilité pour le grand public. Mais ca peut tres bien etre l'integration d'handbrake qui pue du cul

- - - Mise à jour - - -

Pour le AAC, c'est pas ce que disent les tests. Le MP3 et à chier, mais le AAC non.

Ca depend du Bitrate, a partir de 192 tu fais plus trop la différence

[XWolverine]

Plus souvent du DDL (souvent légal d'ailleurs) et du Torrent maintenant. C'est pas tant pour la connexion le soucis, c'est pour le stockage. Si tout tes épisodes font 1Go et que tu veux l'intégrale de One Piece, je te laisse compter ce que ça te coute en disque dur ...

Les 1er épisodes de One Piece ne peuvent pas faire 1Go, vu la qualité à cette époque.

Perso, je pleure, parce que je ne peux pas tout réencoder en h265 (animés, séries, films, près de 9To), mon NUC qui sert de lecteur multimédia sur la TV est trop vieux et saccade méchamment sur le h265

[tompalmer]

Les 1er épisodes de One Piece ne peuvent pas faire 1Go, vu la qualité à cette époque.

Perso, je pleure, parce que je ne peux pas tout réencoder en h265 (animés, séries, films, près de 9To), mon NUC qui sert de lecteur multimédia sur la TV est trop vieux et saccade méchamment sur le h265

C'est pas ton nuc le probleme, c'est la TV. Quand tu aura un modele qui lira le H265 tu pourra faire du Direct Play.

Le transcodage c'est le mal

[Rocca]

Je t'en refait un :

Source = Video Iphone de 12 secondes en 4k, débit de 49 mbps, source H265, framerate variable en passthrough (tout comme l'audio)

Encodage en RF 20, profil Veryslow, avec un 5900x

Source : 70,2 Mo
Av1 : 50,1 Mo 01:18:48
H264 : 62,9 Mo - 01:36
H265 : 49,7 mo - 10:25

A noter que l'AV1 a un setting de pré réglage de l'encodeur qui va de 12 a 0, j'ai mis a 1 je pense que c'est a ne pas faire.

Handbrake a tendance a pas utiliser tout le processeur pour l'AV1, donc il y a de la marge pour optimiser, ca oscille de 17 à 90 %
Par contre je sais pas ce qui fait avec la RAM, il me prend 12,6 Gb pour encoder une chiure du mouche, c'est du grand n'importe quoi.

Du coup pour conserver tes Blue ray, je pense que c'est pas le codec de choix sans Hardware acceleration.

Deuxième experience avec des settings plus standards sur la meme vidéo : Encodage en RF 20, profil Medium (ou 6)

Source : 70,2 Mo
Av1 : 46 Mo 01:23
H264 : 65,5 Mo - 00:22
H265 : 41 mo - 00:42
H265 GPU : 29 mo - 00:10


Voila Voila, donc au mieux ca égale le H265, mais ca peut être moins bien.
Vu les temps de traitements a ce jour, je vois pas l'utilité pour le grand public. Mais ca peut tres bien etre l'integration d'handbrake qui pue du cul

- - - Mise à jour - - -



Ca depend du Bitrate, a partir de 192 tu fais plus trop la différence

Merci pour ces infos.

J'ai testé hier sur un épisode d'une série en 1080p. Temps d'encodage d'environ 50% supérieur, avec les mêmes paramètres juste changé H265 10 bit par AV1(SVT). Au final, dossier de taille similaire au H265.

Effectivement, le gain de place à qualité équivalent, c'est pas pour tout de suite

- - - Mise à jour - - -

Handbrake a tendance a pas utiliser tout le processeur pour l'AV1, donc il y a de la marge pour optimiser, ca oscille de 17 à 90 %
Par contre je sais pas ce qui fait avec la RAM, il me prend 12,6 Gb pour encoder une chiure du mouche, c'est du grand n'importe quoi.

Juste pour info, en H265 c'est aussi le cas et encore plus en H264, mon CPU (R7 2700X) n'est jamais à fond.

Du coup, je ne sais pas si vous avez vu, mais vous pouvez lancer plusieurs "tâches" donc encodages en même temps. Si tu as plusieurs épisodes à faire, le gain en temps n'est pas négligeable.

[tompalmer]

Juste pour info, en H265 c'est aussi le cas et encore plus en H264, mon CPU (R7 2700X) n'est jamais à fond.

Du coup, je ne sais pas si vous avez vu, mais vous pouvez lancer plusieurs "tâches" donc encodages en même temps. Si tu as plusieurs épisodes à faire, le gain en temps n'est pas négligeable.

En H265 il me bloque tout le PC

Et j'ai Deja essayé les encodages parallèles, j'avais eu un bug donc maintenant je fais un par un. Je sais pas si le gain de temps est réel vu que chaque tache se divise le temps de processeur

[XWolverine]

C'est pas ton nuc le probleme, c'est la TV. Quand tu aura un modele qui lira le H265 tu pourra faire du Direct Play.

Le transcodage c'est le mal

Non, pas de transcodage, les fichiers sont stockés sur le NAS, le NUC ne fait qu'executer Kodi pour gérer la bibkiotheque, lire les fichiers et envoyer vers la TV et l'ampli.
Même si ma TV gère le h265, ça ne suffirait pas pour supprimer le NUC.

[Squarealex]

Pour illustrer le problème que je rencontre actuellement avec le x265 sous handbrake.


Je fais en général des test de 60 sec sur les codecs pour voir s'ils me plait par rapport à la qualité / poids. Et de ce fait, même pour les film tourné en numérique, j'ai assez du mal avec le x265.

Je vous montre cette scène par exemple avec différent screenshot. (L'image est zoomé)

https://i.imgur.com/3c4imU7.png
https://i.imgur.com/tfXsA7o.png
https://i.imgur.com/HPHTaCz.png
https://i.imgur.com/HRudD7T.png
https://i.imgur.com/YVAX17c.png


- Le premier est le Blu-Ray, donc "pur"
- Le second est le x264 10 bit avec un RF à 18.5 avec le profil Grain d'activé.
- Le troisième est le x264 10 bit avec le RF à 21 et le profil Grain d'activé.
- Le quatrième est le x265 10 bit avec le RF à 21 et le profil Grain d'activé.
- Et le dernier est le x265 10 bit avec le RF 21 sans profil sélectionné.

Si je devais les classer par ordre de qualité ça serait : BluRay > x264 18.5 > x265 21 Grain - x264 21 Grain (le x265 Grain fait mieux mais à des faiblesse sur certaine partie d'image là ou le x264 21 Grain n'a pas ) >>>>>> x265 21 sans profil

Maintenant, pour le poids c'est encore plus surprenant.

Pour 60 secondes de vidéos de cette scène sombre on a :


14 Mo pour le x264 RF 18.5 Grain soit 1.6 Go pour 2h de film

2.74 Mo pour le x264 RF 21 Grain soit 328 Mo pour 2h de film

23.6 Mo pour le x265 RF 21 Grain soit 2.8 Go pour 2h de film

3.86 Mo pour le x265 RF 21 sans profil soit 463 Mo pour 2h de film

Bien évidemment le film ne reste pas 2h sur la même scène, mais ce n'est qu'a titre d'indication de la différence de poids.

Maintenant, sur une autre scène "clair" le poids et beaucoup plus différent est lourd (normal)...
Mais la différence en terme de poids est identique au précédent.


49.2 Mo pour le x264 RF 18.5 Grain soit 5.9 Go pour 2h de film

18.1 Mo pour le x264 RF 21 Grain soit 2.17 Go pour 2h de film

58.6 Mo pour le x265 RF 21 Grain soit 7.03 Go pour 2h de film

13.2 Mo pour le x265 RF 21 sans profil soit 1.57 Go pour 2h de film

Le soucis... c'est que pour garder les détail quand y a peu de grain... Le x265 Grain fait mieux mais le poids est abusé...., en particulier dans les scène à forte dominance rouge/bleu, comme ici

(l'ordre est pareil que plus haut)

https://i.imgur.com/QdU2WNV.png
https://i.imgur.com/CLrbIff.png
https://i.imgur.com/Wb9I1Bt.png
https://i.imgur.com/564T3Mq.png
https://i.imgur.com/TiJ7OHQ.png

Là on voit clairement que le x265 Grain est le plus proche du BluRay...

Le x264 en RF 21 écrase le x265 sans profil, ce dernier est le pire niveau qualité d'image.


L'idéal c'est que je test le x265 Grain en augmentant le RF pour voir si le poids diminue, mais je suis persuadé qu'il va faire pire que le x264 RF 18.5 a un poids toujours aussi élevée...

Du coup... je bloque... je sais même plus si je dois partir sur du x264 10 bit ou trouver une commande / suffixe miracle sur le x265 10 bit... parce qu'en l'état... c'est un gros nom pour tout passer en x265.

[Rocca]

Si cela peut t'aider, j'avais plusieurs tests (avec graphiques...) et mis des liens vers quelques explications.

ICI

[Nilsou]

En parlant de cela, quelqu'un a-t-il tenté le AV1 avec HandBrake (version 1.6.0) ? De ce que je vois ça sera avec le CPU, ce qui ne me dérange pas, mais je me demandais si c'est au point. Vu que d'après ton lien plus haut, ça fait au moins deux ans qu'ils ont eu le temps de peaufiner le codec...

Bah c'est au point, c'est juste que pour le moment il n'y a pas encore de décodeur hardware partout en standard. Les premiers seront dans la prochaine génération de CG.
Donc pour le moment c'est tout en CPU. À toi de voir selon ton cas d'usage.

[tompalmer]

Il y a déjà dans les CG de cette année

[Nilsou]

Oui pardon, en effet, pour moi c'était « la prochaine génération »
Je suis à la bourre.

[Nilsou]

Je t'en refait un :

Source = Video Iphone de 12 secondes en 4k, débit de 49 mbps, source H265, framerate variable en passthrough (tout comme l'audio)

Encodage en RF 20, profil Veryslow, avec un 5900x

Source : 70,2 Mo
Av1 : 50,1 Mo 01:18:48
H264 : 62,9 Mo - 01:36
H265 : 49,7 mo - 10:25

A noter que l'AV1 a un setting de pré réglage de l'encodeur qui va de 12 a 0, j'ai mis a 1 je pense que c'est a ne pas faire.

Handbrake a tendance a pas utiliser tout le processeur pour l'AV1, donc il y a de la marge pour optimiser, ca oscille de 17 à 90 %
Par contre je sais pas ce qui fait avec la RAM, il me prend 12,6 Gb pour encoder une chiure du mouche, c'est du grand n'importe quoi.

Du coup pour conserver tes Blue ray, je pense que c'est pas le codec de choix sans Hardware acceleration.

Deuxième experience avec des settings plus standards sur la meme vidéo : Encodage en RF 20, profil Medium (ou 6)

Source : 70,2 Mo
Av1 : 46 Mo 01:23
H264 : 65,5 Mo - 00:22
H265 : 41 mo - 00:42
H265 GPU : 29 mo - 00:10


Voila Voila, donc au mieux ca égale le H265, mais ca peut être moins bien.
Vu les temps de traitements a ce jour, je vois pas l'utilité pour le grand public. Mais ca peut tres bien etre l'integration d'handbrake qui pue du cul

Tu tire trop vite tes conclusions je pense. Les paramètres entre les encodeurs varient considérablement, le RF n'a aucun lien entre différents encodeurs et il faut des mesures complexe perceptuelles pour établir des paramètres équivalents.

Lire par exemple :
https://www.repo.uni-hannover.de/bit...pdf?sequence=1

Ou les pages d'infos de ffmpeg :

https://trac.ffmpeg.org/wiki/Encode/H.264
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/AV1

On peut par exemple se baser sur les classiques mesures perceptives que sont le SSIM ou le VMAF de Netflix :
Lire :
https://netflixtechblog.com/toward-a...c-653f208b9652
https://ottverse.com/calculate-psnr-...-using-ffmpeg/

Si je fais un test rapide sur un bout de vidéo lossless, voici mes résultats si je prends les recommandations de ffmpeg qui sont issues des papiers de recherche, soit :

H264 à crf 23 <=> H265 à crf 28 <=> AV1 à ?

Pour trouver le crf équivalent sur svt av1 là je fais un test rapide en calculant le VMAF de Netflix sur la vidéo entre H264 et H265 d'un coté et entre H264 et AV1 de l'autre. Pour H265 j'obtiens 80% de vmaf sur mon réglage à crf 28 (ce qui est pas fou en fait, on peut déja en déduire que crf 28 selon les recommandation pour h265 c'est un peu optimiste sans doute).
Pour AV1, même à un crf très haut comme 40, je reste à 89% de VMAF, je continue pour voir jusqu’où je peux faire descendre la taille du fichier pour le même VMAF, mais je parie sur le fait que ... je vais peu ou prou retomber sur ce qui est annoncé : à savoir environ 30% de gain minimum en place pour le même rendu perceptuel ... (la je suis à 85 de VMAF pour crf de 45 sur svtav1, toujours pas descendu au niveau de H265 à crf 28 ...)

[Nilsou]

Je fais quelques tests rigoureux ces jours ci avec différentes métriques, je vous donnerais ce que j'ai en utilisant les dernières versions de tout ce beau monde.

[tompalmer]

Ce serait bien d'avoir aussi les retours d'un type qui a une 40XX ou une carte intel

[Nilsou]

A priori à partir des 3050 c'est pleinement compatible : https://en.wikipedia.org/wiki/Nvidia_NVDEC

Si c'est bien le cas je peux lancer une batterie de test sur mon super PC du boulot, je vous fait ça pour avoir le temps de conversion vs h265 hardware sur des cas type.

[Nilsou]

Plop, alors j'ai fais quelques tests.

Paramètre par défaut « pratique », j'ai évité les paramètres des encodeurs qui sont tunés pour telle ou tel métrique puisqu'en pratique ce n'est pas ceux là qu'on va utiliser. Donc en défaut pour libx265 et en defaut + tune=0 pour AV1 puisque AV1 est tuné pour les métriques par défaut et fait de belles vidéos avec tune=0, qui sera donc le mode le plus utilisé.

Donc j'ai calculé pour plusieurs facteurs de qualité les paramètres SSIM et VMAF, ce qui aboutit à plusieurs VMAF/SSIM pour des poids.

Donc pour SSIM, qui est le facteur « mathématique » de qualité d'image, voici ce que ça donne :



Donc on peut observer que la difference est ridicule.
Ceci dit il faut savoir que SSIM comme d'autres métriques mathématiques, sont très critiquées car ne percevant pas bien la complexité de la vision humaine, de ce qu'elle voit d'important comme de ce qu'elle néglige. De fait, de plus en plus c'est l'usage de VMAF qui se dégage, une métrique faites par apprentissage réseau de neurone par Netflix, et qui est aujourd'hui peu ou prou l'état de l'art. Même si elle est critiquable également.

Pour le VMAF, voici ce que ça donne :


Il y a une différence assez « faible » visuellement, mais en réalité, comme ce sont des courbes à fortes croissances, une légère différence ça fait pas mal de différence en hauteur de courbe pour la même qualité. Le point de vue est donc relatif.

Donc on peut évaluer la différence de poids des vidéos pour la même qualité et donc évaluer le pourcentage de gagné par AV1 pour la même qualité perçue selon VMAF.
Ce qui donne ceci :



Donc on voit qu'il y a bien un gain perceptible. Qui va dépendre pas mal de la qualité qu'on vise (à noter que le trou vers 90 est débattable, c'est en plein milieu de l'interpolation, faudra que je rajoute un point, edit : testé avec un autre point à cet endroit et c'est la même, chose, il y a donc bien un resserrement des deux algos dans la zone). Ceci dit, vu la gueule des courbes, l'autre point de vue c'est aussi de dire qu'a poids identique on a qu'une légère baisse de qualité en H265. Tout est donc une question de point de vue.

Je n'ai pas encore comparé les temps d'encodage, mais pour avoir fait quelques tests AV1 >> H265 >> h264, on est dans une croissance forte de complexité à chaque fois. Ceci dit j'ai fais mes tests sur un vieux PC, j'attends de tester la chose avec l'encodeur materiel (pour la même qualité visuelle), je fais ça sous peu.

Attention aux réglages ! Les CRF de AV1 n'ont rien à voir avec ceux de H265 qui n'ont rien à voir avec ceux de H264 pour la même qualité visuelle, donc faut réajuster pas mal les réglages.

[tompalmer]

Alors perso je sais pas ce qu' est le VMAF, le SSIIM et je sais pas manipuler FFMPEG sans interface graphique donc je risque pas de comprendre dans le détail, mais je saisis l'idée

Perso le max de ce que je peux faire pour vérifier la qualité c'est de faire un zoom dans VLC et comparer.

[Nilsou]

Ouais pour voir en gros c'est juste, mais dans le détail c'est parfois faux.
Parce que pas mal d'algo s'appuie sur le mouvement pour se dire qu'a certains endroits on peut retirer des infos qui bougent vite dans tel ou tel contexte. Donc parfois une image vue en pause est « légitimement » crade, mais donnera une scène très propre en mouvement.

C'est pour ça que les algos types h265 incluent des paramètres « special benchmark » où ils virent ces optimisations pour les métriques les plus simple (qui, elles, consistent en gros à faire ce que tu dis mais de manière automatique). Ce qui est un peu cheaté amha puisque c'est pas ça qu'on utilisera ensuite en vrai dans la vrai vie.

Le VMAF c'est pas très compliqué également : Netlix en avait marre des métriques de chie justement, puisque pour eux évaluer la qualité d'une vidéo est primordiale pour choisir des algos de compression qui ne descendront pas trop leurs appréciations auprès des utilisateurs. Il leur fallait une alternative.
Ils ont donc préféré mélanger pas mal de système différents et classifier ça à base d'une SVM (une méthode d'apprentissage automatique comme pour les réseaux de neurone) qui est entrainées sur les retours de ses milliers d'utilisateurs. Ça donne le VMAF. Un critère qui mesure la qualité d'une vidéo, en prenant en compte l'aspect temporel et tuti quanti. Le point faible c'est que c'est entrainé sur des utilisateurs dans un cas d'usage. Il faudrait probablement un VMAF pour plein de cas d'usage. Être devant son PC c'est pas pareil qu'être à 2m devant un écran. D'ailleurs ils ont déjà déployé plusieurs versions du VMAF (4K d'une part et smartphone d'autre part).

Sinon FFMPEG en ligne de commande c'est franchement parfois plus simple que de sortir handbrake.

Par exemple pour convertir vers du h265 :

ffmpeg -i video_origine -c:v libx265 -preset slower -crf 25 video_sortie.mp4 (ou mkv, etc.)

Si je veux convertir l'audio aussi je mets c:a

ffmpeg -i video_origine -c:v libx265 -preset slower -crf 25 -c:a libopus video_sortie.mp4 (la je convertie la piste audio en opus)

Et je peux utiliser "copy" pour dire que je vais copier cette piste.

ffmpeg -i video_origine -c:v libx265 -preset slower -crf 25 -c:a copy video_sortie.mp4 (la je convertie la piste video et je copie la piste audio)

etc etc.

Parfois c'est très pratique, surtout que les dernières versions incluent pas mal d'algo sympa.

[tompalmer]

Le gros problème que j'ai avec l'encodage par qualité est que sur une vidéo qui vient de ma caméra je peux avoir un bitrate d'arrivée qui varie grandement. J'essaye d'être autours des 15mbps en 4k mais je peux atteindre ça avec un rf complètement différent selon que je pars du master ou des fichiers sources.

Et en vrai je déteste handbrake, c'est plein de trucs inexpliqués ou de bugs mais j'ai pas connaissance de mieux. Je veux un soft plus simple mais avec des réglages plus fins

[Nilsou]

C'est gênant pour ton cas d'usage que tes vidéos varient en débit ?
Il n'y a que quand tu es limité pour le décodage etc que tu as besoin d'un débit à ne pas dépasser, mais je ne vois pas de cas d'usage classique où on a encore besoin d'un débit stable ...

Si tu veux ajouter une contrainte sur un bitrate à ne pas dépasser, il faut utiliser la balise vbv-maxrate= sous ffmpeg par exemple. C'est pas dispo sous handbrake ? (au pire il me semble qu'il y a un champ sous handbrake pour mettre des options à la mano).

[tompalmer]

C'est gênant pour ton cas d'usage que tes vidéos varient en débit ?

Non, c'est une question de poids final. Mais aussi de consistence, le RF est une valeur relative a la source et pas absolue

- si je passe d'une source a 95 RF 16 -> 15 mbps de moyenne
- et du meme contenu sur un fichier déja ré- encodé a 70 mbps en RF16 -> 30 mbps de moyenne

c'est pas intuitif

[Nilsou]

Si seul le poids final t'intéresse, je pense que le plus propre est de faire un test rapide sur un bout de ta vidéo avec un CRF donné et d'extrapoler.

Il y a bien des modes à plusieurs passes d'encodage pour essayer de converger vers un bitrate moyen donné, mais de fait ça signifie que selon le secteur de la vidéo la qualité va varier, ce qui n'est pas le but si tout ce qu'on dédire c'est une vidéo d'une taille donnée à qualité constante.

Pour obtenir une vidéo de qualité constante à taille finale donnée, le plus simple est donc de tester pour trouver le paramètre crf donné..., selon moi.

[tompalmer]

Oui c'est ce que je fais, mais si je me met a avoir des résultats débiles je passe en mode bitrate double passe et ca se passe très bien

[Nilsou]

Bien sur, mais en gros ça fait que c'est pas opti question gestion de la qualité. Pour respecter ton bitrate moyen imposé l'algo, dans les zones à hautes quantité d'information (mouvement, action) va devoir restreindre la qualité, alors que dans les zones calmes il va avoir de la qualité inutile. Au lieu d'avoir une gestion à l'échelle du fichier ça vient faire des trucs pas constant niveau qualité.

[tompalmer]

Ca reste un bitrate variable, je pense que tu sacrifie plus de poids que de la qualité

[Nilsou]

Normalement c'est bitrate en moyenne constant. C'est à dire qu'il vise que chaque bout de la vidéo (c'est séparé par morceau) donne un bitrate moyen. Donc en gros si tu as un bout très actif et un autre peu, il y aura une différence de qualité. Mais oui ce n'est pas constant parfaitement. Il y a un mode constant constant mais qui est très déconseillé.

[tompalmer]

Oui mais ca c'est pas grave, une vidéo en 4k avec un Bitrate de 15000 en moyenne, tu as pas d'artefacts. Si je l'encodais en mode qualité elle serait avec un bitrate moyen plus faible