Avisynth manual IVTC trouble

[LoopinFool]

I'm working on archiving my old Fantasia LaserDisc to DVD.
I had a lot of problems with the automated IVTC filters like Telecide, perhaps due to the noisy source.

Here's the manual IVTC sequence I came up with by scanning through it with VDub:

Trim(0, 579).SeparateFields().SelectEvery(10, 1,2, 3,4, 6,7, 8,9).Weave() + \
Trim(580, 51891).SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave() + \
Trim(51892, 70278).SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave() + \
Trim(70280, 112304).SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave() + \
Trim(112306, 0).SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave()

Here's the problem. I finally tried a quick CCE Basic encode (no noise reduction) of the whole movie to check audio sync after IVTC. I saw lots of combing artifacts as if the cadence was wrong. I also saw plenty of combing problems later in the encoded movie.
When I open the script in VirtualDub and step through the start of the movie, there are combing artifacts in the opening scene. If I then seek back to the start (ctrl-left-arrow) and step through again, I get perfect progressive frames! As before, the whole movie is perfect then.

So I can't trust the pattern breaks I find by scrubbing through the movie in VDub, since seeking seems to change the cadence used by Avisynth.
I tried going back to Avisynth version 2.5.7 but got the same results. I see the same change after seek in other media players playing the script, so I don't think it's VDub.
I've also tried some alternative syntax in the script to do the same thing but I get the same results no matter what.

Any ideas? Any tricks to make this consistent? I can't go frame-by-frame through the whole movie to find pattern breaks!

One other quick question. After a progressive encode with CCE, previewing the result shows a "12344" sequence of frames with repeated frames making up the 23.976->29.97 frame rate conversion. Is that normal when playing it back on the computer? Is there a setting in CCE I overlooked? I hope I don't need CCE SP for this. Basic has served me very well.

Thanks for any help,
- LoopinFool

[jagabo]

What is the format of your captured file? Some codecs make it hard for a program to consistently get the exact requested frame as you seek around.

A clean laserdisc cap usually doesn't have many pattern breaks.

Regarding the CCE encode, did you enable 3:2 pulldown?

[manono]

I can't go frame-by-frame through the whole movie to find pattern breaks!

Then you shouldn't be using that method. If the automatic IVTCs are failing in places, then perhaps using override files to correct the bad parts might serve you better. Can't be any worse than the results you're getting now, eh?

After a progressive encode with CCE, previewing the result shows a "12344" sequence of frames with repeated frames making up the 23.976->29.97 frame rate conversion.

No, it's not supposed to be like that. When stepping through it in a software DVD player such as PowerDVD you're not supposed to see any frame repeats as it's a flag reader and ignores the pulldown instructions to show only what's been encoded. Somehow you had CCE go from 23.976 to 29.97fps by repeating frames and not by applying pulldown.

If you were to open it in GSpot, if you don't see Pics/s as 23.976 then you messed up.

Perhaps the IVTC is failing for a reason different than what you think. Can you post a link to a short 10 second sample with movement, one that shows the IVTC failing. Use the [ and ] buttons of DGIndex to isolate a small section and then File-Save Project and Demux Video.

[dphirschler]

Here is my manual IVTC script:

function manualIVTC(clip v)
{
	v=assumeFrameBased(v)

	# Sync pulldown pattern
	#v=loop(v, 1, 0,0)# times, start,end

	# split five frames
	v_a  = selectevery(v,5, 0).subtitle("a")
	v_b  = selectevery(v,5, 1).subtitle("b")
	v_bc = selectevery(v,5, 2).subtitle("bc")
	v_cd = selectevery(v,5, 3).subtitle("cd")
	v_d  = selectevery(v,5, 4).subtitle("d")

	# fix the C-frame
	c2=selecteven(separatefields(v_bc))
	c1=selectodd(separatefields(v_cd))
	v_c=weave(interleave(c1,c2))#.subtitle("c")
	

	v=interleave(v_a, v_b, v_c, v_d)
	#v=interleave(v_a, v_b, v_bc, v_cd, v_d)

	#v=v_c

	return v.assumeFPS(23.976)
}

