Je reprend ici le topic crée dans la section dépannage pour parler du HEVC (x265).
Très bon article de techspot trouvé par Megabilou sur le HEVC (comparaison rapidité d'encodate, efficacité, qualité)
Pourquoi encoder une video sur 10bit est plus efficient
Et la mise en pratique de ce principe avec des tests d'encodage
Merci Foudge pour ces deux liens!
Nos canards sont exceptionnels, un zip complet comprenant un handbrake nightly avec les librairies pour encoder en 10/12bit. Merci Squarealex !
C'est un codec ayant pour but de réduire la taille des vidéo en gardant une qualité équivalente au AVC (x264). Et ce par l'utilisation d'algorithme plus complexes.
Ce codec est conçu pour des formats HD et plus (2k 4k 8k) et des framerate élevé.
- Compatibilité
Aujourd'hui la plupart des lecteurs moderne le prennent en charge. Son gros point faible et la puissance de calcul nécéssaire pour le décoder qui est plus important que le x264.
Sur nos machines de bourgeois le problème ne se fait pas trop sentir, mais sur des périphériques mobiles ou assez vieux le problème est bien plus sensible!
Heureusement, comme pour le x264 le décodage matériel arrive petit à petit.
-Intel le gère depuis skylake (un peu avant en support partiel)
-Amd le gère depuis carrizo
-Nvidia le gère mais c'est le bordel et gère également le format sur sa tablette shield.
Pour les autres puces, notamment les ARM, le support est encore assez rare. Mais ça se démocratisera en même temps que les sources 4k logiquement.
- Qui a besoin de faire de l'encodage en x265?
Actuellement le x265 est encore un peu jeune comme format pour arriver a donner des résultats équivalent au plus ancien x264 a haut bit-rate. Par contre il excelle quand le bitrate est assez bas.
En gros si vous voulez sauvegarder une video 1080p d'1h30 dans un fichier de <2Go, le résultat sera très certainement meilleur en x265 qu'en x264.
Par contre si la taille importe peu et que vous voulez conserver la plus grande qualité vidéo le x264 est à privilégier.
Personnellement je compte tout transcoder en x265 pour le gain de place. Pour les quelques test que j'avais fait, la réduction en terme de taille est de 30 à 50% pour une perte de qualité dur à percevoir si perceptible tout court.
Il me reste encore à tester le passage au x265 des vidéo à faible résolution (dvd) pour voir le gain.
- Transcoder c'est long
Autant le transcode x264 n'est pas des plus rapide. Autant le transcode x265 est abominablement long. Environ 10x plus long. Donc si vous voulez vous lancer dans l'aventure, attendez-vous à laisser votre PC tourner h24.
Niveau vitesse d'encodage chez moi:
Atom C2750 (8c@2.4Ghz) -> ~4fps en slow
Xeon x5670 (6/12c@3.93Ghz) -> ~7fps en slow, dans une VM.
- Maintenant parlons technique
J'utilise ffmpeg sous linux pour le transcodage. J'essaierai de faire un tour d'horizon d'handbrake à l'occasion.
Mes paramètres sont assez simple et sont les suivant:
ffmpeg -i input.mkv -map 0 -c:v libx265 -preset slow -x265-param "profile=main:CRF=18" -c:a copy -c:s copy -c:t copy output.mkv
-map 0 : prend tout les "stream" du fichier passé en entré
-c:v : pour les stream video on applique les options suivantes
libx265 : la librairie utilisé pour encoder
-preset slow : voir en dessous
-x265-param : les paramètres propre au HEVC, expliqué plus bas
-c:a copy : on copie les stream audio
-c:s copy : même chose pour les sous-titre
-c:t copy : même chose pour les fichier "attaché" comme les polices d'écriture
output.mkv : le fichier de sortie, ffmpeg détecte automatiquement le type de fichier en fonction de l'extention. On peut aussi lui préciser via l'option -f
Les presets
-slow est réservé au vidéo que vous voulez archiver sinon passer sur du medium->veryfast suffis largement normalement.
-pour du quasi temps réel ou de l'encodage pour tester les options (qualité par exemple) ultrafast!
-les presets influent la qualité par bit de l'encodage, donc si on utilise CRF pour déterminer la qualité c'est la taille du fichier qui changera seulement. Si on utilise un bitrate constant (ex 2 pass encod) , le preset influencera la qualité final de la vidéo.
-En dessous l'économie de bitrate par rapport au temps d'encodage, en bleu on vois la courbe du x265, les trois points en bas à gauche sont placebo/veryslow/slower. On vois bien le coût en terme de temps par rapport au gain. Celui-ci deviens plus raisonnable avec slow.
Graphique imageant bien le rapport temps/compression des trois codec récent
Credit graphique
CRF
Pour un équivalent 23 en x264 je prend un CRF de 18 en x265. Pour l'instant x265 n'est pas des plus aboutis niveau qualité, et c'est normal. Le HEVC est plutôt conçu pour les bitrates assez faible.
Exemple un gros film d'action en 1080p encodé à 1Mbps en x264 et x265 fera vraiment ressortir l'intérêt du HEVC en terme de qualité. Par contre à >3Mbps l'intérêt s'inverse, et on commence à percevoir que le grain et les détails sont plus présent en x264 qu'en x265.
Pour la rétention du grain
-comme pour le x264: -tune grain
Les profile
Les profiles permettent la compatibilité avec les décodeurs hardware. Les profiles habituellement accepté sont main et main10. Pour plex par exemple, si le lecteur prend en charge le décodage materiel la vidéo n'est pas transcodé.
Autre
Il y a pléthore d'autre paramètres pour optimiser le poids ou la qualité de l'encodage. Exemple: le parametre keyint qui fait varier le nombre d'image entre deux images de référence. Une valeur plus haute peut diminuer le poids du fichier mais augmenter le seek-time, il peut également casser la compatibilité avec certains lecteurs. Une valeur trop haute ne donnera aucun gain de bitrate.