Salut à tous.
Je me suis lancé dans l'archivage/convertion d'anciennes vidéos en format cassette 8mm.
Chaque cassette fait environ 1h et chaque rip brut pèse environ 13Go/cassette... Pas facile de stocker tout ça dans le cloud!
Surtout que j'ai 16 cassettes...
je vais donc les compresser via handbrake pour gagner de la place.
Au niveau des vidéos, les rips bruts sont des .dv, en 720x576, 25fps, avec un débit de 24.4Mbit/sec...!
Niveau son, c'est plus simple, une simple conversion en mp3 160kbps devrait etre largement suffisant.
Sauf qu'andbrake demande une conversion par modification du "quality factor" ou du bitrate.
J'ai une nette préférence pour le bitrate.
Sauf que je n'ai aucune idée du choix optimal de ce bitrate...
D'apres vous, sachant que la résolution ne va pas bouger, quel serait le bon bitrate à choisir?
A peu pres hein, pas la peine d'etre super précis!
Je voudrais garder une qualité optimale, sachant que la source, c'est pas de la 4K...  
un chiffre à proposer?
Merci!

Bonjour,
J'ai longtemps cherché la bonne définition, sans la trouver. Comme je stocke mes vidéos sur un serveur, et que j'ai installé Chromecast sur mon téléviseur, j'utilise la compression préconisée par Google. Soit :
-vidéo H264 ; 720 x 576 ; 25 i/s ; débit 2 Mb/s
-audio AAC+ Version 2 ; 128 Kb/s
 
Par exemple : j’obtiens un fichier de 430 mo pour 28 minutes de film. Et la qualité est tout à fait acceptable.

Nickel, tu confirmes ce que je pensais.
Je viens de réaliser des petits tests vite fait entre 1?5 et 3Mb/sec et je dois avouer que la différence n'est pas flagrante!
Par contre il faut choisir l'encodage le plus lent possible.
Je sens que mon PC va tourner à fond pendant un moment!
Actuellement sous linux, handbrake n'utilise pas ma 660 GTX.
Mais j'ai un dual boot avec W7 que je n'utilise quasi jamais.
Je pensais utiliser la CG pour accélérer l'encodage.
Ya un truc de particulier à faire sous windows pour activer cette fonction?

Pourquoi ? C'est un "a priori" ou un impératif de fixer le débit ?

En effet, donnant la même qualité de compression à débit identique, l'encodage en 2 passes (bitrate) est bien plus long qu'un encodage une passe (crf)

Cela dépend si vous voulez/pouvez jouer avec les paramètres du x264 ou pas.

Ya un truc de particulier à faire sous windows pour activer cette fonction?
Ce sont les programmes qui doivent être conçus pour utiliser les GPU.
Avec Handbrake, il y a une option qui permet d'utiliser la carte graphique :
Il faut choisir l'option bicubic au lieu de lanczos (source en anglais : https://trac.handbrake.fr/wiki/GPUAcceleration).

J'ai regardé vite fait la version windows, à priori ça ne fonctionne qu'avec un chip intel (quicksync), j'ai une cg nvidia...
Peut etre essayer l'option openCL...
Perso, je préfère utiliser le bitrate, car c'est plus parlant pour moi.
De plus, cela permet de calculer à l'avance la taille du fichier final, ce qui est important pour moi: les vidéos vont etre uploadées dans un cloud, donc une taille trop importante poserait un problème.

C'est bien compréhensible.
Dans ce cas, juste un conseil personnel (mais que l'on lit aussi ici et là sur le web) :  
si les vidéos sont de natures différentes, alors, avant de commencer chaque encodage, n'hésitez pas à faire un test de compressibilité pour avoir une idée de la complexité de la vidéo traitée (cela permet de ne pas fixer a priori un débit trop faible ou inutilement trop important), car il est difficile d'apprécier la chose a priori ;
si un test de compressibilité n'est pas envisageable, alors, en fin d'encodage (effectué avec la résolution d'origine bien sûr), vérifiez bien que le Final RateFactor (après passe n°1) obtenu soit compris entre 18 et 23 (s'il est inférieur à 18 alors le débit est inutilement trop important, s'il est supérieur à 23 alors la compression n'est pas optimale en qualité...)

Je suis convaincu qu'avec 2 Mb/s, un film DVD sera bien encodé. Mais je pense que ce débit est inutilement trop important bien souvent.
Pour d'autres genres de vidéos, des vidéos persos par exemple, alors 2 Mb/s est un minimum en ce qui me concerne.
Bref, pour dire, attention aux a priori.

Hello.
Comment vérifies tu apres compression le final rate factor?
J'ai tout compressé en x264 et ça fonctionne tres bien.
Mais je viens de mettre à jour ma version linux (cli et gtk) et maintenant, je peux compresser en x265.
Je viens de tester, c'est plus long, mais ça me permettrait de gagner encore un peu de place, ce qui dans mon cas n'est pas négligeable....
Par contre, j'ai gardé le meme débit, et j'obtiens donc logiquement la meme taille finale qu'en x264.
Ma question est donc:
en x265, quel devrait être le débit approximatif pour ce type de vidéo?

Quand le codec a terminé la première passe, il produit (à l'écran) des stats de ce genre :

(c'est un extrait de quelques lignes de stats d'un mini exemple sur lequel je viens de faire une passe n°1)

Ah pas mal, mais j'ai pas ça sous linux.
V voir du coté d'une activation de logs.
Le final ratefactor est du meme ordre en x265 ou pas du tout?

Un type a comparé les 2 et en a fait un pdf ;
http://forum.doom9.org/showthread. [...] ost1679062
Débit à peu près 3 fois moindre en x265 qu'en x264 à CRF égal mais durée d'encodage quasiment 10 fois plus élevée.
Il a posté d'autres comparatifs plus bas et des mkv à divers débits pages 2 et 3.

Ah merci pour cette info.
V donc pouvoir un peu baisser le bitrate.
Mais au final, vaut il mieux fixer avec un RF correct (on va dire 21 par ex), ou un encodage 2 passes avec au final un rf valant 21 environ?
Les RF sont ils transposables du x264 au x265?En gros, doit -on viser les memes RF?
J'ai fait un petit test sur mon pc, un quad core Q9550 avec 8Go de ram, proc non OC:
Par rip de cassette (13.5Go environ), il faut quasi 15h à mon pc pour faire la compression x265 en 2 passes!!!
Impressionnant quand meme...

Tout dépend si on a un impératif sur la taille finale du fichier.
 

Sur le document pointé par Arnuche (haut débit x264), on lit :
 
preset medium :
x264 crf 22 = x265 crf 22
x264 crf 20 = x265 crf 20
x264 crf 18 = x265 crf 16
 
preset slow :
x264 crf 21 = x265 crf 22
x264 crf 20 = x265 crf 20
x264 crf 18 = x265 crf 17
 
 
   

en effet. j'ai vu ça.
sauf que la résolution n'est pas indiquée.
Cela veut dire que ce ratio est indépendant de la résolution, ou pas?
Car dans mon cas, mes rushs bruts sont loin d’être de la 4K...!

Suis pas sur qu'un encodage pas trop exigeant sur la qualité finale soit si différent du rush brut...

Disons que si on n'a pas trop envie de chipoter sur les détails, on peut considérer que dans la plupart des cas le CRF est quasi pareil entre les 2 codecs. Donc si on n'a pas une taille précise à atteindre, il faut plutôt savoir quel CRF nous convient et on peut l'appliquer aux 2 codecs, surtout si on choisit un CRF de 20.

Tu vois où ce comparo ? Dans aucun des pdf il ne dit à quel CRF du x264 correspond un CRF du x265. Ou tu as comparé les données SSIM ?

En effet, j'ai simplement fait cela, vu qu'il n'y a pas d'autres mesures qualitatives dispo dans le document.

Je ne pense pas que la résolution joue dans ce genre de comparaison entre valeurs de crf.

Nickel.
Mon pc est plus que sur les rotules en ce moment, j'ai 300Go de rushs à compresser en x265...Dur pour un q9550!
Je me pose aussi la question du preset à utiliser.
J'avais pour habitude en x264 d'utiliser le preset very slow, qui est comme son nom l'indique vraiment très lent...Plus lent, ya que "placebo".
Je me demandais si au final, relever le preset à une valeur plus rapide pourrait me faire gagner du temps, sans trop dégrader le rendu final.
Avec quel preset compressez vous?

En x265, preset medium plus que recommandé. Passer au preset suivant "slow" c'est quasiment diviser par deux ou même 3 le temps d'encodage pour grapiller quelques misérables Mo.

ok, donc j'ai la main lourde quoi...!

le preset ne modifie que la taille du fichier ?
Mais si on fixe le bitrate, je ne vois pas pourquoi le preset medium et le preset slow donnent des fichiers de taille différente.
Je pensais qu'a bitrate fixé, le preset influerait sur la qualité de l'image et non sur la taille du fichier.

Ah oui, en effet!
Normalement, si le bitrate est fixé, la taille du fichier final ne peut pas bouger.
Donc, on fait varier la qualité de rendu?

Pour une taille de fichier fixée, ie un débit moyen fixé (encodage 2 passes), "slow" produit une meilleure qualité que "medium".
Pour une compression en mode crf à valeur fixée (encodage 1 passe), "slow" produit une même qualité que "medium", mais avec un débit moindre.

Tu voulais sans doute dire multiplier !

En fait les comparos de doom9 datent de 2014 et apparemment le x265 s'est nettement amélioré depuis donc on peut oublier les résultats ci-dessus  

 
Pas tout à fait vrai, concernant slow/medium  

 
Doc ffmpeg https://trac.ffmpeg.org/wiki/Encode/H.265

Ok arnuche, je suis d'accord, le document date un peu.
Le lien (récent ?) donné par crypo indique x265 crf 28 = x264 crf 23 en qualité, et moitié moindre en débit.
 
Crypto, je ne vois pas ce que ta citation contredit par rapport à ce que j'ai écrit. J'y vois même une confirmation. Pas d'accord ?