Feeling Lost with Interlaced Video

[Downgraded286]

What sort of video sample should I upload? Unprocessed video, or after QTGMC? Should I compress it with Handbrake (no filters) first?

[jagabo]

A sample of the source. A clip with moderate motion, including a medium speed panning shot.

[Downgraded286]

Well, here's some sample clips. The first one shows what I was talking about, and the second one has some panning, though it doesn't show the blurring as well in the finished result. I did encode with Handbrake to split the video and drop the file size, but I didn't use any filters or anything.

I tried modifying my QTGMC script by dropping the preset to Slower (Very Slow and Placebo don't work, error complains about some missing filter), and removing SelectEven() and TDecimate(). This was recommended earlier as a better quality method, and though it did seem to improve the motion smoothness, it didn't do much about the blending artifacts.

[jagabo]

Those files contain interlaced frames but they are encoded progressive. Is that really your source or have you re-compressed them? I thought you were working with the original DVDs? If so, use dgindex or mpg2cut2 to make your samples, that won't re-encode them. Upload the resulting MPG or M2V files.

If those are really your sources they already have blending artifacts.

And a panning shot with more detail in the background would have been better.

[Downgraded286]

I am working with the original DVDs. The previous samples, as mentioned, were run through Handbrake to split the video and cut down filesize. As per your suggestion, here is an unprocessed sample I made with dgindex:

[hello_hello]

With NTSC 720x480 for DAR 16:9, the SAR is 40:33.
NTSC 720x480, 4:3 DAR, SAR is 10:11.

I'd be willing to bet by far the majority of NTSC 4:3 DVDs have a 10:11 PAR, and by far the majority of NTSC 16:9 DVDs have a 32:27 PAR.

I haven't been able to compare a lot of 16:9 NTSC DVDs, but I've compared many 16:9 PAL DVDs with a 1080p/720p square pixel version of the same video and they're mostly 64:45, not 16:11.
Although I strongly suspect, without yet being able to confirm it, 16:9 PAL DVDs containing BBC video are the exception to the rule. I think they mostly use mpeg4 PARs, whether the video width is 720 or 704.

[hello_hello]

I am working with the original DVDs. The previous samples, as mentioned, were run through Handbrake to split the video and cut down filesize. As per your suggestion, here is an unprocessed sample I made with dgindex:

QTGMC does tend to do horrible things to animation, as per your screenshot link in post #55. It does produce similar artefacts when processing "video" on occasion, but not as severe, however I've seen similar artefacts where an object is moving over a large flat area (ie an aeroplane moving quickly across a blue sky).

I'm not sure if I understand why this works, but it seems to. Any de-interlacing I tried left a shimmering/bobbing effect to some degree. TFM doesn't. Maybe it's a silly idea, but I think it works......

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
tfm()
SRestore(11.988) # http://avisynth.nl/index.php/Srestore
Spline36Resize(832,468) # Because it's exactly 16:9, but that's just me.
ChangeFPS(24000,1001)

[manono]

Yadif(Mode=1)#or QTGMC
Srestore(frate=23.976)

I don't see any residual blending. It's odd that they'd field-blend a film source. Very shoddy work.

[hello_hello]

Yadif(Mode=1)#or QTGMC
Srestore(frate=23.976)

I don't see any residual blending. It's odd that they'd field-blend a film source. Very shoddy work.

I saw a bit of remaining blending doing it that way, and a spot where the movement "jumped", but maybe I did something wrong. I do see a fair bit of shimmering using Yadif though. If that's the right description. The frame around his glasses annoys me the most. There's two lines along the bottom edge of the table that wobble when using Yadif.
If you use tfm() instead of Yadif the frame around his glasses looks solid and those lines don't wobble. Maybe there's a better way than the way I did it though.

[manono]

I do see a fair bit of shimmering using Yadif though.

Yeah, me too. I just use Yadif for testing because it's fast. For the real thing I'd use QTGMC or NNEDI3.

Maybe there's a better way than the way I did it

Even if the sample was drawn at 12fps and you can get away with duplicating each frame to get to 24fps, you can't really count on the whole thing being that way. But, having never worked with South Park I don't really know what the full episodes are like.

[Downgraded286]

I tried this:

SetMTMode(5, 4)
FFmpegSource2("Z:\Output\MakeMKV Output\South Park S18e01.mkv")
SetMTMode(2)
QTGMC(Preset="Slower", EdiThreads=2)
SRestore()

Still got blending issues. I see you guys specifying something with SRestore(), I imagine that's the framerate? Why would I cut it down to 12fps then redouble to 24fps? It seems cleaner to have SRestore() process it at 24fps in the first place?

[jagabo]

I see you guys specifying something with SRestore(), I imagine that's the framerate? Why would I cut it down to 12fps then redouble to 24fps? It seems cleaner to have SRestore() process it at 24fps in the first place?

SRestore preferentially removes blended frames, then duplicate frames. If you pick a frame rate too high some blended frames will remain. If you pick a frame rate too too many frames will be removed. The sample clip had a base frame rate of 12 fps so reducing it to that with SRestore removes the blended and duplicate frames. Restoring the frame rate to 24 fps with ChangeFPS make exact duplicates which compress down to nearly nothing.

But I agree with manono, there are probably shots where the base frame rate is higher. It's very common for cartoons to have character animation at 12 fps but panning shots at 24 fps. And many cartoons are first created on film, then telecined onto analog video tape, and finally edited as interlaced video. Some shots are then sped up and slowed down to match dialog or for story flow. Field blending is usually used for that. So you end up with orphaned fields (fields with no matching field to complete the original film frame), some film frames that are only represented by blended fields, extra duplicate frames, and/or missing frames. So you often can't reduce them to 24 fps or 30 fps or any other single frame rate and keep all shots smooth (well, as smooth as cartoons get). Sometimes I just give up and use QTGMC and encode at 60 fps.

[Downgraded286]

I tried QTGMC @ 59.94 and the blending was still there. I'll try mucking around with SRestore() some more, though.

How did you guys come to the conclusion that it had a 'base frame rate' of 12fps? I thought it was 24fps?

[jagabo]

I tried QTGMC @ 59.94 and the blending was still there.

Of course. When you do that there is no attempt to remove any blending. But when the blending is only visible for 1/60 second it's less noticeable. And it's pretty much the same thing you see when watching the original DVDs on TV.

How did you guys come to the conclusion that it had a 'base frame rate' of 12fps? I thought it was 24fps?

I'm taking their word for it because I haven't looked at the video myself, but I assume when they reduced the frame rate to 24 fps every other frame was a duplicate.

[hello_hello]

I had another look and if you do nothing but add TFM() to the script there are a couple of places where there's unique frames in a row (rather than a minimum of every second frame) so maybe the way I did it wasn't the best. It's only minor movement (ie the character's mouth moving), but still.... best not to mess with it unnecessarily if you don't have to.

