(Yet Another) Weird Pattern 25 -> 29.97 telecined

[DoctorM]

I've been banging my head against a piece of interlaced video (29.97) for a couple days.

I tried IVTC'ing with TFM and Telecide (then decimating). The output keeps ending up jittery. (Duplicate and missing frames).

Finally in disgust I used bob() and counted unique fields and discovered the source to be 25 fps. The thing is there is no ghosting, blending or anything wierd. Just 25 unique fields and a very strange pattern of duplicates.

My current script looks like:

qtgmc(Preset="medium")
fdecimate(25)
assumefps(23.976)

I'm assuming there will be speed up in the audio that needs correction, but that's a different can of worms.

The point being, this method is slow (even at Medium).
TFM will inverse telecine to 29.97 but drop frames (that I can see with a bobber).

It would be quicker and produce better quality to IVTC directly, but I know of no filter that is tunable to match fields for frame rates besides 29.97.

Suggestions?

[manono]

Originally Posted by DoctorM

Suggestions?

My first suggestion is that you provide a sample. If you're asking here what to do, maybe you don't know how to diagnose what you have either. Samples are always better than descriptions.

Anyway, based on your description, maybe this will work:

TFM()
Tdecimate(Mode=0,Cycle=6,CycleR=1)

But I'd still feel more comfortable offering advice if there was a sample included.

TFM will inverse telecine to 29.97 but drop frames (that I can see with a bobber).

TFM is a field matcher. It's only part of an IVTC. It doesn't drop frames. Your source is also 29.97fps, isn't it?

but I know of no filter that is tunable to match fields for frame rates besides 29.97.

TIVTC can produce a virtually limitless number of framerates. As can Decomb. If there are a bunch of orphaned fields in this thing, then there will be problems and your current solution may be the best.

[TheSkiller]

Please provide a sample.

From your description it sounds like 25p wrapped in 29.97i using pulldown. Nothing weird about that. Manono's suggestion would deal with exactly that (result would be 24.97 fps which can be left as is or speed up to 25 fps).

If you're unlucky, editing has been done in 29.97i.

[DoctorM]

Originally Posted by manono

My first suggestion is that you provide a sample. If you're asking here what to do, maybe you don't know how to diagnose what you have either. Samples are always better than descriptions.

Good point. Clip here.

Anyway, based on your description, maybe this will work:

TFM()
Tdecimate(Mode=0,Cycle=6,CycleR=1)

But I'd still feel more comfortable offering advice if there was a sample included.

TFM is a field matcher. It's only part of an IVTC. It doesn't drop frames. Your source is also 29.97fps, isn't it?

And yet oddly TFM was dropping frames.
Haven't had a moment to test this yet, will a bit later.

TIVTC can produce a virtually limitless number of framerates. As can Decomb. If there are a bunch of orphaned fields in this thing, then there will be problems and your current solution may be the best.

Yes, I realized I mis-spoke when I suggested I needed to IVTC to a different frame rate than 29.97. I meant I needed something besides the standard pattern after frame matching.

If by orphaned fields, you mean single fields without a match, yeah, I've got them. I assumed they'd end up as a remaining combed frame that gets passed to the post processor.

[manono]

Originally Posted by DoctorM

And yet oddly TFM was dropping frames.

It's dropping fields. And yes, they're orphaned fields - fields for which there's no match. TFM won't create a duplicate for an orphaned field on which to match, or bob it. It'll just drop it. This is a most peculiar way to convert PAL to NTSC. I'd do it as you showed in your first post, maybe changing the decimate portion to:

TDecimate(Mode=0,Cycle=60,CycleR=35)

But it doesn't matter a whole lot. Ignore the jump on frame 15 because there isn't a full cycle on which it can work.

Edit: I was thinking about this some more. The only IVTC that bobs fields if needed is the old SmartDecimate. I tried it and even it had trouble going straight to the final framerate. But if field-matching/bobbing to 29.97 followed by a decimate, it did better. Here's the script:

SmartDecimate(30,60)
TDecimate(Mode=0,Cycle=30,CycleR=5)

Here's an MP4 I made of it. I can't tell if it's perfect or not but, while it isn't as fast as using TIVTC alone, it's way faster than having QTGMC in there:

https://mega.co.nz/#!kJxwERSK!ZaG5iH...PB2R-O1ikP4as0

[DoctorM]

Good suggestions, manono.

TDecimate seemed to hit on unique frames more accurately. SmartDecimate preserves a lot more detail. Which onsidering the condition of the source is nice.

I play around with that some more, but that looks to be the best answer... and much faster.

Edit: I cannot get my head around what exactly it is that SmartDecimate is doing. The page doesn't make a lot of sense when I read it.
http://avisynth.org.ru/docs/english/...rtdecimate.htm

[manono]

Originally Posted by DoctorM

Edit: I cannot get my head around what exactly it is that SmartDecimate is doing.

