QTGMC creating stutter on timecode breaks?
 

Hi!

When trying to deinterlace PAL DV-AVI with QTGMC (using VirtualDub), I get horizontal stuttering (that is, the whole frame jumps rapidly back and forth) whenever there is a gap in the timecode. While the interlaced clip will just show a still frame, the frame doubled deinterlaced version will stutter badly.

See attached clips.

This happens on all dv tapes. It does not matter whether I cap in WinDV or Premiere. I get the same stuttering when trying to deinterlace VHS tapes capped with Virtualdub whenever Virtualdub has inserted frames.

The stuttering does not occur when I do Yadif+Bob in Handbrake, but then the quality of the deinterlacing is crap.

Is there a way to achieve the quality of QTGMC while avoiding this stuttering problem?

Check your field order. I think DV-AVI defaults to bottom field first unlike most AVI container codecs. You may need to add "AssumeBFF" to your AVIsynth script.

VHS captures using HuffYUV should always be top field first. Don't know why they would shudder with a default setup.

I've also found that QTGMC can does this on "still" frames. It can often help to use a different preset, though I don't remember which one worked best.

Also for DV captures, it seems some cameras output a still frame on gaps, while others don't output anything when there's nothing on the tape, so the final file will simply transition from one clip to the next.

The field order is correct. If the field order was incorrect, the whole clip would stutter. It only happens on the transition from one recording to the next, where there is a break or a gap in the timecode and the interlaced 25fps clip displays a still image for a few seconds. In the deinterlaced 50fps version, the still image does not remain stationary but moves back and forth, creating a very noticeable stuttering effect. Of course, it can be edited out, but finding all the instances of stutter is very time consuming.

Considering the seeming popularity of QTGMC, I find it strange that no one has had this problem, because it seems to happen on most every DV tape, as well as VHS tapes containing errors which cause Virtualdub to insert frames. Could it be a PAL-only problem?

Different presets do not seem to make a difference, unfortunately.

Ah sorry I misunderstood what it was when writing my previous post. I was thinking of a still image like a full screen logo or something.

In the transition clips there will be two fields with movement repeating which does confuse the deinterlacer as it will think the objects are moving back and forth. yadif and bob seems to do the same if set to double frame rate output, at least when previewing in VLC.

What you can do is to try something like http://avisynth.nl/index.php/ExactDedup to remove the gaps on the DV streams at least. May not be ideal on the VHS caps since the inserted frames may contain audio. It should in theory be possible with some avisynth script-fu to e.g conditionally disable deinterlacing or doing something else when encountering the duplicate fields but I don't know any existing scripts that does this.

You see reversing field orders in broadcast as well. It'll be TFF for a show, BFF for a commercial, TFF for next commercial, back to show at BFF. It's a processing error that drops a field, makes a mess.

Another reason to dislike DV via Firewire transfer/capture.

Yes, I just tested this, and you are right. It would seem all avisynth implementations of bob deinterlacing do this. FFmpeg does not, however. Hence, I may just end up using bwdif (Bob Weaver Deinterlacing Filter) in FFmpeg unless I can find a better solution. It is not as good as QTGMC, but at least it is not awful.

Thanks for the suggestion. I tried ExactDedup, and it did indeed manage to remove the problematic parts, but the sound was out of sync. A possible explanation for this is that the people I am currently digitizing for loved to use the oh-so-very useful photo function of their camera. You know, the one which creates a still image on the tape (which, incidentally, don't stutter when deinterlaced). Besides, the process was somewhat cumbersome, with two separate passes needed, which is ok for the odd file but not very practical when trying to achieve an efficient workflow.

I checked with ffmpeg. It seems that it reads some interlacing info from the input video, if field order is set to auto, it leaves the repeated frames alone, if I force it to bff, it doesn't. I don't know if that's something avisynth can do or not.

If you end up using the ffmpeg deinterlacers, there is also mcdeint, and if you have a recent version, nnedi, to check out. Both are really slow though.

Alternatively, you could use QTGMC in avisynth and use the fpsdivisor=2 parameter which will probably avoid the stuttering but only give you 25 fps output.

That's not the issue here, the problem is that the last frame of a clip is repeated when there is a break in the recording, and since this is interlaced video, this means the last two fields that are repeated over and over which causes stuttering if there was movement from one to the other. I've used an older JVC miniDV camera once that did this when playing back. Every other miniDV and digital8 device I've used (including a newer JVC cam) don't output anything over the firewire stream if there is nothing on the tape.

Interesting... Thanks for figuring that out! It doesn't look like there's any way of making avisynth behave that way, though. :hmm:


Yes, 25fps avoids the stutter problem, but the resulting video is considerably less smooth than the 50fps output, especially during pans, even with the ShutterBlur option set.

Well, at least now I know what is causing the problem. :congrats: Still haven't found a solution, though. If avisynth cannot be prevailed upon to auto detect the field order instead of treating the whole thing as either BFF or TFF, I guess the best solution would be something along the lines of what you suggested: detecting and removing duplicate frames prior to deinterlacing. I've not been able to find a reliable way of doing that, however. So for now I guess I'll just leave the danged things in, even though they look like crap.

Or find a DV camcorder that doesn't output duplicate frames on timecode breaks. As my JVC cams and my two Sony HVR-M15s all do this, I figured DV camcorders / players were supposed to behave this way.:unsure: