New GreedyHMA deinterlace filter from DScaler

[trbarry]

I guess this is mostly a cross post since I've added this in replies on a couple other boards, but it probably should have its own thread in the Avisynth forum.


I sometimes work on the DScaler open source TV/Scaler project and I recently created an experimental port of my DScaler Greedy (High Motion) deinterlace plug-in to life as the GreedyHMA Avisynth filter.

WARNING, much assembler, for SSE supporting machines ONLY. It will bomb on others!

If you don't have at least a 550 mhz Celeron, P-III, or Athlon then don't try it. If this becomes popular then I'll probably create a P-II, 3D-Now compatible version, but it would be a certain amount of work.

This doesn't have the full DScaler IVTC code in it but it does have optional pulldown matching. That is, it will remove the weave artifacts but not drop any frames. (How do you drop frames in an Avisynth filter?)

I'll add some other IVTC enhancements later if there is any demand.

LATER EDIT: It does now do IVTC (read a bit further in this thread).

See www.trbarry.com/Readme_GreedyHMA.txt and www.trbarry.com/GreedyHMA.zip for more details of this still experimental filter.

The GreedyHMA filter can give some decent results with anime and some material with messed up pulldown sequences caused by commercials, edits, etc. I'm fairly happy with the deinterlace part of it but the pulldown/IVTC recognition could still use improvement. If you've already got a source with perfect pulldown material then you are probably better with one of the other IVTC methods. But for mixed or video stuff please give it a try.

I need feedback here as I am most definitely not an Avisynth guru.

- Tom

[Larva]

Sounds like it will be great for working with anime sources that are part telecined and part 30 fps progressive. I'm not sure if this would work, but it might be good if it could optionally return repeated frames as dropped instead of removing them (for hybrid sources). That way they would be repeated automatically (like svcd with 2:3 pulldown), and wouldn't take up any extra space.

[trbarry]

Right now it just returns all the frames, but possibly either deinterlaced or matched with different fields, depending upon which makes the least comb (weave) factor.

Right now when I want to decimate to only 24 fps I just follow the GreedyHMA filter with a SelectEvery(5,1,2,3,4). That will do the job, but causes judder.

I thought the easiest short term solution to code would be to drop whichever frame out of 5 was the most match-like in the previous group of 5. But again, I haven't even figured out how to tell Avisynth that I want to drop a frame yet. It may be in the doc or the code somewhere, but I was hoping I could be lazy and someone here would just know. If not I'll find it.

There is really not very much Avisynth specific code in this. I just designed the Greedy/HM stuff so it would be easy to port various places and Avisynth seemed to offer the most leverage besides DScaler.

And I wanted something that could deinterlace 1080i HDTV for my own purposes. Avisynth/DVD2AVI seemed the best way to process those files.

So, did anyone try this yet? Any comments?

- Tom

[DDogg]

I'm coming in late on this, but it was odd, as today I was at the store looking at vid cards and the thought popped into my mind, "I wish we could get the descaler guys to work with us". Then, this post, strange indeed. ;)

I hope to get the time to play around with this myself soon but I hope Wizard, Steady and Dividee can look too. Wizard wrote the IVTC we have been using and should have some good input. Have you checked out the development forum?

Let us know how we can help the effort and thxs for sharing :)

DD

[trbarry]

I actually posted first about this on a reply at the IVTC thread over at the Developer's forum but that is not very active today.

I've been mostly sitting on this for a few weeks. I'd hoped to get the full IVTC with frame dropping into it before pushing it much but I've gotten side tracked with some other unrelated issues. Once I'd posted on the developer's forum (on impulse) it seemed I should start the thread here.

- Tom

[Larva]

Doing some testing on a hybrid anime clip, which is primarily telecined but also includes some 30 fps progressive CG scenes. It's 10-15% faster than dividee's smart deinterlace port (motion map denoising/inerpolate/fast mode), and the telecined parts are comparable in quality.

Edit: removed comments about quality in progressive scenes

On second thought, it seems to handle both parts equally well. The filesize was lower than with smart deinterlace as well, although that could be different on another clip.

Edit 2: Upon closer analysis, this is much better for telecined stuff. I think the filesize was lower because repeated frames look the exact same. With smart deinterlace set to interpolate, you can tell it's a repeated frame but it shifts around a little.

[trbarry]

Edit: removed comments about quality in progressive scenes

Larva -

I guess I'm afraid to ask. ;)

But .. something I should know about progressive scenes?

If you happen to have your source on DVD or VHS and a DScaler compatible capture card then you can experiment real time with the various GreedyHMA options and more quickly see what they might look like, though I guess you can mostly do that with Virtualdub anyway.

Since the DScaler version is really executing the same code you might test turning on and off things like the Auto Pulldown, Median Filter, Vertical Filter, or Edge Enhancement with DScaler v3.08 or so, using Greedy/HM. Then set the Avisynth GreedyHMA options accordingly for the batch job. You woudn't get quite the same results but it should be close.

As far as performance, it shouldn't be too much of an issue compared to Avisynth/DVD2AVI/Vdub, since this was written to run real time on my machine (866 P-III PC133) and output, say, 720x480 @ 60 progressive frames / second under DScaler, as long as you don't turn any of the extra options on. And even then it would be very close to that. But I could be overlooking something.

- Tom

[Larva]

Basically, I thought it was screwing up one scene badly, but that part was screwed up to begin with. As for DScaler, I've been using that for a while, but I hadn't tried out this setting before. BTW, I thought vertical filter would help out in this section, but instead it made a funky colored strip on the right side throughout the clip. Then again, I don't have SSE, so that could be my computer's fault.

