Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 1 sur 16 12345678911 ... DernièreDernière
Affichage des résultats 1 à 30 sur 467
  1. #1
    Je reprend ici le topic crée dans la section dépannage pour parler du HEVC (x265).

    Très bon article de techspot trouvé par Megabilou sur le HEVC (comparaison rapidité d'encodate, efficacité, qualité)

    Pourquoi encoder une video sur 10bit est plus efficient
    Et la mise en pratique de ce principe avec des tests d'encodage
    Merci Foudge pour ces deux liens!

    Nos canards sont exceptionnels, un zip complet comprenant un handbrake nightly avec les librairies pour encoder en 10/12bit. Merci Squarealex !



    C'est un codec ayant pour but de réduire la taille des vidéo en gardant une qualité équivalente au AVC (x264). Et ce par l'utilisation d'algorithme plus complexes.
    Ce codec est conçu pour des formats HD et plus (2k 4k 8k) et des framerate élevé.


    • Compatibilité

    Aujourd'hui la plupart des lecteurs moderne le prennent en charge. Son gros point faible et la puissance de calcul nécéssaire pour le décoder qui est plus important que le x264.
    Sur nos machines de bourgeois le problème ne se fait pas trop sentir, mais sur des périphériques mobiles ou assez vieux le problème est bien plus sensible!

    Heureusement, comme pour le x264 le décodage matériel arrive petit à petit.
    -Intel le gère depuis skylake (un peu avant en support partiel)
    -Amd le gère depuis carrizo
    -Nvidia le gère mais c'est le bordel et gère également le format sur sa tablette shield.

    Pour les autres puces, notamment les ARM, le support est encore assez rare. Mais ça se démocratisera en même temps que les sources 4k logiquement.


    • Qui a besoin de faire de l'encodage en x265?


    Actuellement le x265 est encore un peu jeune comme format pour arriver a donner des résultats équivalent au plus ancien x264 a haut bit-rate. Par contre il excelle quand le bitrate est assez bas.
    En gros si vous voulez sauvegarder une video 1080p d'1h30 dans un fichier de <2Go, le résultat sera très certainement meilleur en x265 qu'en x264.
    Par contre si la taille importe peu et que vous voulez conserver la plus grande qualité vidéo le x264 est à privilégier.

    Personnellement je compte tout transcoder en x265 pour le gain de place. Pour les quelques test que j'avais fait, la réduction en terme de taille est de 30 à 50% pour une perte de qualité dur à percevoir si perceptible tout court.
    Il me reste encore à tester le passage au x265 des vidéo à faible résolution (dvd) pour voir le gain.


    • Transcoder c'est long


    Autant le transcode x264 n'est pas des plus rapide. Autant le transcode x265 est abominablement long. Environ 10x plus long. Donc si vous voulez vous lancer dans l'aventure, attendez-vous à laisser votre PC tourner h24.

    Niveau vitesse d'encodage chez moi:
    Atom C2750 (8c@2.4Ghz) -> ~4fps en slow
    Xeon x5670 (6/12c@3.93Ghz) -> ~7fps en slow, dans une VM.


    • Maintenant parlons technique


    J'utilise ffmpeg sous linux pour le transcodage. J'essaierai de faire un tour d'horizon d'handbrake à l'occasion.

    Mes paramètres sont assez simple et sont les suivant:

    ffmpeg -i input.mkv -map 0 -c:v libx265 -preset slow -x265-param "profile=main:CRF=18" -c:a copy -c:s copy -c:t copy output.mkv

    -map 0 : prend tout les "stream" du fichier passé en entré

    -c:v : pour les stream video on applique les options suivantes
    libx265 : la librairie utilisé pour encoder
    -preset slow : voir en dessous
    -x265-param : les paramètres propre au HEVC, expliqué plus bas

    -c:a copy : on copie les stream audio
    -c:s copy : même chose pour les sous-titre
    -c:t copy : même chose pour les fichier "attaché" comme les polices d'écriture

    output.mkv : le fichier de sortie, ffmpeg détecte automatiquement le type de fichier en fonction de l'extention. On peut aussi lui préciser via l'option -f

    Les presets
    -slow est réservé au vidéo que vous voulez archiver sinon passer sur du medium->veryfast suffis largement normalement.
    -pour du quasi temps réel ou de l'encodage pour tester les options (qualité par exemple) ultrafast!
    -les presets influent la qualité par bit de l'encodage, donc si on utilise CRF pour déterminer la qualité c'est la taille du fichier qui changera seulement. Si on utilise un bitrate constant (ex 2 pass encod) , le preset influencera la qualité final de la vidéo.
    -En dessous l'économie de bitrate par rapport au temps d'encodage, en bleu on vois la courbe du x265, les trois points en bas à gauche sont placebo/veryslow/slower. On vois bien le coût en terme de temps par rapport au gain. Celui-ci deviens plus raisonnable avec slow.
    Graphique imageant bien le rapport temps/compression des trois codec récent
    Credit graphique

    CRF
    Pour un équivalent 23 en x264 je prend un CRF de 18 en x265. Pour l'instant x265 n'est pas des plus aboutis niveau qualité, et c'est normal. Le HEVC est plutôt conçu pour les bitrates assez faible.
    Exemple un gros film d'action en 1080p encodé à 1Mbps en x264 et x265 fera vraiment ressortir l'intérêt du HEVC en terme de qualité. Par contre à >3Mbps l'intérêt s'inverse, et on commence à percevoir que le grain et les détails sont plus présent en x264 qu'en x265.

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

    Les profile
    Les profiles permettent la compatibilité avec les décodeurs hardware. Les profiles habituellement accepté sont main et main10. Pour plex par exemple, si le lecteur prend en charge le décodage materiel la vidéo n'est pas transcodé.

    Autre
    Il y a pléthore d'autre paramètres pour optimiser le poids ou la qualité de l'encodage. Exemple: le parametre keyint qui fait varier le nombre d'image entre deux images de référence. Une valeur plus haute peut diminuer le poids du fichier mais augmenter le seek-time, il peut également casser la compatibilité avec certains lecteurs. Une valeur trop haute ne donnera aucun gain de bitrate.
    Dernière modification par shlagevuk ; 01/04/2019 à 12h07.

  2. #2
    Parait que ça rame méchant avec un i5 3570K

  3. #3
    J'en profite pour partager mes preset sur handbrake.

    Sur cette machine



    avec ces paramètres :







    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.

  4. #4
    Ce chat est une Dauphine Avatar de rotoclap
    Ville
    Aix-les-Bains
    Alors question bête : y'a un vrai apport qualitatif à utiliser le profil Main10 si la source n'est codée en 10 bits ?

  5. #5
    C'est une bonne question au contraire.

    à laquelle je n'ai pas la réponse

  6. #6
    Géniale l'idée du topic

    Citation Envoyé par XWolverine Voir le message
    Parait que ça rame méchant avec un i5 3570K

  7. #7
    Citation Envoyé par rotoclap Voir le message
    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:

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

  8. #8
    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 ?

  9. #9
    Citation Envoyé par rotoclap Voir le message
    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

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

    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.

  11. #11
    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 (même si ça me semble un peu vieux comme dossier)

  12. #12
    Ce chat est une Dauphine Avatar de rotoclap
    Ville
    Aix-les-Bains
    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/
    Dernière modification par rotoclap ; 15/01/2016 à 00h10.

  13. #13
    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

    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.

  14. #14
    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.

  15. #15
    Ce chat est une Dauphine Avatar de rotoclap
    Ville
    Aix-les-Bains
    Ah ouais quand même parce qu'un épisode d'1h en 1080p h264 en temps normal, ça tourne autour de 2Go.

  16. #16
    Citation Envoyé par rotoclap Voir le message
    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.


  17. #17
    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
    Dernière modification par MegABiloU ; 15/03/2016 à 21h01.

  18. #18
    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.

  19. #19
    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.

  20. #20
    Super les infos MegABilou on pourra s'appuyer dessus pour les futurs encodages

  21. #21
    Citation Envoyé par MegABiloU Voir le message
    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.

  22. #22
    Citation Envoyé par MegABiloU Voir le message
    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.

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

  24. #24
    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é.

  25. #25
    si tu veux je fais pareil avec mes 3 versions.

  26. #26
    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.

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

  28. #28
    C'est curieux, j'ai choisi Mega aussi, et j'uploade à environ 1 Mo/s... Alors que ma fibre permet bien mieux...


    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.

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

  30. #30
    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •