Another nasty NTSC problem

[Lux Delux]

:o

Well I just got Cobra the tv-series and can't find a solution for a smooth playback final encode. I always end up with stuttering motion, as if 1 frame disappears every few seconds.

Tried a couple of IVTC's but none hit it so I figured this source isn't so easy... Well for me at least :o

A friend of mine recommended this page
http://home.arcor.de/scharfis_brain/ExotischesInterlacing

but I don't know german very well :(

Here is the sample
http://www.sendspace.com/file/ez61x5

If anyone has an idea and perhaps a nice explanation at what goes on exactly here... Please post :) Hopefully I learn something too :p

Cheers, and sorry for the lame thread title :o

[ChiDragon]

zipping/rarring of compressed video files is annoying and next to useless. You only saved 591KB. You would have saved 1.33MB had you stripped out the audio. Anyway...

There are orphaned fields in the source (original film frames that appear in only one video field), but from what I've checked they only occur in the top field. TFM with PP=7 should field match and interpolate fine. Figuring out the frame rate to decimate to is a little tougher, especially since the telecine pattern if there is one seems to change at scene cuts.

EDIT: Okay I spoke too soon. There are orphans in both top and bottom fields (see frame 440 for a bottom, 527 for a top) so you'll have to use something like TDeint(mode=1,tryweave=true) followed by a decimation filter at an appropriate frame rate.

EDIT 2!: This seems to work well, at least in the motel scene:

TDeint(mode=1,tryweave=true)
TDecimate(cycleR=102,cycle=172)

The decimation may be screwy with such a long cycle so you'll probably have to use an ovr file to correct it at points. You can also try:

TDeint(mode=1,tryweave=true)
TDecimate(mode=2,rate=24.394)

but that seemed to perform worse for me.

[Lux Delux]

zipping/rarring of compressed video files is annoying and next to useless. You only saved 591KB. You would have saved 1.33MB had you stripped out the audio. Anyway...

I thought the free hosts usually delete video and similiar files like this fast. That's why I rared it. :)


There are orphaned fields in the source (original film frames that appear in only one video field), but from what I've checked they only occur in the top field. TFM with PP=7 should field match and interpolate fine. Figuring out the frame rate to decimate to is a little tougher, especially since the telecine pattern if there is one seems to change at scene cuts.

thanks for the input, will try a quick encode to see the results. :)

[Lux Delux]

Just saw your edits! :eek:

Cheers will try asap :thanks:

edit: wow the cycled one is really slow, encoding a trimmed part to see the result :)

edit2: indeed with this solution the results are much better although I'd need to try it on a final encode. I think I noticed some interlacing when loading the script in vdubmod (somewhere right at the beginning) but it slows vdubmod to a crawl and even frame by frame caused me extreme slowness up to the point when it froze :( My damn computer.

Tricky stuff this one :p

[elguaxo]

you'll have to use something like TDeint(mode=1,tryweave=true) followed by a decimation filter at an appropriate frame rate.

How can you figure out, or at least try to figure out the framerate in this particular sample?

Edit: TDecimate(cycleR=102,cycle=172) seems to work good and TDecimate(mode=7,rate=24.394) works too (not as good as with cycle, but better than mode=2), but why 24.394 fps?

[ChiDragon]

24.394 fps is just the same as 102 frames dropped of 172 frames input. 172-102 = 70 kept. (70/172) * (60000/1001) bobbed fps = 24.39421044072206862904537323142... fps.

I came up with it from looking at the output file of a filter I made (not really ready/meant for release). One of its functions is to take a TFM match output file and create a text file to aid in looking for patterns of matches or decimation patterns.

But you can do the same thing looking through it manually. Open up Notepad and step through with TFM and TDecimate with display=true, writing down the smaller "cycles" of 4 frames+dupe, 7 frames+dupe, etc. in whatever notation works for you and then try to find something that repeats there. Of course with TFM and orphaned fields you have to be careful since it will match "p" and create extra duplicates where opposite-field orphans are present, i.e.:

AtAtCt
AbBbCb

matching from top gives:

c p c
AtAtCt
AbAbCb

For this particular video I knew that these were taking place when there were drops with only 2 new frames in between. You should even be able to tell most of the time just looking at TDecimate's metrics, as there will be large "local maximums" (I think that's the right term). Like metrics around 6-8, then suddenly one with 16, then back to 6-8.

Anyway, if you do come up with your cycleR and cycle values this way and are going to actually be using them on a double-rate (bobbed, or in this case a bobber with 2-field matching) input instead of single-rate (1-field matching) you will of course have to convert them so that twice the frames are dropped. "4 in 5" can become "2 in 5" or "4 in 10" for example. Whether to halve the # dropped or double the cycle # depends on how exactly the pattern repeats I guess.

When you hit upon good repeating cycles, they seem to "look" the same. At least in the videos I've done, most of the placements of the new and duplicate frames will be the same across multiple cycles.

This turned out longer than I had intended... :eek: Hopefully most of it makes sense.

[elguaxo]

It makes sense! Thanks a lot!!! I have some chinese crap that needs a similar treatment and I was wondering how to figure out the target framerate.

[Lux Delux]

:o

Very well then, need to put that sucker to encode... Gonna take ages since I need to apply filtering too....

Hopefully it will work good on the whole encode :)

Oh and tweaking the combing stuff in TDeint is harmless to the other things right? :o

Need to fix this so that's why I ask

http://img340.imageshack.us/img340/7523/combzr9.th.png (http://img340.imageshack.us/my.php?image=combzr9.png)

although I can't seem to tweak those settings correctly either :eek:

[ChiDragon]

You can try lowering the MI value to pick up this combing, or you can just use an ovr file with a line containing the frame number, a space, and plus sign as in "1000 +" if you just want to fix specific frames.

Changing which frames are detected as combed can change the decimation since the difference metrics will be... well, different.

[Lux Delux]

Setting MI=10 seems to have fixed it :)

Now to wait for an encode to see how it will all look :thanks:

edit: running a comptest, 2% after 8 minutes :eek: lol the encode will indeed take time then :(

[foxyshadis]

Use ffdshow's huffyuv then, it'll save you a lot of time re-rendering things for the second pass.

[ChiDragon]

You should know that MI=10 is really low and may lead to interpolating frames that could be fully weaved instead. This would lower quality and increase encode time.

[Lux Delux]

Use ffdshow's huffyuv then, it'll save you a lot of time re-rendering things for the second pass.

:o I'm sorry but I have no idea where to set this. Been searching both the forum and google for some basic explanation but nothing came up.

I'm encoding it to xvid, is it in someway connected with it's settings or... :o Man I'm embarrassed.

You should know that MI=10 is really low and may lead to interpolating frames that could be fully weaved instead. This would lower quality and increase encode time.

so you recommend the full weaving alternative instead? I'm confused now :o Is it connected with the ovr file you were talking about?

[ChiDragon]

I believe foxyshadis is saying that you should encode a temporary file using ffdshow's Huffyuv codec (specifically that one, for its YV12 support), then encode that temporary file to your final ouput format (XviD). That way your slow script only runs once instead of twice, and the encoding to XviD is fast. Of course the downside is the amount of space a losslessly compressed takes, and this only applies if you're doing a >1-pass encode.

A "full weaving alternative" wouldn't work in this case since we know that there are fields with no proper match. The threshold that you choose for MI (and the other options that affect combing detection that you can try changing, cthresh and blockx/blocky) is a tradeoff between not picking up combed frames like your example pic and falsely detecting progressive frames as combed. Frames with metrics above MI are interpolated with motion adaptation and those below are completely weaved (interpolation makes up new data, weaving uses what's already there). Using the ovr option gives you full manual control over which are interpolated and which are weaved. Read TDeint's documentation if you want to know more about ovr files.

[Lux Delux]

Thank you very much for explaining :)

Now I know where to look and learn more. Cheers :thanks: