Log in

View Full Version : Megui/x264 rendering DVDRip overly red


TakuSkan
22nd June 2013, 04:11
I've been comparing identical frames between DVD VOB files and the MKV videos rendered with x264 & MeGUI recently, and have been finding them overly red. For comparison I rendered a section of the same DVD VOB file as an Xvid file. The color in the Xvid file matches the color in original VOB pretty well.

Here's an example frame of an x254 rendered video:

http://tinyurl.com/q3xn534

Here's the same frame rendered as an Xvid video:

http://tinyurl.com/q5noyyg

And here's a screenshot of the same frame from the original VOB:

http://tinyurl.com/qa7g8zb

From a different DVD, here's a frame from an x264 rendering:

http://tinyurl.com/qa55lwt

And this is a screenshot of the same frame from the source VOB:

http://tinyurl.com/p4wslzw

I've previewed the videos with Potplayer, mpc-hc, smplayer and VLC using a number of different video renderers, each producing pretty much the same results. I just ripped the scene from the DVD in the second 2 screenshots above with a older copies of MeGUI and x264 on another PC, and got the same results.

I also spent an entire evening learning how to modify the Avisynth files to adjust brightness, saturation, contrast and hue. But I wasn't able to come close to the original color balance of the source that Xvid managed to match from the same avs script that x264 rendered overly red.

I've recently updated my copy of MeGUI which included the current version of x264, and my Avisynth seems to be up to date.

I'd certainly appreciate any thoughts on all this.

raffriff42
22nd June 2013, 05:22
Try x264 config, Misc tab, Custom command, --colormatrix bt709

