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

[shlagevuk]

Je reprend ici le topic (http://forum.canardpc.com/threads/103188-HEVC-x264-ici-on-parle-d-encodage-vid%C3%A9o) 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é) (http://www.techspot.com/article/1131-hevc-h256-enconding-playback/)

Pourquoi encoder une video sur 10bit est plus efficient (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)
Et la mise en pratique de ce principe avec des tests d'encodage (http://collab.debian.net/portal/planet-debian/steinar-h.-gunderson-10-bit-h.264-tests)
Merci Foudge (http://forum.canardpc.com/members/10907-Foudge)pour ces deux liens!

Nos canards sont exceptionnels, un zip complet comprenant un handbrake nightly avec les librairies pour encoder en 10/12bit (https://drive.google.com/file/d/0B6OvWEJz8V14Qm1ReC0tdUdtRWM/view?usp=sharing). Merci Squarealex (http://forum.canardpc.com/members/73162-Squarealex)!



Qu'est ce que le codec hevc? (https://fr.wikipedia.org/wiki/H.265/HEVC)

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 (https://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29#Architecture) (un peu avant en support partiel)
-Amd le gère depuis carrizo (https://en.wikipedia.org/wiki/Video_Coding_Engine#VCE_3.0)
-Nvidia le gère mais c'est le bordel (https://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_GPUs_containing_a_PureVi deo_SIP_block) 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 (https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-encoding-speed-1024x752.png)
Credit graphique (https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/)

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 (http://x265.readthedocs.org/en/default/presets.html#film-grain-retention)

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.

[XWolverine]

Parait que ça rame méchant avec un i5 3570K :ninja:

[MegABiloU]

J'en profite pour partager mes preset sur handbrake.

Sur cette machine

http://i.imgur.com/rQllMlP.png

avec ces paramètres :

http://i.imgur.com/525Xqgi.png
http://i.imgur.com/xOQHza4.png
http://i.imgur.com/OoWMmZg.png
http://i.imgur.com/GIaZ16L.png
http://i.imgur.com/UPoo7PS.png

En résumé

Sur la version stable de Handbrake : 0.10.2

Paramètres de l'image :
- Conservation des dimensiosn de l'image
- aucun filtre
- Framerate constant identique a la source
- Qualité constante RF 18
- x265 preset : medium
- x265 tune : psnr
- H.265 profile : main10

Paramètres du son :
quand la source est de bonne qualité (DTS)
- source séréo convertie en AAC fdk @192
- source 5.1 convertie en AAC fdk 5.1 @640

Sinon Bypass pour réutiliser la source.

J'encode environ à 7 ou 8 fps.

[rotoclap]

Alors question bête : y'a un vrai apport qualitatif à utiliser le profil Main10 si la source n'est codée en 10 bits ?

[MegABiloU]

C'est une bonne question au contraire.

à laquelle je n'ai pas la réponse

[Rocca]

Géniale l'idée du topic :love:


Parait que ça rame méchant avec un i5 3570K :ninja:
:p :p

[shlagevuk]

Alors question bête : y'a un vrai apport qualitatif à utiliser le profil Main10 si la source n'est codée en 10 bits ?

Il faudrait tester mais d'instinct je dirait non. Les artefacts présent avec des couleurs codé sur 8b ne seront pas "gommé" (lissé) en passant sur du 10b, en gros l'information a déjà été perdue, il n'y a pas de raison qu'elle réapparaisse après.

Par contre quant on s'y attarde, passer du 10b au 8b fait effectivement apparaître des bandes de couleur.
Exemple:
http://s23.postimg.org/ag6pdv0af/comparatif10b_8b.jpg (http://postimg.org/image/ag6pdv0af/)
(bon à la base c'était du bmp, là ça a un peu perdu du fait de la compression. Saurez-vous distinguer lequel est en x264/10b et l'autre x265/8b?)

Je me souviens d'avoir vu des bandes de ce type sur d'autre support pas forcément aussi bien encodé, surtout avant la démocratisation des profiles main10 et high10 du x264.

[XWolverine]

Déjà, si les blu-ray étaient encodés en 4:4:4, on aurait un intérêt à gérer le 10 bits, sinon, bof quoi.
D'ailleurs le successeur du BR pour la 4K, c'est toujours du 4:2:0 ?

[Taro]

Alors question bête : y'a un vrai apport qualitatif à utiliser le profil Main10 si la source n'est codée en 10 bits ?

Non. ;)

8 bits, c'est 8 fois 1 bit qui permet de stocker 0 ou 1. Soit 2^8 = 256 possibilités. En programmation c'est généralement un "char" qui pourra stocker de 0 à 255 (non signé) ou de -128 à 127 (signé).
En passant sur du 10 bits, on a 2^10 = 1024 possibilités. C'est clairement bien mieux puisqu'en non signé tu pourras stocker de 0 à 1023.

Cependant, quel intérêt d'avoir 1024 garages si tu n'as que 256 voitures ? Je vois un petit malin au fond qui lève la main, il va sûrement dire "oui mais un garage on peut y mettre autre chose qu'une voiture donc ça reste utile", je lui réponds "ta gueule, pète pas mon exemple".
En revanche, si t'as 1024 garages pour stocker tes 800 voitures, et que du jour au lendemain tu passes à 256 garages, oui tu vas devoir te débarrasser de certains de tes véhicules.

Réduire l'intervalle de valeurs alors qu'on l'exploite trop pour l'intervalle d'en-dessous induit forcément une perte d'information, et donc, généralement, une perte de qualité quand on parle d'encodage vidéo.
Augmenter l'intervalle n'apportera strictement rien.

0 ou 1 peuvent être stockés sur 1 bit. On aurait 8 bits, ça ferait 0000 0000 et 0000 0001, ça reste 0 et 1, ça n'a rien apporté.

J'espère avoir été clair dans mon explication ^_^

[shlagevuk]

J'ai enfin trouvé comment compiler ffmpeg avec le support 8/10/12b :lol:

C'était simple en fait, mais c'était tout planqué.

Le temps que je refasse une VM centos 7 propre et je vous donne la procédure.

[MegABiloU]

Je viens de voir un paramètre auquel j'avais du faire attention au début et que j'ai du oublier de recocher quand j'ai réinstallé handbrake.
C'est l'anamorphic.
Bref j'ai du oublier de remettre en strict pour conserver une définition fidèle à la source.
En réalité sur un film en 1080p le fait de choisir loose n'est que très peu perceptible.
Sans entrer dans le détail, on passe de 1920 x 1080 à 1872 x 1054.

le détail ici (https://trac.handbrake.fr/wiki/AnamorphicGuide#loose) (même si ça me semble un peu vieux comme dossier)

[rotoclap]

D'accord, merci pour vos réponses. Si je posais la question, c'est parce que sur une image avec 8 bits par canal, il y a un vrai intérêt à les passer en 16 bits le temps de triturer les niveaux dans Photoshop pour limiter les cassures dans les dégradés. Du coup, je me demandais si le profil Main10 avait le même genre d'apport sur une vidéo encodé en 8 bits avec des aplats de couleurs style ciel bleu ou coucher de soleil.

EDIT : je réponds à johnclaude ici du coup. Pour choisir le bitrate d'encodage, je me suis appuyé sur le tableau disponible sur cette page : http://www.lighterra.com/papers/videoencodingh264/

[MegABiloU]

Petit retour sur mes derniers encodages.

Donc quelques petites modifications notamment sur le paramètre Anamorphic.
Afin de respecter la définition de l'image il y a un paramètre avec lequel j'ai eu des soucis : le cropping.

Donc dans Handbrake onglet picture voici les modifications :
- Anamorphic : Strict
- Cropping : Custom
- Top : 0
- Left : 0
- Right : 0
- Bottom : 0

Ensuite pour ce qui est de l'onglet video voici les paramètres que j'utilise sur des sources en H.264 a bitrate < 11MBps
- video codec : H.265 (x265)
- Framerate (FPS) : Same as source - Constant Framerate
- Quality : Constant Quality RF18
- Encoder Preset : Medium
- Encoder Tune : PSNR
- Encoder Profile : Main
(pour une vidéo d'environ 50 minutes avec 2 pistes en 5.1 AAC @576 on est entre 1.2Go et 2Go)

Variante pour les sources > 11MBps
- video codec : H.265 (x265)
- Framerate (FPS) : Same as source - Constant Framerate
- Quality : Avg Bitrate @3500 - 2Pass Encoding
- Encoder Preset : Medium
- Encoder Tune : PSNR
- Encoder Profile : Main
(pour une vidéo d'environ 50 minutes avec 2 pistes en 5.1 AAC @576 on est environ à 1.6Go)

Audio
J'ai choisi un compromis afin de conserver un qualité correcte compatible tous supports AAC FDK @576 pour 6 canaux et AAC FDK @192 pour 2 canaux. Exit les DTC DOLBY et AC3 propriétaires.

Sur la dernière nightly le paramètre FDK disparait on retourne sur AAC plus d'infos ici (https://trac.handbrake.fr/changeset/0ba02795a907ca86fb220d349777e628f1a0314e)

Ces paramètres sont utilisés pour de la vidéo standard en 1080p, je pense faire des essais sur des films et séries d'animation ce qui ne devrait pas nécessiter de bitrate trop élevé a mon avis du H.265 @1500 doit pouvoir avoir un bon rendu, et je vais également essayer en constant quality voir ce que ça donne.

[MegABiloU]

Petit retour d'encodage sous handbrake à partir d'une source non compressée (blu ray)

J'ai lancé un test sur un épisode de 1h environ en HEVC 1080p piste 2.0 FR et 5.1 Anglais + pistes sous titres.

En MKV.
Profil main PSNR @RF17
AAC FDK 2.0 @192
AAC FDK 5.1 @576

J'ai pas encore fini mais en gros j'ai un peu plus de 4h d'encodage pour un un résultat prévisionnel de 5Go l'épisode.
J'ai mis en file d'attente un preset en avg bitrate @2500 et 3500 en 2-pass pour essayer d'obtenir une taille de fichier un peu moins conséquente.

[rotoclap]

Ah ouais quand même parce qu'un épisode d'1h en 1080p h264 en temps normal, ça tourne autour de 2Go.

[gregounech]

Ah ouais quand même parce qu'un épisode d'1h en 1080p h264 en temps normal, ça tourne autour de 2Go.

En qualité dégeulasse oui.

[MegABiloU]

Résultat environ 4.69Go.

Du coup j'ai lancé l'encodage en 2500 pour voir ce que ça donne. Edit : taille finale 850Mo

Et en 3500 pour essayer de rester sur une qualité correcte tout de même. (normalement environ 1.5Go par épisode)

Pour info le fichier m2ts non compressé fait 13.7Go (inclus les pistes son en DTS en 5-6 langues) et a un débit vidéo de 39Mo/s

[Taro]

En rippant mes Blu-Ray d'animés vers du HEVC h265, deux pistes audio en AAC 192bits 48kHz et une piste de sous-titres, avec RipBot264, ça va de 600 Mo à 1.6 Go pour les extrêmes, avec la plupart des épisodes entre 800 Mo et 1 Go.
Pour des épisodes de généralement 20-25 minutes.
Qualité impeccable pour le coup.

[MegABiloU]

Oui et c'est normal que les animes soient un peu plus légers que les films/ série, cela vient du fait que les images sont moins complexes et il y a beaucoup plus de plan fixes.

Il n'y a pas besoin d'un bitrate très élevé pour obtenir un fichier de bonne qualité pour un anime.

[Rocca]

Super les infos MegABilou on pourra s'appuyer dessus pour les futurs encodages ;)

[Taro]

Oui et c'est normal que les animes soient un peu plus légers que les films/ série, cela vient du fait que les images sont moins complexes et il y a beaucoup plus de plan fixes.

Euuuh... ça dépend des animés. Et justement je trouve ça déjà plutôt gros d'avoir des épisodes de jusqu'à 1.6 Go selon l'animé.
Peu importe, c'est la qualité qui est importante et c'est toujours moins gros que de conserver les ISOs des Blu-Ray (ce que je fais en attendant d'avoir procédé à l'encodage), mais quand même, 1.6 Go pour 20 et quelques minutes, c'est plutôt gros non ?

A vous de me le dire, je suis plutôt averti au sujet du principe de la compression vidéo, mais en ce qui concerne les tailles "normales" obtenues d'un codec à l'autre, pour ça, je manque de recul.

[weedkiller]

Oui et c'est normal que les animes soient un peu plus légers que les films/ série, cela vient du fait que les images sont moins complexes et il y a beaucoup plus de plan fixes.

Il n'y a pas besoin d'un bitrate très élevé pour obtenir un fichier de bonne qualité pour un anime.
C'est quand même assez particulier, il faut à la fois avoir des aplats parfaits avec des jolis contours non crénelés sur les parties mobile, et conserver les détails dans les décors. C'est assez chaud de trouver les réglages car ca s'oppose vachement. Alors qu'un film, les niveaux de détails sont plus ou moins bon, mais similaires dans toutes les scènes.

[MegABiloU]

ça dépend pas mal de la réalisation du type de caméras etc mais je suis d'accord.

[Taro]

Je peux envoyer un épisode sur un hébergeur, si vous voulez le récupérer et me dire ce que vous en pensez niveau qualité.

[MegABiloU]

si tu veux je fais pareil avec mes 3 versions.

[Taro]

Je lance l'upload de trois épisodes (trois animés différents), un de 694 Mo, un de 876 Mo et un de 1.60 Go.
J'ai beau avoir une méga-fibre, selon les hébergeurs le débit est quand même assez limité, ça risque de prendre du temps. Je filerai sûrement les liens demain.

[MegABiloU]

J'ai lancé 3 upload sur mega ca va assez vite j'ai déjà fini d'uploader la version 2500.

[Taro]

C'est curieux, j'ai choisi Mega aussi, et j'uploade à environ 1 Mo/s... Alors que ma fibre permet bien mieux...
http://www.speedtest.net/result/5160391054.png

Une fois j'avais envoyé des trucs sur Uptobox, ça envoyait bien, plus de 30 Mo/s, mais les limitations en téléchargement (hors Premium évidemment) sont trop importantes.

[MegABiloU]

Moi j'ai 10Mb en up donc 1.2Mo/s c'est mon maximum.

[Taro]

Oui du coup on a pareil sauf que tu ne constates pas la limitation... c'est ton "assez vite" que j'ai pas interprété comme il faut en fait ^_^

[Taro]

Je suppose que ce serait contre les règles du forum d'afficher ça ouvertement ici, donc pour ceux qui veulent voir les trois épisodes, ils sont prêts, passez en MP pour me demander les liens. ;)

[MegABiloU]

Je vais refaire ma version en 3500 ya un truc pas clair.

[rotoclap]

En qualité dégeulasse oui.

My bad, c'est plutot 2,4Go. Ca reste quand même toujours 2x plus petits que les 5Go obtenus ici. Et non, c'est pas dégueulasse, je vais pas te donner les sources, mais c'est un peu la "norme" en matière d'épisode et c'est bien assez pour conserver le grain de l'image.

[MegABiloU]

en HEVC ou x264 hdlight?

Si c'est en hdlight x264 normalement ce sont des paramètres très spécifiques mais en effet le résultat est surprenant.

[Taro]

Quand on passe des ISOs des Blu-Ray aux MKV des épisodes / du film, comme moi, peu importe que ça fasse 2, 4 ou 8 Go, tant que ça pèse moins que l'ISO de 40 Go. :ninja:

[MegABiloU]

Moi j'essaie de faire tenir une saison entière (12-13 ép) sur environ 25Go.

[Taro]

Bah pour mes animés, 12-13 épisodes ça représente deux Blu-Ray, et potentiellement donc entre 60 et 80 Go.
Ça me fait relativiser la taille des vidéos MKV que j'obtiens ! :)

[Rocca]

Bah pour mes animés, 12-13 épisodes ça représente deux Blu-Ray, et potentiellement donc entre 60 et 80 Go.
Ça me fait relativiser la taille des vidéos MKV que j'obtiens ! :)

En ajoutant à ça que le moindre HDD de nos jours fait au minimum 500 Go et qu'on est sur un standrard (3,5 pouces) de 2 To en moyenne... :p

[MegABiloU]

Bah pour mes animés, 12-13 épisodes ça représente deux Blu-Ray, et potentiellement donc entre 60 et 80 Go.
Ça me fait relativiser la taille des vidéos MKV que j'obtiens ! :)

Enfin je parle sur des épisodes format 45min 1h, pour des séries de 25min par ep tu double le nombr d'épisodes par BR de 25Go.

- - - Mise à jour - - -


En ajoutant à ça que le moindre HDD de nos jours fait au minimum 500 Go et qu'on est sur un standrard (3,5 pouces) de 2 To en moyenne... :p

Tss 500Go - 2To

Depuis qu'ils existent je n'achète plus que des 6To.

[Taro]

En ajoutant à ça que le moindre HDD de nos jours fait au minimum 500 Go et qu'on est sur un standrard (3,5 pouces) de 2 To en moyenne... :p

Oui mais ça par contre ça va vite... :wacko:

J'ai un SSD de 120 Go pour l'OS et quelques programmes courants
+ 500 Go en 3.5" 7200 Tr pour les jeux (et les fichiers temporaires au démux avant encodage)
+ 500 Go en 3.5" 5400 Tr pour les programmes "ordinaires"
+ 2 To en 3.5" 5400 Tr pour les données (qui récemment a failli être plein à causes des ISOs de Blu-Rays, ce qui a fait que j'ai ajouté le suivant qui était là en rab depuis l'achat récent d'un laptop + SSD pour remplacer ledit disque)
+ 500 Go en 2.5" pour le reste des données

A un instant "t" j'avais mon dossier de vidéos, incluant tout (animés, vidéos/émissions de jeux, films, ISOs de Blu-Rays...) qui était à plus de 1.5 To... :p

[MegABiloU]

Moi j'ai un ssd de 250Go pour l'OS et les soft sur lequel je stock temporairement mes fichiers encodés (moins d'une semaine)
1x 2To en 7200 tours pour mes sources mes jeux.
Et je balance tout sur un de mes NAS qui lui a tonne de disques :)
Et je lance le pc de backup (30To utiles sur une grappe Jbod avec partition de 100Go pour l'OS) 1 a 2 fois par semaine pour une synchro avant stockage a froid.

[Taro]

:o ce grand malade ^_^

[MegABiloU]

Je viens de regarder l'épisode que j'ai encodé en 3500 la qualité est vraiment très bonne.

[MegABiloU]

@Tarounyu sur ta vidéo c'est normal que dans les scenes de mouvement on voit énormément les interlignes?

C'est un peu dommage car sinon la qualité est bonne.
Ca vient d'un réglage de ton logiciel?

[Taro]

Tu parles de quelle vidéo ? Tu as un exemple d'un instant "t" où je peux le constater ?

[MegABiloU]

oui voir ce lien

http://imgur.com/a/b0OAI

zomer pour comparer

La version du bas est un rip x264 en 720p

[Taro]

Ah oui mais c'est carrément dégueulasse ça !
Bah les réglages, il y en a peu, j'utilise RipBot264...
Tain je suis dég du coup car oui sinon c'est super propre...

[rotoclap]

Ce qui est dégueulasse c'est qu'on est en 2016 et qu'il existe encore des sources entrelacées... Mais merde quoi, le tube cathodique c'est fini depuis belle lurette ^_^

[weedkiller]

Sait tu qu'en avril 2016, la télé passe enfin au h264 mais diffuse en 1080i :trollface: :mercilafrance: ? :tired:

[rotoclap]

C'est peut-être une contrainte de débit qui explique l'entrelacé pour la diffusion TNT (et encore, c'est juste qu'on est des grosses buses en France). Par contre sur un DVD ou un BluRay, aucune excuse.

[MegABiloU]

Oui je pense que c'est une contrainte de débit.

[Taro]

Petites questions aux confirmés et experts...

Je démux, encode et remux mes Blu-Ray via RipBot264.

Généralement ce sont des ISOS de 30 à 45 Go, avec du H264 en vidéo et un peu de tout en audio et sous-titres, mais ça à la limite ça joue moins.
Je convertis ça en HEVC/H265 en mode CQ (Constant Quality, je suppose), avec comme CRF (Constant Rate Factor, je suppose) 16 qui semble être le plus intensif en calcul CPU.
(L'autre mode est 2-pass pour lequel le paramètre semble être le débit - Kbps - et qui permet de verrouiller une taille pour le fichier cible)

L'encodage prend longtemps : jusqu'à plus de 3h sur un i7 4 coeurs / 8 threads @4Ghz (fréquence hors turbo).

Voici les films encodés jusque-là, dans l'ordre alphabétique qui est aussi l'ordre dans lequel je les ai rippés :

Batman - Begins, 2h20, 5.49 Go
Batman - The Dark Knight Rises, 2h44, 6.76 Go
Fight Club, 2h19, 11.5 Go (...wow ! C'est gros !)
Gladiator, 2h34, 13.3 Go (...wow ! C'est gros !)
Imitation Game, 1h54, 5.35 Go
Interstellar, ??, 1.05 Go, pas d'aperçu dans l'explorateur, VLC peut ouvrir le fichier mais si je me déplace genre au tiers la lecture s'arrête
Kingsman, ??, 2.75 Go, pas d'aperçu non plus, VLC ne le lit pas, pas d'erreur critique mais c'est comme si le film ne comportait aucune image
Le Hobbit - Un Voyage Inattendu, 2h49, 9.62 Go


Première (série de) question(s) :
J'ai des tailles assez disparates. Pour la même durée on passe grosso-modo du simple au double entre Batman Begins et Fight Club.
Est-ce logique ? De par le Constant Quality, la vidéo cible prend plus ou moins de gras, en fonction des couleurs / mouvements / plans ?

Deuxième question :
J'ai deux fichiers successifs, de taille anormalement ridicule et qui sont en quelque sorte corrompus.
Comme Le Hobbit a été fait le même jour, juste après les deux en question, et dans les mêmes conditions, je me dis qu'il y a peut-être des soucis dans l'outil que j'utilise...
Je vais les refaire faire demain, avec les mêmes paramètres mais en les recommençant à zéro, je supprimerai donc les données temporaires et recommencerait le démux, puis l'encodage, etc.
Néanmoins, vous avez une autre méthode assez simple à gérer ? En termes d'étapes, je veux dire. Je suis assez familier avec l'encodage et le concept de la compression vidéo, et je suis développeur de métier donc je suis capable d'utiliser à peu près n'importe quel logiciel à plus de 7 boutons sans décéder, cependant l'intérêt que je reconnais à RipBot c'est d'être capable de prendre en charge toutes les étapes : analyse des pistes, sélection de ce qu'on garde, démux, sélection de l'encodage, encodage et remux, au final si on ne considère pas l'attente du démux une fois que tout est paramétré ça se fait d'une traite (du coup en réalité c'est en deux parties).

[MegABiloU]

Perso je ne jure que par handbrake :)

a mon avis pour tes fichiers corrompus je pense que ton logiciel a planté en cours d'encodage.

Et pour les divergences de taille bah ça peut s'expliquer par pas mal de choses mais généralement la taille en sortie dépend du bitrate en entrée.

[Taro]

Je pense aussi qu'il y a eu un bug en cours de traitement. Dommage... Je n'ai pas d'explication sur pourquoi ces deux là et pas les autres, mais bon. :sad:

Pour les tailles les ISOS sont globalement très proches en taille d'origine, après peut-être que les variations des pistes vidéos sont plus importantes, après tout en fonction du nombre de pistes audio c'est vrai que ça peut pas mal varier.
Dans tous les cas la qualité est très bonne, je vais les regarder quand même un par un à l'occasion pour voir si je détecte pas ces interlignes dégueu que tu avais détecté sur un des animés que j'ai fourni comme sample.

Tu pourrais me faire un petit topo de ta démarche et de tes paramètres sur handbrake, s'il te plait ? Ce serait vachement cool. Je m'en remets à votre enseignement :prey:

[MegABiloU]

ouais
pas de souci.

[Taro]

Ça c'est cool ^_^

On peut en discuter sur le topic ou par MP, comme tu préfères.

[shlagevuk]

Petites questions aux confirmés et experts...

Je démux, encode et remux mes Blu-Ray via RipBot264.

Généralement ce sont des ISOS de 30 à 45 Go, avec du H264 en vidéo et un peu de tout en audio et sous-titres, mais ça à la limite ça joue moins.
Je convertis ça en HEVC/H265 en mode CQ (Constant Quality, je suppose), avec comme CRF (Constant Rate Factor, je suppose) 16 qui semble être le plus intensif en calcul CPU.
(L'autre mode est 2-pass pour lequel le paramètre semble être le débit - Kbps - et qui permet de verrouiller une taille pour le fichier cible)

L'encodage prend longtemps : jusqu'à plus de 3h sur un i7 4 coeurs / 8 threads @4Ghz (fréquence hors turbo).

Voici les films encodés jusque-là, dans l'ordre alphabétique qui est aussi l'ordre dans lequel je les ai rippés :

Batman - Begins, 2h20, 5.49 Go
Batman - The Dark Knight Rises, 2h44, 6.76 Go
Fight Club, 2h19, 11.5 Go (...wow ! C'est gros !)
Gladiator, 2h34, 13.3 Go (...wow ! C'est gros !)
Imitation Game, 1h54, 5.35 Go
Interstellar, ??, 1.05 Go, pas d'aperçu dans l'explorateur, VLC peut ouvrir le fichier mais si je me déplace genre au tiers la lecture s'arrête
Kingsman, ??, 2.75 Go, pas d'aperçu non plus, VLC ne le lit pas, pas d'erreur critique mais c'est comme si le film ne comportait aucune image
Le Hobbit - Un Voyage Inattendu, 2h49, 9.62 Go


Première (série de) question(s) :
J'ai des tailles assez disparates. Pour la même durée on passe grosso-modo du simple au double entre Batman Begins et Fight Club.
Est-ce logique ? De par le Constant Quality, la vidéo cible prend plus ou moins de gras, en fonction des couleurs / mouvements / plans ?

Deuxième question :
J'ai deux fichiers successifs, de taille anormalement ridicule et qui sont en quelque sorte corrompus.
Comme Le Hobbit a été fait le même jour, juste après les deux en question, et dans les mêmes conditions, je me dis qu'il y a peut-être des soucis dans l'outil que j'utilise...
Je vais les refaire faire demain, avec les mêmes paramètres mais en les recommençant à zéro, je supprimerai donc les données temporaires et recommencerait le démux, puis l'encodage, etc.
Néanmoins, vous avez une autre méthode assez simple à gérer ? En termes d'étapes, je veux dire. Je suis assez familier avec l'encodage et le concept de la compression vidéo, et je suis développeur de métier donc je suis capable d'utiliser à peu près n'importe quel logiciel à plus de 7 boutons sans décéder, cependant l'intérêt que je reconnais à RipBot c'est d'être capable de prendre en charge toutes les étapes : analyse des pistes, sélection de ce qu'on garde, démux, sélection de l'encodage, encodage et remux, au final si on ne considère pas l'attente du démux une fois que tout est paramétré ça se fait d'une traite (du coup en réalité c'est en deux parties).


Sur les questions de taille/durée, déjà c'est très rapide. 3h pour encoder un film complet en x265 ça veut dire que tu es proche des 20fps et c'est très bien!
Pour la taille, c'est dépendant du paramètre de vitesse (placebo, ultraslow, slower, slow, normal, fast, faster, ultrafast). Ce paramètre va faire varier le taux de compression. C'est a dire qu'a qualité constante tu aura un fichier plus petit si tu prend des paramètre plus "lent" et à taille constante tu aura une meilleure qualité.
Typiquement si c'est ton logiciel qui gère le taux de compression en fonction d'une analyse du grain/qualité de la source ce paramètre peut varier et expliquer la différence de taille entre tes fichiers.
J'avais fait des test avec la video bunnymachin, J'avais lancé de placébo à ultrafast avec le temps nécessaire. Tu peux avoir un facteur de 3 sur la taille de la video de sortie. (50mo à 130mo sur la source en 720p@24fps, CRF constant)

Pour les films "noir" sans image je pense que ton demuxer a planté, ne pouvant pas fournir d'image à encoder il a continué a remplir ton conteneur video avec juste le son/ss titre. Regarde tes log d'encodage pour plus d'info ou découpe ton process pour check si les vidéo demuxé sont lisible.

[Taro]

Sur les questions de taille/durée, déjà c'est très rapide. 3h pour encoder un film complet en x265 ça veut dire que tu es proche des 20fps et c'est très bien!
Pour la taille, c'est dépendant du paramètre de vitesse (placebo, ultraslow, slower, slow, normal, fast, faster, ultrafast). Ce paramètre va faire varier le taux de compression. C'est a dire qu'a qualité constante tu aura un fichier plus petit si tu prend des paramètre plus "lent" et à taille constante tu aura une meilleure qualité.
Typiquement si c'est ton logiciel qui gère le taux de compression en fonction d'une analyse du grain/qualité de la source ce paramètre peut varier et expliquer la différence de taille entre tes fichiers.
J'avais fait des test avec la video bunnymachin, J'avais lancé de placébo à ultrafast avec le temps nécessaire. Tu peux avoir un facteur de 3 sur la taille de la video de sortie. (50mo à 130mo sur la source en 720p@24fps, CRF constant)

Pour les films "noir" sans image je pense que ton demuxer a planté, ne pouvant pas fournir d'image à encoder il a continué a remplir ton conteneur video avec juste le son/ss titre. Regarde tes log d'encodage pour plus d'info ou découpe ton process pour check si les vidéo demuxé sont lisible.

Oui c'est vrai qu'en y repensant c'est pas si long. Mais en même temps c'est sur le i7-6700K. :)

Concernant les paramètres, je suis en CQ et j'ai réglé le CRF au minimum, soit 16. Le reste des paramètres est sous le capot de l'outil, je n'ai pas à les définir.
Ça se tient, il vise une certaine qualité, et en fonction du film le résultat est plus ou moins gros à durée égale. Finalement c'est logique que Batman soit plus compact que Fight Club, le premier est moins riche en couleurs et est composé essentiellement de tons de noirs très présents, la compression doit permettre de gagner plus d'espace.

Ta suggestion est intéressante. Je sais où sont stockés les pistes démuxées que je sélectionne comme "à garder" avant le démuxage, j'ai repréparé l'encodage des deux films en questions, ils doivent attendre que deux autres soient finis mais une fois faits je pourrai les regarder et zieuter les pistes démuxées si le problème a réapparu. :)

[MegABiloU]

tiens un article intéressant avec quelques réglages d'encodages. (http://www.techspot.com/article/1131-hevc-h256-enconding-playback/)

[Taro]

C'est très intéressant comme article, j'aime bien cette image qui illustre parfaitement le gain qu'on peut trouver grâce à la segmentation en blocs de dimension variable :

http://www.techspot.com/articles-info/1131/images/compression3.jpg

[MegABiloU]

Faut que je teste l'encodage hardware avec ma gtx 1070 par contre je bite rien à staxrip

[Taro]

Encodage hardware h265 :bave:

[rotoclap]

Faut que je teste l'encodage hardware avec ma gtx 1070 par contre je bite rien à staxrip

J'ai suivi les réglages proposés dans le lien que tu as mis pour encoder The Revenant en 4K sur ma GTX970 => ça a mis environ 1h30, alors que sur HandBrake j'en aurais eu pour une dizaine d'heure facile. J'ai pas d'écran 4K, mais sur mon 1440p, j'ai rien vu de choquant coté qualité alors que coté temps d'encodage, c'est le jour et la nuit.

[MegABiloU]

Moi j'ai pas réussi a faire marcher le soft du coup je serais pas contre savoir comment tu as fait.

[XWolverine]

J'ai suivi les réglages proposés dans le lien que tu as mis pour encoder The Revenant en 4K sur ma GTX970 => ça a mis environ 1h30, alors que sur HandBrake j'en aurais eu pour une dizaine d'heure facile. J'ai pas d'écran 4K, mais sur mon 1440p, j'ai rien vu de choquant coté qualité alors que coté temps d'encodage, c'est le jour et la nuit.
Ce serait bien, ça, mais aux dernières nouvelles (mais ça date un peu, c'était chez H.fr), la qualité n'était pas la même en encodage hardware. J'aimerais bien trouver des comparatifs à jour sur le sujet.

[shlagevuk]

Ce serait bien, ça, mais aux dernières nouvelles (mais ça date un peu, c'était chez H.fr), la qualité n'était pas la même en encodage hardware. J'aimerais bien trouver des comparatifs à jour sur le sujet.

lien que MegABiloU avait link il y a quelque temps sur les qualité d'encodate (02/2016) (http://www.techspot.com/article/1131-hevc-h256-enconding-playback/)

[XWolverine]

lien que MegABiloU avait link il y a quelque temps sur les qualité d'encodate (02/2016) (http://www.techspot.com/article/1131-hevc-h256-enconding-playback/)
Je parlais de la comparaison encodage hardware (GPU) versus encodage software, où lors des premiers tests, que ce soit le Quicksync d'Intel ou l'encodeur h264 de Nvidia, la qualité par rapport au x264 "standard" software était bien en deça sur les scènes critiques, mais avec des résultats corrects sur la plupart des scènes. Je ne sais pas si ça a évolué au pas (ou si les testeurs étaient bien plus exigeants que Rotoclap sur le résultat), raison de ma remarque.
De mémoire, il me semble aussi que les réglages par défaut aidaient bien, en réglant la qualité sur le max, on arrivait à un résultat bien plus proche du mode software, mais avec des temps qui s'en approchait aussi (ou dépassaient, je ne sais plus).
Bref, je suis incapable de dire si c'est encore vrai aujourd'hui, mais du coup, je doute ;)

Pour le h265, je suppose qu'il est trop tôt pour comparer soft et hard.

[MegABiloU]

J'ai aussi posté un comparo GPU v.s. CPU et oui de mémoire l'encodage GPU est de moins bonne qualité.

Edit : c'est la page 5 (http://www.techspot.com/article/1131-hevc-h256-enconding-playback/page5.html) du lien précédent.

[rotoclap]

Moi j'ai pas réussi a faire marcher le soft du coup je serais pas contre savoir comment tu as fait.

Ben j'ai juste téléchargé le soft et suivi la marche à suivre sur ton lien. J'ai juste eu à télécharger AVI Synth et les runtime VC2015 en plus quand il me l'a demandé.

[MegABiloU]

J'ai réussi finalement.


Du coup par défaut je passe d'un BR de 45Go a un mkv de 22Go en moins de 30 minutes.
Je vais expérimenter les reglages.

[shlagevuk]

Du coup avec les récents posts ici j'ai voulu faire un test d'encodage hardware du x265 avec ma nouvelle CG.

J'ai re-encodé à partir d'une source x264 pesant 12.9Go. Encodage avec les paramètre de qualité constant par défaut, encodage par le réseau (film sur mon NAS), je tournais entre 150 et 250fps et le résultat pesait un peu moins de 4Go.

Concernant la qualité j'ai trouvé ça très correcte. Disons que niveau qualité/temps/compression l'encodage HW est imbattable.

[MegABiloU]

L'interface est vraiment pas terrible je serais pas contre un petit tuto je comprends pas grand chose...

[shlagevuk]

J'ai enfin eu le temps d'encoder d'autres vidéos en x265 avec staxrip.

Vidéos de départ, 13 épisodes d'une série, un peu moins de 4Go par vidéo -> 49.5Go au total

Encodage en x265 via le NVenc (encodage matériel nvidia), audio et sub mux, "--cqp 20:23:25 --codec h265 --sar 12:11" en profil main -> 24Go

J'ai scruté les détails des vidéo source et x265 pour voir s'il y avait des différences mais je n'ai rien trouvé de notable, le grain de peau est peut-être un peu moins détaillé mais il faut vraiment être un acharné pour le remarquer lors du visionnage.


L'encodage aura duré environ 1h30, je pense que des bécanes plus récentes auraient fait plus vite, lors de l'encodage malgré l'utilisation de NVenc j'étais à presque 100% d'utilisation CPU (et en plus j'encode les fichiers présent sur le réseau)
(pour info config: xeon x5670 @2.93Ghz (6/12t), 30Go de ram, GTX 1070, réseau Gb. Les fichiers temporaires sont sur le SSD en local)

Je vais lancer d'autres "batchs" de vidéos à encoder, je vais en profiter pour vous faire un tuto avec des screen. :)

[Taro]

Je vais lancer d'autres "batchs" de vidéos à encoder, je vais en profiter pour vous faire un tuto avec des screen. :)

Ça ce serait cool ;)

Par contre j'ai une 980 Ti, pas une 1070, je pourrai pas tester sur ma machine. :cry:

[MegABiloU]

Le souci avec staxrip c'est qu'il faut se taper le remuxage a part, c'est pénible

[shlagevuk]

Tu es sûr que la 980ti ne supporte pas l'encodage HEVC? D'après wikipedia tu as le NVenc de 3e génération. Et sur internet on trouve des références à de l'encoding hevc hardware avec la 980ti.

Tu entends quoi par "se taper le remuxage à part"? Le fait qu'il réencode l'audio?

[MegABiloU]

Bah je m'y suis peut être mal pris.

Mais en gros je voudrai que ce soit pratique comme handbrake pour metre les chapitres l'audio les sous titres dès le début de l'encodage.

sans qu'il me copie les fichiers source.

[Taro]

Tu es sûr que la 980ti ne supporte pas l'encodage HEVC? D'après wikipedia tu as le NVenc de 3e génération. Et sur internet on trouve des références à de l'encoding hevc hardware avec la 980ti.

Je me suis peut-être fourvoyé. Tu as un lien ?

[MegABiloU]

bah si la 960 et la 950 savent le faire, pourquoi les plus grosses cartes ne pourraient pas?

[shlagevuk]

Bah je m'y suis peut être mal pris.

Mais en gros je voudrai que ce soit pratique comme handbrake pour metre les chapitres l'audio les sous titres dès le début de l'encodage.

sans qu'il me copie les fichiers source.

Bah pour le coup moi j'ai jamais testé de faire du RIP BR/DVD -> HEVC, je ne fait que du x264->x265. Par contre tu as des options dans staxrip qui te permettent de choisir les langues de sous-titre à prendre/conserver ainsi que l'ordre dans lequel les positionner. Pour les pistes audio tu dois les avoir en bas de la fenêtre principale, par défaut il transcode l'audio en AAC, mais tu peux choisir juste "mux" pour copier tel quel l'audio.


Je me suis peut-être fourvoyé. Tu as un lien ?

test guru 3d: (http://www.guru3d.com/articles-pages/nvidia-geforce-gtx-980-ti-review,7.html)
"one new addition that’s been added to GM200 is support for H.265 (HEVC) encoding and decoding."

[Taro]

test guru 3d: (http://www.guru3d.com/articles-pages/nvidia-geforce-gtx-980-ti-review,7.html)
"one new addition that’s been added to GM200 is support for H.265 (HEVC) encoding and decoding."

Merci beaucoup. :)
Du coup j'essayerai avec mon prochain bluray.

[shlagevuk]

Tuto staxrip
avec des vrai morceaux de Stargate dedans

Staxrip permet d'encoder des vidéos dans différents formats et même que si on sait s'en servir on peut lui dire d'en faire tout plein et il se débrouille tout seul!

http://tof.canardpc.com/preview/80401d9a-03d4-485c-8d1a-1a631826eff1.jpg (http://tof.canardpc.com/view/80401d9a-03d4-485c-8d1a-1a631826eff1.jpg)


Tout d'abord on va créer un template d'encodage en x265 (hevc).

Pour cela on va déjà changer le type de vidéo en sorti voulue. Ici on prend NVIDIA H.265 parce que je suis un nantis avec une GTX 1070 qui me sert essentiellement à jouer à factorio (et par conséquent est grandement inutile).
Vous pouvez bien sûr utiliser l'encodage x265 "simple" qui utilisera votre processeur mais ce sera atrocement long.
http://tof.canardpc.com/preview/6840226d-fa3e-448c-9a05-b601f9646b0d.jpg (http://tof.canardpc.com/view/6840226d-fa3e-448c-9a05-b601f9646b0d.jpg)

Par défaut Staxrip utilise CQP qui de mémoire est le mode qualité constante, ça tombe bien c'est ce que l'on veut et c'est ce qui donne les meilleurs résultat avec l'encodeur HW de nvidia. Il se peut que les nvenc des génération précédentes aient de moins bon résultat, personnellement avec les paramètres par défaut ici présent je ne vois pas de différence notable avec la source.
http://tof.canardpc.com/preview/f7396962-fae1-4d27-86d5-a960c125af13.jpg (http://tof.canardpc.com/view/f7396962-fae1-4d27-86d5-a960c125af13.jpg)

Ensuite pour ceux qui le veulent, on peut choisir le profil d'encodage audio désiré, personnellement je ne cherche pas a changer l'audio donc je vais choisir "just mux" qui correspond simplement à copier la ou les bandes sons dans le nouveau fichier.
http://tof.canardpc.com/preview/53bffd20-e466-4c24-ada9-9d4c01e3166f.jpg (http://tof.canardpc.com/view/53bffd20-e466-4c24-ada9-9d4c01e3166f.jpg)

Ensuite dans les options
http://tof.canardpc.com/preview/34c0a83e-cf56-4a2b-8389-059087df2a4e.jpg (http://tof.canardpc.com/view/34c0a83e-cf56-4a2b-8389-059087df2a4e.jpg)

On va choisir les dossier cible, le nom des cibles et le dossier temporaire.
Quelques petites notes:
-Staxrip permet de prendre le nom du fichier de base comme nom pour le fichier cible, vous pouvez ajouter un élement après, ici ce sera x265 pour le distinguer.
-J'ai mis le même dossier de destination parce que je souhaite faire un comparatif des deux fichiers avant suppression.
-Le fichier temporaire est fortement recommandé d'être local, en cas d'encodage audio ou de fusion de différents fichiers vidéo les bandes sons réencodé ou les différents fichiers vidéo avant la fusion dans le conteneur MKV seront stocké dedans! Par le réseau c'est lent.
http://tof.canardpc.com/preview/b6b554bd-a91d-4d2e-8c24-ba440c8a6d03.jpg (http://tof.canardpc.com/view/b6b554bd-a91d-4d2e-8c24-ba440c8a6d03.jpg)

Préférence des langues pour la gestion des sous-titre, même fonctionnement pour la gestion des pistes audio. En gros ici les pistes/sstitre anglais seront listé en priorité, ensuite il y aura les français. Et de mémoire, normalement les autres sont effacés, souvenez-vous-en en cas d'encodage de vidéo en langues moins communes.
http://tof.canardpc.com/preview/41a77158-939a-4174-b78f-766e6a9d1e46.jpg (http://tof.canardpc.com/view/41a77158-939a-4174-b78f-766e6a9d1e46.jpg)
http://tof.canardpc.com/preview/22608550-9aca-4a07-aa53-9232441ee08a.jpg (http://tof.canardpc.com/view/22608550-9aca-4a07-aa53-9232441ee08a.jpg)

Ensuite sauvegarde du template
http://tof.canardpc.com/preview/08e24c27-8760-4292-b527-273235987fa0.jpg (http://tof.canardpc.com/view/08e24c27-8760-4292-b527-273235987fa0.jpg)

Que l'on retrouve dans les templates sauvegardé (merci captain obvious!)
http://tof.canardpc.com/preview/adcdf7a8-b092-4ab9-a719-724c861e0d2c.jpg (http://tof.canardpc.com/view/adcdf7a8-b092-4ab9-a719-724c861e0d2c.jpg)

Poste suivant, un exemple!

[shlagevuk]

Pour lancer l'encodage d'un batch de vidéo qui seraient par exemple toutes dans un même dossier
http://tof.canardpc.com/preview/3146ec0e-bdb3-4694-8f13-8edb583ceb0c.jpg (http://tof.canardpc.com/view/3146ec0e-bdb3-4694-8f13-8edb583ceb0c.jpg)
http://tof.canardpc.com/preview/f7674fe2-32f4-411d-8e35-e3aa616296f6.jpg (http://tof.canardpc.com/view/f7674fe2-32f4-411d-8e35-e3aa616296f6.jpg)
http://tof.canardpc.com/preview/30e141a6-9067-4bd3-b389-6efb12f44c11.jpg (http://tof.canardpc.com/view/30e141a6-9067-4bd3-b389-6efb12f44c11.jpg)
http://tof.canardpc.com/preview/d19f16b0-965c-489d-aca5-4a0d65c2747e.jpg (http://tof.canardpc.com/view/d19f16b0-965c-489d-aca5-4a0d65c2747e.jpg)
http://tof.canardpc.com/preview/905d06de-6d73-4e30-9476-211b5473d523.jpg (http://tof.canardpc.com/view/905d06de-6d73-4e30-9476-211b5473d523.jpg)
http://tof.canardpc.com/preview/60f6b2a4-221b-42d3-b69e-7e031ad310f3.jpg (http://tof.canardpc.com/view/60f6b2a4-221b-42d3-b69e-7e031ad310f3.jpg)
Une fois appuyé sur ok, staxrip vas créer les jobs et donc peupler le dossier temporaire avec un dossier par job.
http://tof.canardpc.com/preview/6b155dd1-a478-4e39-815b-1a6d3d70e316.jpg (http://tof.canardpc.com/view/6b155dd1-a478-4e39-815b-1a6d3d70e316.jpg)
exemple de job en cours de run
http://tof.canardpc.com/preview/78878d7b-adef-497e-a8dc-b034c269c66c.jpg (http://tof.canardpc.com/view/78878d7b-adef-497e-a8dc-b034c269c66c.jpg)
Résultat:
http://tof.canardpc.com/preview/0b01c6fe-f0cb-43ed-91f8-cda5ad43fbdd.jpg (http://tof.canardpc.com/view/0b01c6fe-f0cb-43ed-91f8-cda5ad43fbdd.jpg)
En gros 80s pour 170mo de gagné en terme de place. (-26%)


edit1: Et pour le coup c'est avec les stargate que j'ai pu voir le premier signe de "perte" de qualité à l'encodage, celle-ci est quand même assez subtile. J'ai pu voir sur les murs de le base en arrière plan un effet de gradation des couleurs au lieu d'un aspects plus grain/homogène sur la source en x264.
edit2: Et du coup en poursuivant un peu l'encodage des épisodes du portail des étoiles j'ai pu voir que l'encodeur nvidia a un peu de mal à compresser les épisodes se déroulant en foret d'autant plus s'il y a de l'action.
Les deux fichiers concernés pour l'instant ont finit respectivement à +3 et +40Mo (+0.5 et +6.5%) de l'original, une fois réencodé via cpu et x.265 en preset medium et profile main je suis retombé à une valeur plus normal d'environ -160Mo (-26%). Par contre le temps d'encodage est 30 fois plus important (et quasi 60x pour le preset slow).

[Taro]

Woah ! Merci pour ce tuto :)

[MegABiloU]

ok je ferais des essais aussi

[Rocca]

Tu peux revenir sur tes edits shlagevuj s'il-te-plait ?

Je pige pas trop ce que tu veux dire dans cette phrase

"Les deux fichiers concernés pour l'instant ont finit respectivement à +3 et +40Mo (+0.5 et +6.5%) de l'original, une fois réencodé via cpu et x.265 en preset medium et profile main je suis retombé à une valeur plus normal d'environ -160Mo (-26%). Par contre le temps d'encodage est 30 fois plus important (et quasi 60x pour le preset slow)".

Tu pourrais détailler le raisonnement. Je m'intéresse à la vitesse d'encodage plus rapide d'un GPU vs CPU mais à qualité égale

Tu veux dire qu'au niveau qualité c'est mieux en passant par l'encodage CPU ?

Sinon merci pour le tuto super complet. J'ai une 7870 XT, même si je ne peux tester le X265, le X264 est compatible ;)

[shlagevuk]

En gros j'ai ré-encodé les stargate SG1 que j'avais via staxrip avec encodage hardware (NVenc). Parmi tout les épisodes ré-encodés il y en a certains qui étaient plus gros en x265 qu'en x264.

Cela viens des scènes avec beaucoup de détails en mouvement (ici c'était des épisodes qui se déroulaient en forêt avec pas mal d'action/mouvement). Ce genre de problème se pose également pour les vidéos avec beaucoup de grain, The walking dead par exemple.

Dans ce genre de cas l'encodage hardware x265 finit quasi systématiquement plus gros que le fichier d'origine. Par contre, si je ré-encode les même fichiers via CPU (handbrake ou ffmpeg) le fichier final en x265 dispose d'une taille "normale" permettant un gain de place de 30% environ.

J'essaierai de vous ré-encoder un épisode de TWD via GPU et CPU avec quelques screen pour voir la différence de grain.

Note que pour ton cas ré-encoder du x264 vers x264 risque de ne t'apporter aucun gain, l'encodage HW est rapide (10x à 100x) mais peu efficient, le fichier résultant a un ratio qualité d'image/taille inférieur à l'encodage software. Et cela est le cas pour le x264 comme le x265.

[MegABiloU]

J'ai eu le même problème sur un épisode de mac gyver ou tout se passe en forêt avec des scènes de rafting.

L'épisode fait plus de 1Go pour 300Mo pour les autres épisodes de la même saison.

Beaucoup de grain et de mouvement.

[Rocca]

Petit retour sur mes derniers encodages.

Donc quelques petites modifications notamment sur le paramètre Anamorphic.
Afin de respecter la définition de l'image il y a un paramètre avec lequel j'ai eu des soucis : le cropping.

Donc dans Handbrake onglet picture voici les modifications :
- Anamorphic : Strict
- Cropping : Custom
- Top : 0
- Left : 0
- Right : 0
- Bottom : 0

Ensuite pour ce qui est de l'onglet video voici les paramètres que j'utilise sur des sources en H.264 a bitrate < 11MBps
- video codec : H.265 (x265)
- Framerate (FPS) : Same as source - Constant Framerate
- Quality : Constant Quality RF18
- Encoder Preset : Medium
- Encoder Tune : PSNR
- Encoder Profile : Main
(pour une vidéo d'environ 50 minutes avec 2 pistes en 5.1 AAC @576 on est entre 1.2Go et 2Go)

Variante pour les sources > 11MBps
- video codec : H.265 (x265)
- Framerate (FPS) : Same as source - Constant Framerate
- Quality : Avg Bitrate @3500 - 2Pass Encoding
- Encoder Preset : Medium
- Encoder Tune : PSNR
- Encoder Profile : Main
(pour une vidéo d'environ 50 minutes avec 2 pistes en 5.1 AAC @576 on est environ à 1.6Go)

Audio
J'ai choisi un compromis afin de conserver un qualité correcte compatible tous supports AAC FDK @576 pour 6 canaux et AAC FDK @192 pour 2 canaux. Exit les DTC DOLBY et AC3 propriétaires.

Sur la dernière nightly le paramètre FDK disparait on retourne sur AAC plus d'infos ici (https://trac.handbrake.fr/changeset/0ba02795a907ca86fb220d349777e628f1a0314e)

Ces paramètres sont utilisés pour de la vidéo standard en 1080p, je pense faire des essais sur des films et séries d'animation ce qui ne devrait pas nécessiter de bitrate trop élevé a mon avis du H.265 @1500 doit pouvoir avoir un bon rendu, et je vais également essayer en constant quality voir ce que ça donne.

Bonjour tout le monde.

J'ai repris les paramètres ci-dessus, merci MegaBiloU, afin d'effectuer des tests sur une courte vidéo de mon appareil photo, détaillée ci-dessous, en regardant les propriétés du fichier, par suite, avec format factory onglet "avancé >> information sur le fichier".

Vidéo de départ (1080p en 50i/s) :
MEPG-4 Base media mp42
Format : AVC
Taille vidéo : 209 Mo
durée : 50 secondes
Overall bit rate : 34.5 Mbps

Audio : PCM 16 bits, 44100 Hz, stéréo et 1411 kbits/s


Après passage sous HandBrake avec les paramètres ci-dessus à la différence de ceux modifiés mais précisés :

Option 1 :

Taille : 75.2 Mo
Overall bite rate : 12.4 Mbps

Option 2 :

Taille : 22.1 Mo
Overall bite rate : 3659 kbps


En mettant à la place de "Main", "Main 10"

Option 1 :

Taille : 75.2 Mo
Overall bite rate : 12.4 Mbps

Option 2 :

Taille : 22.1 Mo
Overall bite rate : 3659 kbps



En indiquant variable framerate à la place de constante

Taille : 75.2 Mo
Overall bite rate : 12.4 Mbps

Option 2 :

Taille : 22.1 Mo
Overall bite rate : 3659 kbps



Au niveau des résultats, je ne vois aucune différence entre "main" et "main 10" à part la durée d'encodage plus longue et lors du décodage software (avec le CPU) une charge plus importante du CPU.

Entre l'option 1 et 2 dans tout les cas, je dirais que l'option 1 apporte une meilleurs qualité, mais c'est difficile de distinguer les deux dans une vidéo classique (ici un petit bébé sur le dos qui joue). Et puis, certes meilleur qualité, mais taille nettement plus important quasi 3 fois. :O

Bref, le main 10 n'apporte rien et la "variable framerate" non plus (le débit reste le même au final).


Quelqu'un pourrait-il me dire qu'apporte donc ce "Main 10" ??


EDIT : je viens de tester avec quasi avec les mêmes paramètres, mais en H264. Donc, en gros qualité option 2 avec taille option 1 :p:p:p:p

Je n'ai pas indiqué la finalité, j'ai une vidéo de 38 Go (montage vidéo de 34 minutes fait avec VSDC video free) que je veux convertir pour envoyé sur un "cloud" et partager...

EDIT : je viens de voir en créant un profil que VSDC permet d'encoder directement en HEVC :p mais il lui faut 14 heures en "medium" :tired::tired:

[MegABiloU]

Merci pour ton retour.

Hé oui hevc de 38Go ça peut durer un peu.

[Rocca]

Merci pour ton retour.

Hé oui hevc de 38Go ça peut durer un peu.

Ouai et non au final :p

En ce moment, j'encode le montage de plusieurs vidéos coupées, scindées avec des effets en H264 avec VSDC. Ensuite, je vais réeconder en H265 avec Handbrake le fameux dossier d'environ 38 Go.

Avant de faire les tests, j'avais tenté avec Handbrake c'était, d'après ces calculs, dans les 4 h 00-45 d'encodage. Tu rajoutes à ça le premier encodage de VSDC en H264 d'envrion 2 heures, ça nous donne avec une grosse louche dans les 6 heures.

On est quand même loin des 14 heures. De plus, l'essai effectué donnait en medium sous VSDC un résultat illisible, pixelisation de malade (comme quand tu sabres la qualité à la hache) et en taille 10 secondes = 138 Mo :p :p

J'ai donc laissé tombé l'encodage en H265 avec VSDC et privilégié Handbrake avec tes réglages que j'ai testé sur une petite vidéo d'abord. Je vais d'ailleurs testé encore quelques trucs.

Ayant repéré où se situe la dégradation de la qualité sur les images (une couverture sur le côté), je vais pouvoir faire le compromis bitrate/taille et je ferais un petit retour bien entendu ;)


EDIT : pour info les temps son sur un i5 750 OC 3.36 Ghz. D'ailleurs, je me tâte à réquisitionner le PC à ma femme (Asus avec i7 6700 HQ). :p Mais bon faudrait installer Handbrake dessus puis faire tous les réglages. Et vu qu'elle l'utilise...

[MegABiloU]

Par contre mes réglages sont pas forcément les meilleurs et handbrake a évolué légèrement depuis mon précédent post, j'imagine qu'il y a moyen de trouver d'encore meilleurs compromis.

[Rocca]

Par contre mes réglages sont pas forcément les meilleurs et handbrake a évolué légèrement depuis mon précédent post, j'imagine qu'il y a moyen de trouver d'encore meilleurs compromis.

Ouai je viens de m'en rendre compte, je fais un résumé dès que je peux ;)

Il y a aussi le support de HEVC avec INtel GPU !! Mais bon, j'ai pas trouvé folichon le machin. Le main 10 n'est plus là d'ailleurs...

Je reviens dans quelques heures faire un résumé, je viens de passer à la toute dernière version :)

[Rocca]

Bon grosso modo, je viens de faire les tests sur la nouvelle version 1.0.7 version 64 bits :)

Ce que j'en retiens, en prenant les paramètres déjà évoqués et repris ci-dessous, la taille du dossier final en "simple pass" est quand même nettement plus petite. J'ai l'impression qu'il y a eu de l'optimisation de ce côté là. Pour la double pass ça reste identique en taille.

Les différents points :

- Taille en simple pass plus petite que précédemment pour la même qualité depuis la mise à jour ,
- Encodage avec un i7 6700HQ VS i5 750 OC 3.36 Ghz >> temps à peu près identique ce qui est plus que surprenant et decevant :(
- Encodage avec IGP Intel, résultat pas terrible, au final 141 Mo en taille et 23.3 Mbit/s en bit rate et illisible avec VLC,
- Entre RF18 et RF22, la différence n'est pas folichonne, voir détails plus bas,
- Passage de vidéo 50 images/s à 30 images/s, gros ressenti de perte de qualité, tremblement et déplacements latéraux (image qui vibre sur les bords) très accentués. La différence visuelle est importante, bien plus que le passage de RF18 à RF22 ou de la source à RF22...

Vidéo de départ pour une taille de 208 Mo pour 50 secondes :

https://tof.cx/images/2017/06/03/dea0cd81b2dc3e41c6e479ea5a45142d.png


Les paramètres d'encodage :


https://tof.cx/images/2017/06/03/462793ca9fe7f25dfb3d020ff8badf4b.png
https://tof.cx/images/2017/06/03/58f7a162c03e1d4b1834e8f1c18066f8.png

Ce qui donne en RF 18 avec 50 images/s :

- taille : 38.6 Mo
- overall bit rate : 6376 kbit/s

Ce qui donne en RF 22 avec 50 images/s :

- taille : 16.8 Mo
- overall bit rate : 2781 kb/s

Avec l'encodage GPU H265 (paramètres légèrement différents) :

- taille 141 Mo
- Overall bit rate : 23.3 Mbit/s
Vidéo illisible sous VLC. :tired:


Bon maintenant que les tests sont effectués et que je ne gagne pas grand chose en temps à le faire avec le i7 6700HQ, je vais enfin encoder le fichier que j'ai mis au point ce matin en H264 pour une taille de 66.6 Go avec bit rate de 291 Mbit/s :O :O

[shlagevuk]

Le main 10 permet d'avoir les couleurs encodé sur 10b au lieu de 8b. Typiquement ça permet d'éviter les dégradés de couleurs "visible" surtout sur les manga ou par exemple sur une scène de couché de soleil.

[Rocca]

Le main 10 permet d'avoir les couleurs encodé sur 10b au lieu de 8b. Typiquement ça permet d'éviter les dégradés de couleurs "visible" surtout sur les manga ou par exemple sur une scène de couché de soleil.

Ah ok sympa merci pour la précision ;)

Malheureusement, il ne semble plus disponible dans les paramètres :tired:

Sinon, l'encodage de 4 h 45 vient de finir, le fichier est passé de 66.6 Go en H264 à 530 Mo en H265 (RF22). Je vais essayer en RF18, mais le résultat, vu la gain de place :O, niveau qualité image est franchement pas mal du tout !!

[shlagevuk]

Niveau gain de place, pense qu'il faut factoriser le type d'encodage initial en x264. Si tu fait du x264 en ultrafast et derrière tu fait du x265 en slow, l'écart de taille est monstrueux, sauf que l'un s'encode a +100fps et l'autre à 2 ou 4 fps ;)

[Rocca]

Niveau gain de place, pense qu'il faut factoriser le type d'encodage initial en x264. Si tu fait du x264 en ultrafast et derrière tu fait du x265 en slow, l'écart de taille est monstrueux, sauf que l'un s'encode a +100fps et l'autre à 2 ou 4 fps ;)

Nope, le H264 était en mode normal sans augmentation de qualité, quasi par défaut mais en haute qualité. Le but étant que suite au montage vidéo, l'encodage étant nécessaire, il y ait le moins de pertes en qualité vidéo par rapport à la vidéo en H264 d'origine (ou plutôt les vidéos).

https://tof.cx/images/2017/06/04/db7e8caed86317e91760efab25ed5380.png


Ensuite, la perte est jaugée lors de l'encodage en H265 (d'où les différents tests). J'aurai bien entendu encodé directement en H265 avec VSDC mais les réglages sont limités et ne me convenaient pas.

Au passage en RF18, sous Handbrake, ça passe à 1.1 Go avec une qualité plus que satisfaisante. J'ai regardé sur une télé 1080 p de diagonale 102 cm et c'est top :)

[shlagevuk]

La qualité d'encodage joue sur le rendu de l'image.

La vitesse d'encodage joue sur la taille du fichier final à qualité constante. (ou sur la qualité à taille constante)

[Rocca]

La qualité d'encodage joue sur le rendu de l'image.

La vitesse d'encodage joue sur la taille du fichier final à qualité constante. (ou sur la qualité à taille constante)

Ouai, j'ai testé les deux :)

En H265 (HEVC) avec VSDC et qualité constante + les paramètres ci-dessus, ça donnait 138 Mo pour 10 secondes comme indiqué plus haut. J'ai pas trouvé autant d'options que sous Handbrake et le seul essai sous HEVC était illisible sous VLC.

D'où mon choix d'encoder en H264 avec VSDC sans dégrader la qualité même si le dossier final est énorme.

Donc si j'ai bien compris en prenant Handbrake, si je passe le preset de medium à very slow voire placebo, la taille de la vidéo sera plus faible pour une même qualité d'image, vu que je laisse le RF à 18 ?

Ben ça va être rapide, je vais faire le test sur ma vidéo de test évoquée plus haut et je reviens poster les résultats...

[Rocca]

Me revoilà pour les résultats plus au moins partiels, car le temps d'encodage était vraiment long pour le coup.

Petite parenthèse : le gain de place dans mon cas était nécessaire pour pouvoir uploader la vidéo sans bloquer ma connexion pendant 10 jours :)

Je suis en adsl 12 Mbits/s débits descendants et autour des 1.2 Mbit/s en débit montant. Tout ça pour dire que la recherche de place, dans le cas présent, n'est peut-être pas nécessaire pour ceux qui ont la fibre et pourront se contenter d'un encodage ultra rapide :)

Vidéo de départ pour rappel :

- Taille 208 Mo ou 209 Mio (d'après format factory)
- Durée 50 secondes mais c'est du 50 images par secondes (soit 2500 images à calculer) !!
- raw vidéo (MPEG4 AVC MP 42) en 34.3 Mbit/s.


- Premier test avec preset sur placebo :

https://tof.cx/images/2017/06/05/d5b7e30be0e71048297e24f534b60d43.png

Temps gigantesque !!

Grosso modo on a 20 % au bout de 45 minutes. On en déduit environ 3 h 45 minutes, voire plus, pour rappel 50 secondes de vidéo

- Taille : inconnue pas testée jusqu'au bout trop long désolé les canards :tired:
- Temps : 3 h 45
- Qualité à l'oeil : inconnue
- Qualité niveau débit (bon indicateur) : inconnue

A l'oppose de l'échelle maintenant :)

- Preset ultrafast (testé 2 fois) :

- Taille : 34.6 Mo
- Temps : 2 minutes 21 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 5729 kbit/s


- Preset ultrafast2:

- Taille : 34.6 Mo (idem)
- Temps : 2 minutes 20 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 5729 kbit/s (idem)


- Preset superfast 1 (fait 4 fois) :

- Taille : 41.3 Mo
- Temps : 3 minutes 10 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 6833 kbit/s

- Preset superfast 2 :

- Taille : 41.3 Mo (idem)
- Temps : 3 minutes 09 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 6833 kbit/s (idem)


- Preset veryfast :

- Taille : 35.2 Mo
- Temps : 4 minutes 28 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 5819 kbit/s


- Preset faster :

- Taille : 35.2 Mo
- Temps : 5 minutes 10 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 5818 kbit/s


- Preset fast :

- Taille : 36.2 Mo
- Temps : 5 minutes 55 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 5988 kbit/s


- Preset medium :

- Taille : 37.6 Mo
- Temps : 8 minutes 46 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 6226 kbit/s


- Preset slow :

- Taille : 39.1 Mo
- Temps : 19 minutes 01 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 6464 kbit/s


- Preset slower :

- Taille : 39.6 Mo
- Temps : 47 minutes 35 secondes
- Qualité à l'oeil : bonne
- Qualité niveau débit (bon indicateur) : Overall bit rate : 6551 kbit/s


On en déduit, merci pour l'intervention shlagevuk, que le temps d'encodage est plus ou moins rapide, mais c'est pas graduel de manière linéaire en tout cas :p

On pourra noter, sur cette vidéo test du moins, que la qualité vidéo ne semble pas plus impactée que cela. Seule la taille du fichier final semble varier mais pas de manière linéaire bizarrement :O

Je rappelle, d'après les tests ci-dessus, que on peut tirer à peu près la même conclusion, au niveau de qualité, sur le RF de 18 à 22. Au final, l'image ne semble pas se dégrader de manière visible (légèrement), mais la taille du fichier évolue pas mal (c'est plus sensible avec le passage du RF18 à RF22).

Le point important est également le nombre d'images par secondes. Le fichier de départ étant à 50 images / s, j'ai testé à 30 i/s. Là, clairement la dégradation au niveau de la vidéo est importante, bien plus qu'avec tous les autres curseurs. Je ne sais pas trop comment le décrire. La vidéo semble moins nette et les mouvements (normal me direz-vous) sont bien moins fluides et limite on pourrait commencer à taper sur le gars qui a filmé :p :p avec des mouvements trop brusques niveau déplacements latéraux (les bords de l'image) avec des effets de tremblements (ça me faisait la même chose avec mon appareil photo précédent qui avais 9 ans, il filmait de mémoire à 25 images/secondes).

Au final, si j'ai le temps dans les prochains jours, je testerai sur une vidéo en extérieure avec plus de lumière et de détails en arrière plan (dans le jardin par exemple). Faut juste que je trouve une très courte séquence on que j'en fasse une avec l'appareil photo, histoire de ne pas avoir des temps d'encodage de 10 ans :p

Je ferais également un post dessus, bien entendu :)



En image par rapport à ce qui est indiqué ci-dessus :


Original :

https://tof.cx/images/2017/06/05/ec74b6d796e941702cba2ebfa7570020.png

Ultrafast :

https://tof.cx/images/2017/06/05/b2940a94a767c1fe9066b2a48c4f7211.png

Medium :

https://tof.cx/images/2017/06/05/017b1ce6e2832f170159bd0a201ceff4.png


Slower

https://tof.cx/images/2017/06/05/334f21e5db0a21273d051d61c5aa5ce7.png

[shlagevuk]

Bon du coup je vais link quelques trucs utile pour mieux comprendre ce que font les preset.

Déjà ce que font les preset sur le traitement de la video, ces preset sont en fait une succession d'options de l'encodeur x265 jouant sur le ratio de compression, la liste de ces options par preset est trouvable ici (http://x265.readthedocs.io/en/default/presets.html).

Ensuite y'a un blog assez bien fait (https://sonnati.wordpress.com/) qui explique le fonctionnement des encodeurs video et notamment x265/vp9/x264, l'article sur le x265 (https://sonnati.wordpress.com/2014/06/20/h265-part-i-technical-overview/)


Et pour la variation de la taille en fonction du preset, avec des fois une augmentation de la taille c'est assez normal du coup. Ces preset sont généralistes, tu as forcément une vidéo spécifique à encoder et certaines sous-options peuvent être contreproductive dans une certaines mesures.

[Foudge]

Le point important est également le nombre d'images par secondes. Le fichier de départ étant à 50 images / s, j'ai testé à 30 i/s. Là, clairement la dégradation au niveau de la vidéo est importante, bien plus qu'avec tous les autres curseurs. Je ne sais pas trop comment le décrire. La vidéo semble moins nette et les mouvements (normal me direz-vous) sont bien moins fluides et limite on pourrait commencer à taper sur le gars qui a filmé :p :p avec des mouvements trop brusques niveau déplacements latéraux (les bords de l'image) avec des effets de tremblements (ça me faisait la même chose avec mon appareil photo précédent qui avais 9 ans, il filmait de mémoire à 25 images/secondes).Et t'as testé à 25 ips justement ? Je me demande comment il fait pour faire du 50 => 30 proprement, sans micro-stuttering.

[Rocca]

Et t'as testé à 25 ips justement ? Je me demande comment il fait pour faire du 50 => 30 proprement, sans micro-stuttering.

Nan du coup, j'ai pas testé :tired:

Vu que mon ancien appareil photo avait ces effets de bords (les bords de la caméra qui tremblent en 25ips), j'ai pas jugé le truc utile.

Mais, ça se tente :)

[MegABiloU]

Voila voila transcodage HEVC sur plex.

http://tof.cx/images/2017/06/10/aaecdccee91a7d964ad2c9c8d59b5787.png

[Squarealex]

Yo les canards.
J'encode quelques vieux anime japs en x264. J'y gagnerais quelques chose si je choisis le 10 bits ? (Qualité ? Poids ?) Le x265, je suis pas encore chaud, le x264 va rester longtemps je pense pour sa précision, pour ma part (ou alors je règle mal).
De plus, je suis plutôt du style à laissé en 720x480 / 720x576 (même si c'est en 16/9) / 1920x1080... (je déteste le cropping avec des réso exotique).

Pour certain film, il y a du grain et c'est le genre de truc que j'aimerais préservé, mais forcément ça prend plus de place ce genre de choix. Pour le coup, vous êtres plutôt réglage basique ou avancé ?

[MegABiloU]

Le 10 bits t'apportera une meilleure précision des dégradés de couleur. pas d'effet de bandes des couleur.

[shlagevuk]

(mais il faut que la source soit en 10bit aussi)

[Foudge]

De ce que j'ai lu, et ça parait contrintuitif, il y a des avantages à encoder en 10bit, même si la source et l'écran sont en 8bit. Pour résumer en quelque mot : meilleur efficacité (petit gain de place, ou léger gain de qualité à taille égale) mais encodage plus lent à preset égal (en savoir plus (http://collab.debian.net/portal/planet-debian/steinar-h.-gunderson-10-bit-h.264-tests)) et moins compatible (surtout avec les smartphones/TV/box).
Why does 10bit save bandwidth (even when content is 8bit)? (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

Conclusion simpliste : ton lecteur multimédia sait lire de l'H264 10bit ? si oui => encodage 10bit, sinon => encodage 8bit.

[shlagevuk]

The most dramatic example is when comparing the “medium” presets directly, where 10-bit runs at 2648 kbit/sec versus 3715 kbit/sec (29% lower bitrate!) and is only 5% slower. As one progresses towards the slower presets, the gap is somewhat narrowed (placebo is 27% slower and “only” 24% lower bitrate), but in the realistic middle range, the difference is quite marked. If you run 3 Mbit/sec at 10-bit, you get the quality of 4 Mbit/sec at 8-bit.

:O


So why does a AVC/H.264 10bit encoder perform better than 8bit?
When encoding with the 10bit tool, the compression process is performed with at least 10bit accuracy compared to only 8bit otherwise. So there is less truncation errors, especially in the motion compensation stage, increasing the efficiency of compression tools. As a consequence, there is less need to quantize to achieve a given bitrate. The net result is a better quality for the same bitrate or conversely less bitrate for the same quality: between 5% and 20% on typical sources.

TIL

Merci pour le lien Foudge, je les met en première page.

[Squarealex]

Hum, merci pour le lien. C'est vrai que c’était plus ce coté là que je voulais voir les différence. Donc grosso modo, 10 bits c'est plus ou moins mieux qu'en 8 bits que ça soit en qualités ou la place gagné quelle que soit la source. (D'ailleurs, les sources 10 bits on peut les trouver sur DVD ou seulement sur BluRay ?). Ça doit d'ailleurs être similaire pour le x265 ? En 10 bits ça sera forcément mieux qu'en 8 bits... (bon par contre, bonjour la conso CPU)
Pour l'encodeur, il faut une version spéciale de Handbrake ? Je me rappelle que quand j'avais testé le 10bits, ça n'a pas trop fonctionné.

[Taro]

:O

TIL

Merci pour le lien Foudge, je les met en première page.

C'est pas étonnant, ma foi, les processeurs modernes en x86 ont l'extension x86 extended precision qui fait que les opérations sur les nombres 64 bits sont effectuées en 80 bits.
C'est la même chose mais dans une moindre mesure et appliquée "à la mano" aux nombres 8 bits durant un encodage.
Et oui ce genre de "magouille" peut grandement augmenter la précision sur certains calculs.
:x1:

[Foudge]

Hum, merci pour le lien. C'est vrai que c’était plus ce coté là que je voulais voir les différence. Donc grosso modo, 10 bits c'est plus ou moins mieux qu'en 8 bits que ça soit en qualités ou la place gagné quelle que soit la source. (D'ailleurs, les sources 10 bits on peut les trouver sur DVD ou seulement sur BluRay ?). Ça doit d'ailleurs être similaire pour le x265 ? En 10 bits ça sera forcément mieux qu'en 8 bits... (bon par contre, bonjour la conso CPU)
Pour l'encodeur, il faut une version spéciale de Handbrake ? Je me rappelle que quand j'avais testé le 10bits, ça n'a pas trop fonctionné.A l'encodage ou au décodage ?
Au décodage, avec une résolution <= 1080p, même en software, ça devrait pas poser de problème, sauf cas spécifique (vieil Atom, petit CPU avec grosses contraintes de dissipation et/ou de consommation).
Pour l'encodage, pas tant que ça : c'est plus lent à preset égal mais à qualité égale, tu peux te permettre de descendre d'un cran le preset et être au moins aussi rapide (cf mon 1er lien). Bref, l'encodage 10bit est plus efficace à tous les niveaux. Au final, le seul réel inconvénient, c'est la compatibilité du 10bit.
D'ailleurs il semble bien qu'il faille effectivement une version spécifique d'Handbrake (pas testé) : https://mattgadient.com/2016/02/15/how-to-10-bit-x264-and-10-12-bit-x265-encodes-with-handbrake-mac-os-x-linux-windows/

[Squarealex]

Merci pour les réponses, du coup je sens que je vais réencoder certain truc. :D

[Foudge]

Merci pour les réponses, du coup je sens que je vais réencoder certain truc. :DSi t'arrives à encoder en 10bit avec Handbrake (à travers la GUI et non la CLI), tu pourras nous dire ici comment tu as fait ?

[Squarealex]

Pour le x264 10 bits, ils fonctionnent très bien en GUI avec les build Nightly que tu peux trouver là : https://handbrake.fr/nightly.php
Et le DLL x264 10bits (déjà compilé) que tu peux trouver là : https://mattgadient.com/download/handbrake/libx264_main10.dll.zip

Il faudra juste mettre le DLL dans le répertoire du Nightly. Tu auras accès au x264 10 bit dans vidéo codec
Tu peux aussi ajouter le DLL x265 edit : DLL trop ancien ou peut être bugué
En revanche, pour le x265 (que ça soit 10 ou 12 bit) ça ne fonctionne pas, l'encodage plante dès le début. Alors c'est peut être des ancienne version DLL qui provoque ce bug (bien que j'ai lu qu'actuellement seul la version CIL d'Handbrake est apte à encoder en 10bit, mais je pensais pas que le x264 10 bit fonctionnerais sur la GUI Nightly actuel).

[Squarealex]

Bon alors je confirme que pour le x265 (10bit et 12bit) ça vient bien des DLL trop ancien, donc si on veut encoder en x265 10 et 12 bit, il faudra les prendre dans le forum Dev de Handbrake.
Donc je récapitule, pour ceux qui veulent encoder en x264 10 bit et en x265 10 & 12 bit, il faut déjà un Handbrake Nightly (version récente en Dev) qu'on peut trouver ici : https://nightly.handbrake.fr/HandBrake-20170721-6eaa4e3_x86_64-Win_GUI.exe

Il faut ensuite télécharger le codec voulu à part dans le forum dev dans les fichiers joints (tout en bas pour les versions récente :cigare: ) qu'on peut trouver ici : https://forum.handbrake.fr/viewtopic.php?f=11&t=34165 (inscription obligatoire :tired: )

Et on place les fichiers dans le répertoire Handbrake Nightly. Ça devrait automatiquement le détecter dans la partie codec.

[Taro]

Merci pour le tuto ;)

Un peu relou d'avoir à s'inscrire par contre... :(

[Foudge]

Limite faudrait repackager un Handbrake 10bit et le mettre à dispo à tous les canards :ninja:

[Taro]

J'y pensais, mais bon, j'ai rien dit, de peur que ce soit contraire à la charte du forum.

[Squarealex]

A vous de voir, j'ai déjà préparer un .zip au cas où. Je sais juste que Handbrake est OpenSource. :p

[MegABiloU]

balance en mp :)

[Foudge]

La licence utilisée est assez permissive, il y a moyen de faire ça "proprement", en ajoutant dans le package un fichier readme.txt avec quelques infos : https://handbrake.fr/docs/license.html

[Squarealex]

J'ai fait un readme rapidement.


Ce package contient simplement Handbrake Nighty pour Windows x64 ainsi que les fichiers DLL nécessaire pour l'encodage en 10 bit (x264 et x265) et 12 bit (x265).

Aucun des fichiers présents ont été modifié.

Ce package est simplement un moyen accessible pour encoder en 10 et 12 bit.

Vous pourrez trouver Handbrake Nighty vià ce lien : https://handbrake.fr/nightly.php

Et les fichiers DLL nécessaire pour l'encodage 10 et 12 bit dans ce lien : https://forum.handbrake.fr/viewtopic.php?f=11&t=34165

Version de Handbrake : Nightly 20170720183902-6eaa4e3-master – 64 bit
Version des DLL : x265 v2.3, x264 r2708, b148, 86b7198
Date du package : 23/07/2017.


J'ai rajouté par la suite Licence.txt (de Handbrake ci-dessous) et Licence Summary.txt .



Copyright (C) 2003-2017 The HandBrake Team

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Je pense que ça devrait passer, ça autorise la distribution même en version Nightly. Confirmer si vous pensez que c'est ok. :cigare:

[Taro]

Ce package contient simplement Handbrake Nighty pour Windows x64 ainsi que les fichiers DLL nécessaires pour l'encodage en 10 bit (x264 et x265) et 12 bit (x265).

Aucun des fichiers présents n'a été modifié.

Ce package est simplement un moyen accessible pour encoder en 10 et 12 bit.

Vous pourrez trouver Handbrake Nighty via ce lien : https://handbrake.fr/nightly.php

Et les fichiers DLL nécessaires pour l'encodage 10 et 12 bit dans ce lien : https://forum.handbrake.fr/viewtopic.php?f=11&t=34165

Version de Handbrake : Nightly 20170720183902-6eaa4e3-master – 64 bit
Version des DLL : x265 v2.3, x264 r2708, b148, 86b7198
Date du package : 23/07/2017.

Fixed ;)

[Foudge]

Et il manque un "l" à "Nighty". J'pense que tu peux poster le lien de téléchargement ;)

[Squarealex]

Merci. :)
Je prends ça pour un Ok ;)

Voila le lien : https://drive.google.com/file/d/0B6OvWEJz8V14Qm1ReC0tdUdtRWM/view?usp=sharing - 16,4 Mb
Bouton télécharger en haut à droite, au cas-où. <_<

EDIT : Ah, je précise aussi que c'est en mode "portable". Donc les fichiers preview se feront dans le même dossier que Handbrake.

[shlagevuk]

C'est en première page, merci!

[XWolverine]

Super initiative ;)

[MegABiloU]

Pour la rétention du grain
-comme pour le x264: -tune grain

tiens je viens de tester staxrip pour faire de l'encodage avec nvenc sur ma gtx1070.

J'ai voulu tester le reglage -tune grain ou --tune grain bah on dirait que le truc connait pas la commande, des infos la dessus?

[shlagevuk]

Ce sont des options bien spécifique lié à l'encodeur.

Tu aura un jeu d'option complètement différent entre nvenc, quick sync, amd vce et x265. Pour les premier c'est parce que ce sont des encodeurs hardware qui ont assez peu de marge de manoeuvre. Et pour les encodeur software comme x265 ça dépend de l'implémentation ou non de ces options, par exemple x264 support le tune grain, pas (encore) x265.


Pour exemple ce que fait les option --tune en x264. Tu peux voir que les options sont un "alias" pour d'autres options.

--tune <string> Tune the settings for a particular type of source
or situation
Overridden by user settings.
Multiple tunings are separated by commas.
Only one psy tuning can be used at a time.
- film (psy tuning):
--deblock -1:-1 --psy-rd <unset>:0.15
- animation (psy tuning):
--bframes {+2} --deblock 1:1
--psy-rd 0.4:<unset> --aq-strength 0.6
--ref {Double if >1 else 1}
- grain (psy tuning):
--aq-strength 0.5 --no-dct-decimate
--deadzone-inter 6 --deadzone-intra 6
--deblock -2:-2 --ipratio 1.1
--pbratio 1.1 --psy-rd <unset>:0.25
--qcomp 0.8
- stillimage (psy tuning):
--aq-strength 1.2 --deblock -3:-3
--psy-rd 2.0:0.7
- psnr (psy tuning):
--aq-mode 0 --no-psy
- ssim (psy tuning):
--aq-mode 2 --no-psy
- fastdecode:
--no-cabac --no-deblock --no-weightb
--weightp 0
- zerolatency:
--bframes 0 --force-cfr --no-mbtree
--sync-lookahead 0 --sliced-threads
--rc-lookahead 0

[MegABiloU]

Donc si je copie

--aq-strength 0.5 --no-dct-decimate
--deadzone-inter 6 --deadzone-intra 6
--deblock -2:-2 --ipratio 1.1
--pbratio 1.1 --psy-rd <unset>:0.25
--qcomp 0.8
dans mes réglages je devrais obtenir le bon rendu.