Do you really have to understand what it's doing? Isn't it enough that it works?

Think of it as a regular IVTC with the extra added attraction of being able to use bobbed fields when needed. I believe it was developed as a way to get a single framerate out of hybrid material - things like the Star Trek spinoffs where there's a mix of film and interlaced computer generated material. By being able to use bobbed fields on occasion, it's better at getting nicer-looking results from the video portions than the Decomb or TIVTC methods of blending frames (when converting from interlaced 29.97fps to progressive 23.976fps).

Knowing that, I decided to see if it worked with your sample or other material with orphaned fields. It does, after a fashion. I think it bobbed and kept all the orphaned fields, but because the duplicate pattern was peculiar afterwards, I decided TDecimate was better to remove those dupes. As I mentioned, I used SmartDecimate to get progressive 29.97fps from your source, before then using TDecimate to bring it down to 24.975fps.

You'll notice it uses the AviSynth Bob filter when bobbing. You might want to use a better bobber when needed, maybe even QTGMC. The manual explains how to replace Bob with any bobber you might want to use.

[DoctorM]

Good point. There are some confusing details about the filter. At one point it is just about saying it decombs instead of matching fields and then later you can set how aggressively it matches fields.

Good eyes with the bob= option. Missed that. Unfortunately, Yadif, Yadifmod and qtgmc all cause a crash. Either a silent crash or a program error (not avisynth) (Media Player Classic, VDubMod, etc.) and "R6025 Pure Virtual Function Call". Even dgbob (their example) didn't work. Huh?

Not sure what's going on there.

[manono]

Yeah, I had trouble getting it going too. It's been years since I used it and several AviSynth versions ago. Maybe someone with more knowledge than I can give a more efficient way to set it up, but what made it work for me was sticking the other needed DLLs before the AviSynth_C.dll needed by SmartDecimate. I couldn't get it going with either the LoadCPlugin or StdCallPlugin. Something like this worked:

LoadPlugin("D:\AviSynth Stuff\Dlls\DGDecode.dll")
LoadCPlugin("D:\AviSynth Stuff\Dlls\Yadif.dll")
LoadPlugin("D:\AviSynth Stuff\Dlls\avisynth_c.dll")#Yadif before AviSynth_C.dll
LoadCplugin("D:\AviSynth Stuff\Dlls\SmartDecimate.dll")
LoadPlugin("D:\AviSynth Stuff\Dlls\TIVTC.dll")
MPEG2Source("E:\Test\Test.d2v")
SmartDecimate(30,60,Bob=Yadif(Mode=1))
TDecimate(Mode=0,Cycle=30,CycleR=5)

But as I said, there are probably better ways to set it up.

[DoctorM]

Cheers. I'll give it a go.

[DoctorM]

Still unable to get a custom bobber to work. I figured it was because I wasn't calling the autoloading plugins, but that didn't help.

Btw, I found there was still the occasional incorrect frame after decimation.
Counting SmartDecimate's output I found this pattern: 12344 1234566 12344 1234566

As a result having TDecimate check cycles of 30, a range not divisible by 12, produces one improper decimation every second.

Changing to: TDecimate(Mode=0, Cycle=12, CycleR=2) improved accuracy and produced a serious bump to performance.
The pattern seems to hold throughout the video.

Now if I can just get the bobber fixed...

[manono]

Originally Posted by DoctorM

Counting SmartDecimate's output I found this pattern: 12344 1234566 12344 1234566

I noticed that too, but it's not consistent all the way through. Sometimes it switches.

As a result having TDecimate check cycles of 30, a range not divisible by 12, produces one improper decimation every second.

I found the two different decimation methods to produce frame-for-frame identical results with the sample. Of course, yours is faster and if it works throughout the whole complete video, then of course you should go with it.

I'm sorry you haven't got the other bobbers to work with SmartDecimate yet. I don't know what other advice to offer. Good luck.

[johnmeyer]

The pattern in your sample is a little convoluted, but appears to repeat. Therefore the Cycle/CycleR in TDecimate works perfectly, if you count the pattern correctly. Here is the field count I came up with, where each digit represents a frame, and 1, 2, and 3 represent the number of fields in each frame in the original video ("2" fields is, of course, what you want for every frame). I viewed this using a script that is nothing more than "separatefields()" :

3-1-3-2-3-2-3-2-3-2-2-2-3-2-3-2-3-2

If you count the number of digits, there are 18 digits, so there are 18 frames. So, after field matching and decimation, we want to end up with 18 frames (36 fields) from these 43 fields. Therefore, out of every 43 fields, we should decimate 7.

AssumeTFF()
tfm(display=false,order=-1)
tdecimate(display=false,cycleR=7,cycle=43)

However ...

There is something in the TFM logic that I don't quite understand in how it post-processes the individual fields that have no match. If you set "order=1" TFM will correctly post-process the unmatched odd fields. For these single fields (shown by the "1" in the pattern above) it will give you a frame that contains the original unmatchable field plus a synthesized field, created using whatever technique you choose using the "pp" parameter. However, it skips the even fields. If you instead set "order=0," it then does the even fields but skips the odd fields.

So near and yet ...

So, the TDecimate logic works great, but the TFM matching and post-processing doesn't quite do the trick.

Another approach might be to double the frame rate using a bobber or deinterlacer, and then decimate from that.

One final note. I found that the pattern repeats every 43 fields but when I actually walked through the result, putting a separatefields() at the end of the recovered video so I could see what was happening, I found there was still an undecimated result every two cycles. So I doubled Cycle and CycleR and then added one to CycleR in order to remove these remaining duplicates:

AssumeTFF()
tfm(display=false,order=1)
tdecimate(display=false,cycleR=15,cycle=86) 
separatefields()

The separatefields() statement is there for debugging purposes, so I can see exactly what is going on, and would of course be removed when using the script to actually generate the final video.

[johnmeyer]

P.S. to my last post. I didn't actually use "MPEG2Source("E:\Test\Test.d2v")" to read the video and perhaps I should. In reading the TFM documentation, there is a parameter that sounds like it might solve the problem:

d2v -

This option is intended to be used if you are using an mpeg2source() with a d2v file.
It sets the name and path to a d2v file, which TFM will analyze to see if there are any
illegal field order changes and optionally set the order parameter using the field
order of the d2v file.

[manono]

Originally Posted by johnmeyer

If you set "order=1" TFM will correctly post-process the unmatched odd fields.

It doesn't. There are 2 missing fields/frames doing it that way. Using this script:

TFM(Order=1)

Even before decimation there are already two missing frames, before frames 30 and 73. TFM just cannot handle this.

AssumeTFF()
tfm(display=false,order=-1)
tdecimate(display=false,cycleR=7,cycle=43)

That can't be correct. The final framerate is 25.091 when it should be 24.975fps. You still have the same two 'jumps' plus three duplicate frames.

AssumeTFF()
tfm(display=false,order=1)
tdecimate(display=false,cycleR=15,cycle=86)

Nope again, the same two missing frames and the wrong final framerate. Anything that doesn't return 24.975fps is wrong.

In reading the TFM documentation, there is a parameter that sounds like it might solve the problem:

It won't as there are no field order problems with the sample. The D2V setting is mainly for helping when there's a mix of hard and soft telecine.

TIVTC isn't optimum for this video.

[johnmeyer]

OK, I guess I'm an idiot. I'm sorry I spent the time doing this.

[manono]

It's a learning experience sometimes just to discover how many ways a simple video can be completely messed up by the so-called 'professionals'. There are so many ways to screw up PAL2NTSC when it's so easy just to do it correctly the first time. The mind boggles sometimes because it's then up to us amateurs to try and put things right. I was stumped too, and had tried all sorts of things with TIVTC before giving up, but had had experience with SmartDecimate years ago and decided to give it a try. Maybe there are other and more simple ways to solve this one, but that will have to await the efforts of someone else.

[DoctorM]

@johnmeyer - If I read you right, you didn't get TFM to work then? It seems apparent that TFM won't properly process an orphaned field.

Besides, I don't know how I feel about using a 43 frame range. That'll take forever to process.

@manono - Fixed my bobber issue. You need to get the bobbing out of the way before SmartDecimate made things awkward.

MPEG2Source("Test.d2v")
yada=yadif(mode=1)
SmartDecimate(30,60,bob=yada)
TDecimate(Mode=0,Cycle=12,CycleR=2)

Btw, I see what you mean about the odd pattern. The clip I posted generates a 7 7 5 7 5. The full version produces a slightly different one with one 9 frame run.

Yet once fully run through the script there are no duplicate frames or apparent missing ones (the movement is smooth).

With the 30/5 numbers I did see some duplicates and missing frames in the video 1-2 seconds before the clip I posted (when there was a smaller difference for the frame matcher to detect).

[Gavino]

Originally Posted by DoctorM

Fixed my bobber issue. You need to get the bobbing out of the way before SmartDecimate made things awkward.

...
yada=yadif(mode=1)
SmartDecimate(30,60,bob=yada)

Not sure what you mean here.
Internally, that code is exactly the same as manono's
SmartDecimate(30,60,bob=yadif(mode=1))

Your earlier problem almost certainly has something to do with incompatibilities between the built-in LoadCPlugin() and the older avisynth_c.dll (which declares its own LoadCPlugin() function).
I suspect Yadif needs the built-in version while SmartDecimate needs the older one, so the order of loading the dll's becomes important. Hence manono's solution of manually loading the plugins in the appropriate order.

[DoctorM]

Except manono's script as he posted it did not work for me. Yes, I loaded the plugins in the same order he did, but for me I had to actually use Yadif before SmartDecimate.