QTGMC Script in meGUI

[duffbeer]

Please see attached file in my previous post. MediaInfo reports the encoded files as 60fps but VLC reports 59.94156fps.

Interestingly, if I add SelectEven() after QTGMC() it produces a file with 29.970628fps (according to VLC) but the first test file was reported as 29.97030. Is this normal for NTSC? I know it's very close to 29.970 but it is off a little so maybe when the frame rate is doubled it exaggerates the effect.

It's hard to tell if your encode is any smoother than mine because it's such a short sample. Could you try encoding the file in this post and comparing it to the encode,mkv attachment in my post above?

[jagabo]

It looks to me like you're having a problem decoding your source, not with QTGMC or encoding. Occasionally there are some out of order frames (creating backward steps in the motion) and what looks like the result of AviSynth's Subtract() filter (causing flickering):



Attached is what I get with this AviSynth script:

ffVideoSource("source.mkv") 
AssumeTFF()
QTGMC()

encoded with the x264 command line encoder. No jerks, no flashes.

Sorry, I haven't read the entire thread. What source filter are you using? Are you still encoding with megui?

[poisondeathray]

Those decoding errors are from ffms2 and mpeg2 video in mkv
Extract the elementary stream and use dgindex


I don't see anything wrong with the megui logfile, or the source. If it's "not smooth" , maybe you should upload your encoded file. It might just be a playback issue

[BÌG•bµdd]

u can use QTGMC like this i think if u just want the same fps.

QTGMC("settings",Inputtype=2) 
QTGMC("settings",fpsdivisor=2) 

1st use on progressive
2nd use on interlaced

[hello_hello]

There appears to be out of order frames in your encoded sample. It's fairly obvious near the end, if you open the video in MPC-HC and step through the frames one at a time it's not hard to see. I'd try removing AssumeTFF() from the script. The only time I use AssumeTFF() with QTGMC is when there is problems with frames being out of order, other wise maybe it can cause it.

There is something a little odd with the frame rate of your encoded sample. MPC-HC reports it as 59.940fps but MediaInfo reports two frame rates, one being 60fps and also an "original frame rate" of 59.940fps. When I open the encoded sample with MeGUI it sees the frame rate as 60fps. I'm not sure why that's happening. It didn't for me when I encoded the "extract.demuxed.m2v" sample. I suspect it's to do with the muxing but I'll have a better look at the log file later and report back if I see anything odd (I've got to do some real world stuff at the moment) or someone else might be able to help.

For the record, when I re-encoded "extract.demuxed.m2v" with QTGMC it encoded fine with or without AssumeTFF() in the script. Does that particular sample encode okay for you (no judder)?

Edit: Sorry, I appear to have missed page two of this thread before posting, so I'm a bit behind. Here's what MediaInfo displays for me for "encode.mkv" from post #29. I've no idea where VLC is getting the frame rate it's reporting, but I'd ignore it. I think the issue is why MediaInfo is reporting two frame rates and it possibly indicates the stream frame rate and the container frame rate are different.

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24s 900ms
Bit rate : 3 277 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Original display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 60.000 fps
Original frame rate : 59.940 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.158
Stream size : 9.73 MiB (98%)

[hello_hello]

I can duplicate the dual frame rate issue above by remuxing MeGUI's output file while specifying the frame rate in the command line as MeGUI does.

"--default-duration" "0:60000/1001p"

So even though I'm specifying 59.940 there's a 60fps frame rate being seen somewhere by MediaInfo.

If I remux MeGUI's output file without specifying a frame rate, it gets even more odd.

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 14s 579ms
Bit rate : 4 789 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 59.880 fps
Original frame rate : 59.940 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.231
Stream size : 8.32 MiB (98%)

