QTGMC Script in meGUI

[poisondeathray]

It doesn't prove or disprove anything. If ripbot works for you , then use it. It accepts avs scripts. It's just a GUI like megui. They both use the same tools.



But if you want to figure out what is going on, use the process of elimination

Don't use QTGMC for now, since it has a dozen dependencies. Bob() is the simplest deinterlacer . Don't encode anything for now. You don't want other variables that might be affecting your results. You need to go step by step.

Demux "source.mkv" with mkvextract. It will give you a mpg file. Index that with the file indexer (It will use DGIndex)

The script will be

MPEG2Source()
AssumeTFF()
Bob()

Open that in vdub and go frame by frame. i.e. preview what is being frameserved to the encoder. If something is wrong (e.g. frames out of order) , you know already at that point, that something is wrong with decoding . There is no need to go into QTMGC or x264 settings, or muxing, or anything downstream. Already you have some different results than everyone else. So you would have to look at the specific dgdecode.dll version, and perhaps system stability issues, maybe corrupt ram etc....

On the other hand, if the sequence is in order, no problems (there is a frame out of order at the very end, as reported by hello_hello, but it might be from the way it was cut), then you carry on to the next step. Changing 10 different things at a time won't tell you much. You need to go step by step

[hello_hello]

I asked about the frame rate change caused by re-muxing at doom9.

http://forum.doom9.org/showthread.php?p=1709837#post1709837
MKVMerge uses a time base of 1000000ns, which amounts to an accuracy of 1ms. X264 and quite a few other programs use a time base of 50000ns, which gives a far more accurate representation of display time. Apparently 1ms isn't accurate enough for whatever frame rate heuristic MediaInfo uses to detect the frame rate at 60/1.001 fps. Since each frame at that frame rate has a shorter duration than in most other standard frame rates small inaccuracies in the time codes have a greater effect.

That's the theory anyway. As I normally work with PAL it wouldn't be something I'd see (frames have an exact duration of 20ms at 50fps), but it appears the frame rate difference reported by MediaInfo should be ignored.

I'd be pretty confident the judder isn't being caused by MeGUI. I know it's too slow with QTGMC in a script but with Yadif (and Bob) you could open the script with MPC-HC. If there's judder it can't be MeGUI's fault. I can't imagine a circumstance where MPC-HC could display without judder but it happens when MeGUI is encoding. Can you display a script in MPC-HC okay?