new brain-dead UnComb YV12 IVTC filter

[trbarry]

Today I sat down and wrote another IVTC filter, UnComb.dll.

This is for Avisynth 2.5+ YV12 only. It's fast, but not very smart, so use it only on non-problem material. I'll just post an excerpt from the readme file below.

As always, feedback appreciated.

- Tom

********** from Readme_UnComb.txt **************

UnComb is a simple IVTC filter for matching up even and odd fields of properly telecined NTSC or PAL film source video. Think of it as a poor mans little brother to Telecide(). It is fast but that's because it makes no attempt at finding frames that must be deinterlaced.

USAGE - To use it just:

1) Place the UnComb.dll in a directory somewhere. If that is the C:\ProgramFiles\AviSynth 2.5\plugins folder (recommended) then you can omit the LoadPlugin command in your script. You can get UnComb from:

www.trbarry.com/UnComb.zip

2) In your Avisynth file use commands similar to

LoadPlugin("F:\UnComb\UnComb.dll")
Avisource("D:\wherever\myfile.avi")
UnComb()

Of course replace the file and directory names with your own. There are no parameters.


KNOWN ISSUES AND LIMITATIONS

1) Requires Avisynth 2.5 and YV12 input.

2) Sorry, currently requires a P-III, Athlon, or higher. Needs SSEMMX support.

3) It will not handle improperly telecined material or bad video edit. It does not even check for combed frames. It just makes the best field match from what is available. It will not blend, interpolate, deinterlace, or even care. It is for reasonably good source material.

4) It does not and likely will not have fancy options like Telecide(). Use Telecide() when needed.

5) It does not decimate. Follow UnComb with Decimate(5) when you need to decimate frames from 30 to 24 fps.

6) It is wicked fast. ;-)

FILE LOCATIONS

For now, both source, this readme, and DLL should be at:

www.trbarry.com/UnComb.zip

A copy of this Readme_UnComb.txt file should be at:

www.trbarry.com/Readme_UnComb.txt

[trbarry]

What? (bump) :D

Nobody cares about Telecide/UnComb/IVTC speed?

- Tom

[Koepi]

Sorry, I sure would - but I live in europe and have to deal with PAL. Well, sometimes we even have NTSC material converted to PAL, and guess what, it simply s*cks as the well paid big companies mess terribly up with that.

Thanks for the new filter, let's hope I get my hands on some Region1 DVD sometime to play around with it.

Best regards
Koepi

[Guest]

Originally posted by trbarry
Nobody cares about Telecide/UnComb/IVTC speed?I care, but I'm trying to finish up some existing projects before I look into the implications of your interesting new work. I fully intend to do so.

[trbarry]

Koepi -

This is just a field matcher, no decimate. So it should also work to correct bad 2:2 PAL cadence when needed. It doesn't even look for 3:2 patterns NTSC patterns.

- Tom

[bb]

Thank you very much for this filter, Tom! I just downloaded it, and I'll report back my findings as soon as I have some results. I'll use it on analogue captures, and I'm curious to see how it works out. Up to now I check the source if it's field shifted or not, and if it is, I use Donald's Telecide (just for lazyness, and to make sure I don't miss field order changes...).

bb

[trbarry]

Just out of curiousity, why don't you post some timing numbers for your filter versus Telecide(post=false)? If it is blazingly faster, we could consider modifying Telecide to use your algorithm (or giving the user a choice of algorithms if their output differs in important ways). Assuming of course, that you'd be agreeable to it.

Donald -

It's blazingly faster. ;)

But please feel free to add the code to yours as sort of a "Telecide-lite" option of post=false if you wish. It's only that one little section of about 50 lines of assembler that would be of any interest.

I still think of you as the IVTC-meister. I don't have the patience to be adding all the options to deal with all the pathological things that folks do to telecined video. And in this your Telecide filter has gone far beyond anything I could do with my quick and dirty Doom9 front end to GreedyHMA, which I would rather not maintain anyway.

But all the options and cleverness can slow things down a bit and I thought maybe a fast simple one for YV12/Avisynth 2.5 might be welcome here. UnComb seems to do an adequate job on most of my HDTV caps so far where I have to be tediously doing it on huge frames of 1920x1080, making performance more of an issue.


bb -

Yep, UnComb should be able to handle most field shifts and order changes. (barring bugs, it's new alpha code)

- Tom

[wotef]

uncomb doesn't seem to give the same results as telecide(post=false) on the pal material i capture from

[trbarry]

Are they good differences or bad differences? ;)

- Tom

[wotef]

ha, good question

after some more testing, for one show (drama), the frames looked very similar indeed

