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

[Rocca]

Je peux te filer des liens de mes différents test si tu veux comparer toi même.

Spoiler Alert!

[OTF] Haruka - Dans Une Epoque Lointaine S01E01.mkv - 738.8 MiB
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf14.mkv - 525.9 MiB
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf16.mkv - 380.9 MiB
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf18.mkv - 285.0 MiB
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf20.mkv - 223.1 MiB
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf22.mkv - 183.8 MiB

j'ai pas l'option main still picture peut être a cause du 10bit

Je regarderais ça demain

Oui en effet, l'option en 10 bit n'est pas présente, désolé petite erreur.

Sinon, je fournirai le graphique demain, mais le passage à cette nouvelle version comporte le même "bogue" ou anomalie que plus haut, mais il y a quand même quelques petits changements à noter.


A noter que j'ai testé en plus, cette fois-ci, slow et slower pour plus de détails

Sinon, je peux également te filer les vidéos si tu souhaites voir ce que ça donne en vidéo (capture d'un camp dans far cry 5 avec champ et forêt)...

[shlagevuk]

Par rapport aux test que tu as fait, on peut voir que les plus pertinents sont ceux se basant sur une qualité constante et non un bitrate constant. Ensuite quand tu as trouvé l'option de qualité constante qui te conviens, refait le test avec des preset différents pour voir ce qui est le plus intéressant en terme de temps Vs taux de compression. Personnellement je trouve que le gain de compression en dessous de slower est quasiment négligeable pour une durée d'encodage qui augmente exponentiellement.

La vidéo source peut avoir son importance, par exemple, un manga, un jeu 2d/cartoon, un jeu 3d, un film d'action, une sitcom ou un pron; auront des "profils" d'encodage assez différents. Certains gagnent beaucoup plus niveau qualité a avoir un encodage 10/12b par exemple (manga/jeu 2d/cartoon). Les sitcom gagnent plus a avoir des preset slow/slower/ultraslow (l'encodeur peut utiliser moins d'image de référence). Les films d'action ou pron avec des plans très mobiles gagneront peu a avoir un encodage plus lent, mais perdront potentiellement moins a baisser le niveau de qualité.
Dans l'ensemble je ne saurais que te conseiller de tester plusieurs video de jeux que tu prévois de conserver.

Concernant l'utilisation CPU, c'est normal. L'encodage vidéo utilise pas mal de bande passante mémoire, les ryzen sont assez sensible sur ce point, du coup tes coeurs ne doivent pas être alimentés correctement avec les CU de taille standard.
Si tu poursuis tes encodage en medium/slower avec des CU a 64, essai de passer ton encodage sur les coeurs physique uniquement (desactive le SMT ou utilise le gestionnaire de tâche pour que handbrake ai une affinité pour 1 Vcore sur 2). Ca te permettra de voir si les thread d'encodage sont bien limité par la bande passante mémoire. En soit c'est pas un problème hein, c'est juste plus long pour encoder, d'ou le fait que les preset plus rapide changent cette composante de CU

Si tu veux creuser un peu plus le pourquoi ultrafast prend moins de place que superfast je te conseil de regarder la documentation de ffmpeg. Ces presets correspondent en fait a des regroupements de sous-options (y'en a beaucoup).
https://x265.readthedocs.io/en/default/presets.html

Pour les encoders profils PSNR et SSIM, ils ne servent que si vous voulez utiliser les outils du même nom pour évaluer la perte de qualité vidéo. Il ne faut pas les utiliser sinon (on perd en compression).

[Rocca]

Salut, pour ton lien tu me l'avais déjà filé, il est super, et j'ai pas mal regardé toutes ces informations.

Ok pour ultrafast et superfast

Je suis parfaitement d'accord avec toi pour les qualités constantes. Je n'y comprends pas grand chose hein, que les choses soient claires d'entrée, mais j'ai l'impression que quand tu imposes un bitrate constant, avec des scènes très variables, l'encodeur s'oblige à être autour de cette valeur et du coup traite pas comme il faut les vidéos. En effet, on peut voir qu'à qualité constante, pour des vidéos différentes, le bitrate n'est jamais le même et, surtout, après lecture des vidéos on voir qu'un bitrate constant nuit à la qualité visuelle si tu le compare à une vidéo encoder avec une qualité constante ayant un bitrate dans les mêmes valeurs.

Sinon, c'est rigolo, car ce que tu me demandes de faire pour tester, c'est exactement ce que j'ai fais avant-hier dans la nuit avec la nouvelle version de Handbrake

Je posterai tout à l'heure les résultats pour un RF 20 avec les différents "encoder preset".

Concernant l'utilisation CPU, c'est normal. L'encodage vidéo utilise pas mal de bande passante mémoire, les ryzen sont assez sensible sur ce point, du coup tes coeurs ne doivent pas être alimentés correctement avec les CU de taille standard.
Si tu poursuis tes encodage en medium/slower avec des CU a 64, essai de passer ton encodage sur les coeurs physique uniquement (desactive le SMT ou utilise le gestionnaire de tâche pour que handbrake ai une affinité pour 1 Vcore sur 2). Ca te permettra de voir si les thread d'encodage sont bien limité par la bande passante mémoire. En soit c'est pas un problème hein, c'est juste plus long pour encoder, d'ou le fait que les preset plus rapide changent cette composante de CU

Quand tu lis différents sites (handbrake, ton lien et autres), tu te rends comptes qu'au delà 8 cores handbrakes ne suit plus trop (ce qui rejoint ce que tu dis). Sinon, de ce que j'ai compris, ultrafast avec ces CU plus "grossiers" ne demande pas de sous-traitement ce qui fait qu'ils envoient plus vite les données aux processeurs qui attendent pour calculer. Les autres "encoder preset", ayant des sous-calculs diminuent par conséquent cette parallélisation des calculs.

[Rocca]

Bon, voilà les résultats sous forme de tableur et de graphiques sur mes tests effectués avec la version de Handbrake 1.2.0.

Paramètre de la vidéo de départ pour l'ensemble des encodages ci-dessous. Pour ce qui est de ce qui se passe à l'écran, il s'agit d'une capture vidéo sur une libération de camp dans FarCry 5 (y'a des passages à l'intérieur et extérieur avec végétation).

Complete name : U:\Nvidia\Far Cry 5\test2\Libération_Camp2.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/mp42)
File size : 1.62 GiB
Duration : 4 min 44 s
Overall bit rate : 48.8 Mb/s

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.2
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4 min 44 s
Source duration : 4 min 44 s
Bit rate : 48.6 Mb/s
Width : 1 680 pixels
Height : 1 050 pixels
Display aspect ratio : 16:10
Frame rate mode : Variable
Frame rate : 59.940 (59940/1000) FPS
Minimum frame rate : 59.016 FPS
Maximum frame rate : 60.770 FPS
Original frame rate : 60.000 FPS
Bit depth : 8 bits
Scan type : Progressive



Graphique avec un temps d'encodage croissant (double axe Y).


Graphique avec une taille de fichier .mkv final croissante (double axe Y).

[shlagevuk]

C'est très intéressant comme résultat, ça va complètement en sens inverse des résultats supposés (plus le preset est "lent" meilleur est le taux de compression).

Dans les options changées par le preset on a rc-lookahead, rdLevel, et b-adapt qui changent pas mal entre medium et fast/faster/veryfast. Tu pourrais relancer l'encodage en medium avec "--rc-lookahead 15" pour confirmer?

Au final c'est assez logique que l'on ai un gain de temps sans perte de taux de compression avec ça puisque dans un jeu il n'y a pas vraiment de "changement de scène" (le lookahead ne sert a rien puisque l'action est continue sans changer de point de vue).
Du coup c'est peut-etre aussi le b-adapt qui prend pas mal de ressources sur le temps d'encodage et qui insère des images de références inutile ce qui augmente la taille du fichier final. (bon je suis pas expert non plus, mais la théorie me semble correcte)

