Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 8 sur 16 PremièrePremière 12345678910111213141516 DernièreDernière
Affichage des résultats 211 à 240 sur 467
  1. #211
    Citation Envoyé par Rocca Voir le message
    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é.

    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).
    Dernière modification par Foudge ; 25/11/2018 à 14h40.

  2. #212

  3. #213
    Citation Envoyé par Foudge Voir le message
    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é.

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

  4. #214
    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 ? ^^
    Dernière modification par aidelimo ; 26/11/2018 à 09h49.

  5. #215
    PSNR <- optimisation 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

    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.

  6. #216
    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.

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

  8. #218
    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.
    Dernière modification par Rocca ; 12/12/2018 à 23h27.

  9. #219
    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.

  10. #220
    Citation Envoyé par shlagevuk Voir le message
    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
    Dernière modification par Rocca ; 14/12/2018 à 11h31.

  11. #221

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

  13. #223
    Citation Envoyé par Tilt Voir le message
    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.

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

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

  16. #226
    Citation Envoyé par Rocca Voir le message
    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,..)

  17. #227
    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 ?).

  18. #228
    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) :


    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 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 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"
    Dernière modification par Rocca ; 30/12/2018 à 14h57.

  19. #229
    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
    Dernière modification par Rocca ; 29/12/2018 à 23h55.

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

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

  21. #231
    Citation Envoyé par MegABiloU Voir le message
    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).
    Dernière modification par Rocca ; 30/12/2018 à 13h08.

  22. #232
    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 :



    Pour le x265 10 bit :



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



    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.




    Graphique avec temps croissant :


    Graphique avec taille du fichier finale croissante :


    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.
    Dernière modification par Rocca ; 30/12/2018 à 19h57.

  23. #233
    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 :



    Capture montrant les défauts constatés :




    Preset RF 20 Medium


    Preset RF20 medium 10 bit


    Preset RF 20 Fast


    Preset RF20 Fast 10 bit


    Prest RF 20 Faster :


    Preset RF20 Faster 10 bit :
    Dernière modification par Rocca ; 30/12/2018 à 21h12.

  24. #234
    Preset RF20 Veryfast :


    Preset RF20 Veryfast 10 bit :


    Preset RF20 Superfast :


    Preset RF20 Superfast 10 bit :


    Preset RF20 Ultrafast :


    Preset RF20 Ultrafas

    Preset RF21 Medium


    Preset RF22 Medium

  25. #235
    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 :


    Zone bois, RF20 Medium


    Zone bois RF20 Ultrafast


    Zone bois RF21 Medium


    Zone bois RF22 Medium


    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

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












    Dernière modification par MegABiloU ; 01/01/2019 à 20h02.

  27. #237
    Comment fais-tu pour mettre deux passes en passant par le réglage en RF ?? Moi c'est grisé

    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é) ??
    Dernière modification par Rocca ; 31/12/2018 à 20h42.

  28. #238
    Ah tu as raison c'est grisé

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



    Source


    Encodage rf16

  29. #239
    Ah ok, merci pour cette précision.

    Après avoir été sur le site de Handbrake, tout simplement , 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 , 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 ?

  30. #240

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
  •