edit : j'ai testé ça doit être un peu plus complexe.

[shlagevuk]

Tu n'as pas forcément les même option en x265, et trouver les équivalents va être compliqué puisque là il est question de tuner les options relatives au fonctionnement de la compression.

[MegABiloU]

J'ai testé la version de l'op de handbrake. en 10 et 12 bits hevc

ben le rendu est pas terrible pas mal d'artefact...

d'autres on testé?

[Taro]

Perso je suis resté sur un build officiel. Depuis que j'ai un Ryzen 1700X, je ressens un peu moins le besoin d'utiliser le GPU de la 1070 pour l'encodage. :)
Tu as un screenshot des artefacts que tu obtiens ?

[MegABiloU]

bah la c'était pas en gpu justement ....

[Foudge]

Artefacts vs 8bit ou vs x264 ?
Problème avec la nightly ?

[MegABiloU]

@Foudge,
Artefact tout court en hevc 10bits et 12 bits source blu ray. Je n'ai pas encodé en h264 car ce n'est pas mon objectif.
Je posais la question pour savoir si d'autres utilisaient cette version.

http://tof.cx/images/2017/09/11/c1f363504dd5fc3c8b28b773b0cb4f0e.md.png (http://tof.cx/image/3Y9ac)

ce genre d'artefact.