[Rocca]

Je vais lancer le test avec "extra option" --rc-lookahead 15", mais ne faudrait-il pas ajouter "--b-adapt" au vu de ta dernière phrase ?

[shlagevuk]

Pour le coup --b-adapt 0 car justement on ne va pas faire de lookahead pour déterminer le placement des b-frames lors de l'incodage, on vas uniquement utiliser les valeurs keyint/bframes (cf doc)

[Rocca]

Bon, me revoilà avec les résultats

J'ai donc réencoder en medium main 10 (10 bit) et main (8 bit) pour voir ce que ça donne en rajoutant la commande "--rc-lookhead 15" dans extra options.




Courbe croissante en fonction du temps :





Courbe croissante en fonction de la taille du fichier :

[shlagevuk]

La taille de fichier est strictement identique entre avec et sans l'option.
(le temps d'encodage aussi +- 15s)

Je me demande si c'est pas handbrake qui override l'option.

(je vais faire quelques tests)

[Awake]

Salut à tous, question de noob, peut-être qu'il y a un meilleur topic mais j'ai pas trouvé :

J'aimerais convertir une vidéo 1080p@60fps d'une minute pour pouvoir l'utiliser sur le web. La source fait 149Mo.
En essayant plusieurs choses sous ffmpeg, le résultat n'est pas satisfaisant : soit la vidéo est trop lourde, soit la qualité n'est pas assez bonne, simplement en variant -crf sur cette commande :

ffmpeg -i input.mp4 -vcodec libx264 -crf 20 -an -r 24 output.mp4

Dans l'idéal, il faudrait que la vidéo reste en 1080p, passe à 30 fps et n'ait plus de son, le tout avec un bon ratio qualité/poids (moins de 40Mo ?).

Un idée de comment faire ?

[revanwolf]

Un idée de comment faire ?

Ne pas utiliser le format MP4?

Je suis pas un spécialiste en la matière mais il y a des formats plus adapté aux web comme le WEBM par exemple qui est conçu spécialement pour les vidéo internet.

et aussi utiliser un codec comme le VP9 qui est adapté pour ton usage.

[MegABiloU]

Si tu ne veux pas t'emmerder fait un upload sur Youtube puis télécharge la vidéo convertie de youtube.
Par exemple une vidéo 1080p @60fps de 330Mo passe à 58Mo comme ça.
Voire 29Mo si on choisit 30fps.

[Awake]

Ne pas utiliser le format MP4?

Je suis pas un spécialiste en la matière mais il y a des formats plus adapté aux web comme le WEBM par exemple qui est conçu spécialement pour les vidéo internet.

et aussi utiliser un codec comme le VP9 qui est adapté pour ton usage.

En cherchant un peu avec ces infos, j'ai trouvé la commande magique :

ffmpeg -i video_source.m4v -c:v libvpx-vp9 -b:v 5M -c:a libopus -an -r 30 -threads 16 output.webm

Super qualité et < 50Mo !

Merci

[MegABiloU]

Je viens de faire un tuto pour faire un OCR et traiter les pistes de sous titres

le lien permet d'effectuer des modifications si jamais vous voyez une erreur ou souhaitez apporter des contributions.
Comme par exemple sur d'autres OS que Windows.
https://docs.google.com/document/d/1...it?usp=sharing

[Sunseille]

yopla

J'ai commencé a regarder comment faire pour upscale des dessins animés asiatiques en 4K, le principe m'interessait et je suis tombé sur une ou deux vidéos qui m'avaient plutot bien vendu le truc.
Le principe est de demander a ffmpeg de découper toutes les frames de la vidéo sur lequel on travail, de les upscale avec waifu2x puis de les recoller avec ffmpeg. Oui, c'est pas l'opti du bonheur et ca prend beaucoup trop de temps a faire, mais le resultat est plutot interessant.
Il y a aussi sous windows cette fois-ci, nnedi3 en filtre avisynth qui fait a peu pres le même résultat (je trouve l'image moins nette avec ce dernier) mais qui a l'avantage d'etre plus rapide a ce que l'on m'a dit. Je n'ai pas de resultat a présenter par contre pour nnedi3.

Donc waifu2x voilà comment que j'ai fait sous linux pour faire fonctionner le tout.
Premièrement il m'a fallu plusieurs logiciels:
- https://ffmpeg.org/
- https://github.com/DeadSix27/waifu2x-converter-cpp
- installation d'un environement CUDA ou OpenCL
- d'une carte graphique pas trop mauvaise. Petite preference pour les nvidia pour le CUDA.



Utilisation:
J'ai monté une VM en GPU passthrough pour faire le gros du calcul sans que ca touche au reste de ma configuration.
VM debian avec ffmpeg + waifu2x-converter-cpp d'installé.

J'ai pris ffmpeg sur le host ou j'ai découpé toutes les frames de la vidéo a upscale:

ffmpeg -i video.webm decompose/thumb%04d.png -hide_banner

Tout le repertoire ou les images ont été découpées sont déplacées sur la VM qui va effectuer le calcul.
J'upscale chaque image avec waifu2x et son traitement CUDA/OpenCL.
Toutes les images sont déplacées vers un autre dossier ou je peux voir le résultat avant de passer à l'étape suivante.
Au cas ou je vous partage le petit script bash que j'ai monté pour traiter en masse les images présentes dans le dossier source.

Spoiler Alert!

#!/bin/bash

list_filename=`ls *.png`


for filename in $list_filename; do
    echo "fichier trouvé:  $filename";

    if [ -e "../4K/4K_$filename" ]; then
        echo "File already exist:  ../4K_$filename";
    else
        echo "Start waifu2x on:  $filename";
        waifu2x-converter-cpp --scale_ratio 2 -i $filename -o ../4K/"4K_"$filename
        echo "Finished waifu2x on:  4K/4K_$filename";
    fi
done

Dès que c'est fini (c'est TRES long !) je rapatrie tout sur l'host ou je peux laisser ffmpeg mettre les images bout a bout avec la commande suivante:

ffmpeg -r 24 -f image2 -s 3840x2160 -i 4K/4K_thumb%04d.png -vcodec libx264 -crf 24  -pix_fmt yuv420p test.mp4

A partir de la la video est prete et j'ai pu admirer le resultat et voir si il n'y a pas eu une anomalie durant le traitement des images. Oui ca peut arriver, ca m'est arrivé sur une frame en pleins milieu d'un scrolling horizontal, donc ca va j'ai pas eu trop besoin de me casser la tête pour refaire la frame.

Il manque par contre la musique:
j'extrait la musique du fichier original

ffmpeg -i "video.mkv" -f mp3 -ab 640000 -vn music.mp3

et enfin je rajoute la dite musique dans la vidéo precedement faite

 ffmpeg -i "video.mp4" -i music.mp3 -codec copy "video.mkv"

Et hop j'ai ma vidéo en 4K toute propre de disponible !



Résultat:




Statistiques:
A noter que les résultats sont a peu pres similaires sur les 2 vidéos car elles ont la même durée et un nombre de frames très proche, de ce fait j'ai préféré donner des résultats arrondies pour vous donner un ordre d'idée du temps que ca a pris.
De plus le temps CPU est a titre informatif du temps qui aurait été pris dans la configuration que je vous présente.

	Temps Traitement	Frames	Temps Video
CPU	12:30:00	2205	00:01:32
GPU	03:20:00	2205	00:01:32

Hardware	Designation	Threads fixé
CPU	Ryzen 1700	14
GPU	GTX 1070	CUDA

[shlagevuk]

L'upscaling par ce procédé est vraiment intéressant? Tu as fait des tests sur des animés particuliers ? (j'ai pas d'écran 4k pour pouvoir comparer)

C'est intéressant le comparatif de temps entre le traitement via CUDA et celui via CPU. Bon pour 12 épisode de 25 minutes on est a 28 jours de traitement, mais c'est toujours mieux que 104 jours.

Y'a un gain quelconque sur l'utilisation de cette methode pour faire une sorte de super-sampling ? (passer la video en 4k puis encoder avec un downscale en FHD)

[Laiz]

Hello. Je viens sur ce forum pour vous demander une petite information (ou conseil) à propos de l'encodage en H265.
En effet, j'encode mes animés (H264) 1080P vers du H265 en utilisant HandBrake. (Constant Quality à 22 RF [que je suis en train de descendre à 20 pour voir si il y a un changement).
J'en suis toujours très satisfait et je ne remarque pas de différence visuelle entre la version originale d'un épisode, et la version encodée en H265.
Néanmoins je me pose quand même des questions quant au bitrate. Je sais qu'il diminue fortement avec le H265, mais (même si je n'ai remarqué aucune différence de qualité entre l'original et leH265), je me demande s'il serait pas *trop* faible.
Par exemple, un épisode d'un animé (WEBRip 1080P 2,92 Go) avec un bitrate de 17,4 Mb/s en H264, une fois convertit en H265 aura un bitrate de 1 603 kb/s (pour un poids de 299 Mo). Un autre exemple, un autre animé (WEBRip, 1080P, 1,22 Go) ayant un bitrate en H264 de 7 463kb/s aura un bitrate de 772 kb/s en H265 (pour un poids de 158 Mo).

J'aimerais bien que quelqu'un me donne son avis et puisse me dire si le "rapport" poids/bitrate est correct sachant que je ne remarque aucune différence de qualité entre l'originale et la version H265.
Merci

[Rocca]

Salut,

Un facteur 10 en bitrate me parait effectivement élevé.

Maintenant, tu encodes en H265, mais avec quoi comme paramètres (voir ci-dessus les graphiques) ? Après l'essentiel est le résultat final, s'il te convient, un faible bitrate en sortie, c'est un gros gain de place.

[Laiz]

Ouaip c'est vrai que c'est un énorme gain de place, et j'en suis content (d'autant plus que je ne remarque pas de différence de qualité. Mais contradictoirement, je voudrais avoir le "meilleur" possible (même si dans ce cas là je n'ai qu'à garder mon H264 O).
Enfin bref, mes paramètres sur Handbrake sont les suivants :

Section "Dimensions" :

Dimensions : 1920 * 1080 (comme la source en gros)
Anamorphic : Automatic
Modulus : 2
Cropping : Automatic


Section "Filtrers" : je n'y ai pas touché, donc ce sont les paramètres de base.

Section "Video" :
Video Codec : H.265 (x265)
Framerate : Same as source (Variable Framerate)
Optimise video : Encoder preset : Fast
Encoder Tune : None
Encoder Profile : Auto
Constant Quality : 22 RF

Section "Audio" : Codec Auto passthru (je ne touche pas à l'audio, je le laisse tel quel).

[Foudge]

A mon avis tu pourrais obtenir un facteur 5 sur le bitrate sans que tu remarques de différence tout en restant en H264.
Dit autrement, c'est plutôt le bitrate de ton épisode de 3Go (pour 25min de 1080p) qui serait inutilement élevé dans ton cas.

[Laiz]

Hmm. Ouaip c'est fortement possible, parce que 17 mb/s pour un épisode de 25 minutes en 1080P ça fait un peu beaucoup je pense x)

Et sinon, pour l'autre épisode où le bitrate est passé de 7 483 kb/s à 772 kb/s (ce qui me paraît un peu faible), rien à signaler ou bitrate "trop" faible ?

[Sunseille]

L'upscaling par ce procédé est vraiment intéressant? Tu as fait des tests sur des animés particuliers ? (j'ai pas d'écran 4k pour pouvoir comparer)
Y'a un gain quelconque sur l'utilisation de cette methode pour faire une sorte de super-sampling ? (passer la video en 4k puis encoder avec un downscale en FHD)

L'upscaling par traitement neuronal ouais est vraiment très intéressant au niveau de la qualité, je suis assez bluffé de ce qui en sort. T'as l'impression que ca a été fait par un pro pour un cout réduis et puis tu peux le faire de chez toi avec la carte graphique qui va bien.Mais je risque de me repeter, mais je n'ai pas tester le filtre nnedi3 avec avisynth qui a ce qu'il parrait a des resultats très proche pour un meilleur rendement.
Pour le moment je reste sur les animes avec des lignes très nettes, c'est plus facile pour moi pour voir la différence et je pense que c'est ce qui mérite le mieux ce genre de traitements (Nichijou ).
Mais je pense que ca devrait marcher un peu partout.

Le gain au niveau du supersampling serait sur la qualité de l'upscale qui est beaucoup plus propre que les filtres habituels (mais rapide) que nous avons.


Ca reste un traitement de foie gras ou ta carte graphique tourne a 100% pendant plusieurs heures consécutive. A voir si un rack de carte graphique pour miner du bitcoin pourrait être utiliser pour ce genre de trucs, mais bon après la conso pour mater des dessins animées....


note a part, le thread c'est toujours topic [HEVC] pourquoi pas le rendre plus général au traitement vidéo, surtout avec l'arrivée prochaine de AV1 qui m'a l'air bien interessant tout pleins.

[shlagevuk]

Hmm. Ouaip c'est fortement possible, parce que 17 mb/s pour un épisode de 25 minutes en 1080P ça fait un peu beaucoup je pense x)

Et sinon, pour l'autre épisode où le bitrate est passé de 7 483 kb/s à 772 kb/s (ce qui me paraît un peu faible), rien à signaler ou bitrate "trop" faible ?

Comme le dit Foudge, je pense que tes deux animés "source" ont des bitrate très élevé de base, ces bitrates doivent en plus être fixe. Tu auras forcément un gros gain en les encodant en qualité constante 22RF en x265 étant normalement un encodage "imperceptible". De plus la plus part des animés sont très facilement compressible, il y a peu de détails dans l'image comparativement à une représentation réelle. Donc un épisode de 25min d'animé qui pèse 200mo ne me choque pas particulièrement, ça dépend du contenu (beaucoup d'action/mouvement, décors riche etc...). Le mieux étant toujours de comparer le résultat à la source pour voir si la qualité te suffis.

note a part, le thread c'est toujours topic [HEVC] pourquoi pas le rendre plus général au traitement vidéo, surtout avec l'arrivée prochaine de AV1 qui m'a l'air bien interessant tout pleins.

Yep je vais renommer le topic. Y'a de beaux progrès côté AV1 d'ailleurs, le temps d'encodage est toujours super long mais on s'approche petit à petit de l'acceptable

[shlagevuk]

Je viens de découvrir une feature bien cool des conteneurs MKV, le file linking (segment linking) qui permet basiquement d'ajouter une intro/outro présente dans un fichier externe à la liste des chapitres d'un conteneur mkv. Ainsi pas besoin de répéter une intro dans les X fichier ou elle est présente.

Sauf que personne ne supporte la feature (VLC ok, mais plex ko et handbrake ko....)

[Guapo]

Assez incroyable comme feature.
Si je comprends bien, tu peux encoder une série complète et permettre au (télé)spectateur de passer le récap et le générique. Ce que permet Netflix par exemple mais je n'avais jamais imaginé que c'était une "feature" incluse dans les formats de fichiers.
Moi qui pensait que le MKV était un truc de tipiak, en fait c'est très également très professionnel...

[shlagevuk]

Bon, après les déboires lié aux features mkv pas pris en charge par la plupart des lecteurs et notamment par handbrake lors d'un transcod, je me suis tourné à nouveau vers ffmpeg.

Je suis tombé sur une image docker très bien foutu et j'ai fait un petit batch de transcod pour voir quel niveau de CRF était acceptable avec differents preset.

for crf in 20 24 28 32; do
  for speed in ultrafast fast medium slow; do 
     time docker run --cpuset-cpus="0,2,4,6" --cpus="4" -v$(pwd):/temp/ jrottenberg/ffmpeg -loglevel panic -i /temp/Violet.Evergarden.01.mkv -map 0 -c:0:1 copy  -c:0:2 copy -c:0:v libx265 -preset $speed -crf ${crf} /temp/out_${crf}_${speed}.mkv
  done
done

Globalement seul CRF 20 donne un résultat "indetectable", à CRF 24 on vois quelques petits artefact par ci par là, au dessus c'est dégueulasse.
De même le preset est très important pour le rendu final de l'image. Pour tout les CRF le preset ultrafast rend la video "blocky" du au "motion search method" utilisé pour ce preset. Le preset fast quant à lui souffre d'un taux de compression bien plus mauvais que les autres preset, vu que je vise un transcodage pour archiver les videos à long terme ce preset est inutile pour moi.

Reste donc medium et slow en CRF 20/24.

Temps d'encodage (minutes):

CRF	20	24
medium	104   	94     	90.38%
slow  	243   	213   	87.65%
	233.65%	226.60%

Un coût de ~220% en temps d'encodage pour une faible difference de qualité
~10% de temps d'encodage en moins avec un CRF plus haut

Taille des fichiers (Mo):

CRF	20	24
medium	248	156	62.90%
slow  	243	154	63.37%
	97.98%	98.72%

Un gain quasi nul entre medium et slow niveau taille, et logiquement la taille varie beaucoup en fonction du CRF.
A voir si la difference de qualité entre medium crf 20 et slow crf 24 justifierai le temps d'encodage en plus.


Après avoir encodé 16x la même video je me suis dit qu'il serait de bon ton de les comparer avec un outil fait pour ça. Je suis tombé encore une fois sur un conteneur docker incluant vqmt pour faire ça!

Pour utiliser cet outil il faut d'abord extraire la video en format brut (non compressé). Convertis ainsi le fichier fait une taille monstrueuse (220mo pour 3s) il faut donc travailler avec des morceaux de fichier video, pour les extraires:

for debut in "05" "10" "20"; do
  for crf in 20 24; do
    for preset in medium slow; do
      docker run -v $(pwd):/temp/ jrottenberg/ffmpeg -ss 00:${debut}:00 -i /temp/out_${crf}_${preset}.mkv -t 00:00:03 -c:v rawvideo -pix_fmt yuv420p /temp/out_${crf}_${preset}_${debut}m_3s.yuv
    done
  done
  docker run -v $(pwd):/temp/ jrottenberg/ffmpeg -ss 00:${debut}:00 -i /temp/Violet.Evergarden.01.mkv -t 00:00:03 -c:v rawvideo -pix_fmt yuv420p /temp/out_source_${debut}m_3s.yuv
done

#On génère les morceaux de fichiers bruts de 3s aux timestamp à 5 10 et 20 minutes. On génère les même pour le fichier source.

Pour avoir l'image vqmt:

git clone https://github.com/h3dema/ubuntu-vqmt.git
cd ubuntu-vqmt
docker build -t vqmt .

Ensuite on lance les tests:

for debut in "05" "10" "20"; do
  for crf in 20 24; do
    for preset in medium slow; do
      for test in PSNR SSIM MSSIM VIFP PSNRHVS PSNRHVSM ; do 
        docker run -v $(pwd):/videos -w /videos vqmt vqmt out_source_${debut}m_3s.yuv out_${crf}_${preset}_${debut}m_3s.yuv 1080 1920 60 1 ${crf}_${preset}_${test} ${test}
      done
    done
  done
done

(je renvois vers la documentation des differents outils pour savoir a quoi correspond tout )


Bon j'ai pas de résultat pour le comparatif de qualité parce que j'ai choisi les morceaux au pif et je suis tombé sur des séquences statiques (merci les mangas), c'est donc pas super intéressant comme résultat.


Et c'est à ce moment là que je me suis rendu compte d'un truc, libx265 avait plusieurs version de retard dans le build de ffmpeg par defaut! (2.3 vs 3.0).
J'ai donc rebuild l'image ffmpeg avec la version 3.0 comme cible. Et là j'ai eu une petite surprise... La version 3.0 est beaucoup plus lente! (250% sur les deux encod qui ont terminé pour l'instant)

En conséquence je vais lancer un batch de transcod en utilisant une video source plus courte (big buck bunny) et tester les differentes version de libx265 pour le temps d'encodage et la qualité.

J'ai un autre batch de transcod que je vais lancer avec la version "officielle" en limitant les preset à medium/slow et crf à 19/20/21/22.

bref, plus de données bientôt.



tips bonus, pour générer les commandes ffmpeg de transcod permettant de garder toutes les pistes audio et tout les sous-titres:

# commande de base (limitation cpu, volumes...) et le fichier source
echo -n 'docker run --cpuset-cpus="0,2,4,6" --cpus="4" -v$(pwd):/temp/ jrottenberg/ffmpeg -i /temp/Violet.Evergarden.01.mkv -map 0 ';
# on utilise ffmpeg pour lire les stream et on filtre pour n'avoir que le "numero" des stream qui ne sont pas de la video
for i in $(docker run -v$(pwd):/temp/ jrottenberg/ffmpeg -i /temp/Violet.Evergarden.01.mkv 2>&1 |grep -v "Video" |grep "Stream #"| grep -o -e "#.:[0-9]*"); do 
  # pour tout les stream
  echo -n " -c:0:${i:1} copy "
done
# commande pour le transcod video
echo -n '-c:v libx265 -preset veryfast -crf 20 /temp/outtest2.mkv'
echo ""

C'est assez basique et je ne suis pas certains que ça marche dans 100% des cas mais c'est une bonne base pour lancer un gros batch de transcod dans un dossier sans se poser de question

[Sunseille]

Good news everyone! AV1 ca avance plus rapidement que prévu !
https://people.xiph.org/~negge/NAB2019.pdf

[shlagevuk]

Effectivement c'est impressionnant. Et en juste quelques mois l'encodeur a fait des progres spectaculaires en terme de vitesse!

J'aime bien la citation sur la dernière slide:

Considering that video and images make up about 80% of all
internet traffic, the impact of how things get encoded is pretty big.
Even a modest 1% BDR gain tool translates into about 20 EB of traffic
yearly currently, or 20,000,000,000 GB.

Je suis en train de tester la branche master comparé au tag 1.0 de libaom-av1 et effectivement le gain en vitesse est considérable, x10 au moins!

[Guapo]

Un petit bench sans prétention sur ma nouvelle config que j'utilise entre autre pour faire de la vidéo.
Mon ancienne était un i7 3770K, légérement OC à 4GHz, la nouvelle un Ryzen 7 3700X. Les deux ont 32 GB de RAM.

Pour faire un test, j'ai encodé un BRD d'un film de 2h10 avec le profil H265 MKV par défaut de Handbrake (1080p30). Le BRD avait été copié sur un SSD et la destination était également un SSD histoire de ne pas fausser les tests par des problèmes de latence.

Résultat : 9h55 pour encoder sur l'ancienne plateforme contre 2h50 sur la nouvelle, soit une réduction de 71% du temps nécessaire à l'encodage

[Foudge]

Presque 4 fois plus perf ! C'est donc plus lié à l'architecture et aux nouvelles instructions, qu'au nombre de cores.