I think when I tested originally I managed to leave TFM() in the script so I was doing this:

TFM()
QTGMC(preset="fast")
SRestore(frate=23.976)

Which I guess was messing with the process and the blends weren't being removed. Without TFM() and just doing this:

QTGMC(preset="fast")
SRestore(frate=23.976)

It seems to work fine so I think manono's suggestion was better. As long as QTGMC doesn't produce any odd artefacts. I've not always had success using it with animation but I didn't see any problems with the sample (I only tested with the fast preset).

[jagabo]

Another trick to get a bob'd series is to interleave TFM based on the top fields and bottom fields:

Interleave(TFM(field=0, pp=0), TFM(field=1, pp=0)).vInverse()
SRestore(frate=24000.0/1001.0)

pp=0 disables the post processor that detects any residual combing and deinterlaces. After the interleaved TFMs any orphaned (and blended) fields will still have comb artifacts so they're blended with vInverse.

And another method is to use TFM(pp=0) several times in a row:

TFM(pp=0)
TFM(pp=0)
TFM(pp=0)
vInverse()
SRestore(frate=24000.0/1001.0)

Again, vInverse is used to blend any remaining comb artifacts.

[Downgraded286]

This isn't quite working out either

SetMTMode(5, 4)
FFmpegSource2("Z:\Output\MakeMKV Output\South Park S18e01.mkv")
SetMTMode(2)
QTGMC(Preset="Slower", EdiThreads=2)
Srestore(frate=23.976)

I'm going to try

Interleave(TFM(field=0, pp=0), TFM(field=1, pp=0)).vInverse()
SRestore(frate=24000.0/1001.0)

If not, I think QTGMC @ 60FPS would be the only/best real option left... unless I'm missing something.

-ed must be missing something, VirtualDub complains about no function named vInverse.

[hello_hello]

http://avisynth.nl/index.php/Vinverse

[jagabo]

Neither of those multi-TFM scripts gives perfect results. I just presented them as more options.

