QTGMC Script in meGUI

[duffbeer]

I've just started testing QTGMC in meGUI to deinterlace some really bad DVDs that I need to backup.

At the moment I am just trying to use the basics to see if the result is good enough for my use. I am using QTGMC() in the script. Is that correct or do I need to declare the preset within the brackets?
I was of the understanding that the default setting of QTGMC is the "slow" preset and that it carries out some basic noise reduction. Is that automatic if I use QTGMC()?

[poisondeathray]

I've just started testing QTGMC in meGUI to deinterlace some really bad DVDs that I need to backup.

What does "really bad" mean ?

Are you sure they need to be deinterlaced in the first place ?

At the moment I am just trying to use the basics to see if the result is good enough for my use. I am using QTGMC() in the script. Is that correct or do I need to declare the preset within the brackets?
I was of the understanding that the default setting of QTGMC is the "slow" preset and that it carries out some basic noise reduction. Is that automatic if I use QTGMC()?

QTGMC() uses the slow preset by default if you don't specify otherwise. Yes it does have the effect of reducing noise

You have to precede it with the correct field order according to the source ( AssumeTFF() or AssumeBFF() )

[duffbeer]

Yes it is 100% interlaced PAL that I believe has been converted from an interlaced NTSC source. By "really bad" I meant the image quality. I have tried deinterlacing in RipBot and Handbrake but they both give very poor results.

I did a quick first test last night using a 30 sec clip of my source and the result looked very impressive. I just wanted to be sure that my script was actually using QTGMC and not the meGUI deinterlacer. Output file was also 50fps which had much smoother motion. I'm not too sure about the other commands like NNEDI etc so I was going to try and just use a basic script like this:

(I can't remember what the source is, this is just an example)

Source( "x:\yourfile.mkv" )

AssumeTFF()

QTGMC()

Anything else I should know before I spend many hours encoding?

Is there much difference between slow and fast? I've read as much as I can but I cannot decide is slow is really worth the extra encoding time.

[poisondeathray]

Interlaced PAL from interlaced NTSC usually has other problems like field blending that might require other treatment (it depends on how the conversion was done)

"bad" image quality can still mean many different things. Sometimes there are things you can do to subjectively improve it

If you upload a sample with steady movement , someone will take a look at it and give suggestions

[duffbeer]

Not sure if that's permitted. It is a commercially available DVD.

[hello_hello]

The way I understand it, some noise reduction is a side-effect of QTGMC's de-interlacing. From the QTGMC HTML help file:

Noise Bypass / Denoising
The use of multiple temporal smooths means that this script denoises by default. QTGMC can extract some noise/grain from the source at the start, then optionally restore some of it back in again at the end. This allows either denoising, or for the grain/noise from the source to be retained.

I can't say I've experimented with the grain restoration part, but QTGMC's EzDenoise function works fairly well. I'd add a little denoising if the de-interlacing on it's own doesn't remove enough. I've found a little denoising can also help with reducing any mild blocking in the source. Mostly, only low values for the denoising are required. The "extra" denoising, or the denoising preset isn't enabled by default, so you need to specify it along with a denoising strength. Something like:

QTGMC(EzDenoise=1)

Mostly, I don't specify a field order. I add QTGMC to the script, use the preview and step through the frames one at a time. If they're in order then all is well, but if they step backwards, then step forwards, then back again, then forward etc, obviously not progressing smoothly, adding AssumeTFF() should fix it.

A couple of QTGMC tips for you.

It's $@$% slow. As a result, your CPU probably won't work all that hard (quad core or more). My solution is to run 2 encodes at a time. If that's not an option, create a copy of the script and use the AVS Cutter under MeGUI's Tools menu to select start and end frames so each script encodes around half the video. Or add the cuts manually (although I split the encode on a scene change so the AVS Cutter preview is handy) but Trim(0, 20976) at the end of a script will only encode frames zero to 20976, while Trim(20977, 45768) ......well you get the idea. Trim(675, 0) would encode from frame 675 till the end.
If you split encodes, make sure --stitchable is checked in the x264 encoder configuration to prevent any tears. Then you should have no trouble appending the encoded video with MKVMergeGUI and saving it as an MKV. If you want MP4 as the output format rather than MKV...... well you're on you're own there.

QTGMC has a progressive mode, so even if you don't need to de-interlace, it can do wonders for stabilising the picture and removing noise. Progressive mode looks like this:

QTGMC(InputType=1)

Progressive mode with some noise removal looks like this:

QTGMC(InputType=1, EzDenoise=1.5)

You'll probably find EzDenoise values below 2 hardly blur. At 2 or higher you're into blurring territory, but that's what noise removal does. I sometimes use a fast(er) preset because any noise that isn't removed tends to be "stabilised", so it's not really noise any more and doesn't look natural. Faster presets don't stabilise as much, so any remaining noise is more noise-like.

Something like this, but whatever looks good to you:

QTGMC(InputType=1, Preset="Medium", EzDenoise=2)

And finally..... read the explanation under "why should I use it" and add the following to the end of a de-noised script if you have banding issues when encoding. If the clip is still a bit noisy, you won't need it.
http://forum.doom9.org/showthread.php?p=1386559

gradfun3()

Oh and if you downloaded the QTGMC 32 bit plugins package, or one of the QTGMC plugin packages, and any of the required plugins for dither are duplicates of a QTGMC plugin, use the dither version,
and you're probably using mt_masktools-2.5.dll or mt_masktools-2.6.dll
Give it the flick and download the appropriate flavour of this version. http://avisynth.nl/index.php/MaskTools2

[duffbeer]

Thanks for all the info hello_hello

I have been doing my homework before I started playing around with QTGMC but it gets really complicated really quickly. I have many hours of video to encode so I don't have too much time to mess around testing.

I'm not 100% sure what your last comment means. I did download the 32 bit plugins package but I don't understand "any of the required plugins for dither are duplicates of a QTGMC plugin, use the dither version".
I am using masktools-2.5.dll (not the MT version) is the MaskTools2 that you suggest faster or does it give some other benefit?

[poisondeathray]

Not sure if that's permitted. It is a commercially available DVD.

Not sure about UK laws, but samples are permitted in Canada/USA under fair use for educational purposes

The genre/content can often indicate what the DVD is in generic terms. For example, a theatrical movie, drama TV series etc.. will almost never have interlaced content . Something like a sports DVD would probably have interlaced content

[hello_hello]

I'm not 100% sure what your last comment means. I did download the 32 bit plugins package but I don't understand "any of the required plugins for dither are duplicates of a QTGMC plugin, use the dither version".

Many of the AVISynth scripts such as QTGMC use the same third partly plugins (dlls), or they have several plugins in common. The dither-1.26.5.zip file I linked to contains a script and plugins. Some of them will possibly be the same as the plugins used by QTGMC. The dither versions (if they're different) are likely to be newer.
There's links to 16 bit versions of dfttest 1.9.4 and MVTools 2.6.0.5, under the Dither link. I'm pretty sure both plugins are also used by QTGMC. If you want to use Dither, you'll need the 16 bit versions. Just replace the old ones you copied from the QTGMC zip file with the newer ones. QTGMC can still use them. Dither requires Masktools 2a48. It's likely to be the same version as supplied with QTGMC, but if not, use the Dither version.
And those files you had to copy to a Windows System folder..... I think there's 16 bit versions too (I don't recall for certain).

I am using masktools-2.5.dll (not the MT version) is the MaskTools2 that you suggest faster or does it give some other benefit?

I can't remember which versions I played with, but some cause QTGMC to slow to a crawl if the video width isn't mod16. The version I linked to is fine with any width. It's a tad faster than the rest anyway.

Keeping plugins organised can do your head in as there's lots of versions floating around.

If you're using the portable version of Avisynth supplied with MeGUI, it's version 2.6, so I'm pretty sure you should be using masktools-2.6.dll, not masktools-2.5.dll
The versions I linked to are named differently again (the Avisynth 2.6 version is just named masktools2.dll) but it's obvious which one to download according to the AVISynth version you're using from the links on the page.
If you have Avisynth installed and you're using it, switch MeGUI to using the portable version. It's a tad faster and plays better with MeGUI (another story). If you have Avisynth installed, it should be the latest 2.6 version. Then the scripts MeGUI creates will work with either Avisynth. ie You can use the portable Avisynth with MeGUI, and if you open a script with another program (such as MPC-HC) it'll use the installed version and you won't get plugin errors.

Anyway, if you have QTGMC working there's no need to swap out required plugins for newer versions right this minute, but if you want to use Dither at some stage, I'd replace any common plugins with the Dither versions. If you have plugins in the "installed" AVISynth plugins folder so they'll auto-load when AVISynth runs (they'll also auto-load from there if the portable version of AVISynth is used), multiple versions of a plugin can end in tears.

If I'm experimenting with plugins, I make a backup copy of the AVISynth plugins folder first, that way if it all goes south it's easy to go back to where you started.