que l'on a pas sur le blu ray

http://tof.cx/images/2017/09/11/d1a99af0bcb06675605d7b9c87a0b505.md.png (http://tof.cx/image/3YICG)

[Foudge]

Il y a moyen, dans le cadre du droit de courte citation (article L122-5 du code de la propriété intellectuelle) si c'est soumis à du droit d'auteur, dans un but purement pédagogique/scientifique, de nous mettre à disposition une très courte séquence non transcodée afin qu'on puisse faire le test de notre côté ?
Je n'utilise que la version officielle, pas une nightly, ni le package 10/12bit.

[Taro]

Ah ouais c'est assez moche, et comme je sais que tu as l'oeil tu dois sûrement le voir très nettement même en mouvement.

[MegABiloU]

Du coup la nightly en op faudrait voir a faire des tests de votre coté si c'est que chez moi que ça merde ou pas.

Ou alors c'est le profil grain qui fout la merde.

je vais faire un test en psnr (ce qu' j'utilise habituellement)

[MegABiloU]

Bon bonne nouvelle, c'est juste moi qui suis un peu con et qui ai coché l'option de décodage nvcuda alors que le copy back est recommendé.

Codec réinstallé tout fonctionne.

d'ailleurs en conservant le grain c'est vachement propre.

http://tof.cx/images/2017/09/15/f59935234ddbd7e618ebecdf6d8e0ad6.png (http://tof.cx/image/DDZcZ)

[Galoup]

Bonjour les Canards !

Je suis nouveau sur ce forum, est pour raison votre topic m'intéresse :D

J'ai quelques questions :

Au jour d'aujourd'hui, quel est le meilleur logiciel pour de l'encodage en X265 ?
Est-ce mieux d'encoder via le CPU ou GPU ?
Voulez vous voir ma config pour me donner votre avis ?

Suivant les réponses, les questions suivront.

Merci

[Squarealex]

Salut.

Le meilleur logiciel est je pense celui ou on se sent mieux. Je connais un peu Handbrake, car à la fois accessible, pratique et pour l'instant, il est le seul que je connais qui tente le x265 (Je peux me tromper, bien sûr). Xmedia Recode est plus complet (beaucoup de paramètre) mais ne fait pas encore le x265. Peut être qu'AVIDemux le fait, mais c'est un logiciel que je trouve assez instable le peu que je l'ai utilisé.

Pour la seconde question, d'après ce que je lis à droite et à gauche, bien que le GPU peu accélérer le traitement, son support peut être en deçà d'un encodage Full CPU.
Pour la troisième, si tu veux. Même si le plus important reste le CPU. ^_^


Bon bonne nouvelle, c'est juste moi qui suis un peu con et qui ai coché l'option de décodage nvcuda alors que le copy back est recommendé.

Codec réinstallé tout fonctionne.

d'ailleurs en conservant le grain c'est vachement propre.

Hum, d'ailleurs, le fait de conserver le grain ne va t-il pas rendre la vidéo plus lourde ? (voir plus qu'en x264 ?).
Aussi, que signifie PSNR et SSIM dans encoder tune ? :blink:

[Galoup]

J'ai cherché sur le net, j'ai handbrake et DVDFab 10 je trouve DVDFab sympa. mais est-il bien ?

PC Asus G11CD
I7-6700 3.40Ghz (8cpus)
8Gb Ram
Nvidia GeForce GTX 1060 6Gb

[Squarealex]

Je pense pas que DVDFab soit aussi complet que Handbrake en terme d'encoage, après je le connais pas trop. (Mais sans doute bon pour transformer un BluRay en Remux, bon les DVD c'est plus compliqué).
Concernant ta config, c'est largement bien :D

Après, faut faire des test pour voir si c'est plus rapide avec ou sans MT pour le CPU. (Par exemple, sur Sony Vegas, c'est plus rapide sans avec mon i7 3770k.)

[Rocca]

Y'a aussi format factory qui permet d'encoder en H265.

Perso, je préfère Handbrake qui va plus loin dans les paramétrages.

Néanmoins, format factory offre plus de "formats" de sortie.

[Galoup]

'accord merci pour vos infos, j'ai pris le handbrake de juillet 2017 en zip trouvé sur ce topic.


Dois-je laisser les paramètres par défaut ou alors que me conseilleriez vous ?

Je voudrais avoir un bon réglage et commencer a transformer une saison de breaking bad

[MegABiloU]

Breaking bad je les ai déjà faits ;)

En HEVC je les ai faits dans les 5000 Kbps de bitrate vidéo car en dessous ça ne me plaisait pas.

du coup faut trouver le rf correspondant : RF18 probablement.
Et si tu veux garder le grain ça va faire long l'encodage par contre.

[Galoup]

lol pas grave je laisse tourner le PC ^^

Donc dans Hb je juste un preset de mkv en h265 1080p et je modifie moi mémé le RF ?

Si tu as les liens de download je les veux bien ^^ ça me ferait gagné du temps lol

[MegABiloU]

Fais des essais pour voir et si ça te conviens lance 1 épisode voir si la taille va.

[Taro]

Si tu as les liens de download je les veux bien ^^ ça me ferait gagné du temps lol

J'veux pas casser l'ambiance, copain, mais ça je pense que ça irait à l'encontre des règles du forum. ;)

[Galoup]

J'veux pas casser l'ambiance, copain, mais ça je pense que ça irait à l'encontre des règles du forum.

Ok merci ;)

Voilà un essai :

Vidéo source :

Général
Identifiant unique : 247877249538605205570968625563090257256 (0xBA7B6BF7468726898E46C36698238568)
Nom complet : G:\Series\American horror story\American.Horror.Story.S06\American.Horror.St ory.S06E01.FRENCH.720p.HDTV.x264-AMB3R.mkv
Format : Matroska
Version du format : Version 4 / Version 2
Taille du fichier : 621 Mio
Durée : 40 min 48s
Débit global moyen : 2 128 kb/s
Date d'encodage : UTC 2017-04-22 19:59:46
Application utilisée : mkvmerge v10.0.0 ('To Drown In You') 64bit
Bibliothèque utilisée : libebml v1.3.4 + libmatroska v1.4.5

Vidéo
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Profil du format : High@L4.1
Paramètres du format : CABAC / 5 Ref Frames
Paramètres du format, CABAC : Oui
Paramètres du format, RefFrames : 5 images
Identifiant du codec : V_MPEG4/ISO/AVC
Durée : 40 min 48s
Débit : 1 934 kb/s
Largeur : 1 280 pixels
Hauteur : 720 pixels
Format à l'écran : 16/9
Type d'images/s : Constant
Images par seconde : 25,000 Im/s
Espace de couleurs : YUV
Sous-échantillonnage de la chrominance : 4:2:0
Profondeur des couleurs : 8 bits
Type de balayage : Progressif
Bits/(Pixel*Image) : 0.084
Taille du flux : 565 Mio (91%)
Bibliothèque utilisée : x264 core 148 r2762 90a61ec
Paramètres d'encodage : cabac=1 / ref=5 / deblock=1:1:1 / analyse=0x3:0x112 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Oui
Forced : Non

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Paramètres du format, Endianness : Big
Identifiant du codec : A_AC3
Durée : 40 min 48s
Type de débit : Constant
Débit : 192 kb/s
Canaux : 2 canaux
Position des cannaux : Front: L R
Echantillonnage : 48,0 kHz
Images par seconde : 31,250 Im/s (1536 SPF)
Profondeur des couleurs : 16 bits
Mode de compression : Avec perte
Taille du flux : 56,0 Mio (9%)
Langue : Français
ServiceKind/String : Complete Main
Default : Oui
Forced : Non


Vidéo convertie :

Général
Identifiant unique : 238935332083922771690360138339476312247 (0xB3C14565B64C5325BC9FD4D61BE410B7)
Nom complet : G:\Series\American horror story\American.Horror.Story.S06\American.Horror.St ory.S06E01.FRENCH.720p.HDTV.x264-AMB3R1.mkv
Format : Matroska
Version du format : Version 4 / Version 2
Taille du fichier : 267 Mio
Durée : 40 min 48s
Débit global moyen : 915 kb/s
Date d'encodage : UTC 2017-10-23T06:52:28Z
Application utilisée : HandBrake 20170720183902-6eaa4e3-master 2017072101
Bibliothèque utilisée : Lavf57.7.2

Vidéo
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Profil du format : Main@L3.1@Main
Identifiant du codec : V_MPEGH/ISO/HEVC
Durée : 40 min 48s
Largeur : 1 160 pixels
Hauteur : 720 pixels
Format à l'écran : 16:10
Type d'images/s : Constant
Images par seconde : 25,000 Im/s
Espace de couleurs : YUV
Sous-échantillonnage de la chrominance : 4:2:0
Profondeur des couleurs : 8 bits
Bibliothèque utilisée : x265 2.4:[Windows][GCC 5.3.1][64 bit] 8bit
Paramètres d'encodage : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1160x720 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / refine-level=5 / no-limit-sao
Default : Oui
Forced : Non
Gamme de couleurs : Limited
Coordonnées de chromaticité : BT.709
Caractéristiques du transfert : BT.709
Coefficients de la matrice : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Profil du format : LC
Identifiant du codec : A_AAC-2
Durée : 40 min 48s
Canaux : 2 canaux
Position des cannaux : Front: L R
Echantillonnage : 48,0 kHz
Images par seconde : 46,875 Im/s (1024 SPF)
Mode de compression : Avec perte
Titre : Stereo
Langue : Français
Default : Oui
Forced : Non

[Rocca]

En passant vite fait, tu passe d'une résolution de 1280 X 720 à 1160 X 720 !

C'est voulu ?

[shlagevuk]

En fonction des soft t'en as qui font automatiquement du cropping s'il détecte que le format video réel est différent du 16:9 habituel. Ça ne marche pas toujours d'ailleurs (the grand budapest hotel qui est transformé en 4:3 chez moi ^^')

[MegABiloU]

faut mettre cropping en manuel à zero, par défaut handbrake met un cropping auto.

En vrai tu ne vois pas la différence mais bon ....

[Galoup]

En passant vite fait, tu passe d'une résolution de 1280 X 720 à 1160 X 720 !

C'est voulu ?

Non du tout.


@MegABiloU :

Comment mettre en manuel le cropping ?

[MegABiloU]

Tu sauvegarde dans ton profil en faisant comme suit :

http://tof.cx/images/2017/10/24/e525e2f76ffd7f8359a71dd8f28145e3.png

[Galoup]

Ok je refait un test :)

[Askulmin]

Bonjour les canards,
Le reglage basique x265 suffit t-il pour conserver une qualité suffisante pour du stockage sur un NAS ? Ou vaut-il mieux passer sur un autre format ?

[MegABiloU]

En HEVC le profile de base doit être correct.

Je pense que le HDlight peut aussi faire le taf. (x264 avec des reglage optimisés et un bitrate vidéo dans les 1500-2500 max.)

Si c'est pour du stockage le temps d'encodage sera un critère de sélection.

PAr contre je n'ai pas de profile hdlight (ça m'intéresse par ailleurs)

[Askulmin]

Je pense que le HDlight peut aussi faire le taf. (x264 avec des reglage optimisés et un bitrate vidéo dans les 1500-2500 max.)

Si c'est pour du stockage le temps d'encodage sera un critère de sélection.

Que veut tu dire par 'temps d'encodage' sera un critere ?
Et le x265 n'est pas plus leger ?

[MegABiloU]

le hdlight doit pouvoir s'en approcher sans trop de compromis.

[Galoup]

Général
Identifiant unique : 252700511461910408244931348237556397227 (0xBE1C59238BE67145F6A7B2EDCE0C34AB)
Nom complet : G:\Series\American horror story\American.Horror.Story.S06\American.horror.st ory.s06e01.french.720p.hdtv.x264-amb3r-1.mkv
Format : Matroska
Version du format : Version 4 / Version 2
Taille du fichier : 254 Mio
Durée : 40 min 48s
Débit global moyen : 870 kb/s
Date d'encodage : UTC 2017-10-24T13:16:18Z
Application utilisée : HandBrake 20170720183902-6eaa4e3-master 2017072101
Bibliothèque utilisée : Lavf57.7.2

Vidéo
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Profil du format : Main@L3.1@Main
Identifiant du codec : V_MPEGH/ISO/HEVC
Durée : 40 min 48s
Largeur : 1 160 pixels
Hauteur : 720 pixels
Format à l'écran : 16/9
Type d'images/s : Constant
Images par seconde : 25,000 Im/s
Espace de couleurs : YUV
Sous-échantillonnage de la chrominance : 4:2:0
Profondeur des couleurs : 8 bits
Bibliothèque utilisée : x265 2.4:[Windows][GCC 5.3.1][64 bit] 8bit
Paramètres d'encodage : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1160x720 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=255 / sar-width / : / sar-height=32:29 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / refine-level=5 / no-limit-sao
Default : Oui
Forced : Non
Gamme de couleurs : Limited
Coordonnées de chromaticité : BT.709
Caractéristiques du transfert : BT.709
Coefficients de la matrice : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Profil du format : LC
Identifiant du codec : A_AAC-2
Durée : 40 min 48s
Canaux : 2 canaux
Position des cannaux : Front: L R
Echantillonnage : 48,0 kHz
Images par seconde : 46,875 Im/s (1024 SPF)
Mode de compression : Avec perte
Titre : Stereo
Langue : Français
Default : Oui
Forced : Non



Voila le second essai.

[MegABiloU]

ET visuellement ça te convient? La taille du fichier est cohérente.

[Askulmin]

Alors petite review perso :
Fichier d'origine x264 720p - 1GO
Encodage x265 720p - 450mo
Encodage fast 720p - 750mo

Comment vous pouvez comparer les différentes qualité d'image ? Parce que visuellement je n'ai pas de grosse différence sur le x265.

[Foudge]

Alors petite review perso :
Fichier d'origine x264 720p - 1GO
Encodage x265 720p - 450mo
Encodage fast 720p - 750mo

Comment vous pouvez comparer les différentes qualité d'image ? Parce que visuellement je n'ai pas de grosse différence sur le x265.Ce n'est pas simple : http://www.hardware.fr/articles/828-5/mesurer-qualite-psrn-ssim-leurs-travers.html

[Galoup]

Super Merci je m'en sort pas trop mal ^^

Dite moi comment je peux convertir du 2.0 vers 5.1 ? Possible ?

[Foudge]

Ca peut se faire en temps réel lors de la lecture. J'sais pas si Handbrake sait faire ça.
Bien entendu, tu te doutes bien que ça n'auras rien à voir avec du vrai 5.1.

[MegABiloU]

tu peux le faire dans handbrake facilement.

[NicCo]

Bonsoir tout le monde :)
Je débarque sur ce topic parce que j'aimerais me lancer dans le x265 donc je cherche des infos ;)
J'ai actuellement une collection de Blu ray que j'avais converti en x264 CRF18 preset slower et j'aimerais maintenant la passer en x265.
Je me demande si je peux repartir de mes conversions x264 -> x265 ou si je dois ripper de nouveaux mes Blu ray... Je me doute que repartir d'un Blu ray doit être l'idéal mais vu le temps de rip si je peux éviter c'est mieux ^^
J'ai commencé quelques tests en slower mais c'est beaucoup trop long (entre 36 et 48 heures pour un film de 2h15), j'ai testé le slow qui est déjà plus raisonnable en temps mais toujours un peu long et le medium qui est un bon compromis de temps. J'ai lu par ci par là que le preset influence ou non la qualité, selon les sources ça impacte la qualité et la taille du fichier, selon d'autres uniquement la taille finale. Quelqu'un a des infos là-dessus ?
Si le preset a une influence, est-ce qu'on peut le compenser en baissant un peu le CRF pour avoir plus de bitrate ? Si certains ont fait des tests je suis intéressé. Merci !

[Galoup]

Ok merci !!

Par contre j'ai fait quelques test. j'ai un fichier vidéo en x264 1080p à 9536kbps et quand je l'encode en x265 il passe à 2618kbps.

C'est ça de l'HDLight ?
Comment je peu garder mon kbps d'origine ?

[NicCo]

Il ne faut pas chercher à comparer les bitrates de 2 codecs différents. La HDLight peut se faire en x264 en abaissant le bitrate assez bas mais en réglant plus finement l'encodage, tu peux réussir à avoir quelque chose de correct pour une taille contenue. En x265 la compression est plus optimisée donc tu peux avoir un bitrate bien plus bas tout en conservant une qualité d'image identique.

[Guapo]

Ok merci !!

Par contre j'ai fait quelques test. j'ai un fichier vidéo en x264 1080p à 9536kbps et quand je l'encode en x265 il passe à 2618kbps.

C'est ça de l'HDLight ?
Comment je peu garder mon kbps d'origine ?

Quel intérêt de passer tes x264 en x265 dans ce cas là ?
Ta source est déjà compressée, donc tu ne vas pas avoir une meilleure qualité après réencodage en x265. Le seul intérêt est donc de tirer parti d'une meilleure compression et de gagner de l'espace de stockage...

[MegABiloU]

Quel intérêt de passer tes x264 en x265 dans ce cas là ?
Ta source est déjà compressée, donc tu ne vas pas avoir une meilleure qualité après réencodage en x265. Le seul intérêt est donc de tirer parti d'une meilleure compression et de gagner de l'espace de stockage...

Oui de mon coté je reprends systématiquement des sources originales ou faut de mieux du H.264 très peu compressé.

[Guapo]

Dite moi comment je peux convertir du 2.0 vers 5.1 ? Possible ?

Le mieux est encore d'utiliser un player ou un décodeur qui permet de faire ça.
La plupart des amplis HC permettent de faire du Dolby Prologic 2 ou du NEO6.
Si tu fais ça lors de l'encodage, tout ce que tu vas faire est ajouter un piste 5.1 (et donc des bps) sur ton fichier pour le même résultat.

[NicCo]

Oui de mon coté je reprends systématiquement des sources originales ou faut de mieux du H.264 très peu compressé.
Et tu utilises quoi comme settings pour tes compressions ?

[shlagevuk]

En ce moment pour l'archivage, je prend des sources x264 avec un bitrate élevé (BRrip remux ou film x264 >8Go) et je les passe en x265 avec CRF 25 et preset medium. En fonction du film je tombe sur un fichier vidéo aux environ de 4Go dont la qualité me suffit.

[MegABiloU]

Super Merci je m'en sort pas trop mal ^^

Dite moi comment je peux convertir du 2.0 vers 5.1 ? Possible ?

Quel intérêt?
ton installation doit pouvoir lire nativement du 2.0 et le lire sur le 5.1.


Et tu utilises quoi comme settings pour tes compressions ?

ça fait longtemps je ne saurais te dire mais c'est assez proche des settings de shlaguevuk.

[weyb06]

bonsoir,

je suis nv sur le forum, je suis tombé sur cette discussion après recherches, mais vu qu'elle a l'air de dater un peu, je ne sais pas du coup si je suis au bon endroit...

Mon contexte :
j'ai une CG GTX 960 et j'aimerais ré-encoder mes TRES nbeuses videos en H265.
Elles sont de qualité TRES diverses (HD, SD, TV, etc.) avec donc des débits TRES variables...
j'ai commencé a le faire de façon unitaire, avant d'avoir la CG, en choisissant le CRF=23.
mais avec elle, j'utilise "NVEnc" et là, plus de CRF :|
--> y a-t-il un moyen d'avoir un équivalent ? genre "je veux telle qualité d'image, débrouille-toi avec le débit" comme avec le CRF ?

j'ai cherché sur le net et je suis tombé sur CQP, mais sans aucun conseil pour la valeur :|

