Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 4 sur 4 PremièrePremière 1234
Affichage des résultats 91 à 114 sur 114
  1. #91
    Citation Envoyé par MegABiloU Voir le message
    Merci pour ton retour.

    Hé oui hevc de 38Go ça peut durer un peu.
    Ouai et non au final

    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

    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). Mais bon faudrait installer Handbrake dessus puis faire tous les réglages. Et vu qu'elle l'utilise...
    Dernière modification par Rocca ; 03/06/2017 à 14h20.

  2. #92
    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.

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

  4. #94
    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 :




    Les paramètres d'encodage :





    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.


    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

  5. #95
    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.

  6. #96
    Citation Envoyé par shlagevuk Voir le message
    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

    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 , niveau qualité image est franchement pas mal du tout !!

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

  8. #98
    Citation Envoyé par shlagevuk Voir le message
    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).




    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

  9. #99
    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)

  10. #100
    Citation Envoyé par shlagevuk Voir le message
    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...

  11. #101
    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 :



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

    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

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

    Je ferais également un post dessus, bien entendu



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


    Original :



    Ultrafast :



    Medium :




    Slower


  12. #102
    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.

    Ensuite y'a un blog assez bien fait qui explique le fonctionnement des encodeurs video et notamment x265/vp9/x264, l'article sur le x265


    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.

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

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

    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

  15. #105

  16. #106
    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é ?
    Saigo no Uta 最期の詩 - ♥ 忍野 忍 ♥

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

  18. #108
    (mais il faut que la source soit en 10bit aussi)

  19. #109
    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) et moins compatible (surtout avec les smartphones/TV/box).
    Why does 10bit save bandwidth (even when content is 8bit)?

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

  20. #110
    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.


    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.

  21. #111
    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é.
    Dernière modification par Squarealex ; 21/07/2017 à 02h01.
    Saigo no Uta 最期の詩 - ♥ 忍野 忍 ♥

  22. #112
    Citation Envoyé par shlagevuk Voir le message


    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.
    Sombrero d'or since 2015/12/03
    Citation Envoyé par Darkath Voir le message
    Mais enfin c'est toi l'expert, trouve des solutions bordel.

  23. #113
    Citation Envoyé par Squarealex Voir le message
    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/h...linux-windows/

  24. #114
    Merci pour les réponses, du coup je sens que je vais réencoder certain truc. :D
    Saigo no Uta 最期の詩 - ♥ 忍野 忍 ♥

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
  •