There are a number of commented lines in there for debugging purposes since the pattern usually gets off track at the disc flips. Also, you should comment out the subtitles when you have it just the way you want it. Those are only there to help with debugging.

You can sometimes do a quick check by uncommenting the #v=v_c line which only reveals the c-frame. But I've never had the problem you describe. I can check it in Virtual Dub and it's golden.

EDIT:
Now that I take a closer look at your function, I admire its simplicity for getting the same thing done. Nice job. I was working too hard! LOL.


Darryl

[LoopinFool]

What is the format of your captured file? Some codecs make it hard for a program to consistently get the exact requested frame as you seek around.

A clean laserdisc cap usually doesn't have many pattern breaks.

Regarding the CCE encode, did you enable 3:2 pulldown?

This was captured with Avid DV, so it's now a Quicktime reference file. I'm using the Medialooks Quicktime DS filter to import it. It seems to work perfectly, except it only outputs RGB.

This was the CAV pressing, so there are many "sides" in the capture that I had to edit together. There aren't that many pattern breaks -- the script snippet I posted is for the whole 2hr movie. There also seems to be a pattern break at one point in the middle which might have been a capture glitch or minor video edit they did before the pressing.

I tried CCE both with and without the "inverse 2:3 pulldown" option selected. I didn't see any difference when playing them back, but need to do more testing. I always had progressive and zig-zag on.

Thanks,
- LoopinFool

[LoopinFool]

I can't go frame-by-frame through the whole movie to find pattern breaks!

Then you shouldn't be using that method. If the automatic IVTCs are failing in places, then perhaps using override files to correct the bad parts might serve you better. Can't be any worse than the results you're getting now, eh?

I was merely talking about how ridiculously long it would take to check frame-by-frame without scrubbing in VDub. It's a 2hr movie.
I started out trying a manual override file with Telecide and decided this would be simpler/clearer. It's also what I found recommended here.

After a progressive encode with CCE, previewing the result shows a "12344" sequence of frames with repeated frames making up the 23.976->29.97 frame rate conversion.

No, it's not supposed to be like that. When stepping through it in a software DVD player such as PowerDVD you're not supposed to see any frame repeats as it's a flag reader and ignores the pulldown instructions to show only what's been encoded. Somehow you had CCE go from 23.976 to 29.97fps by repeating frames and not by applying pulldown.

I will do more testing, but there are very few options in CCE Basic for this. I tried the "inverse 3:2 pulldown" setting and it didn't seem any different. I will do more testing after this (busy) weekend.

If you were to open it in GSpot, if you don't see Pics/s as 23.976 then you messed up.

I will enlist the aid of GSpot to validate my MPEG2 test files.

Perhaps the IVTC is failing for a reason different than what you think. Can you post a link to a short 10 second sample with movement, one that shows the IVTC failing. Use the [ and ] buttons of DGIndex to isolate a small section and then File-Save Project and Demux Video.

Well, it does work every time after seeking back to the start in VDub. If I can't get it fixed somehow I will cut out the opening animation and post a link to it.

I'm now leaning towards it being a problem using the DirectShow filter to seek in the source file. I have an alternative Quicktime filter to try. I normally do my captures/edits in the Avid software and use CCE to encode directly from the reference QT file. This is the first movie I've done and the first capture that really needed a lot of processing (comb filter, noise filters, levels, etc.). Avisynth is great for that.

Worst case, I could re-capture the movie directly to AVI files to avoid the QT stuff. I still have the LD player (for now), but didn't want to spend even this much time on the project.

Thanks for the help!
- LoopinFool

[LoopinFool]

Darryl,

That's an interesting alternative way to do IVTC in Avisynth!
I'll give it a try if nothing else works.

- LoopinFool

[jagabo]

Darryl,

That's an interesting alternative way to do IVTC in Avisynth!

