Oh la belle mauvaise foi.
J'avoue un peu mais on va dire que mes compétences actuelles et mon temps libre ne me permettent pas d'exploiter correctement ces données.
Aujourd'hui aussi, j'utilise plusieurs softs, j'aime pas les tout en un
(me rappelle même plus comment je faisais du temps de ces divx 3.11 dont je parlais, probablement join des VOB -> mpeg2 puis divx, OCR des VOB -> srt).
Je ne sais pas si c'est un bon investissement de tuner les paramètres, vu que l'implémentation du codec va probablement beaucoup bouger.
Pour ma part, j'envisageais de "migrer" pas mal de médias pour gagner de la place, mais je vais attendre que ça se stabilise (et que je change ma config, là ça rame trop) et ne faire ça que sur des medias courts. En attendant, le medium à 5Mb/s pour le 1080p m'a l'air un bon compromis.
Euh les rips Bluray avec conservation du grain qui font 10Go, c'est déjà faisable avec du h264. D'ailleurs l'avantage avec le h264, c'est que tu as un preset "grain" pour les films qui en ont beaucoup.
Il me semble que ce paramètre est également disponible en HEVC (à confirmer)
mais je n'y mettrais pas ma main au feu.
Du coup j'ai creusé un peu la question vu que je fait des test d'encodage de x264 vers x265 sur mon NAS. J'utilise FFMPEG mais certains paramètre se retrouvent sous handbrake.
Pour le support 10b, il est fonction des options de compilation, il de peut que les versions nighly en soient dépourvue.
Typiquement j'utilise ça:
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
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. Credit image
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
Profile
Les "profile" permettent la compatibilité avec les décodeurs hardware présent sur les derniers GPU (intel gen 5/6 de mémoire, amd pour leur derniere itération de gpu de mémoire, certain gpu intégré à des puces ARM, nvidia je sais plus). 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.
Niveau vitesse d'encodage:
Atom C2750 (8c@2.4Ghz) -> ~4fps en slow (un film d'action met plus d'un jour à encoder)
Xeon x5670 (6/12c@3.93Ghz) -> ~7fps en slow également dans une VM.
Sur le CRF il y a également des différences entre un encodage des couleurs des pixel sur 8b et sur 10b. Sur 8b il va de 0 à 51, sur 10b il va de 0 à 63.
Peut-être handbrake garde l'échelle CRF du x264 (en faisant un équivalent). Quelle est l'amplitude possible sous handbrake?
Ouais slow / medium en CRF 18 c'est un peu ce qui revient comme paramètres c'est pour cela que j'ai opté pour ceux la, ps : j'aurais choisi slow plutôt que medium si mon proc était un poil plus véloce.
- - - Mise à jour - - -
Je ne crois pas que handbrake gère le x265 en 10bits pour le moment.
- - - Mise à jour - - -
il reste le mode advanced ou tu entre les commandes (par contre en effet il est possible que certains paramètres ne sont implantés que sur la nightly)
D'ailleurs il me semble que la version du codec HEVC en est a la 1.5 sur la stable contre la 1.8 sur la nightly.
Oui, bien sûr, ce que je voulais dire c'est qu'à taille égale je pensais obtenir mieux en qualité. Ou obtenir la même qualité à taille moindre.
Mais visiblement c'est pas aussi simple que ça (voir ci-après).
Très intéressant comme info.
Du coup, oui je peux espérer une meilleure qualité que le x264 si c'est sur de petits fichiers... Mais si je reste sur de gros rips, mieux vaut rester sur du x264.
Bah tant mieux, théoriquement l'encodage sera plus rapide et la lecture sera un poil moins gourmande.
Bah disons que si la place n'est pas un problème pour toi effectivement le X264 est préférable niveau qualité a gros bitrate.
Et d'un autre côté si tu veux faire un rip avec du 1080p qui pèse environ 1.5Go le X265 aura moins d'artefact de compression.
Exemple encodage à 1Mbps:
x264
x265
(crédit Atak_Snajpera doom9.org)
Par contre il ne faut pas oublier que les lib d'encodage x265 sont assez jeune par rapport au x264 qui a pu évoluer et se perfectionner. Peut-être que dans un an ou deux tout le monde aura laissé tombé x264 car il ne présentera juste plus d’intérêt par rapport au x265 qui aura gagné en qualité/détails.
Dernière modification par shlagevuk ; 13/01/2016 à 00h05.
Eh bien pour répondre à cette question... J'ai un SSD de 120 Go pour l'OS et les programmes récalcitrants, 500 Go de HDD 5400 pour les programmes en tous genres, 500 Go de HDD en 7200 pour les jeux, et 2 To de HDD en 5400 pour les données... et malgré cette séparation ce dernier a bien grossi.
Malgré tout j'y stocke actuellement des ISOS de mes Bluray, donc si je passe d'une ISO de 30-40 Go à un Mkv de 10 Go, j'suis content
En ce sens non la place ne sera pas un problème pour moi...
Merci pour les liens, je vais y jeter un œil.
Alors oui, on est d'accord.
Je ne suis clairement pas spécialisé vidéo, mais je suis développeur, et je me suis un peu intéressé au concept de l'encodage et de la compression.
Suffisamment pour envisager que ça s'améliorera avec le temps.
Mais il me suffira alors de repartir depuis mes x264, ou carrément repartir depuis mes Bluray. Le but est de ne pas avoir à les solliciter, à les abîmer, et à risquer des saccades ou des temps d'accès trop longs.
Et puis j'ai un poto qui a développé une petite appli de gestion de filmothèque et j'ai envie de la pousser dans ses derniers retranchements.
Mais vous ne seriez pas mieux en software, il ya des cacahuètes là bas, c'est mieux pour le pastis. Car ici on lance plutôt des oranges, et on préfére le Whisky.
Bah vu qu'au départ c'était par rapport à une comparaison entre 2 cpu pour l'encodage et que ça a basculé vers l'encodage en lui même, oui je ne serais pas contre un petit transfert vers la bas. (l'edit du titre du topic est trompeur du coup)
Goldorak l'intégrale, edition remasterisé en HD : http://www.amazon.fr/Goldorak-Int%C3...words=goldorak, là ça va t'en faire de l'encodage
Je n'ai pas grand chose à encoder, mais à chaque fois c'est la misère je galère à trouver le bon rapport qualité/poids. Je suis preneur de conseils.
Et sinon j'ai choppé il y a quelques temps une clé pour dvdfab, qui permet d'encoder et même de couper un peu les vidéos de façon succinte. Niveau réglages de la qualité c'est terriblement simple/pratique (simpliste?) et ça utilise cuda pour certains trucs: ça va à la vitesse du vent.
@Johnclaude du coup Shlaguevuk a ouvert un topic exprès
http://forum.canardpc.com/threads/10...n-aime-encoder
On finira bien par arriver à un bon compromis avec le temps.