for another show (sports), they both weren't really ideal so i've confused myself now!

guess all i was saying was you wouldn't necessarily assume they'd match the same in all cases, or rather, you'd wanna know in what circumstances they wouldn't

[trbarry]

Sports is likely to be from video cameras. This would have to be deinterlaced by TomsMoComp or something.

Telecide would probaby be smart enough to recognize this and do it automatically but UnComb is too "brain dead", it has no such code.

So be sure ahead of time you use UnComb only for telecined film source material, i.e. movies.

- Tom

[Guest]

@Tom

Thank you for your work and kind words. I will certainly look into incorporating your fast field matching code as soon as my current extended decimate and declick filters reach decent beta states. I also have some good postprocessing code optimizations from sh0dan. So Decomb could well become faster thanks to your two efforts.

[Guest]

I've moved the technical discussion to the Development forum. Please continue the usage discussion and results reporting here. Thank you.

[bb]

Originally posted by trbarry
bb -

Yep, UnComb should be able to handle most field shifts and order changes. (barring bugs, it's new alpha code)

- Tom
Hm, have the results now for my Star Trek capture (the original series). PAL, phase-shifted, but UnComb didn't resolve it correctly - still many combs left after the filter... whereas Donald's Telecide(guide=2) gave a perfect result. Maybe I'm doing something wrong with UnComb's long list of parameters? ;)

I'd like to add that I use AviSynth 2.51 with a YUV2 source (converted to YV12 right at the beginning of the script).

bb

[trbarry]

bb -

Dunno. It should be able to handle it. Are you sure it was film source? And can Telecide(post=false) handle it okay?

Finally, is it just on scene changes where it fails?

- Tom

[Guest]

@bb

Can you make available a short (unprocessed) source clip that does not get matched correctly? This would really help Tom and I. This new approach by Tom has so much portential that anything you can do to help get it perfected will pay off big for all of us!

Thank you!

[Guest]

Just wanted to point this out for those who haven't realized it...

You can make a full IVTC with postprocessing out of Tom's field matcher:

Uncomb()
FieldDeinterlace(full=false)

Add decimation if you have NTSC 3:2 telecining:

Uncomb()
FieldDeinterlace(full=false)
Decimate()

Barring unforeseen developments, this new matching will find it's way into Telecide(), so this may be a temporary expedient. :)

[Guest]

I've started running Uncomb() on my entire torture test suite and I can confirm bb's results. Uncomb() does emit combs in cases where Telecide(post=false) does not. And they are not scene changes. I am now trying to pin down the reason. It may be due to the restriction to luma. I will report back when I determine the cause.

On the other hand, there are cases where Uncomb() emits good matches where Telecide() does not. The important question is which one succeeds more often.

[trbarry]

Donald -

Interested in your opinion here. Imagine an edit done on teleceined but staggered PAL video giving frames:

a b c edit f g h
b c d edit g h j ...

UnComb only looks backward, so the f/g frame has no match. I decided to live with that because of my rule of taking at least one field from every frame, to keep the timing smooth. But that is why I asked about scene changes since I thought the change would have been obvious.

OTOH, maybe I just have a silly bug somewhere. Be interested to hear the results of your analysis.

- Tom

[bb]

I apologize. I did the encode again, and this time everything was fine: no more combs after UnComb. I still don't know what was wrong, because I don't remember that I changed anything in the meantime - weird. But I have to assume that it was my fault.

@neuron2: I doubt that my material can compete with your torture tests. I didn't see any combing in my second test after applying either filter (UnComb / Telecide), so there probably aren't any borderline cases in the 48 min episode.

False alarm from my side, congratulations to Tom for the fast filter!

bb

[Guest]

Originally posted by trbarry
a b c edit f g h
b c d edit g h j ...

UnComb only looks backward, so the f/g frame has no match. I decided to live with that because of my rule of taking at least one field from every frame, to keep the timing smooth. But that is why I asked about scene changes since I thought the change would have been obvious.

OTOH, maybe I just have a silly bug somewhere. Be interested to hear the results of your analysis. Both Telecide and Uncomb emit a combed frame at this edit. The VirtualDub Telecide will emit a frame c/c twice if desperation mode is turned on. The Avisynth Telecide would need the six-way match to do that.

Is it better to emit a duplicate than a combed frame? Is it worth the extra processing? I doubt it. I suppose it could be optional.

Your point about smoothness seems to be moot at a scene change. :-)

I think your comparison strategy is fine and probably Telecide will adopt it as well.

