VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 12 of 12
Thread
  1. Everything I say is false koberulz's Avatar
    Join Date
    Oct 2006
    Location
    Australia
    Search Comp PM
    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...
    Quote Quote  
  2. 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

    Code:
    AVISource()
    Yadif(1,1)
    ConvertToRGB24(matrix="rec709")
    or

    Code:
    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
    Last edited by poisondeathray; 9th Feb 2017 at 13:55.
    Quote Quote  
  3. Everything I say is false koberulz's Avatar
    Join Date
    Oct 2006
    Location
    Australia
    Search Comp PM
    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?
    Quote Quote  
  4. 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.
    Quote Quote  
  5. 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.
    Quote Quote  
  6. Originally Posted by koberulz View Post
    So: Used Advanced Frame Server to frameserve a YUY2 AVI into an AviSynth script which then runs yadifmod.
    Originally Posted by koberulz View Post
    Yadif refuses to load.
    You are confusing me.
    Quote Quote  
  7. Everything I say is false koberulz's Avatar
    Join Date
    Oct 2006
    Location
    Australia
    Search Comp PM
    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.
    Quote Quote  
  8. 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
    Quote Quote  
  9. Originally Posted by koberulz View Post
    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
    Quote Quote  
  10. Everything I say is false koberulz's Avatar
    Join Date
    Oct 2006
    Location
    Australia
    Search Comp PM
    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.
    Quote Quote  
  11. Originally Posted by koberulz View Post

    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
    Last edited by poisondeathray; 10th Feb 2017 at 00:40.
    Quote Quote  
  12. Everything I say is false koberulz's Avatar
    Join Date
    Oct 2006
    Location
    Australia
    Search Comp PM
    Setting SAR to 12:11 fixed both the aspect ratio and the color shift in VLC.

    Still reporting 720x578 though.
    Quote Quote  



Similar Threads