It only works for 1 of 5 possible starting points. It's equivalent to:

SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 8,9).Weave()

I think the SelectEvery() in the first line (as posted) of your script will pose a problem:

...SelectEvery(10, 1,2, 3,4, 6,7, 8,9)...

By removing the very first field you have changed the field order of the remaining fields. AviSynth won't Weave() the fields back together the way you want. When this happens I start one frame earlier or one frame later and adjust the SelectEvery() pattern to suit.

[dphirschler]

Darryl,

That's an interesting alternative way to do IVTC in Avisynth!

It only works for 1 of 5 possible starting points. It's equivalent to:

SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 8,9).Weave()

I think the SelectEvery() in the first line (as posted) of your script will pose a problem:

...SelectEvery(10, 1,2, 3,4, 6,7, 8,9)...

By removing the very first field you have changed the field order of the remaining fields. AviSynth won't Weave() the fields back together the way you want. When this happens I start one frame earlier or one frame later and adjust the SelectEvery() pattern to suit.

Yes. As I said, I was working too hard. I would insert 1-5 frames at the beginning in order to get the pattern synched up, then I would delete the extra frames after IVTC.

I think LoopinFool is experiencing a problem with the DirectShow filter. I used to see much of the same thing with mpeg2 filters. Now I use dgIndex to parse the m2v (or vob) file and that problem has gone away. That worked for mpeg2, but I don't know how to work around the directshow filter with your file. If you play it from the start instead of scrubbing through it, is it fine then?


Darryl

[jagabo]

I think LoopinFool is experiencing a problem with the DirectShow filter.

That was why I asked what format he was using. I recommend remuxing the DV into an AVI file. AviSynth will have no problems dealing with that via AviSource(). And use Cedocida to decompress the DV. It can give you YUY2 output instead or RGB.

[LoopinFool]

That was why I asked what format he was using. I recommend remuxing the DV into an AVI file. AviSynth will have no problems dealing with that via AviSource(). And use Cedocida to decompress the DV. It can give you YUY2 output instead or RGB.

I might do that if I knew of any easy way to pull the DV data out through the reference Quicktime movie without decoding/re-compressing it into an AVI. As far as I know, programs like RADTools just read into frame buffers and save out through AVI compressors. I'm also pretty sure the AVI export from the Avid software does the same.

Thanks, everyone. I now have some ideas for how to attack this (after the weekend).
- LoopinFool

[jagabo]

I think Enosoft has a free tool that will let you remux DV: http://www.enosoft.net/

[LoopinFool]

I did some quick testing Friday night with just the original file through the QT DShow filter. That is indeed the problem.
It looks like when you seek backwards, you get one extra frame from an internal (look-ahead?) buffer instead of the destination frame.
That makes the frame numbers off-by-one which completely changes the pulldown sequence.

I think seeking forward is fine. I should be able to re-do the search for pattern breaks, being careful never to seek backwards.
I may still try an older version of the Medialooks QT filter or a different one.

I'm glad to have found the source of the problem. Thanks again for your knowledgeable input.

- LoopinFool

[LoopinFool]

Update:
I found that any seeking changes the pulldown sequence. So, I re-did my pattern change search using the results of 1-pass CBR encodes. I only needed four zones so it didn't take too long.

As to CCE and the frame rate issue:
CCE Basic doesn't support Film->NTSC pulldown at all. I had the "DVD" option selected during early encodes, which made CCE change the frame rate to be DVD-compliant. It did that by inserting frames.
By changing to the "MPEG-2" option, I got it to do a true 23.976 encode, though the MPEG frames were still flagged as interlaced.
I am able to use PULLDOWN.EXE to fix the m2v file now that I know the magic "-prog_frames p" option (which really should be the default). DVD-lab can also apply the pulldown flags but it left the frames flagged as interlaced.

