IVTC for xvid choppy on TV playback

[spiritgumm]

On some xvid I converted from dvd video (using avisynth), the playback looks fine on a monitor, but on TV looks like it dropped frames. The original dvd video looked like typical telecine, and I used TFM & Tdecimate. I'm not familiar with earlier IVTC methods so I'm not sure how to diagnose the problem.

[PuzZLeR]

Maybe the DvD was a true interlace, not a film source. The functions tfm() and tdecimate() are for film sources that are "interlaced", otherwise if applied on the wrong source it can create a weird jitter and quiver.

First, preview your script/source with VirtualDub, but without any IVTC or deinterlace filters.

During movement, if there's 2 out of 5 frames that are "interlaced", then it's not a true interlace but a film source that is "interlaced" - then go ahead and use tfm() and tdecimate().

If the interlacing has no discernible pattern, then it's a true interlace and tfm() and tdecimate() will not help - only make it worse, which might be your case.

[manono]

Sample of the source.

[spiritgumm]

Well, it could be a dvd player issue, because the problem xvids sometimes play smoothly if I restart them. But other xvids play fine all the time.
I gave a dvd of the first xvid to someone, and they said it was slightly choppy on TV; I dont know if they tried restarting it.
I'm posting 2 dvd-video samples for two problem xvids. Perhaps I should post xvid samples. I did not make any of the original dvd recordings.
The first is a home dvd recording (from retail vhs):
movie.m2v

The next video is a home dvd recording (I believe direct from TV), of a TVshow. There was a 2nd episode on the dvdr, and I made an xvid of that, too. That xvid plays fine, even though they essentially have the same source, and I used same type of script
tv show.m2v


MOVIE SCRIPT
MPEG2Source("C:\Documents and Settings\Desktop\Doomsday\VTS_01_1.d2v", cpu=0)
video=MPEG2Source("C:\Documents and Settings\Desktop\Doomsday\VTS_01_1.d2v", cpu=0)
audio=NicAC3Source("C:\Documents and Settings\Dave\Desktop\Doomsday\VTS_01_1 T80 2_0ch 256Kbps DELAY 64ms.ac3")
AudioDub(video, audio).DelayAudio(0.064)
tfm()
tdecimate
Tweak(hue=1.3,Coring=True)
HDRAGC(min_gain = 1.0, coef_sat = 1.9,Corrector=0.8,Reducer=1.5)
crop(8,0,-8,-4)
lanczos4resize(640,480)
trim(43,139314)


TVSHOW SCRIPT
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\xlogo.dll")
V=MPEG2Source("C:\Documents and Settings\Desktop\New Folder\VTS_01_1.d2v", cpu=0)
A=nicac3Source("C:\Documents and Settings\Desktop\New Folder\VTS_01_1 T80 2_0ch 256Kbps DELAY 0ms.ac3")
audiodub(a,v)
tfm()
tdecimate()
a=trim(1860,2017).Sharpen(0, .6).crop(0,4,-2,0).LanczosResize(416,304)
XLogo("Logo_2.bmp", X=252, Y=398, ALPHA=60,SCENE=10,feather=12)
Sharpen(0, .6)
crop(0,4,-2,0)
LanczosResize(416,304)
b=trim(2018, 31468)
d=trim(34468,46621 )
e=trim( 48779,62948)
f=trim( 67269,79802)
g=trim(82809, 88051)
a+b+d+e+f+g
resampleaudio(48000)

[PuzZLeR]

Hi again.

I've looked at the "movie" sample and you're correct about the broken movement when using tfm() and tdecimate(). Yes, at first look it appears as if it's a film source.

But unless I'm mistaken, upon further inspection, it's actually a true interlace that's been hard teleclined? Weird.

So, you can't use conventional means to deinterlace it.

I've used standard deinterlacing scripts such as QTGMC and YadifMod/Nnedi3 with success (no broken movement), but will further experiment if can deinterlace down to 24/1001 fps.