Either way, good luck with the frame removal. Looks like the pulldown reconstruction is working great so far, although I'm guessing it would run into problems with field order changes since that is one of the settings. A workaround until you get frame removal working would be to use Donald Graft's decimate filter, although that would mean getting VirtualDub involved.

[trbarry]

BTW, I thought vertical filter would help out in this section, but instead it made a funky colored strip on the right side throughout the clip. Then again, I don't have SSE, so that could be my computer's fault.

I see it didn't make it into the Readme file but GreedyHMA currently only properly supports horizontal resolutions that are a multiple of 16 pixels. In DScaler this could be adjusted by the Video_Adjustments/Overscan setting but in Avisynth you would have to use Crop(). But please let me know if that doesn't fix it.

I think Divx4 also currently has to be a multiple of 16 pixels and even some video cards won't display using a hardware overlay if you don't do this. But I could loosen this up if it became a major issue.

[Larva]

Hmm, it was already cropped to 704x480. Probably just a fluke.

[trbarry]

Maybe, but it doesn't sound good. I'll try to check one that size. Could you post your filter script?

[Larva]

Here is the problem script:

MPEG2Source("test.d2v")
Crop(8,0,704,480)
GreedyHMA(1,0,1,0,1,0)
BicubicResize(480,360,0,0.5)

It works fine without cropping or with vertical filter off however.

[trbarry]

Larva -

There was indeed an off-by-1 bug in the vertical filter code. It would give you a bonus 4 pixels of garbage on the right of the screen when the vertical filter was turned on. Maybe when you didn't use crop those pixels happened to be all black. Let me test a longer batch run overnight and I'll put a new one out tomorrow.

BTW, thanks for testing and reporting this. I'm a little surprised that after all the posts here about needing IVTC/deinterlacing code I think you are the only one that has actually run this.

Anybody else tried it?

- Tom

[Larva]

Maybe things are just slow with the forum switch. In case anyone is just joining the discussion, this filter looks like the best way to deal with hybrid ntsc/telecined animes (aside from TMPG's inverse 3:2 pulldown option, but that only works with svcd). That's right, no more shimmering with smart deinterlacer. ;)

Edit: Thanks for fixing that little problem. The rightmost 4 pixels were black before cropping. A couple questions: Is vertical filter needed to get rid of all interlacing? And what effect does the delay in the median filter have exactly?

[Inwards]

This is an interesting project. I started doing my own thing a few months back in an attempt to create a better filter for dealing with hybrid anime. My approach was a bit different, though.



My filter would use the RFF/TFF flags in the original m2v stream to reconstruct all the progressive frames possible, then it would try and reconstruct/deinterlace the remaining 29.97fps frames. The nice thing about this approach is that the RFF/TFF stripping gives perfect results for those frames and consumes very little CPU resources.



Problem is, I couldn't come up with an deinterlacing algorithm that gave decent results. You always get jerky motion somewhere... My next idea (which I never got around to implementing) was to compare the frames to each other and throw away ones that seemed to be identical. I ran out of time/motivation/expertise by that point, though. If any of this sounds like it might be useful, let me know...

[trbarry]

Inwards -

In DScaler those flags were never available to us so we did without. :(

Are they available somehow to Avisynth filters? I always thought I'd have to imbed GreedyHMA directly into DVD2AVI in order to have access to those.

Though it would be very nice if DVD2AVI would (or does) pass them along for Avisynth to use.

I've posted on other forums that i think the reliability of those flags may be increasing as the DVD mastering industry matures, but I don't have any hard evidence of this.

But I'd still love to be able to see them in GreedyHMA. I'd just add a "Trust the mpeg flags" option.

- Tom

[Inwards]

As far as I know, the the D2V file does not pass along the status of the flags. However, if you go noodling through the d2v file, you can figure out what is going on. Given that the d2v file format tends to change with every release of dvd2avi, I decided not to go that route. Instead, I created a little program that read the original m2v stream directly and created two files: one file that recorded exactly what the mpeg-2 flags were and another that told AVISynth with fields to delete. My filter then read the latter file and nuked/recombined those fields right off...

As far as the reliability of the flags, I can guarantee the RFF/TFF flags will perform as advertised. Other parts of the MPEG-2 spec seem open to interpretation, but this flag seems to behave in a uniform fashion. Of course, what you cannot guarantee is that the whole stream will be pure 24fps with no interspaced 30fps frames thrown in there. That's why I created the frame file...

That much I had working. The real problem was dealing with the remaining 30fps frames. Sometimes you have real honest-to-goodness 60 fields/sec animation which needs to be creatively reconstructed. Other times there was so much ghosting/garbage left over from the original transfer that my algorithms couldn't make an intelligent decision.

Your work sounds promising, so perhaps if I get some time this week I can run some of my test clips through and see what happens...

[trbarry]

I'd very much like to know the results. So far I've spent about 90% of my effort on deinterlace of 60 fps stuff, 10% on pulldown/IVTC, and zero % trying to process the flags, since I didn't have any.

I'm especially interested in how good the flags based approach can be made to work in the face of edits, video overlays, dropped frames, and just bad mastering.

... and another that told AVISynth with fields to delete. My filter then read the latter file and nuked/recombined those fields right off...

Uhh, how do you do that?

- Tom

[trbarry]

I posted a bug fix for the vertical filter bug, and also increased the max size to allow for HDTV 1920x1088 (previously 1080) since that is what can actually get captured by my WinTV-HD card.

See www.trbarry.com/Readme_GreedyHMA.txt and www.trbarry.com/GreedyHMA.zip for the new dll.


Larva -

Sorry, I missed your question in my above post. The Vertical Filter isn't needed. It's just another option if you've got a messy source but sometimes it also seems to give good results if you are going to be downsizing. If you are going to be adding other smoothing filters anyway then you can sort of get this one for free, it doesn't add much to the processing time. And sometimes maybe it will be enough, possibly combined with the (temporal) Median Filter on a low setting (say 2-4). But beware the Median Filter can cause motion artifacts if set higher than 5 or so on fast moving material.

Some notes on delay. GreedyHMA causes a 1 field (1/2 frame) time delay in the video unless Median Filter is on, then it is a 2 field delay. You would think that would mean you should also delay the audio for (NTSC) 17 or 33 milleseconds but I haven't been able to verify that because of other unrelated sound sync problems I've been having with HDTV material. They just dwarf this issue. And I'm fairly dumb when it comes to computer sound stuff and I'm such a bad lip reader that it takes me forever to adjust sound sync when there is a problem.

So I'll certainly defer to others on that.

- Tom

[Inwards]

Originally posted by trbarry
I'd very much like to know the results. So far I've spent about 90% of my effort on deinterlace of 60 fps stuff, 10% on pulldown/IVTC, and zero % trying to process the flags, since I didn't have any.

I'm especially interested in how good the flags based approach can be made to work in the face of edits, video overlays, dropped frames, and just bad mastering.



Uhh, how do you do that?

- Tom

Take a look at the sourcecode for the AVISynth IVTC plugin (get it from www.videotools.net). It should give you some clear examples on how to recombine/delete fields.

As far as how well the flag removal method works, I guess that it's tough to say as I was never able to produce results that were significantly better than just running it through TMPGEnc with adaptive deinterlace on.

I do think that the combination of mpeg-2 flag-based IVTC and proper field decimation is the most promising route, though. My filter is in pretty ugly shape as it never got out of proof-of-concept mode. If you think that it'll help, I'll scrape together some code and send it your way...

[trbarry]

Inward -


Take a look at the sourcecode for the AVISynth IVTC plugin (get it from www.videotools.net). It should give you some clear examples on how to recombine/delete fields.

Inward -

I looked at that about a month ago but apparently I didn't know enough then about Avisynth to understand what was really happening. I took another peek. If IVTC works okay then that should be the missing piece for me. - Thanks


I do think that the combination of mpeg-2 flag-based IVTC and proper field decimation is the most promising route, though. My filter is in pretty ugly shape as it never got out of proof-of-concept mode. If you think that it'll help, I'll scrape together some code and send it your way...

Yes, by all means! I don't want to have to rely on the flags but I'd really like to be able to use them when they were available.

- Tom

trbarry@trbarry.com

[trbarry]

Well, okay. I've been happily claiming that I use SelectEvery() following GreedyHMA() in order to decimate frames from (aprox) 30 fps down to 24. Meanwhile I'd been starting to wonder whether my new deinterlace method worked quite as well as I previously thought.

GreedyHMA has to look at EVERY single frame in order to run properly. But what I did not understand is, if you have a file containing 100 frames (I made one) and you use the following script

GreedyHMA(1,0,1,0,0,0)
SelectEvery(5,1,2,3,4)

then GreedyHMA will be called only 80 times and will not always process adjacent frames. It seems it doesn't matter which order the commands are in. This of course royally screws up any chance of properly handling deinterlace or pulldown functions. My mistake.

So for now, GreedyHMA is only for deinterlace or pulldown matching, to 30 fps. If you really want 24 fps I'm afraid you'll have to do two passes or find something more clever to use.

But I still expect to fix this soon. And maybe I'm still overlooking something.

- Tom

[Inwards]

Sounds like we need to clarify a couple of things...

Deleting frames in AVISynth:

This doesn't really happen. If you look at the IVTC plugin, what it does is give you back a different frame from the one that you asked for. You never actually remove a frame, you're just choosy about which ones you pass back.

Eg: Requesting frame 24 from the filter will end up with frame 30 being displayed. Every time a request for a frame is made, a realtime IVTC happens. To compensate for this, the number of frames and the framerate are overidden.

If you're still lost, I could post a simple example.

Proper implementation of the deinterlacer w/IVTC:

Ideally, you want to recombine all the fields possbile (possibly using a flag file to help) using some kind of interlace detection scheme. Frames that fall within a certain interlaced threshold will need to have the deinterlace routine applied. The trick is to do it in such a way as to not create jerky motion. This is where things get nasty...

[trbarry]

Thanks, yes, I'd finally puzzled out some of that from tracing my own code and revisiting the IVTC code.

But at first I never would have guessed that applying a selection to the result of GreedyHMA would cause GreedyHMA to process fewer frames.

And I never would have come up with the idea that you could set the file size to be 20% smaller and then still proceed to happily read past the end of where you said it was. But I guess there are multiple different view of the size.

Ideally, you want to recombine all the fields possbile (possibly using a flag file to help) using some kind of interlace detection scheme. Frames that fall within a certain interlaced threshold will need to have the deinterlace routine applied. The trick is to do it in such a way as to not create jerky motion. This is where things get nasty...

I already recombine all the fields (no flags) and deinterlace those that appear to need it, albeit not always the correct ones. This is shipping code used in the last few months of DScaler alphas. While not perfect it appears to mostly work. But there I'm always putting out 60 frames / second, no drops. I felt that better handled things like cuts and video overlays but DScaler had different options to handle judder.

I haven't decide what to finally do about the judder problem. But I think as a first cut I'm just going to drop the one frame out of every 5 that differed the least in the last group of 5. That's probaby not best but would work with consistant pulldown and also might give decent results if decimating deinterlaced source. I'll consider more lookahead later. And I think I want a constant 24 fps output. I'm storing some high res HDTV stuff that can't display 30 anyway. If that works at all then I'll tinker with it for a few months until I get one that really works. I tend to do thlngs like this in 2's and 3's. But if anyone sees me heading down a blind alley here, please shout.

I'll probably have the above idea coded soon if I don't run into any other show stoppers. But tonight was Buffy night, no time for coding.

- Tom

[macdaddy]

I am glad these two groups have gotten together. I tried to make the connection by posting links to DVD2AVI in the AVSforum months ago, but nothing came of it. The progress is exciting...

btw, if you have no idea what dScaler is all about, and you are into home theater, pick up an issue of this month's "Stereophile." In it you will find a two page spread on the program. I stumbled on it while in the checkout line at Fry's when buying my copy of "The Phantom Menace."

[trbarry]

Hey, Thanks for the heads-up on the article. I hadn't seen that.

But they are talking about an older version that doesn't even have Greedy/HM in it yet. :(

- Tom

[manono]

Hi trbarry-

. I'm a little surprised that after all the posts here about needing IVTC/deinterlacing code I think you are the only one that has actually run this. Anybody else tried it?

Don't worry. I know there are many that are following this with interest-many are testing, and others are waiting until it's proven. After all, the thread is coming up on 500 views. I tried it first on a movie the other day that had a few interlaced frames and GreedyHMA(1,0,1,0,0,0) took care of them nicely. It didn't have to be cropped on the right side. I've been fooling around with it for the last day (not continuously) with more difficult material-a Battle Athletes Victory anime DVD for conversion to DivX .avi using GKnot-Nandub- with mixed results. Using the original .dll, I also had the colored bars along the right side, as Larva reported. So I got the new .dll. This disc needed cropping on both sides and on top as well. For me, instead of the colored bars on the right, I now get pieces of wrong video along the right, also several pixels wide (same as the previous bars).They come and go, but are mostly there. This is with both GreedyHMA(1,0,1,0,0,0), and GreedyHMA(1,0,1,0,1,0)(but if I don't crop, all is OK). By the way, with (1,0,1,0,0,0) there were small interlaced parts remaining, like around characters mouths when they're speaking, but GreedyHMA(1,0,1,0,1,0) got rid of them, and left a nice appearance as well. For what it's worth, here's the script:

LoadPlugin("C:\xxx\mpeg2dec.dll")
LoadPlugin("C:\xxx\InverseTelecine.dll")
LoadPlugin("C:\xxx\GreedyHMA.dll")
mpeg2source("C:\xxx-30fps.d2v")
crop(12,6,695,474)
DoubleWeave.InverseTelecine(40,10,15)
GreedyHMA(1,0,1,0,1,0)
BicubicResize(512,384,0,0.5)

If I've done anything wrong on the setup, please let me know.

So back to Smart DeInterlacer, at least when I have material needing cropping on the sides. But keep up the good work-I also expect to switch after the kinks are ironed out.

Hey Larva- I've learned much from your posts, but I enjoyed you more when you were Western Shinma. You sounded kind of mysterious and exotic. Now you just sound kind of....wormy.;)

[Larva]

I'm testing out the new version now (finally). So Battle Athletes Victory is also a hybrid? I was hoping that would be 100% telecined, since that's my next project (getting tired of hybrids).

BTW, sorry about the name switch, but originally I wanted this name for the old board as well. After a while I've decided that using an anime character's name is lame though, so maybe I'll go back. If you were wondering, the original meaning of this word is an evil spirit or terrifying mask.

Here's the results: no funky stuff on the right side with or without vertical filter, on the same clip that was causing problems before. Glad to see this fixed, as I had noticed some minor interlacing without vert. filter. I tried cropping a little off the top to see if I could duplicate your problems, but it still looks alright here.

[trbarry]

manono -

I don't know if GreedyHMA would be compatible with the

DoubleWeave.InverseTelecine(40,10,15)

line. That would be somewhat like doing InverseTelecine twice since GreedHMA sort of has one built in when you specify a nonzero value for the third parm. For pure deinterlace you could use GreedyHMA(1,0,0,0,0,0) instead but it still might get confused because InverseTelecine would stop it from seeing all the frames. I'm not sure.

Also GreedyHMA still has the limitation that it has to work on a width that is a multiple of 16, though you can crop it later. For an experiment, you might instead try skipping the InverseTelecine line and changing the order like:

LoadPlugin("C:\xxx\mpeg2dec.dll")
LoadPlugin("C:\xxx\GreedyHMA.dll")
mpeg2source("C:\xxx-30fps.d2v")
GreedyHMA(1,0,1,0,1,0)
# or GreedyHMA(1,0,1,0,0,0) if you don't really want the v.filter
crop(12,6,695,474)
BicubicResize(512,384,0,0.5)

This assumes your source width was originally a multiple of 16. The results will still sadly be at 30 fps, not 24, but I should have that limitation fixed within a couple days. But hopefully the above will fix the rest of the problems you mentioned and I should have full IVTC soon.

- Tom

[manono]

Thanks for the reply-Between what you and Larva said, I started thinking and tinkering. I think the fix was to exit Nandub, and then start it up again. Anyway(not really sure-maybe the reboot was the fix), no more screwy stuff along the right side. In addition, GreedyHMA works just fine with Dividee's IVTC .dll. So I'm encoding now using the IVTC together with the GreedyHMA (in spite of your admonition). The alternative was to produce a .d2v file at 23.796 fps, and then use just the GreedyHMA on it. I may try that later, but was afraid that it would turn out too jerky or have too much ghosting. Do you have any thoughts on that? But I refuse to ever go frame by frame in TMPGEnc. again. Also, based on the projected time for this encode, the GreedyHMA is about 6-7% faster than the Smart Deinterlacer. Every little bit helps. So I (as well as many others, I'm sure) anxiously await your full IVTC. Again, thanks for your help
-Tom (also)

Hey Larva-I may be too ignorant to be of help to you. BAV-Disc 3 was 46% NTSC. I guess that means hybrid-which is what?-mixture of 24fps and 30fps originally? Or mixture of hand drawn and CG? Or is that the same thing? I'm assuming that what DVD2AVI calls NTSC is the same as telecined (but as I said...) No need to explain-I've read enough about it by now, that I should understand, and I might be trying your patience.
I had never seen a pure NTSC until the other day when a Trigun DVD was NTSC all the way through the .d2v creation.
If you hadn't told me why you changed your name, I wouldn't have known, as I haven't seen whatever anime it comes from. But I can understand that someone else that was familiar with the anime might sneer if they saw your nick. So I forgive you for changing:)

[western shinma]

You haven't seen Vampire Princess Miyu? Darn.

Anyway, the percentage is irrelevant. Usually anime discs are encoded with what TMPGEnc refers to as "inverse 3:2 pulldown", which is how you get the weird percent NTSC number. Actually most DVDs are encoded this way, unless they are pure film or pure interlaced (both seem quite rare actually, although most SVCDs are one of these).

Nonetheless, most animes are 100% telecined, they just aren't encoded that way. Which is why you have to use inverse telecine rather than force film. The only way you can tell is if you look at a CG scene and step through a few frames one at a time to see if every frame is a new progressive frame. If not, just do full IVTC in TMPGEnc and you should be good to go, you don't have a hybrid anime after all.

Of course there's another way to tell, IVTC first and see if it comes out jerky, this is usually what ends up happening to me (after wasting maybe 10+ hours).

Looking forward to the new version, doing some more anime next week. :D

[manono]

Hi Again-
I've been studying your GreedyHMA pretty carefully today, and I like it a lot. I create DivX conversions of DVDs using the GKnot-AviSynth-Nandub method, so I know nothing about SVCD, or TV capture conversions, or any of the other uses for AviSynth. In addition, I am by no means an expert (my earlier posts should prove that). But I think the conclusions should hold for all of them. I made 2 .avis of the same anime DVD. All the settings were exactly the same except for bit rate and the deinterlacer used. One used the Smart Deinterlacer at default settings after dividee's IVTC, had a bit rate of 1472, and produced a file size of 730 MB (I screwed up the bit rate somehow, but in the end it was instructive). The other used GreedyHMA after dividee's IVTC with this setting-GreedyHMA(1,0,1,0,1,0)-had a bitrate of 1412, and produced a file size of 702 MB. I did use the same .stats file (done with Smart Deinterlacer) for the second pass of both movies. You would think the larger sized movie would have an advantage, but with the quality guage in Nandub(File-File Information-DivX Quality), the SmDeInt movie recorded 64.769, and the Greedy movie 68.507. This tells me that Greedy produces the same quality movie with about a 5-6% smaller file size. Or, put another way, given the same file size, the Greedy movie will be about 6-7% better quality. Thats about the only objective measurement I could think of.

I did a couple of subjective measurements, asking my wife, who knows nothing about this stuff, to help. First I lined up the same frame(one in WMP6.4, and the other using the BS Player) of both movies side by side and after noticing an obvious difference, asked my wife if she could tell the difference. A while later I switched the player used for each movie (to negate any differences between the 2 players), and asked her again. She said that the Greedy movie looked "darker" in both tests. Now, it wasn't darker-what she meant was that the colors were richer, more vibrant, more highly saturated. Not that the Smart Deinterlader movie was washed out, but that the Greedy movie had brighter colors, a good thing in my book, especially for anime. I checked both movies carefully for "shimmer" or "dot crawl", and although both were pretty good, compared to, say, using VerticalReduceBy2 as a deinterlacer, and fairly close, again Greedy was the clear winner. Next I checked for "line clarity", that is, were the lines straight in the diagonals, without "jaggies" or any "crud" on the outside of them. Here, I would say it was a tossup, but If I had to pick a winner, I'd probably go with the Smart Deinterlacer movie. But very close. And as I said in an earlier post, using Greedy is a bit faster. And both of them did a good job of getting rid of any remaining interlacing after the IVTC.

Perhaps some arguments can be made about my methodology (using the same first pass for both movies comes to mind, but I was too lazy to do it all over again for the Greedy movie-these things take time-I'd think, if anything, it would give the SmDeInt movie an advantage). In addition, this was for only one anime DVD,testing only 2 deinterlacing methods, so maybe broad conclusions can't be drawn yet. I know some prefer to use Bob, others the Smart Deinterlacer with "true,false,true" as part of the argument. But,I'm very pleased with the results so far, and will do other tests soon. I'm sorry for the long post, but hope to encourage others to do their own tests, perhaps comparing other deinterlacing methods, and report back. And shortly, we'll have a GreedyHMA IVTC to play around with. Thanks trbarry for the great program, and keep up the good work.

[western shinma]

Oh yeah, if you're using Greedy to get rid of interlacing after doing IVTC with something else, I think you should turn off auto pulldown. (Something along the lines of (1,0,0,0,1,0) would probably be good). Since you're doing IVTC though, the ideal result would of course not need any deinterlacing afterward. TMPGEnc's auto IVTC has actually been able to do just that on a number of animes as well as live action movies. It also has an automatic deinterlacer built in (animation adaptation with threshold 200 seems best for animes that have some interlacing after IVTC). Sure, it's slow, but so is the avisynth IVTC plugin.

When Greedy gets full pulldown support, however, things could change rather quickly.

[manono]

OK-Thanks. I'll give it a try. Check your private messages.

[trbarry]

manono -

I'm actually fairly new to many of these tools and won't understand all the ramifications of many. My video experience has mostly been in real time with DScaler so I've not yet learned either Gordian Knot or TMPGEnc. Afraid I'm a newbie in some of this.

I'm also a bit confused about the versions of IVTC. Is Dividee's IVTC a version of the one by WizardFL? If so, I got source from Edwin's site awhile back but I'm not sure we are talking about the same one. If we are then I probably second Western Shima's opinion that doing a pure deinterlace with no pulldown matching (x,x,0,x,x,x) might work better in combination with the IVTC filter. But I haven't tested the interaction between the two yet and can't really predict.

GreedyHMA can steal pixels or even an entire field from the preceding frame. If that frame was dropped then Greedy will be using the wrong one. If the dropped frame was truly a duplicate then it should be okay but if not then there would be more artifacts. I don't know if that would be a problem when IVTC was actually operating on interlaced video source, but it might be.

But thanks for shaking this down some.

On another topic ...

How does everyone feel about adding two more positional parms?

The DScaler version of this offers two sliders to set Good Pulldown Level and Bad Pulldown Level. These determine a bias towards pulldown (film) vs deinterlace (video). If I did that then we'd be able to tinker more but it would be up to an 8-parm plist, GreedyHMA(x,x,x,x,x,x,G,B). But leaving them at zero would still take the defaults.

Is that overkill? Feaping Creaturism?

- Tom

[western shinma]

That sounds like a nice option to have. Dividee's plugin is just a recompile of WizardFL's initial IVTC plugin btw, to remove some extra debugging code or something.

[DDogg]

Wizard finished up on his V2 IVTC.

It should be up and around by now I would think. No more doubleweave and the plugin automatically detects reversed field order :). Hopefully there will be some synergy between these two efforts, and two authors. I know Wizard asks for some optimization help and it sounds like trbarry knows his way around some mighty hot assembler routines. Wizard is a hell of a resource about IVTC. Hope you guys get some comms goin' on.

I'll put some of the readme here:

WHATS NEW
I changed a few thing within the code to make thing easier for you guys... First, no more doubleweaving, the plug-in does that on it's own (any volonteers for uptimizing this??). Second, it also detects reversed field order so you don't have to guess if it is or not.
Third, I added a DeInterlace function that only matches fields (no blending) and doesn't change the framerate (useful for hybrid material).

PLANS
I'd also like to add a blend deinterlacing for those rare frames that get past the IVTC algorithm. That way, the interlacing won't be as noticible.

WHAT YOU NEED TO KNOW
1- This plug-in was designed to work with avisynth 1.0 or higher. I don't know if it could work with any other program (I'm pretty sure it couldn't) and I wouldn't recommend trying.

2- To work properly, the plug-in requires that the video stream be in a YUV format (more on this farther down the document). In fact, anything else will probably get seriouly screwed!

3- It is supposed to reconstruct video streams which have gone through Telecine process.
The plug-in can't InverseTelecine video streams which are only Interlaced or haven't gone through a recognised Telecine process.

4- The plug-in takes in 3 parameters: High limit, Low limit and Threshold(more on this farther down the document). Values can range from 0 to 255 for High and Low limit,and 1 to 1000000 for threshold (I've had good results with values of 40,10,15).

ex: LoadPlugIn("c:\archive\InverseTelecine.dll")
SegentedAviSource("D:\capture.avi")
InverseTelecine(40,10,15)

5- For DeInterlace, no parameters are necessary...
ex: LoadPlugIn("c:\archive\InverseTelecine.dll")
SegentedAviSource("D:\capture.avi")
DeInterlace

ADVANCED INFORMATION
YUV and RGB formats
As far as I know, any codec will decompress in either a YUV or RGB format. To keep it simple, RGB defines a pixel by assigning 8 bits for RED, GREEN and BLUE values. YUV defines a pixel by its Luminence and 2 Chroma (which is the difference between 2 colors and I can't remember which). The thing to remember here is that the plug-in uses the Luma value to see if 2 lines are interlaced, so RGB format will not return the correct information. If your codec does not decompress as YUV, try using the CONVERTTOYUY2 function.

Telecine process
A process by which a video stream of 24 fps is converted to a stream or 29.97 fps (NTSC standard) by adding 2 fields (either odd lines or even lines) every 5 frames (not at the same time). By doing so, 3 out of 5 frames become interlaced, which will dislpay fine on an interlaced screen but display badly on computer screens.

Parameters
High Limit: If the difference between the luma values of 2 pixels (one above another) are higher than this, the pixel are considered "interlaced".

Low Limit: If the difference between the luma values of 2 pixels (one above another) are lower than this, the pixel are considered "not interlaced".

Threshold: The interlace value at which a recalculation of the pulldown order is necessary.

How the plug-in works
First, the plug-in analyses the first 5 frames and determines the pulldown order by selecting the 2 frames with the less interlace artifacts. Then,it continues to select each next frame by using the previously determined pulldown order. However, each output frame is analysed to ensure that no interlaced frame gets by. If the interlace value of an output frame exceeds the threshold value, the pulldown order is recalculated.

CONTACTS
Email: Wizard_FL@Hotmail.com
ICQL: 4105331

[trbarry]

Gee, I guess when it rains it pours. ;)

I've also released a new version tonight, very alpha experimental.

I added a bunch of parameters, including optional frame dropping for Auto Pulldown, so the old parm lists won't work anymore.

See www.trbarry.com/Readme_GreedyHMA.txt or www.trbarry.com/GreedyHMA.zip which contains the dll, the same readme file, and also now the source. It's not very large.

You now have a bit more control over frame dropping, Auto Pulldown, and things like Force Film or Force Video. From (part of) the readme file, the new plist now has 8 parms, and looks like:

GreedyHMA(TopFirst, SwapFields, AutoPullDown, MedianFilter, VerticalFilter, EdgeEnhance, GoodPullDownLvl, BadPullDownLvl)

The main change is there are now 6 different values that can be specified for Auto Pulldown:

0 - No pulldown, just do pure deinterlace (Force Video). Doesn't drop
any frames so FPS is left at 30 FPS, or wherever. Doesn't decimate
(pentimate?). Use if you have (and want) 30 fps video source or
maybe 25 FPS PAL video.

1 - Auto Pulldown. Automatically decide which frames should be IVTC'd
or deinterlaced, depending upon the settings of the Good and Bad
Pulldown Lvls (see below). Don't decimate. This is best if you
have mixed film and video and wan't 30 fps output. Also better
for PAL sources.

2 - Pulldown only (Force Film). Assume film source, always do IVTC and
never deinterlace. Don't decimate. Use for PAL film source.

Values 3-5 match those above but with frame dropping (Decimation, pentimation?)
Five frames at a time are looked at and the one most likely to be a duplicate
is dropped, thus lowering the FPS from, say, 30 to 24.

3 - Deinterlace (Force Video) but with frame dropping. Use for NTSC video
if you still want to decimate. With video source there really are no
proper fields to drop, but this will drop the ones looking most like
dupes.

4 - Auto Pulldown with frame dropping. The best (most automatic) setting.
Works in most cases, at least if I get all the bugs out.

5 - Pulldown only (Force Film) with frame dropping. This will give the best
results if you have 100% properly mastered NTSC film source with no
video sections and not too many edits. It can adjust for most scene
changes and changes in pulldown cadence, but not mixed up fields. (none of the setting handles badly mixed up fields)


The last 2 parms, Good & Bad Pulldown level should usually be left at zero to take the defaults. See the readme file.

So in most cases I would just use the following and call it good: ;)

GreedyHMA(1,0,4,0,0,0,0,0)

All my new code this week is pulldown related but most of the effor in Greedy/HM is still specialized in the video deinterlace area. So I'd be glad to share or collaborate with WizardFL or anyone on the pulldown side of it. That's partly why I also added the source to the zip this time. But either way we should have lots of new stuff to test this week.

Anybody please let me know if I overlooked something, or if it immediately catches fire when you run it.

- Tom

[vlad59]

Hello,

Last weekend I tried GreedyHMA on a PAL Interlaced video so I used the following param :
GreedyHMA (1, 0, 0, 1, 1, 1)
Anf the quality was really great and this was faster than SmartDeinterlacer. But One frame (frame 435) became the first frame : I have always the same number of frames but one frame was displaced.

It's strange, isn't it !!!

I tried GreedyHMA (1, 0, 0, 1, 1, 0)
And then more frame were inverted.

It's really strange.

I hope I am not the only one !!!!

[trbarry]

vlad59 -

I have one other report of something similar. Could you post your entire filter script?

Also, you might want to download the files again to get the newer version, as I can tell by your using only 6 parms that you don't have it. It likely won't fix the problem but does add the new features above, and would help with my own hunt for your problem.

Except beware that if you really need the Median Filter, that is temporarily disabled in the newer release.

- Tom

[vlad59]

Here is my entire script :

LoadPlugin("C:\MPEG2DEC.DLL")
LoadPlugin("C:\GreedyHMA.dll")
Mpeg2Source("C:\Downloads\Friends.d2v")
GreedyHMA(1, 0, 0, 1, 1, 1)

I've just downloaded your new plugin, I'll make the same test tonight.

[trbarry]

Okay, thanks.

I have some idea of what maybe the problem is. If so I'll post a fix later today. If I'm correct then the first frame may be often wrong.

If anyone is using Trim() then possibly up to the first 4 frames might be wrong. But I'm not sure yet.

- Tom

[vlad59]

Hi trbarry,

The new version seems to have corrected my problem. I'll make some other test at home but with a sample PAL vob it worked perfectly.

But without Median Filter the quality is just good not very good (like with the median filter).

Here is the scrip I use :

LoadPlugin("C:\MPEG2DEC.DLL")
LoadPlugin("C:\GreedyHMA.dll")
Mpeg2Source("C:\Downloads\Friends.d2v")
GreedyHMA(1, 0, 0, 1, 1, 1, 1, 1)

Sorry for bugging you before trying the new version !!!

[trbarry]

I'm glad to hear that it helped, but I still suspect there may sometimes be a problem with the first record. I'm still checking.

I'll try to re-enable the median filter code soon.

BTW, it does not make any difference in your particular case, but the last two parms should almost always be zero, like:

GreedyHMA(1, 0, 0, 1, 1, 1, 0, 0)

This is because if they are nonzero they will be used to override the default values used in Auto Pulldown. But you currently Auto Pulldown turned off anyway, so it won't matter here.

- Tom

[trbarry]

When you use the frame dropping options (AutoPD=3-5) GreedyHMA will not always return the correct frames, causing jerkiness.

I'm still looking at it. Hopefully fix ASAP.

- Tom

[trbarry]

Okay, with a minor bit of rending and tearing (to code not video) I've got GreedyHMA now apparently doing Auto Pulldown (IVTC) correctly.

It should now drop & return the correct frames and give a much less jerky result than before. The Auto Pulldown should not be very sensitive to changes in pulldown cadence, but it won't handle it if the fields are totally mixed up somehow.

I'm afraid the Median Filter option is still disabled.


A few quick usage hints that I just added to the readme file: (www.trbarry.com/Readme_GreedyHMA.txt)

Generally, if you think you have mostly film source, or DVD2AVI says so, then use:

GreedyHMA(1,0,5,0,0,0,0,0) # which is ForceFilm+Decimation to 24 fps.

If you have all video, use:

GreedyHMA(1,0,0,0,0,0,0,0) # for 30 FPS output, or
GreedyHMA(1,0,3,0,0,0,0,0) # for 24 FPS output

and when you don't know, don't care, or it's all mixed up, just make it auto:

GreedyHMA(1,0,4,0,0,0,0,0) # the all purpose most automatic setting


See the Readme file for the other parms. Likely the only other one you might want would be the Vertical Filter, say

GreedyHMA(x,x,x,x,1,x,x,x)

when you've got very messy source, or sometimes useful if you will be downscaling the result.

The new version GreedyHMA R0.3, including source, is at www.trbarry.com/GreedyHMA.zip

Please, feedback needed.

- Tom

[manono]

Hi Tom-
Thanks for the revision. I have a couple of observations.

GreedyHMA(1,0,3,0,0,0,0,0) seems to work a bit better with my current anime source than (1,0,4,0,0,0,0,0) at getting rid of all interlacing. The first seemed perfect, but I found a few interlaced frames with the second setting. And with (1,0,5,0,0,0,0,0) interlacing is all over the place. It would seem that (1,0,3,0,0,0,0,0) is the industrial strength IVTC.

Also, I was getting those multi-colored bars again along the right side with certain resolutions and/or croppings. This one works fine:


crop(8,6,704,471)
GreedyHMA(1,0,3,0,0,0,0,0)
BicubicResize(544,400,0,0.6)

And this one gives me colored bars:


crop(17,4,685,476)
GreedyHMA(1,0,3,0,0,0,0,0)
BicubicResize(544,416,0,0.6)

But after doing some more fooling around, by putting GreedyHMA before "crop" like so:

GreedyHMA(1,0,3,0,0,0,0,0)
crop(17,4,685,476)
BicubicResize(544,416,0,0.6)

The bars along the right side went away. Now, maybe this is basic AviSynth 101, but I, for one, had no idea it was supposed to be like this, and perhaps others will be helped.

I can't comment on the jerkiness fix just yet, as I don't mess with snippets-gotta do both passes first. Thanks for the program.

[trbarry]

GreedyHMA(1,0,3,0,0,0,0,0) seems to work a bit better with my current anime source than (1,0,4,0,0,0,0,0) at getting rid of all interlacing. The first seemed perfect, but I found a few interlaced frames with the second setting. And with (1,0,5,0,0,0,0,0) interlacing is all over the place. It would seem that (1,0,3,0,0,0,0,0) is the industrial strength IVTC.


manono -

Actually, with AP=3 you are not exactly doing IVTC.

With AutoPulldown=3 (x,x,3,x,x,x,x,x) you are doing pure video deinterlace, but still with frame dropping/decimation. AP=4 means automatic sensing of Video vs Film on a frame by frame basis and AP=5 means assume all Film, no Video. But all three of these will still always drop the most likely duplicate out of each group of 5, dropping your frame rate to 24. With pure film this should do IVTC but with mixed in video it is only an approximation that should still give the smoothest pans.

So from your results above I'd bet (only small amounts ;) ) that you have a large amount of video in your source. When selecting Video it works fine, when selecting Auto it mostly works but a few frames slip through, and when selecting Film it mostly sucks.

Or else I have more bugs that I haven't found. This is also possible.


Also, I was getting those multi-colored bars again along the right side with certain resolutions and/or croppings. This one works fine:
...
The bars along the right side went away. Now, maybe this is basic AviSynth 101, but I, for one, had no idea it was supposed to be like this, and perhaps others will be helped.

It is not basic Avisynth 101 for me. I have yet to be able to completely visualize the order of processing of Avisynth functions. I can tell you that the color bars are almost certainly related to GreedyHMA wanting to process horizontal lines that are a multiple of 16 pixels. But what I can't do is always predict what order of crop, trim, resize, etc will allow that to happen. I know from experiments that it is not always what I expect, but that is likely because I'm using some broken paradigm to think about it.

But if I did understand it, I could tell you there are 2 ways around the multiple of 16 problem. One is to give Greedy a proper screen width. The other way is to give it something else, which will leave unprocessed garbage on the right hand side. But then Crop the garbage off later. I think your examples show both solutions to the problem.

The order of processing will affect GreedyHMA in another way also. It is important that GreedyHMA manage to process the fields before they have been blended, filtered, or resized as that may hide some of the info needed to put the even/odd fields back together again. Incidentally, Crop is harmless to this second process.

I still don't have enough experience with all the other filters to predict how they will interact with Greedy.

Maybe someone else that really understands how Avisynth parses and processes could jump in here and explain it better.

But anyway thanks for so promptly trying this out. And let me know what the final results are.

- Tom

[western shinma]

Well, I would do some major testing, but I need to buy some blank cds to free up some space for vobs first. In the meantime, I ripped some anime trailers which are apparently telecined, and auto pulldown=5 combined with vertical filter is working wonderfully. With TMPGEnc on the same source, there is some leftover interlacing, which can be cleared up with its auto deinterlace option, but this plugin does it all automatically without having to mess with thresholds or anything. Not to mention that it is insanely fast, TMPGEnc is considerably slower even after finishing the preprocessing. Now if there was auto field order detection, it would be perfect (probably slower though). Either way, it's looking great so far.

[vlad59]

I tested a vob of "Sex and the city" wich is know as NTSC 55% in DVD2AVI and GreedyHMA(1,0,3,0,0,0,0,0) is better then GreedyHMA(1,0,4,0,0,0,0,0).

With GreedyHMA(1,0,4,0,0,0,0,0) some frame remain interlaced.

Carry on with this good work Trbarry