I may give HCEnc a try for this. Some people like it better than CCE for animation, and it can natively write out a proper 3:2 pulldown-flagged file. There's also ffmpeg, but nobody seems to use it for DVD encoding. That one's also a pain because it doesn't write out a sequence end code in the mpegtsraw format. PULLDOWN.EXE needs an end code or it messes up the end of the stream.

I'm not too worried about the encoder's speed, though. Once I put the processing filters back into my AviSynth script (TComb, ColorYUV, FFT3D, and MSmooth), the full movie will take forever to process anyway.

- LoopinFool

[jagabo]

You can also use DgPulldown to add pulldown flags. It can handle 25 to 29.97 fps pulldown, and other patterns.

[manono]

According to the Doom9 guide to Basic CCE, there's a check box (along with a pic showing exactly where) to have it flagged as progressive:

Check Progressive source if you're dealing with progressive content, if your content is interlaced, make sure this is not checked.

http://www.doom9.org/mpg/ccebasic27.htm

I am able to use PULLDOWN.EXE to fix the m2v file now that I know the magic "-prog_frames p" option (which really should be the default).

I disagree, since pretty much by definition any candidate for pulldown has to be progressive to begin with. It does seem strange, though, that CCE Basic doesn't have the ability to apply pulldown and screws up a 23.976fps encode by adding duplicate frames if you encode it for 29.97fps. And you must know this already, but if planning on applying pulldown the N/M in that pic should be changed to 4.

[LoopinFool]

jagabo,

Thanks for the pointer to DGPulldown. I forgot about that one. I'll give it a try and see if it's faster/better/works on ffmpeg output.

manono,
That CCE check box just tells the encoder to treat the source frames as progressive vs interlaced. I have it checked, along with the Zigzag scan order. It clearly has nothing to do with the output.
CCE SP fully supports film encoding, but Basic doesn't. I found that it always marks the output frames as interlaced even when doing a progressive encode at 23.976. It simply doesn't support pulldown. It's pretty lousy that it duplicated frames with the "DVD" option, but it did create a DVD compliant bitstream!

When I used PULLDOWN.EXE with the defaults (the docs say it will flag all frames as interlaced), both WinDVD and my Panasonic standalone player looked pretty bad. Hard to describe, but every other frame had some softness and field artifacts. Since the stored frames in the m2v file really are progressive, it makes sense (to me) to mark them that way. The pulldown flags are still in there. The results of setting the "-prog_frames p" option speak for themselves.

I've been very happy using CCE Basic for video encodes for around 5 years now. This is my first film-based project and it's been an adventure. Thanks again for the help!

- LoopinFool

[manono]

That CCE check box just tells the encoder to treat the source frames as progressive vs interlaced. I have it checked, along with the Zigzag scan order. It clearly has nothing to do with the output.

Why do you say that when it's not true? How are you determining it's not setting the progressive flag? Just for you I downloaded the CCE Basic Trial, did an encode with that "Progressive Source" box checked. The resulting MPV shows as progressive in every app with which I check it:

[jagabo]

It does seem strange, though, that CCE Basic doesn't have the ability to apply pulldown

I guess that's how they get people to pay $2000 for SP2.

[LoopinFool]

Why do you say that when it's not true? How are you determining it's not setting the progressive flag? Just for you I downloaded the CCE Basic Trial, did an encode with that "Progressive Source" box checked. The resulting MPV shows as progressive in every app with which I check it:

I've been using GSpot and it clearly shows interlaced BFF on my CCE encodes at 23.976 with the progressive source box checked. I checked one with ReStream and it showed the same. I believe I'm using the latest release of CCE (version 2.70.01.16), but I'll have to check.

Thanks for checking that out. I must be setting something different than you did. Of course, the file still needs pulldown processing and all the flags can be re-set to the right values then.

Perhaps CCE is relying on the i/p status coming from its input and saving the "correct" type based on that. The source is DV so is interlaced. I don't know how to fix it if that's why CCE thinks the source is interlaced.

What program did you use to examine the file? I like that display. It's compact and full of info.
*edit: Nevermind, I see it's the latest version of DGIndex.

