module inscription newsletter haut de page forum mobile

Ateliers et Formations

[Problème] Vidéo légèrement rose - RGB avi non compressé vers (YUV) mov x264

Discussion in 'Compression, conversion vidéo' started by Sylvanounet, Aug 3, 2012.

Tags:
  1. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    Bonjour :hello:

    J'ai un petit soucis avec le x264, pour illuster un petit peu:
    il y a 5 ans quand je n'y connaissais rien et que j'utilisais un logiciel tout fait pour encoder un .avi en autre chose compressé en x264, je me rendais compte que les couleurs de ma vidéo présentaient une légère déviance, par exemple un gris 128 se retrouvait à être un r132 v127 b133 après encodage :rolleyes:

    Maintenant j'utilise mencoder.exe pour encoder en ligne de commande en x264 et c'est exactement pareil, petite déviance de couleur.

    Ca ne parait pas mais 5 ou 6 en plus ou en moins ca produit par exemple un ciel qui est avant encodage bleu clair, et après encodage bleu/rose clair, y a pas à dire mais c'est moche :p

    Je crois que l'espace de couleur du x264 c'est YUV non? Donc ce genre de chose:
    [​IMG]

    Jusqu'à maintenant je compençais ce décallage en modifiant r-4 v+1 b-4 avant encodage, mais la j'aimerais vraiment arrêter ce bidouillage et vous demandez si jamais vous avez des idées sur ce problème :hello:

    Donc comme je l'ai vaguement montré, le problème ne vient pas de ma config puisque avant je n'avais pas le même ordinateur et c'était pareil, ca ne vient pas non plus de mencoder.exe puisque avant j'utilisais des logiciels pour encoder, même problème, et ca ne vient pas non plus de mon lecteur pour lire la vidéo parce qu'avant je n'utilisais pas vlc, et que mes vidéos x264 c'est pour mettre sur mon site perso, donc lecture en streaming en as3 (flash) et que les couleurs par rapport à vlc sont pareil (légère teinte de rose) :sad:

    Voila merci de m'aider s'il vous plait :help: :hello:
     
  2. THEMASTER

    Trophy Points:
    1,970
    Likes Received:
    11
    Messages:
    991
    Appréciations:
    +9 / 18 / -0
    Si tu as un écran non calibré ça peut expliquer les défauts que tu observe

    Le mieux et d'utiliser un script avisynth avec un "test pattern" comme on dit

    exemple:
    colorbars(width=720,height=576,pixel_type="YV12").trim(0,400)
    changefps(25.000)

    Une fois encodé avec mediacoder tu pourras comparer les deux avec avisynth via le logiciel avspmod de préférence:

    script (en supposant que tu encodes dans un conteneur avi, car, mkv/mp4 plus compliqué):

    import("C:\Program Files\AviSynth 2.6\plugins\histogramCMY.avs")
    function int2mode(int index) { return Select(index, "classic", "levels", "color") } # pour HISTOGRAMME
    avisource(C:\mavideo.avi")
    ColorYUV(analyze=true) # donne les valeurs YUV précises
    Histogram(int2mode(1)) # HISTOGRAMME YUV
    # Optionnel:
    #HistogramRGBLevels # Histogramme RGB (rouge,vert, bleu)
    #HistogramCMYLevels(range=true) # Histogramme CMY (Cyan,Magenta,Jaune)
     
  3. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    Merci de ta réponse, mais je ne comprend pas très bien pour l'écran non calibré :perplexe:

    Ca n'a rien à voir avec l'écran, il serait en noir et blanc tout baveux en 320x240 je pourrais également te confirmer qu'il y a un problème après encodage et te donner les couleurs exactes puisque je contrôle la valeur des pixels directement (avec la pipette) :hello: D'ailleur avant je n'avais pas le même écran et c'était pareil, même décalage pourtant l'écran était un crt de 22 pouce tout vert flou. Alors bien sûr la vidéo avant encodage étaient vert flou dégueux et la vidéo après encodage x264 était vert flou rose dégueux :laugh:

    Ca vient uniquement de la conversion rgb vers yuv je pense, mais comment régler le problème... :perplexe:
     
  4. jakovideo

    jakovideo Regretté Modérateur
    Modérateur So

    Trophy Points:
    15,150
    Likes Received:
    230
    Messages:
    11,073
    Appréciations:
    +166 / 324 / -1
    Salut , tu peux essayer ceci : nettoyer tous les contacts véhiculant ton signal RVB , avec une bombe spéciale contacts électriques . j'avais le même défaut sur mon lecteur de DVD en utilisant pourtant un cable péritel plaqué or . Malgré la basse impédance de sortie des 3 composantes ( 75 ohms ) , un faux contact est tjrs possible .
     
  5. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    Héhé merci encore mais ca ne viens pas de ça c'est sûre :laugh: Par contre en effet c'est un bon conseil pour ceux qui ont ce genre de soucis analogique.

    Pour mon cas il faudrait que je nettoye les contacts de mon processeur ou de ma carte mère alors :mdr:

    Blague à part, c'est bien en controlant informatiquement à la pipette la couleur des pixels de mon fichier vidéo .avi avant encodage et après que je m'aperçois de ce léger décalage de couleur! C'est un décalage qui peut paraitre logique pour certain car il y a compression des informations, donc perte, mais il s'avère que la perte pourrait très bien produire un décalage vers du vert ou du bleu, au lieu du rose actuelement.

    Donc je rappel ce que je fais parce que j'ai l'impression de parler extraterrestre :cry2:, j'ai mon fichier video.avi 25p uncompressed rgb, je l'encode en video.mov 25p x264 (qui possiblement est en yuv d'après ce que j'ai compris, d'ou le soucis de rose).

    Voici ma ligne de commande batch pour mencoder.exe:
    for %%n in (*.avi) do "C:\Program Files\Codec\mencoder.exe" %%n -of lavf -ovc x264 -x264encopts pass=1:keyint=25:bitrate=4096:subq=9:frameref=1:mixed_refs:bframes=1:me=umh:partitions=all:8x8dct:direct_pred=auto:no_fast_pskip:nr=0 -vf harddup -noskip -passlogfile "%%~nn.log" -oac copy -mc 0 -o "%%~nn.mov" & "C:\Program Files\Codec\mencoder.exe" %%n -of lavf -ovc x264 -x264encopts pass=2:keyint=25:bitrate=4096:subq=9:frameref=1:mixed_refs:bframes=1:me=umh:partitions=all:8x8dct:direct_pred=auto:no_fast_pskip:nr=0:global_header -vf harddup -noskip -passlogfile "%%~nn.log" -oac mp3lame -lameopts cbr:br=128:aq=0 -srate 44100 -mc 0 -o "%%~nn.mov" & del *.log & del *.mbtree & rename "%%~nn.mov" "%%~nn.tmp" & "C:\Program Files\Codec\qtfaststart.exe" "%%~nn.tmp" "%%~nn.mov" & del "%%~nn.tmp"

    Mais cette ligne de commande on s'en fou totalement puisqu'il y a 5 ou même 10 ans avec le x264, sur un autre matos, avec un autre écran, avec tout de différent lol (je me répète mais bon :mdr:), ca faisait exactement le même bug de couleur.

    Donc ma question c'est, pourquoi quand on encode en x264 nos images sont légèrement roses (de 5 ou 6 valeurs sur une échelle de 256) ?

    Merci d'avance pour votre aide :hello:
     
  6. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    [​IMG]

    Apparement j ne suis pas le seul à avoir constaté ce problème :unsure:
     
  7. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Trophy Points:
    24,400
    Likes Received:
    573
    Messages:
    11,303
    Appréciations:
    +443 / 1,461 / -13
    Quels sont les espaces colorimétriques de la source (quelle est-elle, d'ailleurs) et de l'encodage de cette même source ?
     
  8. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    la source:
    .avi rvb (srgb) non compressé 1024x512 25p
    la destination:
    .mov (yuv) x264 1024x512 25p

    Merci de ton aide :hello:
     
  9. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Trophy Points:
    24,400
    Likes Received:
    573
    Messages:
    11,303
    Appréciations:
    +443 / 1,461 / -13
    Bon, je ne sais pas si je vais pouvoir t'aider à trouver la solution mais je te donne une piste.

    Outre des problèmes de conversion (parfois complexes à résoudre) de RVB en YUV, il faut aussi tenir compte des espaces colorimétriques dans lesquels on travaille et s'assurer que tout est cohérent.

    En vidéo il y en a principalement deux qui sont à la norme de diffusion :

    Le BT 601 qui est la norme pour la définition standard (dvd par exemple) et le BT 709 qui est la norme en HD (Blu-ray par exemple). Les caméras devraient donc filmer selon ces normes (c'est ce qu'elles font) mais avec des apn en vidéo c'est un peu la panique. Même un EOS 5D MK II n'est pas à la norme.

    Donc, déjà, si tu travailles dans le mauvais espace, l'encodeur va repasser le métrage en BT 709 ou 601 selon que l'on est en HD ou SD. Et tu ne vois plus exactement la même chose.

    C'est pourquoi je te demandais l'origine de la source et ta réponse n'est pas très rassurante dans la mesure où le format est bizarre et que tu me parles de sRGB plutôt dédié à la photo courante. Pour de la bonne photo on utilise Adobe RGB voire Prophoto mais ce n'est pas le sujet.

    Un exemple en vidéo : passer de la HD à la norme en DVD SD à la norme. L'espace colorimétrique n'est pas le même et, soit on fait une correction (mais qui peut être pire que le mal si on ne maîtrise pas) soit on laisse comme cela ce qui n'est pas forcément gravissime.

    Certains encodeurs ou autres logiciels permettent de bien choisir et de bien valider les espaces (sources et destination) afin de rester cohérent. C'est le cas de TMPGEnc Video Mastering par exemple ou l'on peuut gérer cette histoire à l'encodage dans les paramètres avancés.

    C'est aussi le cas d'After Effects pour exécuter des compositions en cohérence totale avec le format de diffusion (et selon les sources). Tout comme en photo sérieuses, ces paramètres sont très importants à maîtriser.

    Voici un lien vers la notice d'After qui traite de ce sujet délicat :

    Adobe After Effects * Gestion des couleurs

    D'une façon générale, quand on utilise du matériel courant et des encodeurs courants, ceux-ci se mettent par défaut sur les bons espaces suivant le format utilisé.

    Mais si tu as des rushes un peu exotiques (comme le laisse supposer ta réponse) une dérive peut survenir pour les raisons exposées plus haut.

    Vu la complexité de ces histoires de colorimétrie, il est impossible de te donner à distance une réponse fiable pouvant résoudre ton problème (en admettant que le matériel dont tu disposes permette de le résoudre) mais je tenais à attirer ton attention sur ces histoires d'espaces colorimétriques au cas où il y aurait une anomalie de ce côté là.

    Bon courage pour la suite... ;-)
     
    • Je recommande ! Je recommande ! x 1
  10. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    Ok merci pour ta réponse :hello:

    Par contre pour mon 1024x512 ce n'est pas ici le problème, puisque ca le fait sur n'importe quelle taille de vidéo normée, que ce soit 4/3 ou 16/9.

    En fait j'ai un sony a65 et je converti mes .mts x264 1920x1080 en .avi non compressés 1024x512 (taille de vidéo sur mon site) pour facilement rajouter de l'image de synthèse dans les vidéos.

    Donc la taille 1024x512 il ne faut pas du tout s'en inquiéter, c'est pour de la diffusion sur le web uniquement. C'est un format que j'ai décidé après des semaines de reflexions à me demander la pérennité des formats vidéo. Je me suis dis que finalement le full hd, 16/9, etc... ne seraient pas plus pérenne que le reste, comme le 4/3, il suffit de regarder l'histoire de la vidéo pour s'apercevoir qu'il n'y a pas grand chose de pérenne en fait :laugh: J'ai été très logique, je me suis posé toutes les questions, du genre 180 degrés de large et 120 degrés (il me semble) de haut pour notre vision, oui mais c'est une elipse, ca dépend du sujet, etc... et j'en passe. Finalement j'en ai eu marre de toutes ces conneries et je suis reparti à la base c'est à dire:
    2 yeux
    base 2 en informatique
    1024 c'est juste avant le 2048
    1024 ca convient bien en mode fenetré pour un site sur la majorité des écrans maintenant
    aller hop 1024x512 :mdr:

    Et si je diffuse sur des écrans plus grand genre de salon, je ferais 2048x1024 :laugh:


    Bon pour mon espace de couleur c'est vrai que la dérive est très petite, mais je t'assure que ce n'est pas très beau de voir un ciel rosatre alors qu'il était bleu à l'origine, par contre pour les autres chose le rose se voit moins. Le soucis c'est que je ne filme qu'en exterieur, donc il y aura toujours un ciel.

    Alors oui effectivement jusqu'à maintenant avant d'exporter mes montages je faisais une petite compensation colorimétrique, qui me donne des résultats très bons, en faisant clignoter alternativement une image de la vidéo d'origine et une image de la vidéo x264, on ne voit que très peu de différences de couleur.

    Pour le BT 601 j'ai déja fait des tests mais il faut que je réésaye parce que ca ne change rien.

    C'est assez galère comme problème. Il faut savoir que quand je converti mon .mts en .avi non compressé, les deux sont exactement pareil, que ce soit la colorimétrie, ou le reste. Par contre, dès que je passe de mon .avi non compressé (qui sera cette fois ci monté, ou pas), en .mov x264, c'est la que se produit le décalage de couleur.

    :perplexe:
     
  11. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Trophy Points:
    24,400
    Likes Received:
    573
    Messages:
    11,303
    Appréciations:
    +443 / 1,461 / -13
    Alors je pense que c'est l'encodeur X264 qui modifie l'espace colorimétrique et entraine une dérive.

    Je viens de me mettre dans la même situation que la tienne à savoir que j'ai converti un rush (avec plein de couleurs et du ciel) en avi non compressé.

    Tout comme toi je n'ai pas de différence entre le non compressé et le rush.

    Puis j'ai encodé (comme toi) le non compressé avec TMPEnc Video Mastering Work 5 en X264. Les paramètres avancés m'indiquent qu'il se met bien en automatique sur l'espace BT 709 sur les trois critères : couleurs d'origine / caractéristiques de transfert / coefficient de matrice.

    L'encodage résultant est strictement identique à l'original. Aucune dérive colorimétrique et... pas de ciel rose !

    Donc je pense que ton encodeur (que je ne connais pas du tout) ne respecte pas le transfert d'espace des couleur et modifie celles-ci. Comme il semble fonctionner par ligne de commande, je ne vois pas quoi te conseiller pour modifier cela car je ne suis pas très doué dans ce genre de programmation.

    Maintenant il est difficile d'avoir des certitudes à distance mais comme j'ai pu voir que chez moi ce type d'encodage fonctionne parfaitement et que chez toi l'encodeur change la colorimétrie (pour le même type de format), on peut avoir de fortes présomptions.
     
  12. THEMASTER

    Trophy Points:
    1,970
    Likes Received:
    11
    Messages:
    991
    Appréciations:
    +9 / 18 / -0
    Il est connu que quicktime a un problème pour reproduire des couleurs fidèles
    et comme tu utilises un conteneur .mov je me dis que le souci vient peut être de là..
     
  13. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    Merci pour vos réponses et d'avoir fait les tests :hello:

    Donc j'ai continué moi aussi mes tests, et surtout mes recherches sur le net, d'après ce que j'ai compris l'encodeur x264 doit avoir l'alpha (rgba) dans le .avi non compressé pour pouvoir fonctionner correctement, et donc produire les bonnes couleurs, même si cet alpha ne sert abolument à rien (étant donné qu'on est à la fin du montage juste avant l'encodage pour créer le média final, ca ne servira pas à faire une autre compo.. mais il doit être présent tout de même).

    Bref, en faisant comme ceci ca fonctionne en effet parfaitement bien, les couleurs sont totalement respectés, allez savoir...

    Pour l'encodeur j'utilise mencoder.exe:
    [ame=http://www.google.fr/search?complete=0&hl=fr&source=hp&q=mencoder&btnG=Recherche+Google&gbv=2]mencoder - Recherche Google[/ame]


    Donc pour ceux que ca intéresse je donne ma ligne de commande batch pour convertir tout les avi du répertoire courant en mov x264 avec mencoder.exe:
    for %%n in (*.avi) do "C:\Program Files\Codec\mencoder.exe" %%n -ffourcc raw -ovc raw -vf format=bgr32,flip,harddup -noskip -oac copy -mc 0 -o "%%~nn.tmp" & "C:\Program Files\Codec\mencoder.exe" "%%~nn.tmp" -of lavf -ovc x264 -x264encopts pass=1:keyint=25:bitrate=4096:subq=9:frameref=1:mixed_refs:bframes=1:me=umh:partitions=all:8x8dct:direct_pred=auto:no_fast_pskip:nr=0 -vf harddup -noskip -passlogfile "%%~nn.log" -oac copy -mc 0 -o "%%~nn.mov" & "C:\Program Files\Codec\mencoder.exe" "%%~nn.tmp" -of lavf -ovc x264 -x264encopts pass=2:keyint=25:bitrate=4096:subq=9:frameref=1:mixed_refs:bframes=1:me=umh:partitions=all:8x8dct:direct_pred=auto:no_fast_pskip:nr=0:global_header -vf harddup -noskip -passlogfile "%%~nn.log" -oac mp3lame -lameopts cbr:br=128:aq=0 -srate 44100 -mc 0 -o "%%~nn.mov" & del *.tmp & del *.log & del *.mbtree & rename "%%~nn.mov" "%%~nn.tmp" & "C:\Program Files\Codec\qtfaststart.exe" "%%~nn.tmp" "%%~nn.mov" & del "%%~nn.tmp"


    Pour TMPEnc Video Mastering Work 5 on peut penser qu'il inclu l'alpha j'imagine non? :perplexe:

    Et sinon pour la problématique en elle même, je viens de penser à une chose peut être idiote mais, en incluant l'apha dans le avi, peut être que l'encodeur x264 du coup voit l'espace comme ceci:
    [​IMG]
    C'est à dire avec un rose qu'il n'utilise pas :perplexe: :mdr: Enfin c'est vraiment une supposition et j'ai pleinement conscience que je dis probablement n'importe quoi... :bravo:

    Merci encore pour m'avoir aidé :hello:
     
  14. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Trophy Points:
    24,400
    Likes Received:
    573
    Messages:
    11,303
    Appréciations:
    +443 / 1,461 / -13
    Non pas du tout car j'ai exporté mon rush en non compressé à partir de Premiere. Et il a été exporté en RVB sans couche Alpha.

    Ensuite je l'ai encodé en X264 avec Work 5 qui n'a pu y trouver de couche Alpha puisqu'il n'y en avait pas.

    C'est bizarre cette histoire car je ne vois pas en quoi une couche Alpha puisse influencer la bonne tenue de la colorimétrie. Il y a un truc quelque part.

    Enfin, le principal est que tu ais pu arriver à un résultat qui te convienne. Il faudra peut-être que tu étudies la façon de fonctionner de ton encodeur X264 car il semble un peu capricieux avec les gamut couleur.

    Là, c'est bien possible, effectivement, que tu dises n'importe quoi... :laugh::laugh:;-)
     
  15. Sylvanounet

    Trophy Points:
    1,200
    Likes Received:
    1
    Messages:
    93
    Appréciations:
    +0 / 3 / -0
    En même temps tout parait cohérent pour penser ca donc :hello:

    Etant donné que l'apha ne sert strictement à rien, que quand on enleve le rose il reste bien rgb sur limage, je vois bien l'apha être la uniquement pour bypasser l'encodeur, d'un point de vue programmation ca me parait bien ;-)
     
Loading...

Dernières occasions

 

Share This Page