j'utilise le freeware Hybrid qui propose alors 2 options :
- soit fixer la valeur
- soit fixer un triplet qui a l'air de correspondre aux "I, P et B" (keyframes ???), dont les valeurs par défaut sont 20/23/25 --> les mêmes valeurs que celles d'un autre freeware StaxRip (cf ici (https://www.reddit.com/r/nvidia/comments/561k3m/pascal_h265hevc_10_bit_encode_feature_and_how_to/)et ici (https://www.techspot.com/article/1131-hevc-h256-enconding-playback/page5.html)), qui a priori sont optimisées pour le rapport qualité/taille finale...
j'ai essayé comme ça mais ça me donne à l'arrivée des fichiers + gros qu'avec le CRF 23 :(

avec le topic "[HEVC] Le topic où on aime encoder", je me dis qu'ici, il doit y avoir qq qui a fait des tests ou qui a une meilleure compréhension que moi du sujet, de tout ce que je "crois" comprendre, etc. et qui doit pouvoir apporter des pistes de réponse à mon besoin - qui ne me semble pas déconnant à la base, d'où ma surprise de ne pas trouver de sujets traitant ce point...

d'avance merci pour votre aide !!!

bien cordt

[Rocca]

Salut, tu veux réencoder avec ta GTX 960 ? Tu as quoi comme processeur au passage ?

Perso, j'ai jamais testé, car à l'heure actuelle j'ai une 7870XT donc bon.

Dans un temps, j'espère proche, je pourrais tester avec le R7 2700X et, normalement si je m'en sors de mes problème de livraison, avec une GTX 1070 Ti.

De ce que j'ai lu jusqu'à maintenant, même résultats pour le X264, c'est qu'au final c'est plus rapide, mais moins bon niveau qualité.

[weyb06]

hello,

j'ai un core i7 4770 et je fais pas du 20fps qd j'encode en H265 sans CG - ce qui est lent, vu que j'ai des centaines de cartoons à encoder...
:(
car avant qu'on me donne la 960, je faisais forcément sans, et j'avais 3 choix :
- handbrake
- hybrid
- ffmpeg en cmdline
et tout en choisissant un CRF = 23 pour chacun des 3, je ne trouvais pas la même taille de fichier au final (http://www.homecinema-fr.com/forum/post179643794.html#p179643794)(à peu de chose près, je ne suis pas tatillon) !!!
:blink:

je trouve de + en + qu'encoder en H265, c'est vraiment une histoire de ouf...
je souhaite juste choisir une qualité correcte, pas passer des heures à trouver les bons paramètres pour tel fichier et recommencer pour un autre...

je vais poster d'ici ce soir ici les autres tests que j'ai fait...

cordt

[MegABiloU]

Coucou j'encode en x265 10bits RF15 sur mon cpu un I7-3820.

Je suis rarement au dessus de 3Fps.
Je vais tester avec nvenc sur la dernière nightly de handbrake.

Pa contre en 20fps tu lance en very fast? Je fais tout en slow de mon coté pour éviter les erreurs.

Sinon tu peux t'amuser à préparer l'avenir avec des encodages en AV1 (https://www.tomshardware.fr/articles/av1-codec-video,1-67204.html) :siffle:

[Rocca]

Tiens salut Megabilou.

J'ai vu que handbrake propose depuis je ne sais combien de temps, du x265 10 bit ou 12 bit (la version standard).

Les réglages effectués, il y a un an étaient en H265 (x265) pour ma part et j'ai laissé comme ça depuis (RF 22; PNSR, MAIN).

J'ai testé hier les différents codecs disponibles indiqués ci-dessus sur une série en 1080 p (H264 au départ) et niveau taille à la fin, y'a pas grande différence. Je ne vois pas plus que ça non plus de différence au niveau de la qualité image.

As-tu des infos ou as-tu fait des tests depuis les derniers posts d'il y a quelques temps maintenant ?

En te remerciant.

[Rocca]

Bon, j'ai pas vu de grande différence entre le 10 bit et 12 bit en H265 à part que la GT 1030 sur le petit HTPC est incapable de lire de manière parfaitement fluide la vidéo en 12 bits (pas de support hardware apparemment).

Après avoir lu les posts précédents à nouveau, j'en comprends que le h265(x265) est en 8 bit et que le H265(10bit) est un peu mieux. Je vais regarder ça plus en détails et notamment la perte de temps pour le gain visuel obtenu ;)

Pour le AV1 connais-tu un logiciel d'encodage qui l'exploite ?

Après faut trouver un lecteur capable de le lire...

[MegABiloU]

Salut Rocca, comme écrit plus haut, je fais mes rip à partir de bluray en x265 10bits via Handbrake, et j'ai légèrement baissé le RF pour 15 car je rip que des animes.

J'ai encore pas mal de test a effectuer avec les nouveaux paramètres dispo sur les dernières nightly de handbrake. Dont le nvenc.

[Rocca]

Ok merci, moi je suis sur la version standard de handbrake qui me va déjà très bien.

Mais tes paramètres et avis me sont très utiles.

D'ailleurs, j'ai encore, à quelque chose près, tes réglages de la page du topic :p

[Thomas91]

Bonjour,

Je ne sais pas si ce sujet est toujours d'actualité mais j'aimerais convertir un fichier TS en MKV avec Staxrip.

J'ai fait plusieurs test mais j'aimerais savoir ce que vous me conseillez pour avoir un fichier de taille réduite tout en gardant une très bonne qualité.

H264 ou H265 ? Combien de bitrate ? Etc.

Je suis un peu perdu.

Merci.

[MegABiloU]

Pour du dvd du h264 suffit en RF 20 ou en bitrate vidéo tu peux partir sur 1200Kbits/s

[Thomas91]

Pour du dvd du h264 suffit en RF 20 ou en bitrate vidéo tu peux partir sur 1200Kbits/s

Bonjour et merci d'avoir répondu.

Donc je met le codec x264 et seulement 1200 en bitrate ?

On parle bien du H264 en HEVC avec Staxrip ?

EDIT: Mon fichier TS a été créé car j'ai enregistré un film sur une chaîne de télévision directement depuis mon PC.
Il fait 14Go pour 2h.

Désolé mais je ne vois pas où je peux modifier le RF et les Kbits/s
https://i.imgur.com/e98MzMU.png

[MegABiloU]

Désolé j'utilise handbrake. Ton logiciel je ne maîtrise pas.

[Thomas91]

D'accord merci.

Et donc quels sont les paramètres exact que tu utilise avec hanbrake stp ?

Tu le fait en mode HEVC ou normal pour le x264 ?

As tu un screen de tes paramètres stp ?

[shlagevuk]

Pour ta cible d'encodage ça dépend de deux critère:
-Sur quoi tu veux le lire?
-Que favorises-tu, la vitesse d'encodage ou la taille du fichier final?

Pour la première, si tu compte lire ta video sur un périphérique mobile (téléphone, tablette) il faut que l'encodage soit utilisable par le décodeur hardware du périphérique. Tous aujourd'hui sont compatible x264, mais pas forcément x265 (et rarement les profile 10/12b du x265). Si tu ne compte le lire que sur un PC assez puissant tu n'as pas de question a te poser.

Ensuite si tu veux encoder rapidement la video, x264 sur un profile slow te permettra d'avoir ta video de dispo en ~ 1h, mais la taille finale peut-être du même ordre de grandeur que l'original ( un BR de 30Go donnerai un fichier en x264 réencodé de ~ 10Go, ça dépend de la qualité que tu souhaite cela dit)
Si tu veux quelque chose que tu vas archiver, x265 est plus pertinent, en utilisant les profils 10/12b du x265 et un encodage en slow tu peux tomber a 6-8Go pour une qualité équivalente au x264 que je donnais juste avant.

Pour info j'utilise toujours un bitrate variable pour qualité constante. RF 20 pour le x264 et RF24 pour x265.

[Thomas91]

Pour ta cible d'encodage ça dépend de deux critère:
-Sur quoi tu veux le lire?
-Que favorises-tu, la vitesse d'encodage ou la taille du fichier final?

Pour la première, si tu compte lire ta video sur un périphérique mobile (téléphone, tablette) il faut que l'encodage soit utilisable par le décodeur hardware du périphérique. Tous aujourd'hui sont compatible x264, mais pas forcément x265 (et rarement les profile 10/12b du x265). Si tu ne compte le lire que sur un PC assez puissant tu n'as pas de question a te poser.

Ensuite si tu veux encoder rapidement la video, x264 sur un profile slow te permettra d'avoir ta video de dispo en ~ 1h, mais la taille finale peut-être du même ordre de grandeur que l'original ( un BR de 30Go donnerai un fichier en x264 réencodé de ~ 10Go, ça dépend de la qualité que tu souhaite cela dit)
Si tu veux quelque chose que tu vas archiver, x265 est plus pertinent, en utilisant les profils 10/12b du x265 et un encodage en slow tu peux tomber a 6-8Go pour une qualité équivalente au x264 que je donnais juste avant.

Pour info j'utilise toujours un bitrate variable pour qualité constante. RF 20 pour le x264 et RF24 pour x265.

D'accord merci beaucoup je comprend mieux.

Ce serait pour la lire sur pc et sur les box TV, la plupart lisent maintenant le x265.

Ensuite passé de 30Go à 10Go je trouve quand même énorme. C'est pas mal.

Tu met combien de temps pour encoder en x265 ? Ca doit être très long non ?

Par exemple un fichier video TS de 5Go, en combien de temps pour le x264 et x265 en slow ?

Et tu choisis bien ce profil

https://i.imgur.com/bKIhuKJ.png

Avec le mode HEVC ?

https://i.imgur.com/Oc29yt2.png

[MegABiloU]

Bah ça dépend de ton proc et de ta carte graphique en fait.
Nvenc ça fonctionne sur des cartes graphiques nvidia à partir des 900.
Pour les profils pas nvenc bah ça dépend de ton processeur.

Si tu as un lien vers ton TS je saurai te dire car la vitesse dépendra beaucoup du fichier source.
Exemple si j'encode un film d'action je n'aurai pas le même temps d'encodage en vbr qu'un dessin animé avec plein de plans fixes.
Complexité de la scène et niveau de mouvement influent beaucoup sur le temps d'encodage et la taille du fichier final. Et on rajoute encore plus de poids si on conserve le grain

[Thomas91]

Bah ça dépend de ton proc et de ta carte graphique en fait.
Nvenc ça fonctionne sur des cartes graphiques nvidia à partir des 900.
Pour les profils pas nvenc bah ça dépend de ton processeur.

Si tu as un lien vers ton TS je saurai te dire car la vitesse dépendra beaucoup du fichier source.
Exemple si j'encode un film d'action je n'aurai pas le même temps d'encodage en vbr qu'un dessin animé avec plein de plans fixes.
Complexité de la scène et niveau de mouvement influent beaucoup sur le temps d'encodage et la taille du fichier final. Et on rajoute encore plus de poids si on conserve le grain

Bonjour et merci.

Ma config:
- Azrock Z170 Extreme 4 Custom
- I5 6500 3.2Ghz Non K que j'ai OC à 4.4Ghz
- Zotac mini GTX 1060 6Gb que j'ai OC 2100Mhz
- 8 Go RAM que j'ai OC 3500Mhz

Le fichier .TS:
https://drive.google.com/open?id=1EGN85boiZTZeaVSY5_u3oMEUVx-ey3dN

[MegABiloU]

je viens de regarder ton .ts et l'encodage est déjà pas trop mal à la base, On peut en réduire la taille en le passant en h265 mais il faudrait déjà couper les pubs avant et après. Sinon en h264 comme il est pas besoin de réencoder.

En nvenc il me met 1 h d'encodage mais je ne suis pas satisfait de la taille du fichier en sortie pour l'instant je regarde quel réglage convient le mieux.
Par contre en encodage logiciel j'en ai pour une bonne journée.

[Thomas91]

Merci pour ton retour.

Je l'ai enregistrer avec un logiciel qui me permet de regarder les chaines TV. Une sorte de VLC.

Oui je comptais supprimer les pub avec un logiciel qui permet de le faire sans re encodage.

Quand tu dit que ça te met une journée en encodage logiciel, tu veux dire encodage avec le CPU pour le x265 ?

[MegABiloU]

CPu,

Sinon après avoir testé le nvenc h265 avec un QP à 24, j'obtiens un fichier plus gros que l'original donc aucun intérêt.

je vais tester d'autres paramètres.

[shlagevuk]

Tu met combien de temps pour encoder en x265 ? Ca doit être très long non ?
Oui, mais c'est mon serveur qui s'en occupe du coup ça me pose pas de problème.

Globalement j'en ai pour ~12 à 18h pour encoder un film en x265 12b en slow sur un xeon X5670 (6c/12t @ 3Ghz, première génération de "core") Je tombe a ~6h sur Ryzen 1800X.

[MegABiloU]

Petit retour en nvenc QP 38 bon je pense que c'est un peu compressé. je passes des 5Go à 1.1Go

http://tof.cx/images/2018/11/13/ad363aa091e78e81394a1b4507d79e08.png

donc je pense que si tu veux un rip qualité correcte sans y passer des heures, tu prends nvenc QP 30 et zou.

[Thomas91]

J'ai lu vos deux derniers messages.

Bah merci beaucoup c'est super sympa à vous.

Et par exemple si ça aurait été un film d'action avec pas mal de mouvement. Un RF 20 ferai l'affaire pour du h264 ?

[MegABiloU]

On ne peut pas vraiment prédire la taille faut essayer.

[Thomas91]

D'accord merci

[rotoclap]

Pour mieux prédire la taille, faut encoder en average bitrate, pas en Constant Quality. Mes encodages, je les fait comme ça justement pour cette raison. Bien sûr, quand on choisit average bitrate, faut le faire en 2 pass, ça évite que l'encodeur gache du bitrate sur des scènes qui ne le mérite pas.

[MegABiloU]

oui pour s'assurer d'un taille mais je suis pas trop fan de ce type d'encodage, je préfère une qualité constante.

C'est un peu comme le format sonore c'est un débat.

[R_K]

Vous faites comment pour calculer le bitrate à indiquer en fonction de la taille voulue en sortie?

[MegABiloU]

Il y a des abaques qui te permettent de déterminer ça.

un petit exemple pour le h264

http://www.lighterra.com/papers/videoencodingh264/

mais il y a probablement des trucs plus à jour.

[Rocca]

Tiens petit retour concernant Handbrake vs Format factory. Le but n'est pas de faire les plus et les moins de chacun, mais simplement de parler de la partie encodage et surtout niveau performances.

C'est difficile d'avoir des paramètres parfaitement identiques, car Handbrake fait peu, mais en poussé contrairement à FF.

Le pourquoi : quand j'encode des divx vers H265 ou fimls H264 1080p vers H 265, j'ai noté, respectivement, une occupation CPU de 25 % et 78 % en moyenne sous handbrake avec mon R7 2700X.

J'ai donc voulu tester un autre logiciel utilisant 100 % de mon CPU :)

C'est là que c'est drôle !!

Test : 4 fichiers divx de 750 Mo chacun en H265.

Format Factory :

Je l'ai mis à son avantage, car il traite jusqu'à 4 tâches en même temps sur mon R7 (et tout processeur me semble). J'ai donc lancé au départ les 4 divx à encoder en même temps (ils ne finissent pas en même temps, d'où les détails ci-dessous ^^).

Au final, l'occupation était de 105 % (4 en même temps) puis 96% (3 restants), puis (75-65% 2 restants) et enfin, le dernier qui trainait (47-36%).

Le tout a mis environ 52 minutes.

Handbrake :

Vu qu'il ne prend pas plusieurs films en même temps, je les ai mis à encoder les uns après les autres (queue). Durée totale : 42 minutes.

Au niveau des fichiers, la qualité finale, déjà plus que médiocre au départ, était identique pour les deux (normal j'ai essayé de rapprocher au max les paramètres d'encodage). Par contre, avantage à Handbrake, car les dossiers finaux, 3 sur 4, étaient plus petits pour une même quantité.


Conclusion : pour une durée moindre, malgré une occupation CPU moindre, handbrake arrive au même résultat plus rapidement.

Comme quoi, j'étais tout content de voir FF utiliser 100 % des ressources processeurs, voire même 105%, mais "in fine", il est juste moins optimisé. :p

Donc attention à ceux qui recherchent comme moi, une occupation CPU de 100% en ayant l'impression que l'application exploite le processeur pleinement. :)

[R_K]

Il y a des abaques qui te permettent de déterminer ça.

un petit exemple pour le h264

http://www.lighterra.com/papers/videoencodingh264/

mais il y a probablement des trucs plus à jour.

Intéressant, j'ai lu rapidement mais je n'ai pas vu d'explications disant pour telle taille voulue avec telle résolution mettez un bitrate de telle valeur.
J'ai utilisé il y a longtemps gordian knot qui faisait ça, et plus récemment staxrip. Tu réglais les paramètres audio et vidéo et la réso de sortie, tu lui disais je veux une taille de 700Mo, deux passes et hop, il t'indiquait le bitrate vidéo. Il n'y a pas un logiciel qui ne ferait que ça? Handbrake ne le fait pas, il est plutôt prévu pour la qualité constante d'après ce que j'ai vu.
Ton lien donne déjà une bonne idée de ce qu'on peut essayer en tout cas. Merci.

[Foudge]

Conclusion : pour une durée moindre, malgré une occupation CPU moindre, handbrake arrive au même résultat plus rapidement.

Comme quoi, j'étais tout content de voir FF utiliser 100 % des ressources processeurs, voire même 105%, mais "in fine", il est juste moins optimisé. :p

Donc attention à ceux qui recherchent comme moi, une occupation CPU de 100% en ayant l'impression que l'application exploite le processeur pleinement. :)D'où sort ce 105% ? Quel % donné par le gestionnaire des tâches ?
Normalement le multithreading est bien géré quand on encode en H264/H265 et un seul fichier suffit à bien exploiter son CPU. Pour moi vouloir en traiter 4 en parallèle est potentiellement contre-productif, d'autant plus que sur la fin, le nombre d'encodage en // diminue et les ressources libres ne sont pas réattribuées.
A mon avis si tu testes à nouveau Format Factory avec les 4 séquentiellement, tu devrais obtenir un temps similaire à Handbrake (même encodeur + même réglages = même résultat).

[MegABiloU]

Je pense qu'il a encodé avec nvenc.

[Rocca]

D'où sort ce 105% ? Quel % donné par le gestionnaire des tâches ?
Normalement le multithreading est bien géré quand on encode en H264/H265 et un seul fichier suffit à bien exploiter son CPU. Pour moi vouloir en traiter 4 en parallèle est potentiellement contre-productif, d'autant plus que sur la fin, le nombre d'encodage en // diminue et les ressources libres ne sont pas réattribuées.
A mon avis si tu testes à nouveau Format Factory avec les 4 séquentiellement, tu devrais obtenir un temps similaire à Handbrake (même encodeur + même réglages = même résultat).

Ben, j'ai testé et non. Format Factory charge moins le R7 2700X et est donc plus lent. Ils n'utilisent peut-être pas les mêmes "types" ou "processus" d'encodage ?

Après, comme indiqué dans mon message, j'étais à la recherche d'un truc qui exploite pleinement les ressources disponibles. C'était l'objectif "in fine" :) . J'y ai cru, jusqu'au test. Je ne suis pas là pour dire qui est le meilleur ou le moins bon des deux. Les deux ont leurs avantages et inconvénients et je les utilise, personnellement, en complémentarité.


Je pense qu'il a encodé avec nvenc.

Nope pas du tout. C'est le premier truc que j'ai viré.

Et au final, vu qu'avec Nvenc j'ai le GPU + 105 % de CPU ça devrait aller beaucoup plus vite, même si pas testé ^^

[aidelimo]

Bonjour
Je veux mettre un blue-ray (fichier .m2ts) en H264, j'utilise Handbrake mais la dernière version à complètement changer depuis celle que j'utilisé, du coup il y a des options inconnues pour moi, en particulier celles dans "Optimise Video:" :
Encoder Tune:
PSNR
SSIM
Grain
Zero Latency

Pouvez-vous m'aider svp ? ^^

[shlagevuk]

PSNR <- optimisation (https://www.hardware.fr/articles/828-5/mesurer-qualite-psrn-ssim-leurs-travers.html)pour avoir un meilleur score PSNR
SSIM <- optimisation pour avoir un meilleur score SSIM
Grain <- preset permettant de mieux conserver le "grain" des video
Zero Latency <- permet d'encoder la video avec une faible latence pour le streaming (https://www.reddit.com/r/handbrake/comments/60bdpa/encoder_tune_zero_latency/)

Les optimisations de "score" d'encodage ne sont pas forcément pertinent si tu cherche une qualité d'encodage particulière. C'est plutôt pour pouvoir comparer l'encodage avec d'autres formats.
La seule optimisation utile a mon avis est le "grain" pour les films qui en ont et que tu veux conserver.

[Ratatouille]

Sympa ce topic.

Perso j'envode avec le CPU, mes derniers essais au GPU n'étaient pas du tout convaincant, certes un encodage beaucoup plus rapide mais de qualitée tellement moins bonne que le CPU.

J'encode en CRF 25, medium, 10 bit, PSNR en SD avec ffmpeg (pour ma part il encode plus rapidement que handbrake). Et j'en suis très content quand on tient compte du ratio poids/qualité j'arrive a des films de l'ordre de 350Mo/450Mo sur mes quelques essais. La qualité est équivalent a un x264 SD de la taille de 900mo/1go.

Donc un gain de place non négligeable quand on multiplie par 1200 films de vacances.

Là je tente des HDlight en gardant les mêmes paramètres sauf la résolution bien sûr.

[Rocca]

Salut à tous,

Quelqu'un aurait-il un lien vers des tables d'équivalence pour le codec HEVC (abaques) ?

Un peu comme le lien précédemment donner par MegaBilou pour le H264 que je remercie.

Merci d'avance.

[Rocca]

Bon vu que personne n'a d'idée, j'ai du coup appliqué une petite règle.

Je prend le bitrate du fichier original en H264 et je divise par 4. "A priori", il n'y a pas de pertes visuelles.

[shlagevuk]

Faudrait que je fasse des tests, en lançant des batchs en option PSNR SSIM et les différentes options communes (8/10/12b, ultra fast a ultra slow, grain etc...) sur plusieurs échantillon.
Faut que je me documente sur les scores PSNR et SSIM, voir quel sont dispo.

[Rocca]

Faudrait que je fasse des tests, en lançant des batchs en option PSNR SSIM et les différentes options communes (8/10/12b, ultra fast a ultra slow, grain etc...) sur plusieurs échantillon.
Faut que je me documente sur les scores PSNR et SSIM, voir quel sont dispo.

Ben après quelques petits tests et recherches, "a priori", il faut diviser par deux pour le passage de H264 >> H265 dans le cas d'un flux 1080p.

Sur captures "jeux", sur FPS rapide, j'ai testé le divisé par 4 et on voit une légère dégradation du décor. On passe de 50.0 Mb/s x264 à 12.8 Mb/s x265.

Je reviens vers vous, si je fais d'autres tests prochainement. Perso, la perte visuel étant limitée et le gain de place non négligeable, je vais peut-être rester sur ce ratio pour les encodages de mes parties en multi.

Toutefois, je continue les recherches pour mes vidéos persos , 1080p 50 i/s en H264, pour les passer en X265 sans pertes visuelles.

Idem, pour le H265 10 bit ou 8 bit.

EDIT : petite question quelqu'un utilise-t-il ou réussi-t-il à utiliser la fonction FAST DECODE ?? Chez moi ça plante à chaque fois :tired:

[MegABiloU]

quelques news

https://www.lesnumeriques.com/accessoire-photo/sony-xevc-nouveau-codec-8k-n81769.amp.html

[Tilt]

Comme titre de topic ce serait pas plus parlant ?
"Le topic des vidéos qui aiment se faire encoder"

[Rocca]

Comme titre de topic ce serait pas plus parlant ?
"Le topic des vidéos qui aiment se faire encoder"

Ben on parle quand même beaucoup du HEVC qui est nouveau ou l'était à l'époque.

Tu peux encoder en moult formats/codecs, je pense donc que Megabilou ne voulait pas que ça s'éparpille.

[MegABiloU]

Ça ne me gène pas spécialement qu'on évoque d'autres codecs car cela évolue un peu depuis quelques temps.

[Rocca]

Ça ne me gène pas spécialement qu'on évoque d'autres codecs car cela évolue un peu depuis quelques temps.

Ah ouai, quoi comme évolution ?

J'ai noté que beaucoup encode en x265 ou x264 avec une piste audio en AC3. Qu'a t'il de particulier ce AC3 ?

Perso, j'encode en VORBIS qui semble, d'après les tests, meilleur que le AAC qui est lui même nettement supérieur au MP3.

[MegABiloU]

Ah ouai, quoi comme évolution ?

J'ai noté que beaucoup encode en x265 ou x264 avec une piste audio en AC3. Qu'a t'il de particulier ce AC3 ?

Perso, j'encode en VORBIS qui semble, d'après les tests, meilleur que le AAC qui est lui même nettement supérieur au MP3.

En fait je parlais d'autres formats en cours de développement.

Pour le son le format Opus fait parler de lui, c'est notamment celui utilisé sur la plupart des logiciels de chat vocal (Teamspeak,..)

[Rocca]

Ben, il est vieux Opus non ??

D'après les numériques, Opus est un peu moins bon que le Vorbis sur des débits un peu plus élevés d'après ce j'ai pu lire.

Au final, Opus est pas mal pour Teamspeak pour avoir un niveau faible bitrate/qualité audio vraiment pas mal. A part dans ce cas de figure, il est très bien, mais pas mieux que AAC ou Vorbis.

D'ailleurs Spotify utilise le Vorbis si je ne me trompe pas :)

Et puis pour encoder en "Opus" l'audio faut un logiciel le supportant. Je ne le trouve pas sur Handbrake ou Format Factory (le nom de l'extension ?).

[Rocca]

Salut,

Je reviens vers vous après quelques tests et des conclusions quelques peu hésitantes !!

Tout d'abord, l'encodage se fait sous Handbrake version 64 bits V 1.1.2 et sur le processeur (exclusivement) un Ryzen 7 2700 X aux fréquences de base (16 Threads).

Le fichier original est une capture vidéo d'une partie de Crysis 3 sur la map Museum (pour ceux qui connaissent). La capture est faite par le logiciel de Nvidia et voici les spécifications du fichiers de départ :


Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 226 MiB
Duration : 37 s 804 ms
Overall bit rate : 50.2 Mb/s
Recorded date : 2018

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 : 37 s 797 ms
Bit rate : 50.0 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 : 54.512 FPS
Maximum frame rate : 60.565 FPS
Original frame rate : 60.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.473
Stream size : 225 MiB (100%)

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 37 s 804 ms
Bit rate mode : Constant
Bit rate : 196 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz

A noter que l'audio n'est pas réencodée en activant l'option passthru AAC dans Handbrake.

Les résultats sous forme de tableau (copier/coller de calc) :

https://tof.cx/images/2018/12/27/54b4ed31d6bcbc026ed834ad1be95998.jpg
Par rapport à la source, il y a une perte visuelle c'est incontestable. Cependant, d'après d'autres tests effectués auparavant, même en augmentant pas mal le bitrate le résultat reste moyen est moins bon que sur la source. Il y a un gain en image, mais la perte en volume est trop importante.

Le but "in fine" est de stocker quelques unes de mes parties, mais sans avoir besoin de 5 HDD de 10 To :)

