MeGUI causing color shift

[koberulz]

I have a Premiere sequence, which I output as an MP4 file and it looked fine, color-wise. But Premiere's deinterlacing is awful.

So: Used Advanced Frame Server to frameserve a YUY2 AVI into an AviSynth script which then runs yadifmod. Brought that into MeGUI, had a look at the video preview, all good.

Queued it up, then opened the resulting file in VLC...it's red. Not hugely so, but noticeably. I've got a nice bright yellow graphic displaying, which is now closer to a gold color. The same shift affects the rest of the picture.

I have no idea what's causing this. The MeGUI preview looks fine, so I'm assuming it can't be the framserve or the AviSynth script...

[poisondeathray]

Probably a Rec 601/709 mismatch . I'm assuming this is HD footage.

But first , rule out a playback issue. Try another media player eg. mpchc, smplayer, potplayer etc.... Make sure you have only 1 media player or display open at 1 time (close everything else before testing) , because some might be using shared or different renderer which can shift colors



IIRC megui's preview uses Rec601 to convert to rgb for display. HD uses 709 by convention , most media players will use 709 for HD dimensions. More likely the error is upstream, probably the process before the frameserver or frameserver itself

You can check where the error occurs by previewing the frameserved AVI with a simple script (e.g. in vdub or avspmod, or even megui). I'm assuming you're frameserving interlaced, so just use something quick to check like yadif

AVISource()
Yadif(1,1)
ConvertToRGB24(matrix="rec709")

or

AVISource()
Yadif(1,1)
ConvertToRGB24(matrix="rec601")

Don't use that for the encode, you just want to diagnose what is being sent by the frameserver. You're forcing/specifying the conversion to RGB directly to see what is going on


If the Rec601 version colors looks correct, then the error is upstream . It would be "fixable" by using colormatrix to shift 601=>709 , but if you're serving 601 upstream there could be other errors (for example, premiere or frameserver might have converted to RGB somewhere and you might get interlaced chroma issues if not done properly) . If that was the case I would fix the underlying issues first


If it's none of those, then post more info, including screenshots

[koberulz]

It's SD video. Originally from VHS, with some After Effects graphics over the top. So 601 would be correct.

The MP4 I exported from Premiere looks right (or at least, looks the same as the sequence within Premiere) when played in VLC, the MP4 from MeGUI looks wrong when played in VLC.

Oddly the MeGUI MP4 is also two pixels taller: 720x578. Display resolution is still 720x576.

Both versions look fine in MPC-HC.

Yadif refuses to load. I either get "not an AviSynth 2.5 or 2.6 plugin" or "not an AviSynth 2 C plugin" depending on whether I run LoadPlugin or LoadCPlugin. So I just deleted that, and added "interlaced=true" to the RGB conversion.

601 looks like the Premiere sequence and export, 709 looks like the MeGUI encode. It's SD, so it should be using 601, right?

[manono]

The Yadif doc explains how to load Yadif. It won't autoload. You have to a load it in your script, one of these two:

Must be loaded with Load_Stdcall_plugin("yadif.dll") or LoadCplugin("yadif.dll") (not LoadPlugin!). Do not use autoloading.

If LoadCPlugin doesn't work for you (it's what I use, with a complete path to where the Yadif.dll is saved), try the Load_Stdcall_plugin. I'm also assuming you have a reasonably recent version of AviSynth so you don't have to also load the Avisynth_c.dll.

[SameSelf]

Ugh, color shift problems. My advice is to generate a test pattern that mirrors your source video (interlaced SD DV-AVI?) and use that to vet your entire pipeline one step at a time. That way you know exactly which step is introducing the shift. Otherwise, these sort of things can be insanely difficult to troubleshoot. I would also recommend eliminating the frameserving step. Export from PP as a UYVY AVI and see if that doesn't solve the problem.

Also, are you familiar with how to use the scopes in PP? Scopes are critical to diagnosing these sort of issues because you can never trust your eyes.

[sneaker]

So: Used Advanced Frame Server to frameserve a YUY2 AVI into an AviSynth script which then runs yadifmod.