The jury is still out on whether simple field differencing is adequate (even with the adjustment for the spatial offset). I have established that your differencing performs better than the simple differencing without adjustment as done by (say) IVTC4. When I complete the torture suite I will know whether it performs as well as, equal to, or better than full comb detection. At that point a decision can be made about whether the performance gain outweighs any possible degradation in matching. Of course, if it matches better on the overall suite, the decision will be simple. :)

I don't think there is any bug in your code right now.

[Guest]

@Tom

I've uploaded one of my torture clips to allow you to assess matters. It is available here (warning -- 108 Mbytes):

http://shelob.mordor.net/dgraft/misc/chest.avi

Uncomb() performs worse than Telecide(post=false), especially as the chest moves from left to right. Neither is perfect, of course, but Uncomb() emits many more combed frames.

My testing so far supports my previous belief that matching by means of field differencing does not work as well as full comb detection. It is also not surprising on theoretical grounds.

EDIT: Forgot to post the script:

loadplugin("uncomb.dll")
loadplugin "decomb.dll")
avisource("chest.avi")
converttoyv12(interlaced=true)
uncomb()
#telecide(post=false)

[trbarry]

Donald -

Thanks, downloading now.

- Tom

[Defiler]

Tom:
You mentioned HDTV. Are you finding that the frame order, etc, is quite regular/good with HDTV? I'm still waiting on broadcasts to start in my area, and I'm curious. This isn't a derailment.. I'm just wondering if your new IVTC filter is a response to something you've noticed while recording HDTV.

Speaking of HDTV.. is there a high-performance MPEG-2 splitter yet? As I recall, that was the nasty bottleneck preventing good full-resolution software playback of HDTV streams.

[trbarry]

Defiler -

Let's move this to the HDTV forum if you want to follow up.

But briefly, I don't consider frame order to be reliable anywhere and HDTV is no exception. They use dumb (but expensive) real time single pass encoders.

And UnComb is mostly a response to waiting to IVTC 1920x1080 clips. They take longer.

Search for a company called Dvico for a card (Fusion) with a mostly workable software HDTV playback solution, using Radeon and Geforce hardware accel.

- Tom

[Defiler]

Thanks. If I have any other questions, I'll take it to the correct forum. Heh.

[Guest]

Tom,

If you did the matching strategy as you are doing now but with the current frame and the next frame, instead of the current frame and the previous frame, you would handle bad-edit scene changes properly.

[trbarry]

You sure? It seems it would just move the problem frame by one.

- Tom

[Guest]

a a b c c
a a c c c

Your strategy fails on the third frame. My suggested modification to it succeeds on all frames. Still doubtful? :)

[trbarry]

Donald -

But how is that any more probable than its reverse?

c c b a a
c c c a a

It seems to me a frame before a video edit cut will have the best chance of matching to the prev frame. But the frame after a video edit will have the best chance of matching forward the next frame. And any cut generates one of each.

So any time we aren't lucky we are liable to get

a b c | e f g
b c d | f g h ...

and we are stuck either way. I thought of looking in both directions but then can end up adding a new kind of judder since there may well be two acceptable match pairs for any frame and whatever criterion we use might cause prev and next matching to switch often. This would be a constantly changing video delay. I don't know if that would be visible or not. (-1,0,+1 field delay)

So it seemed simplest to just accept the possibility of a combed frame at a video edit.

- Tom

[Guest]

You're right. I momentarily forgot that you do not know the field order. If you know the field order, you can look forward for TFF and backward for BFF. Your cut scenario

c c b a a
c c c a a

is a BFF sequence, otherwise the third frame would play out of order. So it seems that to handle the edits best we need to know the field order and match forward or backward appropriately. Decomb 5 knows the field order but I need to add this little finesse.

Does it sound reasonable?

[Guest]

I'm still wrong. :)

There are 4 cases of an orphaned-field bad edit:

TFF:

a b c [and] a a c
a c c a b c

BFF:

a c c [and] a b c
a b c a a cIt can be seen that for either TFF or BFF you have to match forward and back to handle both cases for that field order. But doing both matches all the time can introduce dups and/or missing frames. So it looks like for the cases not dealt with correctly, you have to detect the combing and at that point attempt the other match before giving up.

I do think the first case for each field order may be more probable. Think about how many cuts you need to make to produce the two cases. If true, it would argue for doing forward matching rather than your backward matching.

Does *this* now sound reasonable?

[trbarry]

"Does *this* now sound reasonable?"

Dunno. ;)

But you have convinced me that I should seriously take another look at MPEG2DEC3 and find a way to ensure it reliably always returns the TFF flag on a frame by frame basis.

Otherwise I have to think about it some more.