Il faut que ça reste regardable sinon ça ne vaut pas la peine de les conserver. D'après les infos trouvées à droite et à gauche, le bitrate utilisé semble déjà plus que très bien (bizarre).

Bref, les tests sont surprenants. Quelques soit les vidéos, il y a une perte (normal), mais ce qui est étonnant c'est qu'il n'y pas gain de place, de bitrate ou de grosse perte de qualité entre slower et ultrafast par exemple.

Autant vous dire qu'une partie de la réponse est impossible à trouver sans regarder l'occupation UC du processeur. Vous allez me dire, il est où le rapport ?

Ben c'est simple, si on prend le temps de zieuter le truc.

Quand il encode en "Slower" l'UC est entre 44 et 65 %. En medium on tourne autour des 65 à 94 %, pas plus.

Par contre, en superfast ou ultrafast l'UC est à 105 % d'occupation.

Du coup, je pense qu'une partie de la réponse vient de là. En effet, comment peut-il faire des vidéos de même taille ou quasi même taille (partie 2 du tableau), sans trop de pertes visuelles à l'écran et avec un bitrate équivalent dans un temps limité ???

Vous en pensez quoi ? Des idées sur ces paramètres ?

Est-ce la vidéo source, due à un jeu ancien, qui pose problème ?

Visuellement, y'a pas grand chose de différent par rapport à la source, sauf un détail, les arrêtes moins bien définies.

Que me conseillez-vous du coup ?

Edit : j'ai effectué, durant cette nuit, quelques tests d'encodage sur les captures vidéos dans FarCry 5 (dans la végétation). Sincèrement, je ne vois aucune différence entre medium et superfast au niveau qualité. En sachant, qu'ils ont respectivement un bitrate de 27.9 Mb/s et 27.5 Mb/s. Ils ont été encodés pour un RF21 sur la vidéo testée.

Deuxième point : ayant quatre vidéos au total, j'ai remarqué qu'un fois le RF 21 fixé, le bitrate choisi par Handbrake et très variable (18.1 Mb/s / 14.5 Mb/s / 21 Mb/s). J'en déduit qu'en fonction du type de paysage, il applique le bitrate qui lui parait le plus adapté.

Sinon, j'ai trouvé cet échange, bref mais bien imagé sur un forum : lien (https://www.reddit.com/r/handbrake/comments/5z9jg2/ultrafast_vs_veryslow_quality/) Mes résultats semblent donc normaux à partir du moment où j'utilise le RF comme définition de qualité et non un bitrate imposé :)

EDIT 2 : ce lien (https://x265.readthedocs.io/en/default/cli.html) explique l'occupation CPU supérieure constatée :), c'est la partie "CU"!!

Je reprends les termes :"Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64"

[Rocca]

Petit lien vers les différences entre les différents "encoder presets" dans Handbrake en graphique. Le gars teste, pour une même qualité, les différences entre les presets.

En anglais, mais parlant pour le coup : lien (https://mattgadient.com/2014/01/06/handbrake-rf-slower-speeds-craziness/)

[MegABiloU]

Ouais pour résumer chaque preset dépend de la source.

attention le test date de 2014, handbrake a pas mal évolué depuis.

[Rocca]

Ouais pour résumer chaque preset dépend de la source.

attention le test date de 2014, handbrake a pas mal évolué depuis.

Ouai, j'ai vu et je trouve aussi des résultats bizarres, mais pas sur le même preset. Je les posterai demain (tableau + diagramme + captures d'écran).

Pour crysis 3, je pense que le codec x265 a du mal avec l'espèce de flou créé lorsqu'on court et sur ce type de jeu vraiment très nerveux. Sur Farcry5 (les résultats que je posterai demain sont sur ce dernier), la perte lors de l'encodage est bien moins visible sinon absente sur des captures d'écran.

Au final, dans crysis 3, je ne sais pas comment l'expliquer, sur des captures d'écran à part les éléments très lointains et les arrêtes qui sont moins bien définies on ne voit pas de grands changements. Par contre, lors du visionnage, je sais pas, y'a un truc comme si c'était moins net, mais difficile de dire quoi. Bref, c'est peut-être du aux mouvements très rapides, je ne sais pas trop ou peut-être aux types de couleurs du jeu (ça ne le fait pas sur toutes les maps, j'ai l'impression).

[Rocca]

Salut, voici les résultats des tests effectués.

Je ne me suis concentré que sur les presets Ultrafat à Medium, les autres, étant donné le cout en temps, ne m'intéressent pas plus que ça "in fine".

Les pré-réglages sont pour le x265 8 bits :

https://tof.cx/images/2018/12/30/25da791d1be2c6817eb16a903736260f.jpg (https://tof.cx/image/fXTiG)

Pour le x265 10 bit :

https://tof.cx/images/2018/12/30/6e23fb0e73d6a4db312d5055f74c735d.jpg

La vidéo originale en H264 (geforce experience) :

Format : MPEG-4
Codec ID : mp42 (isom/mp42)
File size : 1.62 GiB
Duration : 4 min 44 s
Overall bit rate : 48.8 Mb/s
Recorded date : 2018

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
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


Voici le tableur obtenu après test en jouant sur le paramètres ci-dessus indiqués (encoder preset) :

https://tof.cx/images/2018/12/30/8ee23dda76269cd948ce31d8d39941cf.jpg (https://tof.cx/image/fXuVD)

Voici les donnée que j'ai jugé intéressantes en graphique en fonction des informations présentes dans le tableur ci-dessus avec deux axes des Y (attention).

Le classement est fait encoder preset du medium au ultrafast + les deux derniers points concernant RF20 et RF 21 en medium.

https://tof.cx/images/2018/12/30/1eaf810afdfb1309aa8c7e54b3ffb9b6.jpg


Graphique avec temps croissant :
https://tof.cx/images/2018/12/30/09cca8f31cfab0011e3c55ae612906ab.jpg (https://tof.cx/image/f6pvZ)

Graphique avec taille du fichier finale croissante :
https://tof.cx/images/2018/12/30/ed5537debbf367d5e4e453fea4bbfc65.jpg (https://tof.cx/image/f66Pw)

Je posterai, par la suite, les captures écrans effectuées par mes soins et indiquant les défauts constatés ou apparus sur la même image. Pour ceux qui voudraient les vidéos (capture d'une partie de FarCry5), je peux les fournir sans soucis étant donné ma connexion internet plutôt sympathique.

A noter que les captures que je vais fournir sont au format JPEG, l'hébergeur étant limité en taille. Par contre, j'ai effectué le travail de recherche d'artefacts...sur des images en .png.

Idem, je peux les fournir pour ceux que ça intéresse les dites captures en .png.

[Rocca]

Suite du test avec les images et ce que j'ai récupéré sur une image (valable pour tous les presets choisis).

- Petits éclats moins nombreux à côté du feu,
- Arrête sur boite au premier plan sur le côté gauche moins bien définie (dents de scie),
- Fumée plus lisse, moins de turbulences visibles,
- Plis moins définis sur le sol côté droit (effet de lissage des aspirités),
- côté gauche en bas de la boite en bois, moins précis (lissage des aspérités),
- Pâles hélices moins bien définies,
- impacts portes absents,
- petits trous en moins dans four,
- tâche de lumière inventée !
- granularité sur moquettes (moins nette les poils)

Tous ces petits défauts sont à peine perceptibles sur une image fixe en la regardant de près. Autant dire qu'en vidéo on les voit pas.

Toutefois, après visionnage attentif des différentes vidéos, on peut noter un flou/lissage sur certains endroits par rapport à l'original valable pour n'importe quel encoder preset.

Là où, j'ai réussi à mettre en défaut l'encoder preset ultrafast c'est au fond à gauche sur le bois à côté du feu. Je ne sais pas si je pourrais les mettre avec ce post (nombre images limités), sinon je mettrai l'agrandissement de cette partie par la suite.

Ce qui est intéressant c'est que c'est ce genre de défaut, présent sur Crysis et Far Cry 5, qui au final font baissé le rendu global quand on regarde la vidéo. On a une impression de perte de quelque chose, mais on ne sait pas trop quoi.

A noter que pour les vidéos RF21 et RF 22 en qualité medium (les deux séparées à droite du graphiques), ce défaut semble moins présent que sur le RF 20 ultrafast.

Capture sur vidéo orignale :

https://i.postimg.cc/HsqffvzX/1-Original.jpg (https://postimg.cc/rK9n4Jvw)

Capture montrant les défauts constatés :

https://i.postimg.cc/PfRx8hfH/9-RF20-Superfast.jpg (https://postimg.cc/PN1hBg8V)


Preset RF 20 Medium
https://tof.cx/images/2018/12/30/417252b180c7921fd4a1749486b4ccc7.jpg

Preset RF20 medium 10 bit
https://tof.cx/images/2018/12/30/09f8e75f181bf0b173a6ce9cd2fe34c9.jpg

Preset RF 20 Fast
https://tof.cx/images/2018/12/30/2f12505f6ce5aee5499b835c7c26fa7c.jpg

Preset RF20 Fast 10 bit
https://tof.cx/images/2018/12/30/25424ba78fbcf072a49f9e124529be22.jpg

Prest RF 20 Faster :
https://tof.cx/images/2018/12/30/1912e3d33d67886e6a47d4eddbcc8ec3.jpg

Preset RF20 Faster 10 bit :
https://tof.cx/images/2018/12/30/d898836f25db7918ee2d2b38252d0564.jpg

[Rocca]

Preset RF20 Veryfast :
https://tof.cx/images/2018/12/30/1a535a32e4193bcfd686d3cc67748552.jpg

Preset RF20 Veryfast 10 bit :
https://tof.cx/images/2018/12/30/248999e5b021cdb65506bc3ab4e212d9.jpg

Preset RF20 Superfast :
https://i.postimg.cc/fWV3C5bY/9-RF20-Superfast2.jpg (https://postimg.cc/Z0hKK8pq)

Preset RF20 Superfast 10 bit :
https://i.postimg.cc/7LPh2ncG/9-RF20-Superfast-10bit.jpg (https://postimg.cc/WdKsRgsT)

Preset RF20 Ultrafast :
https://tof.cx/images/2018/12/30/7cd119130b0d0b9360c375ddecb60b32.jpg

Preset RF20 Ultrafashttps://tof.cx/images/2018/12/30/9d21af2c6d058494042710ec1fb28ec8.jpg

Preset RF21 Medium
https://tof.cx/images/2018/12/30/3d416eb90c8e935ae2fa981c35780353.jpg

Preset RF22 Medium
https://tof.cx/images/2018/12/30/a86acad662b49fe802c130fbc78ed5c3.jpg

[Rocca]

Maintenant, passons en zoom dans la zone où j'ai constaté un vrai défaut avec ultrafast qui peut expliquer le flou ressentie dans différentes vidéos au delà un scaling moins bon.

Zone bois, image originale :
https://tof.cx/images/2018/12/30/a8e2cd4b1655a17dc33d9c8cb7d97dec.jpg

Zone bois, RF20 Medium
https://tof.cx/images/2018/12/30/d26efbfe372878b49be278f9f2f244eb.jpg

Zone bois RF20 Ultrafast
https://tof.cx/images/2018/12/30/608250e92d9a7d5c773b4ee3c4f47ace.jpg

Zone bois RF21 Medium
https://tof.cx/images/2018/12/30/22ff4dd8290afc765baaa5bd9368977c.jpg

Zone bois RF22 Medium
https://tof.cx/images/2018/12/30/79f639547ef1063bcf87e464b164461e.jpg

En conclusion, sur cette "zone bois", on peut dire que le RF22 en medium fait mieux que le RF20 en mode ultrafast. Attention, uniquement pour cette zone d'après ce que j'ai pu voir et pour un temps d'encodage double.

J'attends vos retours sur ces petits tests :) :)

[MegABiloU]

De mon coté je teste des nouveaux preset sur Handbrake

pour rip un dvd d'anime j'ai commencé avec les reglages suivants :

- on garde le ratio et la définition de la source
- pas de croping (enfin plutôt je force à 0 le cropping)
- H.265 10-bit
- on garde le framerate d'origine
- framerate constant
- 2-pass encoding
- qualité constant (test RF 12 à RF 22 par paliers de 2)
- Encoder Preset Slow
- Encoder tune SSIM (au lieu de PSNR)
- Main 10
- tune grain (car il y a une sorte de grain)

Taille du fichier
RF12 : 738Mo
RF14 : 525Mo
RF16 : 380Mo
RF18 : 285Mo
RF20 : 223Mo
RF22 : 183Mo

On voit clairement la taille diminuer sensiblement à chaque palier.
edit :

screenshots de comparaison RF12 à gauche et RF16 à droite (deux lecteurs MPHC côte a côte parfaitement synchronisés)
http://tof.cx/images/2018/12/31/3d50305751c9d6cc3ef618acb56be75a.jpg

http://tof.cx/images/2018/12/31/31d752de80348e11bd09f8684914c96c.jpg

http://tof.cx/images/2018/12/31/3106eec0a67536a667fdb72458622f66.jpg

http://tof.cx/images/2018/12/31/973ef91e3cb69de06fcfadef97ff34fe.jpg

http://tof.cx/images/2018/12/31/a5a6b1d91b1335e54126e767c6286b44.jpg

http://tof.cx/images/2018/12/31/e69eb19f55d72db1b03e6ece6fb553aa.png

http://tof.cx/images/2018/12/31/8d6d77164b20383450976c92988e73ab.png

[Rocca]

Comment fais-tu pour mettre deux passes en passant par le réglage en RF ?? Moi c'est grisé :tired: :cry:

Sinon, je me posais une question : tu mets framerate variable ou constant cela change-t-il quelque chose quand on indique "same as source" et que celle-ci est de 60 fps constants ?

Et si elle n'est pas constante (variation par exemple de 25 à 60 images/s) que fait handbrake si tu bloques à constant + same as source ?

Je vois que tu utilises SSIM à la place de PNSR, tu as une raison particulière ?

EDIT : sur ta dernière image, je vois de la fumée. Aurais-tu une capture avec l'image source et en plus gros plan, (j'ai noté que c'est sur ce point qu'il y a souvent perte de qualité) ??

[MegABiloU]

Ah tu as raison c'est grisé

Pour SSIM j'ai vu des comparatif et je voulais tester moi même

http://tof.cx/images/2019/01/01/15ebc5990acde6f4891db9e895ff8d1c.png

Source
http://tof.cx/images/2019/01/01/d0f32a92ac5146748b032123dddf671a.png

Encodage rf16
http://tof.cx/images/2019/01/01/647003bafbb02c0659f783e683cf1adf.png

[Rocca]

Ah ok, merci pour cette précision.

Après avoir été sur le site de Handbrake, tout simplement :p, j'ai viré le PNSR et SSIM, car ils sont clairement déconseillé d'après ma compréhension de l'anglais (ils prennent des ressources ou plutôt annulent certains traitements) et même si tout n'est pas à jour.

Pour tes DVD, sincèrement sur les images arrêtés on voit quelques petits défauts, mais rien de rédhibitoire. Je pense que sur ce type de contenu, tu peux te permettre des réglages agressifs.

Sinon, j'ai fait d'autres tests avec la nouvelle version de Hanbrake (1.2.0). Pour éviter d'ensevelir le topic d'images :p, je posterai un tableau récapitulatif des résultats qui, à mon avis, sera sensiblement le même que le précédent :)

Enfin, je vais déjà traiter les données et j'aviserai par la suite. ;)

Sinon dernière idée pour tes dessins animés, as-tu testé avec l'encoder profile Main Still Picture pour voir ce que ça donne ?

[MegABiloU]

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


[OTF] Haruka - Dans Une Epoque Lointaine S01E01.mkv - 738.8 MiB (https://uptobox.com/aedx5fdzq8wr)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf14.mkv - 525.9 MiB (https://uptobox.com/ofrnkbcl41fn)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf16.mkv - 380.9 MiB (https://uptobox.com/9uugwa43b2jw)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf18.mkv - 285.0 MiB (https://uptobox.com/eoa8nrkmrb4r)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf20.mkv - 223.1 MiB (https://uptobox.com/x8hz8pknj6y9)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf22.mkv - 183.8 MiB (https://uptobox.com/goq43p1uq33w)


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

[Rocca]

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


[OTF] Haruka - Dans Une Epoque Lointaine S01E01.mkv - 738.8 MiB (https://uptobox.com/aedx5fdzq8wr)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf14.mkv - 525.9 MiB (https://uptobox.com/ofrnkbcl41fn)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf16.mkv - 380.9 MiB (https://uptobox.com/9uugwa43b2jw)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf18.mkv - 285.0 MiB (https://uptobox.com/eoa8nrkmrb4r)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf20.mkv - 223.1 MiB (https://uptobox.com/x8hz8pknj6y9)
[OTF] Haruka - Dans Une Epoque Lointaine S01E01 rf22.mkv - 183.8 MiB (https://uptobox.com/goq43p1uq33w)


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 :p :p

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.

https://tof.cx/images/2019/01/02/9dedb4e080d8271472775601282d9313.jpg (https://tof.cx/image/f5J59)

[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

https://tof.cx/images/2019/01/02/8c837faf4c76e51743efc7be4182a944.jpg (https://tof.cx/image/f5117)

Graphique avec un temps d'encodage croissant (double axe Y).
https://tof.cx/images/2019/01/02/d0265990eb8fee36c839a00537f15e39.jpg (https://tof.cx/image/f5xzb)

Graphique avec une taille de fichier .mkv final croissante (double axe Y).
https://tof.cx/images/2019/01/02/53c43c340d6a77b4d60c410c35e3868a.jpg (https://tof.cx/image/f5yYe)

[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.

https://tof.cx/images/2019/01/13/cd8610f770eedf4240975e4c865d6157.png (https://tof.cx/image/fjJCz)


Courbe croissante en fonction du temps :


https://tof.cx/images/2019/01/13/06ce9ff40e41781eb8180c7c1154b7e8.png (https://tof.cx/image/fj5n2)


Courbe croissante en fonction de la taille du fichier :

https://tof.cx/images/2019/01/13/1902a3b81af9e749e27dc03d7f0d1182.png (https://tof.cx/image/fjcmR)

[shlagevuk]

La taille de fichier est strictement identique entre avec et sans l'option. :nawak:
(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 ?