Does anyone know if there's a forum record for the number of times the word "version" is used in a post, because I must be close to it with this one.

[duffbeer]

Do I need to include "ConvertToYV12" in my script?

[LMotlow]

We have no sample of your video, but you should know by now that DVD is almost always YV12 anyway. If as you said earlier the video looks like NTSC->PAL or similar, it's likely that QTGMC isn't the right tool. If it's film-based and uses telecine or field blending, then you have different problems. This forum has thousands of short video samples made from retail DVD's by people who personally own those recordings. 10 seconds of cut video from those DVD's for non-profit educational use is legitimate -- we're not asking for 4 GB of an entire DVD video.

Without a sample to go by, anything anyone tells you about using QTGMC or QTGMC by itself for this work could be in error. Remarks made about QTGMC settings are accurate as far as they go, but are speculative and might be inappropriate for the video at hand. The same settings can't always be used for every video source. In other words, it seems very likely that you're wasting your time , and getting unpredictable results.

Just my 2 pence worth ($0.03 U.S.D.)

[duffbeer]

Thanks for your advice LMotlow. I will extract a couple of samples when I get home and upload them - hopefully someone will be kind enough to take a look at them and let me know what's best.

As I said earlier, I have quite a few MKV files to process and I think I'm going to start with some WWF and WWE PPVs. They all appear to be interlaced and I believe that is to be expected because they were originally TV shows rather than film. The early ones (pre 2002) are NTSC 29.97fps and the later ones are PAL 25fps (don't ask me why but Silvervision changed the way they produced them).

Would I be correct in my assumption that the PAL titles would have been converted from NTSC 29.97?

[LMotlow]

MKVs are certainly allowed. But I thought you began by writing:

I've just started testing QTGMC in meGUI to deinterlace some really bad DVDs that I need to backup.

Are these DVD's re-encoded as mkv, or did they begin life as mkv's? We would prefer unpocessed originals.

[duffbeer]

Sorry for the confusion. I have used MakeMKV to rip the main title from the DVD discs that I own. They have not been re-encoded - I just find it easier to work with the sources in unencrypted MKV format. Is that a problem?

[manono]

I just find it easier to work with the sources in unencrypted MKV format.

Nonsense. It's way easier to work with them after indexing the VOBs first using DGIndex followed by using MPEG2Source on them together with the DGDecode.dll. It's all explained in the files included in the DGMPEGDec package. And most of us (me included) would much prefer the samples be direct from the DVD and not repackaged as an MKV. You can use DGIndex to cut out M2Vs for upload here. 10 seconds with steady movement will be plenty. And, you're right, if the source is wrestling videos then they most likely really are interlaced.

[hello_hello]

Sorry for the confusion. I have used MakeMKV to rip the main title from the DVD discs that I own. They have not been re-encoded - I just find it easier to work with the sources in unencrypted MKV format. Is that a problem?

I've had issues with mpeg2 video in MKVs before, when FFMS2 was used by MeGUI for indexing (although I can't specifically remember what they were). L-Smash might be better, but as a general rule for MKVs containing mpeg2 video I'd feel better remuxing them as ts files with tsmuxer first, then getting MeGUI to open and index the ts files with DGIndex. But if you've got a choice, simply indexing the original vob files with DGIndex would save all that hassle.

Ripping with MakeMKV might be convenient in respect to having individual MKVs ready to convert, but a similar thing can be done when ripping to standard DVD vob files. I use DVDShrink myself, and it's re-author function to "prepare" the ripped files for encoding (with DVDShrink's target output size set to something large so it doesn't try to "shrink" as it rips. That way you end up with a set of vob files for the movie, or a set per episode etc. For newer copy protections DVDShrink might require AnyDVD running in the background.
Anyway.... if you do have odd problems, and I'm not saying you will, but if you do, try remuxing the problem MKV as a TS file and opening and indexing it instead to see if that fixes it. And if MeGUI is using ffms2 to index mpeg2 in MKVs, keep your eye on the frame rate conversion it adds to the script. Maybe that was the problem, it wasn't always correct. I can't remember....

[duffbeer]

I've successfully managed to encode 3 MKV files so far. All seem to be OK - it took me a few test encodes to figure out the various resize and anamorphic options.
For some reason, if I choose not to resize or crop and just encode the file "as is" the output is horizontally stretched. Weird but I've figured out a combination that crops the black bars from the sides and maintains the 4:3 ratio.

You're right about it being slow - I get around 11fps with default QTGMC settings and x264 on slow so the whole encode takes around 12hrs.

hello_hello - I've checked the scripts and they don't have any frame rate conversion lines - the file I end up with is either 50fps if the source is PAL or 60fps if the source is NTSC. This is what I was expecting due to QTGMC doubling the frame rate when it deinterlaces.

Why do I get 60fps from a 29.970 source? Shouldn't it be 59.94fps?

[hello_hello]

I've successfully managed to encode 3 MKV files so far. All seem to be OK - it took me a few test encodes to figure out the various resize and anamorphic options.
For some reason, if I choose not to resize or crop and just encode the file "as is" the output is horizontally stretched. Weird but I've figured out a combination that crops the black bars from the sides and maintains the 4:3 ratio.

The original video is 720x480 (NTSC) with a 4:3 aspect ratio. 720/480 = 1.5:1 which obviously isn't 4:3 (or 16:9), so it gets stretched to the correct aspect ratio on playback. When you enable anamorphic encoding, MeGUI sets the correct aspect ratio so the encoded video does the same on playback (although it'll still look stretched or squished in the script creator preview). Not all hardware players support aspect ratios in MKVs or MP4s, so if you use one, check your anamorphic encodes display correctly.

Enabling resizing without anamorphic encoding resizes the video to square pixels instead. There's an option in the script creator's profile configuration to enable resizing "up" which will let you resize (for example) a PAL 16:9 DVD to something like 1024x576 instead of the traditional 720x400 etc. How you do it is personal preference.

If you crop, the remaining video won't have the same aspect ratio any more. With anamorphic encoding enabled, check the DAR values in the script tab as you change the cropping. They should change accordingly. Often I'll also crop some picture from the top and bottom if need be until I'm back to 4:3, but keep in mind....

Officially DVDs only use 704 pixels of the width for picture, so for an NTSC 4:3 DVD, 704x480 gives you a 4:3 aspect ratio. If you resize the whole 720x480 frame to the correct aspect ratio, it therefore needs to be a bit wider than 4:3 (that's what the ITU input aspect ratios in the script creator do).
Most newer 16:9 DVDs have picture covering the whole 720 width and probably should be resized to exactly 16:9 as the entire 720x480 resolution is 16:9. In which case you'd change the input aspect ratio in the script creator to exactly 16:9 and crop and resize from there. There's no way to know for sure but as a general rule of thumb.... lots of black each side, ITU input aspect ratio, no black bars each side (or just a pixel or two), straight 16:9 input aspect ratio. I think pretty much all 4:3 DVDs are ITU 4:3

I explain all that, because when you ripped with MakeMKV it probably set a straight 4:3 aspect ratio, so MeGUI might just see the input files as exactly 4:3 rather than default to one of the ITU input aspect ratios. I can't remember for sure, but if it does, you might want to change the input display aspect ratio in the script creator to "ITU 4:3" and crop and resize etc from there.

hello_hello - I've checked the scripts and they don't have any frame rate conversion lines - the file I end up with is either 50fps if the source is PAL or 60fps if the source is NTSC. This is what I was expecting due to QTGMC doubling the frame rate when it deinterlaces.

Why do I get 60fps from a 29.970 source? Shouldn't it be 59.94fps?

How are you checking the frame rate? But yes, for NTSC I'm sure the output should be 59.94.

If MeGUI used FFMS2 for indexing, the frame rate conversion it adds to the script looks like this:

FFVideoSource("E:\video.mkv", fpsnum=30000, fpsden=1001, threads=1)

That'd give you 29.970 (30000/1001) so QTGMC should output 59.940

MeGUI adds the frame rate stuff automatically when opening video with FFVideoSource. It does the same for DirectShowSource (in a different way).
If there's anything like that in the script, check it's correct, or maybe check for sure the MKV's you're converting were muxed using the correct frame rate in the first place, although I can't imagine why they wouldn't be. I'm not sure what's going on there.

[duffbeer]

Thanks - I'll double check the FFVideoSource line when I get home.

I was using Media Info to check the frame rate - is there a better way?

[hello_hello]

Probably not. The MediaInfo GUI does do some rounding at times (ie display aspect ratios), but for frame rates I think it's accurate.

Maybe to confirm, open a file with MPC-HC and use the File/Properties menu. The info under the Details tab should be accurate. There's also a MediaInfo tab but it just displays the same thing as the MediaInfo GUI.

[duffbeer]

Good idea! Why didn't I think of that?
MPC-HC and VLC both report the file as 59.946383 or something like that so MediaInfo is rounding it up to 60fps. Quite annoying really - I thought MediaInfo was the best way to check the stats of my encoded files but maybe this proves that it isn't?

Thanks for your help hello_hello. It's really good of you to respond to my questions. People like you and poisondeathray are constantly helping people and I have learned a lot from reading your replies to other threads too. Hopefully this thread will help someone else in the future.

[hello_hello]

59.946383 is still a tad off though. I don't know why that'd be happening but I'd probably recheck the source MKVs and the script etc. Not that it's anything to get overly excited about, but it'd be interesting to know why it's a little off.

Aside from the rounding the GUI does, MediaInfo doesn't always display everything accurately because sometimes it's just reporting what's written to the file. It's a handy tool, but don't take what it says as gospel.

For checking aspect ratios, I always use the MPC-HC File/Properties menu. If the resolution and the aspect ratio are the same, it'll just display the resolution. If they're different (anamorphic) it'll display the resolution and aspect ratio, far more accurately than MediaInfo. (Actually sometimes MPC-HC would display the aspect ratio wrong by a very, very tiny amount. I discovered that a while back and reported it, and it's been fixed, but I'm not sure if there's been a new "stable" release since. It was just some sort of rounding error and very small, but I thought I'd mention it given my recommendation to check aspect ratios that way. MPC-BE didn't have the same problem).

I'm happy to have been of help.

[duffbeer]

hello_hello - you were right about potential problems with MPEG2 MKV sources - after checking my encoded files I noticed that there was a glitched frame every couple of minutes where the image would virtually white out.
I have re-ripped my discs and this time I kept the original VOB structure, indexed with DGIndex and re-encoded the files and everything looks good.

I have encoded a few PAL discs - QTGMC slow preset doubles the frame rate to 50fps, the image looks good and motion is smooth.

When I encode the NTSC discs, the output has a judder roughly every second (from eyeballing it). I am using the same settings as the PAL encodes and the frame rate ends up at 59.94156fps. When I check the source files in VLC it says the frame rate is 29.970030fps. I assume this is the reason for the judder but I can't understand why the frame rates are both off.

Is there a way to force the frame rate or would that make it even worse? Maybe there is some other filter that I need to use?

I guess you are going to want some sample files but I am struggling to extract the same section from source VOBs and the encoded MKV.

Any help will be much appreciated.

[manono]

Your encoded MKV isn't needed. Just cut a 10-second piece from the VOB using DGIndex, a section with steady motion, and then upload the resulting M2V.

[BÌG•bµdd]

if u want some help then why are you not posting a required sample?
DGINdex can be found in somewher in this location on your pc or laptop

"C: program Files/Megui/tools/DGindex"
"C: program Files(x86)/Megui/tools/DGindex"

or
u can try mpeg2cutt that can do the job pretty well .

[hello_hello]

I guess you are going to want some sample files but I am struggling to extract the same section from source VOBs and the encoded MKV.

Any help will be much appreciated.

As others have suggested you can use DGIndex. Or try TSMuxer. It'll open both VOB files and MKVs and the "Split & cut" tab lets you specify start and end points. It'll save the output as TS or M2TS files but that should be fine.
It might also pay to attach the entire MeGUI log file for an encode where the result shows judder. If you open the script with MPC-HC what frame rate does it report?

[duffbeer]

When I open the AVS file in MPC-HC and select properties from the file menu it says 59.94fps but I cannot see if there is a judder because QTGMC decodes slower than real time.

I thought the PAL sources would be tricky and the NTSC would be simpler but it seems the opposite id true!

I have extracted and attached a clip and the log file from MeGUI as requested. I would be very grateful if someone could take a look and let me know what I'm doing wrong.

[jagabo]

When I open the AVS file in MPC-HC and select properties from the file menu it says 59.94fps but I cannot see if there is a judder because QTGMC decodes slower than real time.

So just encode a short segment and play the resulting video.

Your sample is interlaced NTSC video and results in a 59.94 fps video that plays smoothly after QTGMC.

[duffbeer]

Thanks for your post jagabo but it doesn't help me at all.

I have encoded a sample and the entire video but the playback is not smooth. I am using AssumeTFF() followed by QTGMC() in my AVI Synth script. I'm not sure why it does not produce a smooth 59.94fps video.

The sample attached is from a another NTSC source that shows the judder very clearly. All 29.970fps source files produce the same result when deinterlaced with QTGMC.

[jagabo]

Your log file indicates a double frame rate file was produced. What does MediaInfo say about the file you created? 29.97 fps or 59.94 fps? Does this file play smoothly?