- Tom

[Guest]

Seems to me an AVI has one fixed field order. There's nothing in the AVI format to allow it to change per frame. Am I wrong? We speak of codecs being TFF or BFF. That wouldn't make sense if an AVI could change.

So what is the point of passing the MPEG flags along to Avisynth? The order flag there changes only to allow for the repeated fields. The field order of the content is not actually changing per frame.

For a truly TFF content, the clip has to start with these flags: 30123012... or 222222230123012...

For a truly BFF content, the clip has to start with these flags: 01230123... or 00000001230123...

Knowing that may give a way to get the true field order for the resulting AVI. But if someone makes a bad VOB cut...?

Maybe I am misunderstanding your intent.

[trbarry]

Maybe I'm biased by my HDTV caps. But due to commercial insertions, etc., my recent HDTV recording of NBC's Carrie had long sequences of valid telecined movie interspersed with section of top first video (commercials) and also sections of bottom first video. I can cut out those commercials but I'm not convinced yet they might not change the cadence somehow.

The real time encoders used for digital TV just throw everything into the pot. This NBC recording was the first OTA cap I've done that even had RFF flags at all, but I'm being defensive in case it is an indicator of the future (likely).

- Tom

[CruNcher]

@ trbarry
this filter is again awesome as TomsMoComp i tried it on Matrix Ntsc Trailer had many problems with tweaking telicide correct and it never wanted to get perfect sorry neuron2. Your filters are allways
foolproof :) that you both now work together is great i think we will have soon the ultimate TomGraftTeliComb filter :) keep on you both are a good example of the OSS Spirit, btw i got a little technical question how do DVD filters like Nvidia or Intervideos Deinterlace ? is it Adaptive ?

[trbarry]

btw i got a little technical question how do DVD filters like Nvidia or Intervideos Deinterlace ? is it Adaptive

Cruncher -

There were some extensive discussions of this over on AVS awhile back, but no definitive answers. I think increasingly most of them are trying to take advantage of the M$ code built into VMR or DX9 or whatever. But I don't know how sophisticated it is.

- Tom

[Katie Boundary]

Oh wow. I abandoned Decomb long ago in favor of separatefields/selecteven/resize specifically because I hated the idea that the filter would just go and blend frames without my permission (the only things I hate worse than interlaced frames are blended frames). I wish I had known about this plugin 11 years ago!

The link now leads to something unrelated. Is there a place where I can still get this?

[Reel.Deel]

The link now leads to something unrelated. Is there a place where I can still get this?

The wiki: http://avisynth.nl/index.php/External_filters#IVTC_.26_Decimation

[Katie Boundary]

Cool, thanks.

[ChiDragon]

I assume you're aware of TIVTC's capabilities for such hybrid sources.

http://avisynth.nl/index.php/VFR

[Katie Boundary]

Attempting to use this as a less carpal-tunnel-inducing replacement for tfm(mode=0,pp=0,micmatching=0) for perfectly telecined film sources still yields interlaced frames. This filter just sucks at field-matching even when correct matches exist. :(

Did anyone ever make a filter like this that focused on speed without fancy tricks, but could match fields competently?

[johnmeyer]

Attempting to use this as a less carpal-tunnel-inducing replacement for tfm(mode=0,pp=0,micmatching=0) for perfectly telecined film sources still yields interlaced frames. This filter just sucks at field-matching even when correct matches exist. :(

Did anyone ever make a filter like this that focused on speed without fancy tricks, but could match fields competently?
If you really have "perfectly telecined film," the usual TFM/TDecimate should work perfectly. I've used it literally hundreds of times and never had problems. I always first "walk through" a few hundred fields from various sections of the film after using separatefields() or bob() so I can look at individual fields. This gives me some idea of the patterns and whether there is something unusual going on, like you sometimes get with film that went between NTSC pulldown and PAL, or vice versa. You can also sometimes get orphaned fields at scene changes, although TIVTC (the package that includes these libraries) usually handles that pretty well.

I've also used many of the "more exotic" settings in TFM for field matching and decimation that are completely outside of what the tool was intended to do. This includes removal of pulldown fields from a shutterless projector that I developed as part of my rather unusual 16mm film transfer system.

Now, if you are doing anime or other cartoon film, then you might have to spend a little time with the settings, because the pulldown on those gets mixed in with the intentional repeats used by animators. I've done only a few cartoons, and TFM/TDecimate did seem to work, with a few tweaks.

So my advice is to stick with TFM/TDecimate and fiddle and tweak a bit.

[wonkey_monkey]

If you really have "perfectly telecined film,"

If only there was some way to know!