And extra oddness. This is what MediaInfo displays for a the file above before muxing (MeGUI's output MKV, x264 encoder writing directly to MKV):

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 14s 581ms
Bit rate : 4 786 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 59.940 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.231
Stream size : 8.32 MiB (98%)
Writing library : x264 core 144 r2525 40bb568

This time, re-muxing with GDSMux (no frame rate specified):

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 14s 579ms
Bit rate : 4 786 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 59.880 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.231
Stream size : 8.32 MiB (98%)
Writing library : x264 core 144 r2525 40bb568

I'll play around some more later, but anyone with any clever ideas? So far it only seems to be happening when MeGUI's output frame rate is 59.940fps and I'm remuxing the MKVs written by the x264 encoder. If the output is 29.970fps it appears to remux with the correct frame rate. I'm using using MKVMerge 7.6.0 while MeGUI is still using MKVMergeGUI 7.0.0

So there's probably two separate problems. I think the judder is probably due to AssumeTFF() and there's the frame rate oddness when remuxing that I don't understand.

[jagabo]

The judder isn't due to AssumeTFF(). I used AssumeTFF() in my script and the encoding has no problems. The out of order frames are almost certainly from the source input filter. As poisondeathray indicated, some source filters (ffms2 and DgMpegDec for example -- though neither is giving me problems with his sample, even when using an old version of megui rather than x264 cli) sometimes have problems with MPEG2 video in MKV. That is also probably the cause of the grey frames. He should try remuxing into an MPG program stream container. Or maybe demux to an elementary stream. Then convert.

I just tried my script with a ~6 month old version of megui. No problems.

[duffbeer]

Thanks for all the replies.

Just to be clear with you all, I have tried encoding from an MKV file produced by MakemKV and it caused the image problems I mentioned earlier in the thread. I have also re-ripped the discs to maintain the original VOB structure and this was indexed with DGIndex through MeGUI but this produces a file with exactly the same judder issue.

So it doesn't seem to be the indexer causing the problem?

[duffbeer]

Those decoding errors are from ffms2 and mpeg2 video in mkv
Extract the elementary stream and use dgindex


I don't see anything wrong with the megui logfile, or the source. If it's "not smooth" , maybe you should upload your encoded file. It might just be a playback issue

I'm not using ffms2 and the source is not an MKV. I am using original VOB structure and DGIndex.

[hello_hello]

The judder isn't due to AssumeTFF(). I used AssumeTFF() in my script and the encoding has no problems. The out of order frames are almost certainly from the source input filter.

Yeah, I hadn't tried the sample in post #31. It requires AssumeTFF(), but when I indexed the MKV with ffms2 it looked fine with QTGMC and when I remuxed it as a TS file and indexed with DGIndex it was also fine. No judder. So I don't know what's going on there.

[duffbeer]

So is DGIndex causing my problems? I thought that was supposed to be the best way to index a DVD?

[hello_hello]

duffbeer,
The sample you posted in post #31, if you re-encode it on it's own (just that sample) is it okay? It's okay for me with QTGMC.

The frame rate oldness is something else again though I don't know what's going on there. It's the first time I've seen anything like that happen when muxing. Unless someone else has a clever idea, I might have to ask about it in the MKVMerge thread at doom9, unless you're a member there and want to ask yourself. I don't know why odd things seem to happen to the frame rate displayed by MediaInfo after muxing.

[hello_hello]

So is DGIndex causing my problems? I thought that was supposed to be the best way to index a DVD?

No, you may have misread my post. DGIndex and ffms2 were both fine for me with your sample from post #31.

[duffbeer]

But they don't work for me. This is really frustrating. PAL sources are perfect it's just these stupid NTSC discs that are causing me grief.

The sample in post 31 is the source and the file in post 29 is the encoded output. Same result if I encode from VOB source with DGIndex or MKV source with ffms2 index.

[hello_hello]

This is the part I don't understand at all. The output file according to MediaInfo after re-encoding the sample from post #31.

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24s 892ms
Bit rate : 2 450 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 59.940 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.118
Stream size : 7.27 MiB (98%)
Writing library : x264 core 144 r2525 40bb568


After opening it with MKVMergeGUI and remuxing it without specifying a frame rate it should look the same, but instead it looks like this:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24s 900ms
Bit rate : 2 452 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 59.880 fps
Original frame rate : 59.940 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.118
Stream size : 7.28 MiB (98%)
Writing library : x264 core 144 r2525 40bb568

If nobody comes up with any clever ideas as to why, I can ask about it in the MKVToolNix thread over as doom9.

[duffbeer]

Are we sure this is a muxing problem? Jagabo's post #32 seems to suggest that it's a decoding problem.

[hello_hello]

But they don't work for me. This is really frustrating. PAL sources are perfect it's just these stupid NTSC discs that are causing me grief.

I guess it could be something odd going on with a particular plugin used by QTGMC. If it is though, it'd be a new problem to me, but I'll put all the plugins I use with QTGMC into a zip file a little later and upload them. If you're using anything different, maybe try swapping them to see what happens. I don't know what else to try. In the mean time, which version of QTGMC are you using? Maybe give this one a spin.

[hello_hello]

Are we sure this is a muxing problem? Jagabo's post #32 seems to suggest that it's a decoding problem.

The judder is probably a decoding problem (unless it's a very unusual QTGMC issue). The frame rate being slightly off probably happens when muxing. Try adding a video encoding job to the queue on it's own with the output as MKV (not MP4 or RAWAVC). Check the output MKV with MediaInfo.

Under external program configuration in MeGUI's settings, you might need to uncheck "x264/x265 use external muxer" for the encoder output to be written directly to an MKV file. That's what I'm doing. The output MKV shows the correct frame rate. After muxing, not so much. I've never seen that happen before.

[duffbeer]

So after you mux the file and the frame rate shows incorrectly, does it play smoothly or do you get the same playback as my file in post 29?

Any idea what I can do to resolve the decoding problem?

[hello_hello]

So after you mux the file and the frame rate shows incorrectly, does it play smoothly or do you get the same playback as my file in post 29?

It plays smoothly, which I why I think they're two separate problems. To be honest, I'm not really sure the frame rate problem is a problem, and as long as the audio stays in sync then it probably isn't, but it's still odd and I wouldn't mind trying to work out what's happening. It doesn't appear to be due to anything MeGUI is doing wrong though. I'll ask at doom9 later. Here's my re-encode of your sample after it's been remuxed (don't worry about the aspect ratio).

[hello_hello]

So after you mux the file and the frame rate shows incorrectly, does it play smoothly or do you get the same playback as my file in post 29?

Any idea what I can do to resolve the decoding problem?

Well if it displays okay without any de-interlacing then it's probably the de-interlacing and not the decoding. You could try without de-interlacing, with MeGUI's Yadif (with Bob) and then again with QTGMC to see if the problem suddenly appears or whether it's there from the get-go.

[duffbeer]

So what would cause the decoding issue? Why does it happen with both DGIndex and ffms2?

Any idea how I can narrow it down? This is really irritating me!

Thanks for all your help so far by the way!!

[hello_hello]

I just checked both the samples jagabo uploaded (#30 & #32). They're both 59.940 according to MediaInfo. Until I remux them and then they're both 59.880.
That's what's happening for me, so at least I know I'm not producing odd files, but I don't know why it's happening.

[jagabo]

The samples I posted were made with the x264 cli encoder -- using its internal mkv muxer.

[jagabo]

Try using a different smart bob. Yadif(mode=1, order=1) for example.

Try using ffVideoSource("filename.mpg", seekmode=0) or ffVideoSource("filename.mpg", seekmode=0, fpsnum=30000, fpsden=1001).

[hello_hello]

The samples I posted were made with the x264 cli encoder -- using its internal mkv muxer.

Yeah that's what I've been doing, but remux them with MKVMerge and recheck the frame rate. It's very odd.

[poisondeathray]

There are 3 different issues . 1 & 2 are irrelevant to duffbeer

1) the grey screen problem from jagabo's example is decoding issue with ffms2 and mpeg2 in mkv

2) the "fps" off issue from hello_hello is a mkvmerge muxing issue, and won't cause the problems seen in his encode

3) the main issue is his encode has misorded frames. I didn't see it at first but the posted his encode in post 29



@ duffbeer. Take your actual cut sample, use mkvextract, then put that into megui and try again. There is something going on that is different in your setup . I cannot reproduce what you have on your cut sample "source.mkv". There might be differences in the way you cut the sample and your original VOB

To narrow down the issue, go step by step with your avs script. First comment out QTGMC, then preview the source filter only, go frame by frame in vdub or avspmod or megui preview. Then start adding back other filters

[duffbeer]

I have done a whole bunch of test encodes with different settings and I was prepared to write a long post detailing exactly what I did with each file. The short answer is - it judders. It judders no matter what I do.

I tried internal AVISynth and external AVISynth. I tried with QTMC, QTGMC and SelectEven, Yadif, Yadif Bob, DGIndex, L-Smash indexer, DirectShowSource.

I just don't know what else to do. Maybe MeGUI is just not very good - is there some better GUI for using QTGMC?

I still keep coming back to the same question in my mind, why does it encode PAL content perfectly but not NTSC?

[poisondeathray]

It has nothing to do with Megui . Megui is just a front end. It's using the same tools "in the background" that almost every other GUI uses. If you have a problem here, chances are you will have a problem with the other GUIs that can run QTGMC.

You have to go step by step to find out where the problem is

Start with the exact same sample you uploaded "sample.mkv". So everyone is on the same page and can follow along. Start with the source filter and go step by step adding back in filters one by one if the prevous step is ok. Process of elimination

Maybe your PAL encodes have other problems that you didn't identify yet ?

[duffbeer]

Sorry but I really don't understand what you're asking me to do. My AVISynth script is very simple - I only add AssumeTFF() and QTGMC().

I have done my best to narrow it down by carrying out all the test encodes mentioned above but nothing seems to work with an NTSC source. I have doubled checked my PAL encodes and they are spot on.

I use RipBot264 with both NTSC and PAL sources and I've never had a problem so what does that prove?