Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 9 sur 9 PremièrePremière 123456789
Affichage des résultats 241 à 268 sur 268
  1. #241
    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)...

  2. #242
    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).

  3. #243
    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

    Je posterai tout à l'heure les résultats pour un RF 20 avec les différents "encoder preset".

    Citation Envoyé par shlagevuk Voir le message

    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.

    Dernière modification par Rocca ; 02/01/2019 à 20h32.

  4. #244
    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



    Graphique avec un temps d'encodage croissant (double axe Y).


    Graphique avec une taille de fichier .mkv final croissante (double axe Y).

  5. #245
    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)

  6. #246
    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 ?

  7. #247
    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)

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




    Courbe croissante en fonction du temps :





    Courbe croissante en fonction de la taille du fichier :


  9. #249
    La taille de fichier est strictement identique entre avec et sans l'option.
    (le temps d'encodage aussi +- 15s)

    Je me demande si c'est pas handbrake qui override l'option.

    (je vais faire quelques tests)

  10. #250
    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 ?

  11. #251
    Citation Envoyé par hijopr Voir le message
    Un idée de comment faire ?
    Ne pas utiliser le format MP4?

    Je suis pas un spécialiste en la matière mais il y a des formats plus adapté aux web comme le WEBM par exemple qui est conçu spécialement pour les vidéo internet.

    et aussi utiliser un codec comme le VP9 qui est adapté pour ton usage.

  12. #252
    Si tu ne veux pas t'emmerder fait un upload sur Youtube puis télécharge la vidéo convertie de youtube.
    Par exemple une vidéo 1080p @60fps de 330Mo passe à 58Mo comme ça.
    Voire 29Mo si on choisit 30fps.
    Dernière modification par MegABiloU ; 17/01/2019 à 18h51.

  13. #253
    Citation Envoyé par revanwolf Voir le message
    Ne pas utiliser le format MP4?

    Je suis pas un spécialiste en la matière mais il y a des formats plus adapté aux web comme le WEBM par exemple qui est conçu spécialement pour les vidéo internet.

    et aussi utiliser un codec comme le VP9 qui est adapté pour ton usage.
    En cherchant un peu avec ces infos, j'ai trouvé la commande magique :

    ffmpeg -i video_source.m4v -c:v libvpx-vp9 -b:v 5M -c:a libopus -an -r 30 -threads 16 output.webm
    Super qualité et < 50Mo !

    Merci

  14. #254
    Je viens de faire un tuto pour faire un OCR et traiter les pistes de sous titres

    le lien permet d'effectuer des modifications si jamais vous voyez une erreur ou souhaitez apporter des contributions.
    Comme par exemple sur d'autres OS que Windows.
    https://docs.google.com/document/d/1...it?usp=sharing

  15. #255
    yopla

    J'ai commencé a regarder comment faire pour upscale des dessins animés asiatiques en 4K, le principe m'interessait et je suis tombé sur une ou deux vidéos qui m'avaient plutot bien vendu le truc.
    Le principe est de demander a ffmpeg de découper toutes les frames de la vidéo sur lequel on travail, de les upscale avec waifu2x puis de les recoller avec ffmpeg. Oui, c'est pas l'opti du bonheur et ca prend beaucoup trop de temps a faire, mais le resultat est plutot interessant.
    Il y a aussi sous windows cette fois-ci, nnedi3 en filtre avisynth qui fait a peu pres le même résultat (je trouve l'image moins nette avec ce dernier) mais qui a l'avantage d'etre plus rapide a ce que l'on m'a dit. Je n'ai pas de resultat a présenter par contre pour nnedi3.

    Donc waifu2x voilà comment que j'ai fait sous linux pour faire fonctionner le tout.
    Premièrement il m'a fallu plusieurs logiciels:
    - https://ffmpeg.org/
    - https://github.com/DeadSix27/waifu2x-converter-cpp
    - installation d'un environement CUDA ou OpenCL
    - d'une carte graphique pas trop mauvaise. Petite preference pour les nvidia pour le CUDA.



    Utilisation:
    J'ai monté une VM en GPU passthrough pour faire le gros du calcul sans que ca touche au reste de ma configuration.
    VM debian avec ffmpeg + waifu2x-converter-cpp d'installé.

    J'ai pris ffmpeg sur le host ou j'ai découpé toutes les frames de la vidéo a upscale:
    Code:
    ffmpeg -i video.webm decompose/thumb%04d.png -hide_banner
    Tout le repertoire ou les images ont été découpées sont déplacées sur la VM qui va effectuer le calcul.
    J'upscale chaque image avec waifu2x et son traitement CUDA/OpenCL.
    Toutes les images sont déplacées vers un autre dossier ou je peux voir le résultat avant de passer à l'étape suivante.
    Au cas ou je vous partage le petit script bash que j'ai monté pour traiter en masse les images présentes dans le dossier source.
    Spoiler Alert!
    Code:
    #!/bin/bash
    
    list_filename=`ls *.png`
    
    
    for filename in $list_filename; do
        echo "fichier trouvé:  $filename";
    
        if [ -e "../4K/4K_$filename" ]; then
            echo "File already exist:  ../4K_$filename";
        else
            echo "Start waifu2x on:  $filename";
            waifu2x-converter-cpp --scale_ratio 2 -i $filename -o ../4K/"4K_"$filename
            echo "Finished waifu2x on:  4K/4K_$filename";
        fi
    done

    Dès que c'est fini (c'est TRES long !) je rapatrie tout sur l'host ou je peux laisser ffmpeg mettre les images bout a bout avec la commande suivante:
    Code:
    ffmpeg -r 24 -f image2 -s 3840x2160 -i 4K/4K_thumb%04d.png -vcodec libx264 -crf 24  -pix_fmt yuv420p test.mp4
    A partir de la la video est prete et j'ai pu admirer le resultat et voir si il n'y a pas eu une anomalie durant le traitement des images. Oui ca peut arriver, ca m'est arrivé sur une frame en pleins milieu d'un scrolling horizontal, donc ca va j'ai pas eu trop besoin de me casser la tête pour refaire la frame.

    Il manque par contre la musique:
    j'extrait la musique du fichier original
    Code:
    ffmpeg -i "video.mkv" -f mp3 -ab 640000 -vn music.mp3
    et enfin je rajoute la dite musique dans la vidéo precedement faite
    Code:
     ffmpeg -i "video.mp4" -i music.mp3 -codec copy "video.mkv"
    Et hop j'ai ma vidéo en 4K toute propre de disponible !



    Résultat:




    Statistiques:
    A noter que les résultats sont a peu pres similaires sur les 2 vidéos car elles ont la même durée et un nombre de frames très proche, de ce fait j'ai préféré donner des résultats arrondies pour vous donner un ordre d'idée du temps que ca a pris.
    De plus le temps CPU est a titre informatif du temps qui aurait été pris dans la configuration que je vous présente.

    Temps Traitement Frames Temps Video
    CPU 12:30:00 2205 00:01:32
    GPU 03:20:00 2205 00:01:32
    Hardware Designation Threads fixé
    CPU Ryzen 1700 14
    GPU GTX 1070 CUDA

  16. #256
    L'upscaling par ce procédé est vraiment intéressant? Tu as fait des tests sur des animés particuliers ? (j'ai pas d'écran 4k pour pouvoir comparer)

    C'est intéressant le comparatif de temps entre le traitement via CUDA et celui via CPU. Bon pour 12 épisode de 25 minutes on est a 28 jours de traitement, mais c'est toujours mieux que 104 jours.

    Y'a un gain quelconque sur l'utilisation de cette methode pour faire une sorte de super-sampling ? (passer la video en 4k puis encoder avec un downscale en FHD)

  17. #257
    Hello. Je viens sur ce forum pour vous demander une petite information (ou conseil) à propos de l'encodage en H265.
    En effet, j'encode mes animés (H264) 1080P vers du H265 en utilisant HandBrake. (Constant Quality à 22 RF [que je suis en train de descendre à 20 pour voir si il y a un changement).
    J'en suis toujours très satisfait et je ne remarque pas de différence visuelle entre la version originale d'un épisode, et la version encodée en H265.
    Néanmoins je me pose quand même des questions quant au bitrate. Je sais qu'il diminue fortement avec le H265, mais (même si je n'ai remarqué aucune différence de qualité entre l'original et leH265), je me demande s'il serait pas *trop* faible.
    Par exemple, un épisode d'un animé (WEBRip 1080P 2,92 Go) avec un bitrate de 17,4 Mb/s en H264, une fois convertit en H265 aura un bitrate de 1 603 kb/s (pour un poids de 299 Mo). Un autre exemple, un autre animé (WEBRip, 1080P, 1,22 Go) ayant un bitrate en H264 de 7 463kb/s aura un bitrate de 772 kb/s en H265 (pour un poids de 158 Mo).

    J'aimerais bien que quelqu'un me donne son avis et puisse me dire si le "rapport" poids/bitrate est correct sachant que je ne remarque aucune différence de qualité entre l'originale et la version H265.
    Merci

  18. #258
    Salut,

    Un facteur 10 en bitrate me parait effectivement élevé.

    Maintenant, tu encodes en H265, mais avec quoi comme paramètres (voir ci-dessus les graphiques) ? Après l'essentiel est le résultat final, s'il te convient, un faible bitrate en sortie, c'est un gros gain de place.

  19. #259
    Ouaip c'est vrai que c'est un énorme gain de place, et j'en suis content (d'autant plus que je ne remarque pas de différence de qualité. Mais contradictoirement, je voudrais avoir le "meilleur" possible (même si dans ce cas là je n'ai qu'à garder mon H264 O).
    Enfin bref, mes paramètres sur Handbrake sont les suivants :

    Section "Dimensions" :

    Dimensions : 1920 * 1080 (comme la source en gros)
    Anamorphic : Automatic
    Modulus : 2
    Cropping : Automatic


    Section "Filtrers" : je n'y ai pas touché, donc ce sont les paramètres de base.

    Section "Video" :
    Video Codec : H.265 (x265)
    Framerate : Same as source (Variable Framerate)
    Optimise video : Encoder preset : Fast
    Encoder Tune : None
    Encoder Profile : Auto
    Constant Quality : 22 RF

    Section "Audio" : Codec Auto passthru (je ne touche pas à l'audio, je le laisse tel quel).

  20. #260
    A mon avis tu pourrais obtenir un facteur 5 sur le bitrate sans que tu remarques de différence tout en restant en H264.
    Dit autrement, c'est plutôt le bitrate de ton épisode de 3Go (pour 25min de 1080p) qui serait inutilement élevé dans ton cas.

  21. #261
    Hmm. Ouaip c'est fortement possible, parce que 17 mb/s pour un épisode de 25 minutes en 1080P ça fait un peu beaucoup je pense x)

    Et sinon, pour l'autre épisode où le bitrate est passé de 7 483 kb/s à 772 kb/s (ce qui me paraît un peu faible), rien à signaler ou bitrate "trop" faible ?

  22. #262
    Citation Envoyé par shlagevuk Voir le message
    L'upscaling par ce procédé est vraiment intéressant? Tu as fait des tests sur des animés particuliers ? (j'ai pas d'écran 4k pour pouvoir comparer)
    Y'a un gain quelconque sur l'utilisation de cette methode pour faire une sorte de super-sampling ? (passer la video en 4k puis encoder avec un downscale en FHD)
    L'upscaling par traitement neuronal ouais est vraiment très intéressant au niveau de la qualité, je suis assez bluffé de ce qui en sort. T'as l'impression que ca a été fait par un pro pour un cout réduis et puis tu peux le faire de chez toi avec la carte graphique qui va bien.Mais je risque de me repeter, mais je n'ai pas tester le filtre nnedi3 avec avisynth qui a ce qu'il parrait a des resultats très proche pour un meilleur rendement.
    Pour le moment je reste sur les animes avec des lignes très nettes, c'est plus facile pour moi pour voir la différence et je pense que c'est ce qui mérite le mieux ce genre de traitements (Nichijou ).
    Mais je pense que ca devrait marcher un peu partout.

    Le gain au niveau du supersampling serait sur la qualité de l'upscale qui est beaucoup plus propre que les filtres habituels (mais rapide) que nous avons.


    Ca reste un traitement de foie gras ou ta carte graphique tourne a 100% pendant plusieurs heures consécutive. A voir si un rack de carte graphique pour miner du bitcoin pourrait être utiliser pour ce genre de trucs, mais bon après la conso pour mater des dessins animées....


    note a part, le thread c'est toujours topic [HEVC] pourquoi pas le rendre plus général au traitement vidéo, surtout avec l'arrivée prochaine de AV1 qui m'a l'air bien interessant tout pleins.

  23. #263
    Citation Envoyé par Laiz Voir le message
    Hmm. Ouaip c'est fortement possible, parce que 17 mb/s pour un épisode de 25 minutes en 1080P ça fait un peu beaucoup je pense x)

    Et sinon, pour l'autre épisode où le bitrate est passé de 7 483 kb/s à 772 kb/s (ce qui me paraît un peu faible), rien à signaler ou bitrate "trop" faible ?
    Comme le dit Foudge, je pense que tes deux animés "source" ont des bitrate très élevé de base, ces bitrates doivent en plus être fixe. Tu auras forcément un gros gain en les encodant en qualité constante 22RF en x265 étant normalement un encodage "imperceptible". De plus la plus part des animés sont très facilement compressible, il y a peu de détails dans l'image comparativement à une représentation réelle. Donc un épisode de 25min d'animé qui pèse 200mo ne me choque pas particulièrement, ça dépend du contenu (beaucoup d'action/mouvement, décors riche etc...). Le mieux étant toujours de comparer le résultat à la source pour voir si la qualité te suffis.

    Citation Envoyé par Sunseille Voir le message
    note a part, le thread c'est toujours topic [HEVC] pourquoi pas le rendre plus général au traitement vidéo, surtout avec l'arrivée prochaine de AV1 qui m'a l'air bien interessant tout pleins.
    Yep je vais renommer le topic. Y'a de beaux progrès côté AV1 d'ailleurs, le temps d'encodage est toujours super long mais on s'approche petit à petit de l'acceptable

  24. #264
    Je viens de découvrir une feature bien cool des conteneurs MKV, le file linking (segment linking) qui permet basiquement d'ajouter une intro/outro présente dans un fichier externe à la liste des chapitres d'un conteneur mkv. Ainsi pas besoin de répéter une intro dans les X fichier ou elle est présente.

    Sauf que personne ne supporte la feature (VLC ok, mais plex ko et handbrake ko....)

  25. #265
    Assez incroyable comme feature.
    Si je comprends bien, tu peux encoder une série complète et permettre au (télé)spectateur de passer le récap et le générique. Ce que permet Netflix par exemple mais je n'avais jamais imaginé que c'était une "feature" incluse dans les formats de fichiers.
    Moi qui pensait que le MKV était un truc de tipiak, en fait c'est très également très professionnel...

  26. #266
    Bon, après les déboires lié aux features mkv pas pris en charge par la plupart des lecteurs et notamment par handbrake lors d'un transcod, je me suis tourné à nouveau vers ffmpeg.

    Je suis tombé sur une image docker très bien foutu et j'ai fait un petit batch de transcod pour voir quel niveau de CRF était acceptable avec differents preset.

    Code:
    for crf in 20 24 28 32; do
      for speed in ultrafast fast medium slow; do 
         time docker run --cpuset-cpus="0,2,4,6" --cpus="4" -v$(pwd):/temp/ jrottenberg/ffmpeg -loglevel panic -i /temp/Violet.Evergarden.01.mkv -map 0 -c:0:1 copy  -c:0:2 copy -c:0:v libx265 -preset $speed -crf ${crf} /temp/out_${crf}_${speed}.mkv
      done
    done
    Globalement seul CRF 20 donne un résultat "indetectable", à CRF 24 on vois quelques petits artefact par ci par là, au dessus c'est dégueulasse.
    De même le preset est très important pour le rendu final de l'image. Pour tout les CRF le preset ultrafast rend la video "blocky" du au "motion search method" utilisé pour ce preset. Le preset fast quant à lui souffre d'un taux de compression bien plus mauvais que les autres preset, vu que je vise un transcodage pour archiver les videos à long terme ce preset est inutile pour moi.

    Reste donc medium et slow en CRF 20/24.

    Temps d'encodage (minutes):
    Code:
    CRF	20	24
    medium	104   	94     	90.38%
    slow  	243   	213   	87.65%
    	233.65%	226.60%
    Un coût de ~220% en temps d'encodage pour une faible difference de qualité
    ~10% de temps d'encodage en moins avec un CRF plus haut

    Taille des fichiers (Mo):
    Code:
    CRF	20	24
    medium	248	156	62.90%
    slow  	243	154	63.37%
    	97.98%	98.72%
    Un gain quasi nul entre medium et slow niveau taille, et logiquement la taille varie beaucoup en fonction du CRF.
    A voir si la difference de qualité entre medium crf 20 et slow crf 24 justifierai le temps d'encodage en plus.


    Après avoir encodé 16x la même video je me suis dit qu'il serait de bon ton de les comparer avec un outil fait pour ça. Je suis tombé encore une fois sur un conteneur docker incluant vqmt pour faire ça!

    Pour utiliser cet outil il faut d'abord extraire la video en format brut (non compressé). Convertis ainsi le fichier fait une taille monstrueuse (220mo pour 3s) il faut donc travailler avec des morceaux de fichier video, pour les extraires:
    Code:
    for debut in "05" "10" "20"; do
      for crf in 20 24; do
        for preset in medium slow; do
          docker run -v $(pwd):/temp/ jrottenberg/ffmpeg -ss 00:${debut}:00 -i /temp/out_${crf}_${preset}.mkv -t 00:00:03 -c:v rawvideo -pix_fmt yuv420p /temp/out_${crf}_${preset}_${debut}m_3s.yuv
        done
      done
      docker run -v $(pwd):/temp/ jrottenberg/ffmpeg -ss 00:${debut}:00 -i /temp/Violet.Evergarden.01.mkv -t 00:00:03 -c:v rawvideo -pix_fmt yuv420p /temp/out_source_${debut}m_3s.yuv
    done
    #On génère les morceaux de fichiers bruts de 3s aux timestamp à 5 10 et 20 minutes. On génère les même pour le fichier source.

    Pour avoir l'image vqmt:
    Code:
    git clone https://github.com/h3dema/ubuntu-vqmt.git
    cd ubuntu-vqmt
    docker build -t vqmt .
    Ensuite on lance les tests:
    Code:
    for debut in "05" "10" "20"; do
      for crf in 20 24; do
        for preset in medium slow; do
          for test in PSNR SSIM MSSIM VIFP PSNRHVS PSNRHVSM ; do 
            docker run -v $(pwd):/videos -w /videos vqmt vqmt out_source_${debut}m_3s.yuv out_${crf}_${preset}_${debut}m_3s.yuv 1080 1920 60 1 ${crf}_${preset}_${test} ${test}
          done
        done
      done
    done
    (je renvois vers la documentation des differents outils pour savoir a quoi correspond tout )


    Bon j'ai pas de résultat pour le comparatif de qualité parce que j'ai choisi les morceaux au pif et je suis tombé sur des séquences statiques (merci les mangas), c'est donc pas super intéressant comme résultat.


    Et c'est à ce moment là que je me suis rendu compte d'un truc, libx265 avait plusieurs version de retard dans le build de ffmpeg par defaut! (2.3 vs 3.0).
    J'ai donc rebuild l'image ffmpeg avec la version 3.0 comme cible. Et là j'ai eu une petite surprise... La version 3.0 est beaucoup plus lente! (250% sur les deux encod qui ont terminé pour l'instant)

    En conséquence je vais lancer un batch de transcod en utilisant une video source plus courte (big buck bunny) et tester les differentes version de libx265 pour le temps d'encodage et la qualité.

    J'ai un autre batch de transcod que je vais lancer avec la version "officielle" en limitant les preset à medium/slow et crf à 19/20/21/22.

    bref, plus de données bientôt.



    tips bonus, pour générer les commandes ffmpeg de transcod permettant de garder toutes les pistes audio et tout les sous-titres:
    Code:
    # commande de base (limitation cpu, volumes...) et le fichier source
    echo -n 'docker run --cpuset-cpus="0,2,4,6" --cpus="4" -v$(pwd):/temp/ jrottenberg/ffmpeg -i /temp/Violet.Evergarden.01.mkv -map 0 ';
    # on utilise ffmpeg pour lire les stream et on filtre pour n'avoir que le "numero" des stream qui ne sont pas de la video
    for i in $(docker run -v$(pwd):/temp/ jrottenberg/ffmpeg -i /temp/Violet.Evergarden.01.mkv 2>&1 |grep -v "Video" |grep "Stream #"| grep -o -e "#.:[0-9]*"); do 
      # pour tout les stream
      echo -n " -c:0:${i:1} copy "
    done
    # commande pour le transcod video
    echo -n '-c:v libx265 -preset veryfast -crf 20 /temp/outtest2.mkv'
    echo ""
    C'est assez basique et je ne suis pas certains que ça marche dans 100% des cas mais c'est une bonne base pour lancer un gros batch de transcod dans un dossier sans se poser de question

  27. #267
    Good news everyone! AV1 ca avance plus rapidement que prévu !
    https://people.xiph.org/~negge/NAB2019.pdf

  28. #268
    Effectivement c'est impressionnant. Et en juste quelques mois l'encodeur a fait des progres spectaculaires en terme de vitesse!

    J'aime bien la citation sur la dernière slide:
    Considering that video and images make up about 80% of all
    internet traffic, the impact of how things get encoded is pretty big.
    Even a modest 1% BDR gain tool translates into about 20 EB of traffic
    yearly currently, or 20,000,000,000 GB.



    Je suis en train de tester la branche master comparé au tag 1.0 de libaom-av1 et effectivement le gain en vitesse est considérable, x10 au moins!
    Dernière modification par shlagevuk ; 16/04/2019 à 17h18.

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
  •