[Downgraded286]

You're right. I tried the one I said I was going to (after installing Vinverse) and I still get field blending, and some combing artifacts. Srestore isn't perfect either. In fact, it introduced something that shouldn't be there. With the desk pictured in post 57, the shadow on the side facing the camera, and the line below it, bounce up and down very slightly. With QTGMC alone, it doesn't seem to move.

Nothing we've tried seems to quite get it just right so far...

[jagabo]

Nothing is ever going to get it right. The issue is what wrongs you will settle for.

[Downgraded286]

I see. This looks like an issue of a F***ED up source that somebody ruined, and there's no way we can truly make it right again? How could a commercial DVD have such shoddy work? QTGMC produced perfect results where the Handbrake filters totally fell flat on its face... I wonder why it struggles now.

Looks like my standard QTGMC script (perhaps modified to output 59.94fps) is probably the best solution. There will still be field blending, but nothing really got rid of it anyway.

[jagabo]

This looks like an issue of a F***ED up source that somebody ruined, and there's no way we can truly make it right again?

Yes.

How could a commercial DVD have such shoddy work?

Like I said before, it was shot on film, telecined, edited as interlaced video, then shots were slowed or sped up with field blending. This is very common for made-for-tv cartoons. They can't be cleanly IVTC'd.

[hello_hello]

Looks like my standard QTGMC script (perhaps modified to output 59.94fps) is probably the best solution. There will still be field blending, but nothing really got rid of it anyway.

Srestore worked fine for me on your sample, but don't expect to see it work properly in MeGUI's preview. I think it relies on detecting a pattern of blending, but even if it appears not to be working when looking at the preview, try encoding. Assuming you haven't already....

Or try Yadif instead of QTGMC if QTGMC is producing artefacts, or even try my original method of reducing the frame rate to 11.988 and doubling it again. Yes, you might lose the odd frame where something changes, but being South Park it probably won't be noticeable, and doing it that way be the lesser evil, so to speak.

[manono]

In addition, you can't be just scrolling around to check different parts and expect to see it as it'll be in the final encode. You can, if you want, kind of 'sneak up' on a place you want to examine by beginning early and advancing to the place. But Srestore won't always give you instantly the final result. As hello-hello suggests, encode and then check the results. And there's no way I'd make it 59.94fps.

I wouldn't worry about the odd blended frame, if I were you. As jagabo suggests, it's often intentional. And sometimes the blending isn't entirely removed. Blame your source. Otherwise you'll have to learn interpolation techniques to replace 'bad' frames with better ones created from the frames on either side. And this will mean going through the whole thing frame-by-frame looking for aberrations. I do that myself, but most won't want to take the time.

[jagabo]

there's no way I'd make it 59.94fps.

I wouldn't worry about the odd blended frame, if I were you. As jagabo suggests, it's often intentional.

It's intentional but when you watch the DVD you see that blended field for only 1/60th of a second, and since it's a blend of the two fields around it it's very hard to see. If you IVTC back to 24 fps you will see it for 1/24th (or 1/30th or 1/20th when using 3:2 repeats) second -- making it much more visible. And since parts of the video were sped up or slowed down by removing or adding fields, forcing it to 24 fps will give it jerkiness beyond what it displays at 60 fps. That's why I encode at 60 fps when there is a lot of this in a source.

[Downgraded286]

Well, I went ahead and processed the video with 60fps QTGMC. I'm doing my final encoding now. I think this was probably the best option.

[Skiller]

Not trying to be a smart-ass but this exactly what I proposed back in November in this thread.

Bob-deinterlacing to 59.94 fps is what I would do (if I really feel like not encoding it interlaced) and it's what I would suggest, especially if you want to be done with it before you are old and gray.

[Downgraded286]

I ran into some issues with something else. QTGMC and TDecimate did in fact make something look quite jerky, I see it now. It's very hard to tell with South Park, but having done it with an actual film source (in this case, The Golden Girls) I saw it. Now I just use qtgmc and selecteven, removing tdecimate. The videos process faster now too without it, for a better result.

I may be giving ripbot264 a try here soon. If I can use avisynth and compress to h.264 at the same time, that removes a big step in my process. Even MKVToolNix is slow at this point, because of the massive amount of data I have to move thanks to my preference for using lossless codecs in virtualdub.

[Brad]

QTGMC.SelectEven on a film source would create a stutter pattern of 1 duplicate in every 5 frames.