Trying to learn,
- LoopinFool

[jagabo]

I've been using GSpot and it clearly shows interlaced BFF on my CCE encodes at 23.976 with the progressive source box checked.

GSpot is not reliable for this. Use DgIndex.

[manono]

Right, I forgot to check in GSpot, and if I had I would have mentioned that it's unreliable as far as CCE encodes go. That was an oversight on my part and I apologize. I did check using ReStream and it shows it as progressive. This is using the CCE Basic Trial 2.70.01.14 that puts the nasty logo in the video.

Of course, the file still needs pulldown processing and all the flags can be re-set to the right values then.

Yeah, but you don't have the choice when using DGPulldown. You don't need it either. I stopped using Pulldown.exe when DGPulldown became available, as DGPulldown allows you to do all kinds of "unconventional" pulldowns, perfectly suited for many of my sources.

The source is DV so is interlaced.

It's no longer interlaced after applying your IVTC. I just checked to see if encoding as BFF made a difference anywhere, and it didn't. I'm not quite sure why you're encoding as BFF, though, once it's IVTC'd to progressive 23.976fps.

[LoopinFool]

The source is DV so is interlaced.

It's no longer interlaced after applying your IVTC. I just checked to see if encoding as BFF made a difference anywhere, and it didn't. I'm not quite sure why you're encoding as BFF, though, once it's IVTC'd to progressive 23.976fps.

I only said that in the context that it appears CCE is flagging its MPEG output as interlaced (on my system). I was trying to figure out why it might think the source is interlaced after IVTC in AviSynth.

I would think that checking the "progressive source" option in CCE would override everything else. It's possible I still have the BFF option checked, too (or TFF unchecked - don't remember which is in there).

I'll do some more checking this weekend to figure out why CCE is creating strange MPEG files for me. I do believe I have it properly doing progressive encodes at 23.976 and that it's just flagging its output wrong. I now have more tools with which to investigate. Maybe it was just GSpot getting it wrong.

I also plan to use DGPulldown instead of pulldown.exe. I trust it more and the pattern it creates matches what HCenc creates when viewed in ReStream.

- LoopinFool

[dphirschler]

FWIW, I revised my own manual IVTC function as follows:

function manualIVTC(clip v, int p)
{
	v=loop(v, p, 0,0)
	v=v.SeparateFields().SelectEvery(10, 0,1, 2,3, 5,6, 7,8).Weave()
	v=trim(v,int(p*3/5),0)

	return v.assumeFPS(23.976)
}

I shortened it using the separateFields/selectEvery method. You give it 'p' which would be 0-4. That many frames are added before IVTC to synchronize the pattern. Then the equivalent number of frames are deleted after IVTC.


Darryl

[LoopinFool]

Thanks for bringing this thread back from the dead. Nice little function, by the way.
I had meant to post an update after I got everything working.

The main thing that fixed this project was finding QTSource.dll for AviSynth. It's a real source filter that uses the Quicktime library via its QTInput() function. I got completely consistent pulldown results after I started using it. It fixed all seek-related problems I was getting using DirectShowSource.

My confusion was mainly due to GSpot not giving me the correct info. Once I started using DGPulldown and DGIndex, everything looked right.

If anyone runs across this thread after doing a search -- go get QTSource.dll if you need to process Quicktime files in AviSynth. It will save you headaches.

- LoopinFool

[Selur]

how about replacing 'v.assumeFPS(23.976)' with 'v.assumeFPS(v.FrameRate()*4.0/5.0)' to avoid the hardcoded '23.976' ?

[poisondeathray]

how about replacing 'v.assumeFPS(23.976)' with 'v.assumeFPS(v.FrameRate()*4.0/5.0)' to avoid the hardcoded '23.976' ?

That returns 19.181 fps . For 3:2 (2:3) pulldown removal it will always be "23.976"

but v.assumeFPS(24000,1001) would be more accurate than v.assumeFPS(23.976)

[Selur]

Argh right, the frame rate needs to be taken from the input,...