Encoder en x265 - Quels paramètres appliquer ?

Eric Demeester :

J'utilise Handbrake 0.10 sous Windows 7 ultimate.

Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris
l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray),
mkv « lourds » en « HDLight ».

Le principe est de conserver la taille de l'image initiale (720p ou
1080p), mais de faire « maigrir » la vidéo en l'encodant en x264
(pendant libre du H264), sans perte visible de qualité par rapport à
l'original.

On parvient aussi à « économiser » en encodant les bandes-son en AAC
plutôt qu'en AC3, plus quelques autres astuces.

Débutant dans cette activité et n'y connaissant rien en audio/vidéo, je
me suis largement appuyé sur ce tutoriel :
https://tutox264.wordpress.com/

appris, et obtenu au fil du temps et de discussions avec d'autres
utilisateurs plus avertis que moi, des résultats plus qu'honorables.

- mes questions (vous pouvez virer tout ce qui est au dessus dans vos
éventuelles réponses, ça allègera :)

J'ai découvert récemment le x265 (pendant libre du H265), qui, j'ai pu
le constater en visionnant des exemples, permet encore de diviser en
moyenne par 2 la taille des vidéos par rapport au x264, toujours sans
perte visible de qualité.

J'ai cherché des informations sur le sujet, mais à part le fait qu'on
semble pouvoir obtenir la même qualité qu'en x264 en divisant le
« bitrate » par 2, je n'ai trouvé aucune autre information, et en tout
cas rien de similaire au didacticiel ci-dessus.

Comme il s'avère que Handbrake 0.10 sait encoder en x265 et que VLC sait
le lire, j'ai bien envie de faire des tests, mais avant de partir un
peu à l'aveugle, si vous avez une expérience en la matière, des liens à
me conseiller (l'anglais ne me dérange pas), je suis preneur :)

Par avance merci pour vos lumières.

le H265 est plus performant que le H264, mais pas dans les proportions
que tu indiques (2 fois moins de place à qualité équiv.)
de plus il demande énormément de ressources pour son décodage ce qui le
rend illisible par bon nombre de périphériques de lecture (quand bien
même ceux-ci serait compatible H265/X265).
j'avais noté à l'époque que le MPEG4 Part10 (H264, X264) était meilleur
que le MPEG4 Part2 (Xvid, DivX, MPEG4 ISO,...) lorsque les résolutions
augmentaient. à des résolutions modestes (inférieur à 480p) le gain en
terme de rapport qualité/poids était quasi négligable.
j'en conclue que le H264 a été optimisé pour des résolution HD (entre
le 720p et le 1080p).
qu'en est il pour le H265 ? je n'en sais rien. il a été crée pour la
diffusion du 4K, mais est il optimisé pour de la HD simple...?

j'ai fait des tests d'encodage H265 avec ffmpeg.
j'utilise ces paramètres :
ffmpeg -i INPUT.XXX -c:v libx265 -preset medium -x265-params crf(
-c:a aac -strict experimental -b:a 128k OUTPUT.MKV

On Tue, 10 Feb 2015 20:29:15 +0100, Eric Demeester
<eric.REMOVETHIS@mailody.org> wrote:

Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris
l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray),
mkv « lourds » en « HDLight ».

Le principe est de conserver la taille de l'image initiale (720p ou
1080p), mais de faire « maigrir » la vidéo en l'encodant en x264
(pendant libre du H264), sans perte visible de qualité par rapport à
l'original.

j'ai eu exactement la même démarche que toi, mais à l'envers, lorsque
je me suis équipé en vidéoprojecteur HD avec une diagonale de 100
pouces, j'ai du refaire ma vidéothèque avec des versions de 10Go
minimum (en deça je vois maintenant la différence de qualité) là ou un
peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela
je ne voyais pas de différence).

A méditer donc, si tu compte plus tard t'équiper en plus grand...

Ce que tu peux aussi faire, c'est encoder en 720 afin de vérifier si
tu vois la différence de qualité dans tes conditions de visionnage,
parcequ'en deça d'un certain débit on a tellement enlevé de détail
qu'on ne voit plus de différence entre le 720 et le 1080, et parfois
on visionne tout simplement de trop loin pour faire la différence
entre du 1080 et du 720, un test en aveugle peut être nécéssaire pour
être réelement objectif dans le choix.

Par contre je suis fort interressé par ton retour d'utilisation du 265
car je pense l'utiliser dans le cadre professionel.


--
pas de turlututu. apres l'@robase

Alf92 :

j'ai fait des tests d'encodage H265 avec ffmpeg.
j'utilise ces paramètres :
ffmpeg -i INPUT.XXX -c:v libx265 -preset medium -x265-params crf(
-c:a aac -strict experimental -b:a 128k OUTPUT.MKV

ou si tu veux bidouiller avec qques paramètres :

ffmpeg -i INPUT.XXX -r 25 -b:v 2200k -bt 1000k -s 1280x720 -sws_flags
bilinear -aspect 1.7777 -vcodec libx265 -ac 2 -ar 48000 -b:a 128k -c:a
aac -strict experimental OUTPUT.MKV

Bonjour,

Alf92 (Wed, 11 Feb 2015 12:45:46 +0100
- fr.rec.son-image.video.realisation) :

le H265 est plus performant que le H264, mais pas dans les proportions
que tu indiques (2 fois moins de place à qualité équiv.)

J'ai pourtant eu l'occasion de faire la comparaison entre deux vidéos
encodées à partir d'une même source, l'une en 1080p x264, l'autre en
1080p H265, et c'est le rapport que j'ai constaté. La même était
proposée aussi en H265 avec un taux de compression supérieur, taille
d'1/3 par rapport au x264, mais la perte de qualité était flagrante.

Mais bon, on ne va pas pinailler, si ça me permet de gagner entre 30 et
40% par rapport au x264, je prends :)

Avec mes réglages actuels, je transforme en moyenne un mkv 1080p de 9 Go
en un x264 « HDlight » de moins de 3 Go, parfois autour de 2 Go, mais ça
dépend du type de film (action, dessin animé, etc.) et de son encodage
initial.

de plus il demande énormément de ressources pour son décodage ce qui le
rend illisible par bon nombre de périphériques de lecture (quand bien
même ceux-ci serait compatible H265/X265).

Je suis bien conscient de ce problème, mais on disait la même chose du
x264 il y a encore quelques mois, et j'ai pu en faire avaler sans soucis
à un téléviseur Samsung ayant 4 ou 5 ans d'âge [*].

Je constate en revanche une consommation effarante de ressources lors de
l'encodage en x264. J'ai un hexacore à 3.30 GHz avec 16 Go RAM (peu
utilisée dans ce type d'opération), il faut compter 5 heures en moyenne
pour mouliner un fichier de 9 Go (encodage en deux passes) avec une
consommation CPU de 95%.

Inutile de dire que je crains le pire quand je ferai un essai en x265,
sauf si l'algo d'encodage est moins gourmand que le x264.

j'avais noté à l'époque que le MPEG4 Part10 (H264, X264) était meilleur
que le MPEG4 Part2 (Xvid, DivX, MPEG4 ISO,...) lorsque les résolutions
augmentaient. à des résolutions modestes (inférieur à 480p) le gain en
terme de rapport qualité/poids était quasi négligable.

J'ai constaté la même chose.

j'en conclue que le H264 a été optimisé pour des résolution HD (entre
le 720p et le 1080p).

Idem. Il est d'ailleurs très efficace, au prix des contraintes décrites
ci-dessus.

qu'en est il pour le H265 ? je n'en sais rien. il a été crée pour la
diffusion du 4K, mais est il optimisé pour de la HD simple...?

Optimisé je ne sais, pas, mais efficace en termes de gain de compression
à qualité équivalente, d'après les exemples que j'ai pu voir, c'est
certain.

j'ai fait des tests d'encodage H265 avec ffmpeg.
j'utilise ces paramètres :
ffmpeg -i INPUT.XXX -c:v libx265 -preset medium -x265-params crf(
-c:a aac -strict experimental -b:a 128k OUTPUT.MKV

Merci pour ces paramètres ainsi que ceux proposés dans ton autre
message. Je vais essayer de les comprendre, puis de faire des tests avec
Handbrake, en jouant sur les curseurs disponibles.

Il semble que le gain principal vienne de la possibilité de fortement
baisser le bitrate sans perte de qualité, l'algorithme étant capable
d'extrapoler pour reconstituer l'image (au prix d'une importante
consommatioon de ressources et il faut que le matériel suive, nous
sommes d'accord).

Bon, je dis ça avec mes mots sans être certain de bien exprimer (ni de
comprendre) ce que je veux dire :)

[*] Par rapport à VLC (c'est ce que je connais de plus évolué en lecteur
« universel ») sur un ordinateur, d'après mon expérience, les
principales limitations rencontrées sur des box, lecteurs de salons
et autres téléviseurs, concernent certains paramètres d'encodage et
certains codecs, surtout audio bizarrement. J'en tiens compte quand
j'encode en suivant les conseils prodigués sur le blog que je
citais, mais j'ai souvent des surprises avec les trucs récupérés ici
ou là. Mais c'est un autre sujet, si ça intéresse, je suggère
d'ouvrir un nouveau fil pour en parler.

Bonsoir,

Olivier B. (Wed, 11 Feb 2015 14:47:08 +0100 -
fr.rec.son-image.video.realisation) :

j'ai eu exactement la même démarche que toi, mais à l'envers, lorsque
je me suis équipé en vidéoprojecteur HD avec une diagonale de 100
pouces, j'ai du refaire ma vidéothèque avec des versions de 10Go
minimum (en deça je vois maintenant la différence de qualité) là ou un
peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela
je ne voyais pas de différence).

Je suppose que tu es parti des enregistrements « originaux », car de ce
que je sais, une fois une compression avec perte réalisée, l'opération
inverse est impossible.

A méditer donc, si tu compte plus tard t'équiper en plus grand...

Je ne compte pas, je n'ai même pas de téléviseur, alors un
vidéoprojecteur... Je regarde mes vidéos sur un écran informatique de
27" 1920 x 1080, et pour avoir essayé (j'en passe à mes parents plus
quelques amis), ça reste plus que correct en 1080p « HDlight » sur des
écrans de télé jusqu'à 46 pouces.

Un copain disposant d'un vidéoprojecteur (je ne connais pas la taille
mais c'est forcément plus de 46 pouces) s'est dit bluffé par la qualité
d'un film que je lui ai passé (Pride 2014 1080p x264 AC3 5.1 MULTI -
2.63 Go), mais je crois qu'il ne dispose que d'un lecteur de DVD, pas de
Bluray, ceci pouvant expliquer cela.

Ce que tu peux aussi faire, c'est encoder en 720 afin de vérifier si
tu vois la différence de qualité dans tes conditions de visionnage,

Pour peu que la vidéo originale soit en vrai 1080p, je vois la
différence (testé sur des épisodes de Gotham pour prendre un exemple
récent).

parcequ'en deça d'un certain débit on a tellement enlevé de détail
qu'on ne voit plus de différence entre le 720 et le 1080, et parfois
on visionne tout simplement de trop loin pour faire la différence
entre du 1080 et du 720, un test en aveugle peut être nécéssaire pour
être réelement objectif dans le choix.

Le débit (bitrate ?), si j'ai bien tout suivi, est justement LE
paramètre qui semble important à régler correctement, que ce soit en
x264 ou x265, pour maximiser le rapport qualité/poids du résultat final.

C'est un peu sur le ratio à appliquer que j'espérais des conseils, un
peu comme dans le tableau fourni dans le didacticiel consacré au x264
que je citais, mais il n'existe visiblement pas encore l'équivalent pour
le x265 ; j'ai peut-être mal cherché.

Par contre je suis fort interressé par ton retour d'utilisation du 265
car je pense l'utiliser dans le cadre professionel.

Comme répondu à Alf92, je vais faire des tests en me basant à la fois
sur mes maigres connaissances en la matière et sur les paramètres qu'il
m'a fourni, qu'il me reste à comprendre et à transposer pour les faire
avaler à Handbrake.

Quand, en revanche, je ne sais pas, quand j'aurai le temps et j'ai
tendance à en manquer. Si je me lance, j'essaierai quelques variations
d'encodage sur une séquence de 4 ou 5 minutes, puis je les mettrai à
disposition pour vous (collectif) permettre de comparer.

Merci pour vos réponses à Alf92 et toi, je suis content que le sujet
intéresse, et ça prouve que Usenet non seulement n'est pas mort, mais
s'avère encore parfois plus efficace que le ouibe :)n

Eric Demeester :

Alf92 :

de plus il demande énormément de ressources pour son décodage ce qui le
rend illisible par bon nombre de périphériques de lecture (quand bien
même ceux-ci serait compatible H265/X265).

Je suis bien conscient de ce problème, mais on disait la même chose du
x264 il y a encore quelques mois,

qques années :-)

et j'ai pu en faire avaler sans soucis
à un téléviseur Samsung ayant 4 ou 5 ans d'âge [*].

oui, depuis l'avènement de la TNT HD dont le flux est en H264 1080p.

Je constate en revanche une consommation effarante de ressources lors de
l'encodage en x264. J'ai un hexacore à 3.30 GHz avec 16 Go RAM (peu
utilisée dans ce type d'opération), il faut compter 5 heures en moyenne
pour mouliner un fichier de 9 Go (encodage en deux passes) avec une
consommation CPU de 95%.

ça me semble vraiment bcp pour du H264.
avec un i3 double coeur j'encode un film en simple passe H264-720p en
environ une heure.

Inutile de dire que je crains le pire quand je ferai un essai en x265,
sauf si l'algo d'encodage est moins gourmand que le x264.

le H265 est *vraiment* bcp plus gourmand : au moins 3 fois plus de
temps sur mon i3 !

j'ai fait des tests d'encodage H265 avec ffmpeg.
j'utilise ces paramètres :
ffmpeg -i INPUT.XXX -c:v libx265 -preset medium -x265-params crf(
-c:a aac -strict experimental -b:a 128k OUTPUT.MKV

Merci pour ces paramètres ainsi que ceux proposés dans ton autre
message. Je vais essayer de les comprendre, puis de faire des tests avec
Handbrake, en jouant sur les curseurs disponibles.

Il semble que le gain principal vienne de la possibilité de fortement
baisser le bitrate sans perte de qualité, l'algorithme étant capable
d'extrapoler pour reconstituer l'image (au prix d'une importante
consommatioon de ressources et il faut que le matériel suive, nous
sommes d'accord).

pour l'encodage essaye ffmpeg, c'est au final le plus simple à
utiliser/paramétrer une fois que l'on a compris les 2 ou 3 rudiment de
la ligne de commande.
possible aussi qu'il soit bcp plus rapide que Handblake.

pour le télécharger :
32bits :
http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-latest-win32-static.7z
64bits :
http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-latest-win64-static.7z

tu mets la video dans le même dossier que ffmpeg.exe et tu lances le
fichier de procédure (fichier.BAT éditer avec le bloc-note dans lequel
tu auras copier la formule magique).

Bonjour,

Alf92 (Wed, 11 Feb 2015 21:53:09 +0100 -
fr.rec.son-image.video.realisation) :

le H265 est *vraiment* bcp plus gourmand : au moins 3 fois plus de
temps sur mon i3 !

Arg !

pour l'encodage essaye ffmpeg, c'est au final le plus simple à
utiliser/paramétrer une fois que l'on a compris les 2 ou 3 rudiment de
la ligne de commande.

Je vais suivre ton conseil et tester, pour ce qui est de la ligne de
commande, administrant des serveur Unix à distance via SSH en mode
console, ça ne devrait pas me poser problème :)

possible aussi qu'il soit bcp plus rapide que Handblake.

La comparaison sera difficile à faire, je suppose que ça doit dépendre
dépendre des choix d'encodage et du nombre de paramètres à traiter.

Il me semble d'ailleurs qu'Handbrake embarque ffmpeg à qui il délègue un
certain nombre de tâches.

tu mets la video dans le même dossier que ffmpeg.exe et tu lances le
fichier de procédure (fichier.BAT éditer avec le bloc-note dans lequel
tu auras copier la formule magique).

Je devrais y arriver :)

Le 11/02/2015 21:53, Alf92 a écrit :

Je constate en revanche une consommation effarante de ressources lors de
l'encodage en x264. J'ai un hexacore à 3.30 GHz avec 16 Go RAM (peu
utilisée dans ce type d'opération), il faut compter 5 heures en moyenne
pour mouliner un fichier de 9 Go (encodage en deux passes) avec une
consommation CPU de 95%.

ça me semble vraiment bcp pour du H264.
avec un i3 double coeur j'encode un film en simple passe H264-720p en
environ une heure.

Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas
grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et
il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même)
de l'un à l'autre.

En preset "slow", j'encode à peu près en temps réel une résolution DVD
sur 2,5 coeurs d'un i5 de 2011.

pehache :

Alf92 :

ça me semble vraiment bcp pour du H264.
avec un i3 double coeur j'encode un film en simple passe H264-720p en
environ une heure.

Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas
grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et
il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même)
de l'un à l'autre.

720p / H264-AVC 2200kbps / AAC 128kbps / profil High@L2.1 simple passe

Alf92 :

pehache :

Alf92 :

ça me semble vraiment bcp pour du H264.
avec un i3 double coeur j'encode un film en simple passe H264-720p en
environ une heure.

Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas
grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et
il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même)
de l'un à l'autre.

720p / H264-AVC 2200kbps / AAC 128kbps / profil High@L2.1 simple passe

ffmpeg -i INPUT.XXX -r 25 -b:v 2200k -bt 1000k -s 1280x720 -sws_flags
bilinear -aspect 1.7777 -vcodec libx264 -ac 2 -ar 48000 -b:a 128k -c:a
aac -strict experimental OUTPUT.MKV