In the meantime, I'll experiment with hybrid=3, and deblend(), and need to attach some audio to test sync, but I'm at work right now so will report back shortly.

Or maybe Manono, who knows this stuff better than I, will report back with a better answer.

[spiritgumm]

Ah, I see. I obviously didnt double-check the field order for the movie. TFF appears telecined, BFF appears interlaced (and telecined). Thanks for figuring that out. MY PC isn't very fast - is there a faster deinterlacer that can handle the telecine/interlace?

I did double-check the TV episode field order before processing to xvid, and it's not interlaced (no backward movement in either field order).

[jagabo]

This worked fine for both:

Mpeg2Source("movie.d2v")
AssumeTFF()
TFM()
TDecimate()

[spiritgumm]

does specifying TFF for the 2nd video actually make a difference? Adding TFF or BFF looked the same when I was stepping thru the frames in AvsP to check for telecine/interlace.

[PuzZLeR]

Ok, looked at it better this morning (was at work late yesterday).

The second clip "tv show" was straightforward. You don't have to assume TFF and you'll get the same result. But I am still miffed about the first one called "movie".

MediaInfo reported both files as TFF.

When running the script below:

AssumeTFF()
SeparateFields()

...there was no back-and-forth movement, which indicates it's TFF. If there was this movement it would be BFF (and the reverse applies too).

Jagabo, can I ask, why did you assume TFF, or how did you know to use it then? Is this something you can know before an encode or you do it all the time for every encode?

Nice work by the way.

[jagabo]

I usually explicitly AssumeTFF() or AssumeBFF() to match the field order of the video. I use Bob() to check the field order rather than relying on it being detected automatically:

WhateverSource()
AssumeTFF()
Bob()

I open the script in VirtualDub and step through the video frame by frame. If there are no back and forth jumps the video is TFF. If there are back and forth jumps it BFF.

[spiritgumm]

jagabo, i dont think specifying TFF matters in the TVshow script. I processed it again and it still has slightly choppy look on TV (though I'm watching it off a thumbdrive since it was quicker than burning an RW). I ran it thru Avidemux to unpack the bitpack and rebuild the I/B, which seemed to help.
I dont have the movie on my PC at the moment, so I havent tried that.

[jagabo]

Mpeg2Source() sets the field order to TFF for both the files. That doesn't matter to me. I always check the field order myself (via the bob method) and explicitly set it at the start of the script. So even if the video was encoded with the wrong field order my processing will be right.

[spiritgumm]

did you watch the xvid on a TV?

[jagabo]

I don't have to watch the Xvid on a TV. I can step through the resulting frames and see there are no missing or duplicate frames. Of course, I've only seen the short sample so I can't vouch that the rest of the movie is the same.

If you are seeing differences between packed and unpacked bitstream that's your players problem. 24 fps video is always a little jerky, especially on NTSC TVs which have 3:2 judder in addition to the inherent jerkiness of 24 fps.

If your computer monitor is running at 60 Hz refresh watch the video in this post:

https://forum.videohelp.com/threads/307004-Best-framerate-conversion-%28eg-23-97-to-30-...=1#post1888926

You'll see how 24 fps on a 60 Hz display judders. And 30 fps on a 60 Hz display is still jerky (or flickery) compared to true 60 fps video.

[spiritgumm]

thanks for the link. I played the 24/30/60 video and see what you mean. However, the premise of my thread was it looked slightly off on a TV, though fine on monitor. Most other xvids look fine on TV (no noticeable judder), including one made from a later part of the same dvdr.
Bottom line, I guess keeping it at 29.97 fps (instead of letting the TV telecine it) would improve TV viewing.

[jagabo]

Bottom line, I guess keeping it at 29.97 fps (instead of letting the TV telecine it) would improve TV viewing.

Maybe your TV/player converts from 23.976 fps to 29.97 fps by duplicating frames rather than fields. That would give several little jerks every second instead of 3:2 judder. But it would do that with all 23.976 Xvid videos.

By the way, if your player doesn't handle packed bitstream correctly you can disable it in the Xvid codec.