[Résolu] Vidéos Fraps et erreur de l'espace de couleur au moment de l'encodage

C'est possible !

En tout cas, avec le MainConcept, en débit variable je peux choisir une moyenne et un maximum. Ce qui est sûr, c'est intéressant, parce qu'en faisant de petits tests on peut trouver des bons compromis au niveau de la qualité de l'image par rapport à l'original, à différents débits. On peut doser à toutes les sauces quoi

 

Il y a aussi le mode CRF qui permet de choisir un niveau de qualité et le codec choisit le débit adapté à cette qualité (18 est une valeur assez haute et courante).

 

Oui, j'avais déjà testé auparavant, même si généralement je préfère réglé mon débit moi-même.

J'avais déjà utilisé ce codec avec VirtualDub une fois. Mais là je n'ai pas assez de place pour exporter de Vegas au format non compressé, même en Lagarith, pour ensuite le compresser sour VD.

En fait, je ne sais pas pourquoi ça merde sous Vegas. Mais bon, avec le MainConcept, je trouve qu'on peut déjà faire des choses pas mal

 

Hello

J'ai juste voulu tester l'encodage en x265 avec Handbrake pour voir, et malgré le fait que ce soit super lent, le résultat est pas mal

Les seuls 2 soucis, c'est d'une part que ça floute un peu l'image, mais la compression reste très équilibré je trouve et se fait facilement oublier. D'autre part, et là pour moi c'est le gros défaut, les couleurs sont différentes, légèrement plus flashy.

Si j'arrivais à corriger ça, ce serait pas mal.

Merci d'avance pour votre aide

 

En fait, je crois que le souci vient carrément de Handbrake, car j'ai le même souci de couleurs en x264.

Mais je me souviens que j'avais une fois le même souci avec le codec "x264vfw". J'ai donc dû ajouter "--colormatrix bt709" dans la case "Extra command line". Ça doit donc être un problème d'espace de couleur.

Ce serait bien d'arriver à régler ça, car autrement la qualité est vraiment bonne.

Si quelqu'un a une idée pour corriger ça SVP. Merci

Edit : En fait, j'ai oublié de préciser que les vidéos ont été capturés avec Fraps, donc logiquement elles sont en RGB. A mon avis le souci doit venir de la conversion de l'espace de couleur au moment de l'encodage.

 

Ce n'est pas le seul cas où ça pose problème apparemment.

J'ai essayé de choisir le YV12 en sortie au lieu de RGB dans les réglages du codec Lagarith, et ça me fait la même erreur au niveau des couleurs qu'avec Handbrake.

Donc le souci c'est lorsqu'il s'agit de convertir du RGB en YUV j'ai l'impression.

Par contre aucun souci lorsque j'encode en mp4 dans Sony Vegas.

Je tiens à préciser que je n'ai pas forcé l'enregistrement des vidéos en RGB dans Fraps, donc logiquement même si c'est du RGB pour la vidéo, je suppose qu'au niveau de l'espace de couleur ça équivaut déjà à du YUV.

 

En gros, faudrait que ma vidéo RGB soit reconnue comme du YUV en entrée pour éviter une double conversion YUV vers YUV, vu que c'est déjà capturé dans un espace de couleur YUV à la base, mais au format non compressé, donc RGB

Quelqu'un peut m'aider SVP ?

 

Bon, j'ai trouvé un moyen, même si je ne suis pas totalement satisfait

Avec le codec "x264vfw", on peut apparemment sortir une image sans perte en "Single pass - lossless". Et puis dans "Extra command line" j'ai ajouté "--colormatrix bt709", ce qui au final me sort une image au format YV12 sans perte de couleurs.

Et pourtant, quand je dis que je ne suis pas totalement satisfait, c'est parce qu'il y a quand même eu une légère retouche.

Pour comparer je vais mettre des screenshots.

Fraps :



Lagarith codec RGB :



x264vfw Single Pass Lossless (--colormatrix bt709) :




A vu d’œil, pas grand chose à reprocher, surtout au Lagarith qui est exactement pareil que l'original, mais en RGB par contre.

En fait, c'est avec le x264vfw que ça cloche, car en comparant de plus près, on constate de grosses différences qui se voient au niveau des gouttes de sang (désolé pour toute cette violence ) et aussi autour des lettres de "Tamerlane" par exemple où l'on peut notamment déceler un genre de double contour.

En gros, ça reste un peu du bricolage quoi

J'avais constaté la même chose en utilisant le codec Sony YUV dans Sony Vegas en sortant au format AVI.

Bref, j'aimerais vraiment qu'il n'y ait pas de retouches, comme lorsque j'encode en x264 dans Vegas avec le MainConcept et le Sony AVC.

Sauf que là mon but est de pouvoir exporter une vidéo au format lossless et si possible en YUV (vu que c'est ce que Handbrake attend), pour pouvoir ensuite l'encoder dans Handbrake, donc Sony Vegas n'est censé n'être qu'un intermédiaire.

 

J'ai trouvé les enfants

En fait, j'ai cherché un peu dans l'aide des lignes de commandes du "x264vfw" où il y a toute la liste de celles-ci, et j'ai trouvé une ligne intéressante :

"--colorprim bt709"

Comme ça l'information de l'espace de couleur primaire est contenue dans la vidéo en sortie

Évidemment, pour éviter la conversion, j'ai pensé que le mieux était de rester en RGB. Donc il a fallu que je choisisse "Keep input colorspace" dans les paramètres du "x264vfw".



Et magie ! Ça a marché

Voici donc ce que m'affiche le MediaInfo pour cette vidéo :

J'ai donc de nouveau utilisé le "Single pass - lossless" du "x264vfw" et en comparant c'est identique à l'original :



Voici d'ailleurs ce que m'indique le MediaInfo pour cette vidéo :

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 10s 0ms
Bit rate : 449 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 60.000 fps
Color space : RGB
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 8.126
Stream size : 536 MiB (100%)
Writing library : x264 core 146 r2538bm 121396c
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0
Color range : Full
Color primaries : BT.709
Matrix coefficients : RGB


Ensuite alors (suspense !), j'ai retesté le x265 sous Handbrake, et "oh ! miracle!", là aussi ça a fonctionné :




Je ne veux pas me vanter, mais j'ai été bon sur ce coup là !

J'ai juste modifier le titre du post pour que ce soit plus compréhensible. Comme ça si quelqu'un fait une recherche une fois, il trouvera plus facilement.

 

Par contre, j'ai une petite question. Le MediaInfo du x265 indique du BT601 dans "Matrix coefficients" :

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Original frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.9:[Windows][GCC 4.9.0][64 bit] 8bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=1 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=600 / min-keyint=60 / scenecut=40 / rc-lookahead=15 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=0 / ref=2 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=2 / pass / bitrate=20000 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601


D'après vous, c'est problématique ? Qu'est-ce que ça signifie ? A vue d’œil je n'ai pas eu l'impression qu'il y ait de souci d'espace de couleur.

 

J'ai retesté mais avec en entrée la vidéo encodée avec le Lagarith en YUV (donc avec le problème de couleur), et là par contre le MediaInfo m'affiche ce que j'attendais :

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Original frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.9:[Windows][GCC 4.9.0][64 bit] 8bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=1 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=600 / min-keyint=60 / scenecut=40 / rc-lookahead=15 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=0 / ref=2 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=2 / pass / bitrate=20000 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


Bizarre !

N'hésitez pas à m'aider aussi SVP ! Merci

 

Tu te débrouilles très bien tout seul
Au lieu du Lagarith, tu peux essayer le Ut parce qu'il paraît que dans de rares cas le Lagarith peut créer des petits bugs sur certaines images.
Ut Video Codec Suite 16.1.1 - Download

 

Merci

Je vais tester ça Par contre, le gros problème dans mon cas c'est vraiment avec ce fichu espace de couleur

Je ne comprends pas ! Handbrake a pratiquement tout compris. Il me met la vidéo dans un "color range : limited", reconnait l'espace de couleur BT.709, et à la fin me met "Matrix coefficients : BT.601".

Pourquoi ?

Bon, à l’œil comme dit, je ne vois pas trop de différence (j'ai peur que ça s’emmêle les pinceaux au moment de l'encodage sur Dailymotion par contre... et oui, Dailymotion accepte le x265 apparemment, j'ai testé ). Mais bon, c'est bizarre quand même ! Et puis avec une résolution HD ça devrait me choisir "Matrix coefficients : BT.709" direct non ?

 

J'ai testé le "UtVideo YUV420 BT.709 VCM" et malheureusement, même si les couleurs sont justes, ça me fait exactement la même chose qu'avec le "x264vfw" en "Single pass - lossless" et la ligne de commande "--colormatrix bt709"

En gros, ça refait une conversion vers YUV et ça créé des décalages de pixels ou des espèces de doubles contours autour des textes.

Donc le seul moyen pour que ça reste identique à la source, c'est d'utiliser "x264vfw" en "Single pass - lossless" avec la ligne de commande "--colorprim bt709".

Reste à régler le problème du "Matrix coefficients : BT.601"

Pour moi c'est carrément illogique !


Je viens de tester le codec "x265vfw" (http://jaist.dl.sourceforge.net/project/mpxplay/x265vfw/x265vfw_x86_latest.exe), mais même histoire au moment de sortir du YUV420. De plus il ne prends pas en compte les lignes de commande j'ai l'impression.

 

Je ne sais pas si ça a un rapport, mais j'ai trouvé ça : Encoding Fraps videos: solving colorspace issues (wrong color, faded, etc) | EncodingTalk.com

"Here's how I see the behavior of the applications I tested:

• VirtualDub always assumes Rec.601, unless the Rec.709 tag is added (x264 "--colormatrix bt709"). Otherwise, Rec.709 input (g+) can be corrected with the Alias Format filter (set color space = Rec.709; range = no change). To see the correction in still-frame, at least one other color filter must be active. I suggest the HSV filter, left at default settings."

Si je comprends bien, VirtualDub utilise du Rec.601 par défaut en YUV, sauf si on ajoute la ligne de commande "--colormatrix bt709" dans les paramètres du codec x264vfw.

Sauf que moi je veux éviter la conversion de ce qui est déjà du Rec.709 à la base, mais en RGB, c'est pourquoi j'avais rentré la ligne de commande "--colorprim bt709".

Après j'ai essayé d'enchainer les 2 en rentrant : "--colorprim bt709 --colormatrix bt709"

Je ne sais pas si c'est ce qu'il faut faire, mais ce qui est sûr, c'est que ça a merdé. J'ai obtenu une image toute verte

Bref, pour moi ce n'est pas encore totalement clair tout ça