Log in

View Full Version : Oh my freaking god (script to kill hard pulldown)


Katie Boundary
28th February 2015, 05:31
Separatefields()

Decimate(mode=2)

weave()

Why didn't I think of this earlier?!?

And how do I fix field order?

And why is decimate killing the wrong frames AGAIN?

Katie Boundary
28th February 2015, 06:07
Selectevery is a workable substitute for decimate when I just need to extract short clips, but the pulldown pattern changes every few seconds, making restoration of the whole episode impossible. Stupid Operation Overdrive.

colours
28th February 2015, 06:16
If you have a query relating to Avisynth usage, there's a subforum for exactly that.

SeparateFields().Decimate().Weave() is suboptimal for multiple reasons. It messes up field order (as you probably already noticed) which can introduce bizarre aliasing artifacts after the Weave(), and the top/bottom fields do not necessarily match each other better than the surrounding fields, so Decimate() can potentially delete the wrong field if you use it this way.

Try Telecide().Decimate() instead. This is still an entirely automated solution and it will on occasion detect the wrong telecine pattern; if for whatever reason you must have perfect inverse telecine, YATTA (http://ivtc.vapoursynth.com/yatta/) is the tool of choice.

foxyshadis
28th February 2015, 06:27
Ever tried TFM/TDecimate?

If the problem is that the source is actually moving between fields because of a bad hard telecine transfer, you don't have many options but a manual restoration (which still can't be perfect, since it's moving between "matching" fields). The well of ways to horribly botch video is very deep and ugly.

Katie Boundary
28th February 2015, 06:32
It messes up field order (as you probably already noticed)

"predicted" would be more accurate than "noticed", but yes. I was hoping that someone somewhere had written a plugin that would automatically detect and correct the field order, or at least naively reverse it every 2 frames.

the top/bottom fields do not necessarily match each other better than the surrounding fields, so Decimate() can potentially delete the wrong field if you use it this way.

Nah, Decimate is misbehaving even when the fields from the same frame do match each other best. This isn't the first time it has misbehaved like this.

Try Telecide().Decimate() instead.

I don't like blended frames any more than I like interlaced ones...

Ever tried TFM/TDecimate?

Never heard of it. Will look.

If the problem is that the source is actually moving between fields

I don't know what that means :(

manono
28th February 2015, 07:12
I don't like blended frames any more than I like interlaced ones...

If you had bothered to read the very good included doc, you'd have known already that you can select a different post-processor, one that interpolates rather than blends. In addition, if the post-processor is kicking in when it shouldn't you can fine tune the CThresh or other settings so that it isn't so quick to deinterlace.

Instead of whining about things you don't understand, maybe post a sample of a difficult section so one of us can have a look. I'd almost be willing to bet all these DVDs you've been having trouble with aren't nearly as difficult to IVTC as you claim.

Moving this to the AviSynth Forum.

colours
28th February 2015, 07:35
I was hoping that someone somewhere had written a plugin that would automatically detect and correct the field order, or at least naively reverse it every 2 frames.

This is rather like solving the wrong problem, since you should just not use SeparateFields.Decimate.Weave. That said, automatic field swapping is not hard to do with ConditionalFilter.

source = last
swapped = SeparateRows(2).SelectEvery(2,1,0).WeaveRows(2)
swapmask = mt_makediff(source.CombMask(0,255),swapped.CombMask(0,255)).RemoveGrain(3)
fixed = ConditionalFilter(swapmask,source,swapped,"AverageLuma()","<","128")
fixed

althor1138
28th February 2015, 08:52
TFM messes up too much for me to feel comfortable just letting it do its thing so I usually manually IVTC using this semi-automatic method below. If none of these 5 versions work you can remove the call to assumetff and see what happens. just flip through frames until you see which one is progressive and then use that pulldown pattern to manually ivtc. If the cadence is changing every few seconds most automated filters will not do a very good job at getting it right and will just blend or deinterlace the bad frames. This is why I manually IVTC even if it means it will take me a decade to complete.

dw=clip.assumetff().doubleweave()
a = dw.Pulldown(0, 2).Subtitle("0, 2")
b = dw.Pulldown(1, 3).Subtitle("1, 3")
c = dw.Pulldown(2, 4).Subtitle("2, 4")
d = dw.Pulldown(0 ,3).Subtitle("0 ,3")
e = dw.Pulldown(1, 4).Subtitle("1, 4")
show=ShowFiveVersions(a, b, c, d, e)
return(show)

TheFluff
28th February 2015, 10:18
TFM messes up too much for me to feel comfortable just letting it do its thing so I usually manually IVTC using this semi-automatic method below. If none of these 5 versions work you can remove the call to assumetff and see what happens. just flip through frames until you see which one is progressive and then use that pulldown pattern to manually ivtc. If the cadence is changing every few seconds most automated filters will not do a very good job at getting it right and will just blend or deinterlace the bad frames. This is why I manually IVTC even if it means it will take me a decade to complete.

2003 called and wanted its workflow back

Katie Boundary
28th February 2015, 10:19
Well, TDecimate behaves MUCH more nicely than decimate, so thanks for pointing me in that direction :)

Unfortunately, there are some sections of video where the two fields that make up a frame will form an odd-even pair, and other parts where they form an even-odd pair. A close inspection reveals that this is because there are some frames that contribute only a single field, not 2 or 3. Crap.

But hey, it would have been a pretty clever solution if the pulldown hadn't been screwed up, right?

If you had bothered to read the very good included doc, you'd have known already that

I did read it, but that was like ten years ago lol.

you can select a different post-processor, one that interpolates rather than blends.

cool

I'd almost be willing to bet all these DVDs you've been having trouble with aren't nearly as difficult to IVTC as you claim.

Carmen Sandiego, ER, Birds of Prey, and Star Trek: TNG all include natively 59.94 field-per-second content that can't be IVTCed because it was never telecined to begin with. Carmen Sandiego also includes blended frames. The CGI sequences in Star Trek: Voyager were rendered at 29.97 progressive frames per second and the live-action stuff is all film, so I can at least get clean footage out of that even if I have to put up with framerate issues. Captain Planet is a mixed bag; some episodes, like "Polluting by Computer", are almost pure film, some are a mix of film and NTSC, some are pure NTSC, some have blended frames, some don't... I dunno what the heck those guys were smoking when they did those transfers. South Park is the worst transfer I've ever seen; it looks like someone interlaced the frames, resized them, and then interlaced them AGAIN. What kind of monster resizes interlaced frames?!?

Compared to all of those, yes, Power Rangers Operation Overdrive is quite clean and salvageable. It's just being a tricky little bitch, that's all.

colours
28th February 2015, 10:22
If the cadence is changing every few seconds most automated filters will not do a very good job at getting it right and will just blend or deinterlace the bad frames.

Negatory. Roughly speaking, TFM deinterlaces only when it fails to find a good match (in other words, you have some kind of isolated field), in which case the only choices are to deinterlace that frame or to decimate it away. TDecimate doesn't blend by default, either.

In my opinion, it's better to leave pathological sources (such as those that change pattern often) to automated/semi-automated IVTC methods because any amount of effort you put into making sure the IVTC is "exact" will already be in the diminishing returns territory. If you miss a pattern change, good job, your result is already worse than what TFM.TDecimate would do!

Anyway, speaking from experience (I once spent somewhere around 30 hours manually IVTCing/deinterlacing/deblending a six-hour music concert), manual IVTC is strongly not recommended unless you're doing it just for the sake of learning how to do it. It's a complete waste of time. Learn how to use YATTA instead, which will be slightly less of a waste of time.

TheFluff
28th February 2015, 10:49
pretty much what colours said. if you really care that much about your ivtc (and you probably shouldn't, it's not worth the effort), use YATTA and save yourself at least some effort. especially if you want vfr, doing that by hand is pretty annoying.

althor1138
28th February 2015, 11:17
If you want speed and ease of use with good results I'd definitely recommend tfm/tdecimate as they work very good. In my experience, they do fail though. Like colours said though, any effort put into it is not going to get you much in return.

wonkey_monkey
28th February 2015, 13:04
Star Trek: TNG all include natively 59.94 field-per-second content

Out of curiosity, can you point me at a specific example of 60i in TNG? I thought all the effects were done at 29.97.

Katie Boundary
28th February 2015, 19:22
Out of curiosity, can you point me at a specific example of 60i in TNG? I thought all the effects were done at 29.97.

Q's "flash" effects.

So we're talking about maybe 0.01% of each episode with Q, and there were only like a half-dozen such episodes, but it's still enough to trigger my autistic fury :)

https://scontent-sjc.xx.fbcdn.net/hphotos-xpa1/v/t1.0-9/10982457_1531237153807408_8552049505139150781_n.jpg?oh=02ceea39ac0147aabbae1407998802fc&oe=5587C7EA

scharfis_brain
28th February 2015, 19:48
TNG S05E06 contains lots of 60i.
This episode has nearly all crew members got addicted to a VR-disc-game.

All sequences containing CGI of the VR-game itself are 60i.