Yadif refuses to load.

You are confusing me.

[koberulz]

Yadif wouldn't load with either LoadPlugin or LoadCPlugin, but Load_Stdcall_Plugin works now that I've tried it. Yadifmod was loading fine. I've been using the latter, pdr's scripts used the former.

[poisondeathray]

Well if both PP and Megui MP4 files look the same in MPCHC but different in VLC, you at least have a playback inconsistency problem, in addition to other things

If it's SD, yes 601 is correct

Post the megui log file

@sneaker - yadif was just a quick deinterlacer for the preview / diagnosis script. I think he was using yadifmod for the real encode. Eitherway it won't affect colors

[poisondeathray]

Oddly the MeGUI MP4 is also two pixels taller: 720x578. Display resolution is still 720x576.

This might have something to do with it too - some players base their calculations based on width>1024, or height >576 is considered "HD" and gets 709 treatment for conversion to RGB for playback (maybe the values are slightly different) . But why 578 ? How are you determining those values ? What does mediainfo (view=>text) say about it ? And why would height be changed at all ?

post the megui log file

[koberulz]

Tools -> Codec Details in VLC gives a resolution of 720x578 and a display resolution of 720x576. MediaInfo says it's 720x576.

I can't find the log file, it doesn't seem to exist. It's not in the folder with the rest of the log files.

I tried putting both of them on a USB and playing them through my Blu-Ray player, and they look the same. So it seems the issue is with VLC although I have no idea what it is.

The other issue I'm having is I can't get the aspect ratios to match. This seems to indicate I should flag PAR 16:15 and SAR 5:4, but that's way too wide. Both at 16:15 is slightly too narrow. 12:11 and 11:9 is way too wide again.

Not sure if I even need to set both, I started setting PAR when I couldn't figure out a SAR that would work.

[poisondeathray]

The other issue I'm having is I can't get the aspect ratios to match. This seems to indicate I should flag PAR 16:15 and SAR 5:4, but that's way too wide. Both at 16:15 is slightly too narrow. 12:11 and 11:9 is way too wide again.

Not sure if I even need to set both, I started setting PAR when I couldn't figure out a SAR that would work.

With x264, there is only SAR . There is no PAR with MPEG4. It technically only applies to MPEG2. They are actually different names for the same thing . Conceptually you can think of it as the width:height of the pixels . These can have slightly different names, but the equation is

DAR = FAR * SAR

Display Aspect Ratio = Frame Aspect Ratio * Sample Aspect Ratio

FAR is the Frame Aspect Ratio - it can be thought as the dimensions w:h , sometimes it's called the Storage Aspect Ratio (2 "different" SAR's.... I know, confusing. But when dealing with modern codecs like mpeg4-avc , SAR is the Sample Aspect Ratio)




For full frame 720x576 4:3 , you would use --sar 16:15 . This means the full frame is scaled
4/3 = 720/576 * 16/15

For analog transfers where you have pillarbars, you would normally use --sar 12:11 where the inner 704 width is scaled. It's slightly wider
4/3 = 704/576 * 12/11

You might be setting 2 AR's stream and container, that might be averaging or mixing things up . It varies by player. You should really only set the stream AR. That is the most consistent method across hardware and software players.

Or, maybe your specific source has gone through multiple stages and transfers and it doesn't adhere to any set rules. The actual content might have a different AR. You might have to examine known object with your eyes, like a car tire straight on, or a basketball straight on . Then resize the frame until it looks correct and indirectly calculate what it should be

Premiere uses ITU aspect ratio interpretation rules, so the 12:11 , which is the slightly wider 1.09 PAR. But when you frameserve out, the PAR is 1:1 (square pixel), you need to fix it later. People complain because you have areas cut off when using premiere and exporting. But non ITU interpretation means you use the full frame

Some standards and devices only allow specfiic SAR's. For example, SD Blu ray is supposed to use ITU rules. But if this is intended for something like computer playback, you can use whatever you want

[koberulz]

Setting SAR to 12:11 fixed both the aspect ratio and the color shift in VLC.

Still reporting 720x578 though.