BTW, 3/4 of your sig links are 404 :(

TakuSkan
22nd June 2013, 06:27
Try x264 config, Misc tab, Custom command, --colormatrix bt709
Little change if any:
fds
http://tinyurl.com/qa55lwt

Last rip:

http://tinyurl.com/qa55lwt

Original VOB:

http://tinyurl.com/p4wslzw

BTW, 3/4 of your sig links are 404 :(
Last I checked I wasn't able to modify it... I see can now.

EDIT: Nope... same old problem: "Your signature cannot be longer than 400 characters including BB code markup." Board rules have changed since I joined.

raffriff42
22nd June 2013, 14:00
Your signature cannot be longer than 400 charactersTinyURL FTW ;)

In your AviSynth script, tryColorMatrix(mode="Rec.601->Rec.709")requires ColorMatrix - see notes at doom9 (http://forum.doom9.org/showthread.php?t=82217), avisynth.nl (http://avisynth.nl/index.php/External_filters#Chroma_correction), avisynth.org.ru (http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm)

TakuSkan
23rd June 2013, 00:35
TinyURL FTW ;)
Thanks... Did that, then got this from the board: "Your signature cannot be longer than 200 characters excluding BB code markup." 1st 400, now 200.

In your AviSynth script, tryColorMatrix(mode="Rec.601->Rec.709")requires ColorMatrix - see notes at doom9 (http://forum.doom9.org/showthread.php?t=82217), avisynth.nl (http://avisynth.nl/index.php/External_filters#Chroma_correction), avisynth.org.ru (http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm)
Same results with that. Am still trying to wrap my head around all this.

raffriff42
23rd June 2013, 12:51
Oh man, just TELL me then, what is this Dali painting you speak of? :)

Same results again? Well I never. Try this and tell me you don't see any change:
#avisynth
## original = face (2nd image from top)
O=ImageSource("35cndps.jpg").ConvertToYV12().Crop(320, 80, 176, 240)

G=O.ColorMatrix(mode="Rec.601->Rec.709")
GG=G.ColorMatrix(mode="Rec.601->Rec.709")

R=O.ColorMatrix(mode="Rec.709->Rec.601")
RR=R.ColorMatrix(mode="Rec.709->Rec.601")

return StackHorizontal(
\ GG.SubTitle("GG").AddBorders(0, 0, 8, 0),
\ G.SubTitle( "G").AddBorders(0, 0, 8, 0),
\ O.SubTitle( "O").AddBorders(0, 0, 8, 0),
\ R.SubTitle( "R").AddBorders(0, 0, 8, 0),
\ RR.SubTitle("RR"))
#return GG.Trim(0,-1)+G.Trim(0,-1)+O.Trim(0,-1)+R.Trim(0,-1)+RR.Trim(0,-1)


The color shift is MUCH easier to see with more saturated source material.
https://www.dropbox.com/s/ehcsnrlpbrt9rce/color-compare.jpg?raw=1
https://www.dropbox.com/s/cpzypsies7juspa/colorbars-compare.png?raw=1

TakuSkan
23rd June 2013, 23:59
Oh man, just TELL me then, what is this Dali painting you speak of? :)
Geopoliticus Child Watching the Birth of the New Man (http://salvadordalipaintings.blogspot.com/2008/09/geopoliticus-child-watching-birth-of.html)
Friends with Sigmund Freud, he was quite a thinker.

Same results again? Well I never. Try this and tell me you don't see any change:
I'm able to replicate that and open it in VDub. I'm not quite sure what this means, as the source is a jpg, and not the original Rec.709 MPEG-2 DVD VOB. It appears you've created 2 sets of identical images. The 2 on the left ec.601->Rec.709. - and 2 on the right 709->Rec.601, with the source in the center position. I can see what appears to be a very slight shift from reds on the left to yellows on the right. Maybe it's just that the images on the right seem a bit brighter.

https://dl.dropboxusercontent.com/u/108089426/Screenshots/color-compare.jpg
https://dl.dropboxusercontent.com/u/108089426/Screenshots/colorbars-compare.png

I've read through the links you provided above, but I have to admit I'm way over my head here. I have an extremely limited understanding of Avisynth scripting.

Reading the abstract on the ColoMatrix (http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm) filter though, it would seem that since my source is an MPEG-2 VOB, I should be using 709->Rec.601. The info on that ColoMatrix abstract seems to indicate 601->Rec.709 would be used to convert an XVid/DivX file to MPEG-2:

In case you captured something or you have a XviD/DivX (both are encoded Rec.601 coefficients), and you want to encode it to mpeg-2 using CCE (which assumes Rec.709 coefficients), you should use the following script (progressive material)

ColorMatrix(clip, mode="Rec.601->Rec.709")

I'm using x264, but in reading through the ColorMatrix thread, I see people using ColorMatrix similarly with both Xvid and x264. I tried switching Rec.601->Rec.709 to Rec.709->Rec.601 in my avs script, but the colors in the x264 video produced were still overly red.

Another thing I've been wondering about is why the same Avisynth script used by MeGUI produces an Xvid video that matches the color balance of the original VOB, and produces an x264 video overly red. ColorMatrix wasn't necessary to produce a good Xvid file. Is it possible the problem isn't with Avisynth/ColorMatrix, but is something more directly related to the x264 encoder?

Here's one of the MeGUI avi synth scripts I've modified that is using the DGDecode d2v file as the source:

LoadPlugin("C:\Temp\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\Temp\VIDEO_TS\VTS_02_1.d2v", info=3)
LoadPlugin("C:\Temp\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(mode="Rec.601->Rec.709")
#deinterlace
#crop
LanczosResize(720,528) # Lanczos (Sharp)
#denoise
trim(7000,8000)

Just checked the VOBs with MediaInfo and found it's reporting them as interlaced, where MeGUI was seeing them as progressive. Correcting that had no effect tho'.

EDIT: Looking closer I now see you ran ColorMatrix on both G an R creating GG and RR. So they're not duplicates. But the differences, if any, are more subtle than I can make out. Certainly nothing like the differences between my Xvid and x264 rips from the same avs file.

raffriff42
24th June 2013, 14:03
>Geopoliticus Child Watching the Birth of the New Man
Thank you! I can see how that would be controversial, especially in [1940s] Europe.

>It appears you've created 2 sets of identical images.
The difference is hard to see for sure, but sample GG is twice as green as sample G, since it's been passed through ColorMatrix twice; in the same way, sample RR is twice as red as sample R. I'm doing an exaggerated, double correction to help show the subtle effect of ColorMatrix.

>MeGUI produces an Xvid video that matches the color balance of the original VOB, and produces an x264 video overly red.
Xvid and related codecs support BT.601 only, and that simplifies things a whole lot.

>since my source is an MPEG-2 VOB, I should be using 709->Rec.601
Note the ColorMatrix page (http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm) says "many" MPEG-2 streams use Rec.709, not "all" - this means, to me, that if the encoded version is coming out red, then action is called for.

I suggested two possible corrections, but there is a third: the "matrix" argument to ConvertToYV12 etc. Here all all 3 options, in "pipeline" order:
ConvertToYV12(matrix="Rec709")
If source is Rec709 and ConvertToXXX is required anyway, then this should be used, since ConvertToXXX assumes Rec601.
ColorMatrix(mode="Rec.601->Rec.709")
Modifies the U and V color data slightly - least best option.
--colormatrix bt709
Encoder flag; I believe this only provides a hint to the decoder and does not change any color data.
I would urge you to take a closer look at the results from encoding with "--colormatrix bt709." I use this pretty much all the time with VirtualDub.

Finally, this sums it up really well:As a rule of thumb :
- SD content on anything but a PC : bt601 TV range.
- HD content on anything but a PC : bt709 TV range
- On a PC, do whatever you want, the odds are there will always be a player that doesn't support what you do, and another one that requires what you do.

You should always signaled properly the colormatrix/range with x264 if you plan to play it on a TV. To ensure you actually signal what you're encoding, use the colormatrix filter in avisynth. Some source filters (dgdecode for example) communicate with colormatrix so that it does the proper conversion. If colormatrix/range isn't signaled in the source, or if it is lost by the source filter, you can still force colormatrix to do the proper conversion.

TakuSkan
25th June 2013, 00:14
ConvertToYV12(matrix="Rec709")
If source is Rec709 and ConvertToXXX is required anyway, then this should be used, since ConvertToXXX assumes Rec601.
I've played with ConvertToYV12() with no options successfully in scripts before. But when I place ConvertToYV12(matrix="Rec709") in the script I posted above, with or without loading the ColorMatrix.dll plugin before it, I get this from MeGUI when I try to load the script:

MeGUI encountered a fatal error and may not be able to proceed.
Reason: object reference not set to an instance of an object.
I'm guessing ConvertToYV12(matrix="Rec709") is not a ColorMatrix function, or at least I don't see any mention of it in the ColorMatrix abstract. I attempted several changes to the script to get MeGUI to load it with no success.

I would urge you to take a closer look at the results from encoding with "--colormatrix bt709." I use this pretty much all the time with VirtualDub.
I'm not sure what you're suggesting I take a closer look at. I configured, 'x264 config, Misc tab, Custom command, --colormatrix bt709' in a MeGUI x264 preset as you suggested above, and rendered a small clip. Reviewing tests from last week, I see MeGUI is automatically adding 2 lines to load and execute ColorMatrix commands by default. This is what MeGui creates when I do nothing but resize the video:

LoadPlugin("C:\Temp\VIDEO_TS\VTS_02_1.d2v", info=3)
LoadPlugin("C:\Temp\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
#crop
LanczosResize(720,528) # Lanczos (Sharp)
#denoise
trim(7000,8000)

The resulting video was still overly red, as you can see from the screenshot in my 2nd post above. Is there something I'm not looking at?

EDIT: I went back and reviewed all the tests I've done in the past 10 days, and found the results consistent with what I've posted. Plus, I just started from scratch with rendering a clip from the DVD in the 1st screenshots above. 1st doing nothing but resizing the video (script above). 2nd running that same script, but with --colormatrix bt709 configured in the x264 profile as you suggested. Then 3rd replacing 'ColorMatrix(hints=true, threads=0)' with 'ColorMatrix(mode="Rec.601->Rec.709")'. Still no luck..

How do you use --colormatrix bt709 in VDub? When I modify ColorMatrix options in the avs scripts, I'm not seeing any change in colors when I reload the video preview in MeGUI. Same if I load the avs file in VDub. And I'm not seeing any changes of color in the rendered clips. When I modify values like 'ColorYUV(gain_u=-7, gain_v=-0)' and 'Tweak(sat=.78,bright=5,hue=-3,cont=.8)', I can reopen the video preview in MeGUI and see the changes which are confirmed in the rendered clips.

Finally, this sums it up really well:
The emphasis there is on TV display, but I guess gives a bit of perspective on how ColorMatrix works.

Looking at the images you produced with ColorMatrix, I'm not seeing the radical red shifts I've been getting in my x264 renderings. Is it possible something else is going on?

raffriff42
25th June 2013, 07:43
>Is it possible something else is going on?
I think so; maybe something to do with the "hints" feature of DGDecode, I don't know.

I tried to duplicate your work using MeGUI+DGDecode, and
(1) I don't get a red shift after encoding -- although that may be due to my choice of DVD and/or my media player (MPC-HC w/ Haali)
(2) Like you, I don't see any change using the "--colormatrix bt709" option :confused:
(3) However, I do see a change when use ColorMatrix(mode="Rec.601->Rec.709")

That is, I changed this line in my script:
ColorMatrix(hints=true, interlaced=true, threads=0)
to read:
ColorMatrix(mode="Rec.601->Rec.709", hints=true, interlaced=true, threads=0)


Output from the stock script (or with "--colormatrix bt709", it didn't matter):
https://www.dropbox.com/s/7yf2rj0dejqsw7k/RickSteves-London-2004-bhp-601.mp4.jpg?raw=1

With "Rec.601->Rec.709":
https://www.dropbox.com/s/khft7szkt5qalom/RickSteves-London-2004-bhp-cnv709.mp4.jpg?raw=1

In the second picture, the red flowers are less saturated and darker; the grass is more saturated and brighter.

TakuSkan
26th June 2013, 00:08
Problem solved. Seems the title of Shakespeare's play would be pretty applicable here. A lot of noting for nothing.

When I 1st tested these video clips in the 5 software video players (left out WMP above) I use most of the time, in the back of my mind I was thinking about some point in the past when most were configured with different renderers. Can't believe I failed to actually check that, did the tests, and never looked back 'till now.

Turns out the renderers for 3 out of 5 are now set to 'System Default' or 'Select Automatically'. Potplayer has my default ever since I discovered it and found I could customize the interface via compressed XML files. When I started working on this today, it hit me you wrote you have Haali configured in MPC-HC raffriff42. I was realized I was fuzzy about just how carefully I'd checked the renderers.

I found Potplayer set to 'Select Automatically', I changed that to Haali and bam... the right color balance.

http://tinyurl.com/qcnbw6z

Oddly tho', I switched to each of those renderers and none gave me that overly red hue. So I don't know what renderer Potplayer was using.

Rereading my initial post, I was reminded of a test teachers gave my class in high school. It was 2-3 pages of questions and instructions for things to do. The 1st item said to read through the entire test before doing anything. The last said not to do anything. It took 10-15 minutes for most of us to catch on, and that pretty much because of a gradual rise in muffled laughter.

Where's the animated GIF emoticon with the head banging against the wall? :stupid:

This was the 1st time I've seen this with a MeGUI rip tho'. Not working directly with video on a day to day basis, I'm obviously way behind the curve around here.

raffriff42
26th June 2013, 01:39
Excellent :cool:

TakuSkan
27th June 2013, 04:43
I'd still like to figure out just what it was about these 2 DVDs that caused the player renderers to display the re-encoded x264 video with too much red. Why the Xvid rip wasn't affected by the default renderers. And I'm wondering if that's just what's going to happen from time to time with nothing to prevent it other then switching the media player's video renderer. These were relatively significant shifts in color balance.