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

[western shinma]

vlad, I doubt that show actually contains both 24 and 30fps scenes, which is probably why autopulldown=4 didn't work so well. Can you try this out: GreedyHMA(1,0,5,0,1,0,0,0)

I'm interested in finding out how this handles TV shows, and 5 should be higher quality than 3 if it works. Also, the vertical filter seems to get rid of some leftover interlacing.

I think the main problem with TV shows is field order changes, which sometimes happen frequently. At this point, the only way to deal with that would be using Trim and ComplementParity, which is pretty troublesome.

[vlad59]

western shinma,

I just test your settings GreedyHMA(1,0,5,0,1,0,0,0) and the quality is the same as GreedyHMA(1,0,4,0,0,0,0,0) : with the small test I did (30 seconds) 2 frames are interlaced.

Whereas with GreedyHMA(1,0,3,0,0,0,0,0) there is no interlaced frame. I live in PAL world so I'm not totally aware of different telecine methods but I know that this vob of "Sex and the City" is not easy to IVTC. I'll try to do it manually with Tmpgenc this week end to see really what's wrong with that.

[western shinma]

Maybe the field order is changing, although that probably isn't the case since this is a DVD. You might try using auto pulldown=5 and changing the values for good/bad pulldown level, although that might be more trouble than it's worth. I would only use 3 as a last resort, since that isn't actually doing a real inverse telecine. The point of doing IVTC is rearranging the fields to reconstruct the original frames, which doesn't happen with this setting. Instead it just blends and discards fields and drops a few frames. Deinterlacing like this does remove interlacing, but whenever it kicks in you will get lower quality in the form of blurring or jagged edges.

[trbarry]

It's good to see you guys are trying this. :)

A couple clarifications.

I'm not sure what you mean by field order changes. If you just mean the repeating pattern of 5 frames changes because of video edits or dropped frames then GreedyHMA should handle that okay in all modes. The only problem is when the edit occurs such that half of a frame (1 field) is actually dropped from the video. In that case there is no way to make a perfect match because it is not there. In video (AP=0 or 3) mode this mismatch would just get deinterlaced. In auto (AP=1 or 4) it might get deinterlaced or not depending upon how clever GreedyHMA is and what the BadPulldownLevel is set to. But it probably would be okay. In Force Film (AP=2 or 5) it would probably cause 1 frame with weave artifacts if it occurred during a fast motion scene.

TV has a lot of edits like this but most are between edited sections for time changes or commercials (I think). And a properly mastered DVD has fewer these days. But I think it is still lucky to make it all the way through a show keeping the exact same cadence so I'm not a big fan of manual IVTC, especially for TV caps.

GreedyHMA does look for a repeating 5 field pattern for confirmation but it doesn't mainly rely on it. Instead it mostly makes new frames by matching each dominant field in a frame with either the next or prev field that gives the lower comb/weave factor. So that's why cuts or drops don't hurt it as much.

But there is another possible meaning of field order changes. Maybe you meant when the capture card (or who knows what) actually manages to just get the frames or fields into some bizarre nonstandard order. I don't know the causes of this but GreedyHMA would be less help here.

I've heard for instance that some shows are telecined for American NTSC and then converted to PAL @ 25 FPS with strange consequences.

Some notes on advanced parms:

The Good Pulldown Level & Bad Pulldown level parms have no effect if you aren't doing Auto Pulldown (AP=1 or 4). But if you are using Auto Pulldown and some weave/interlace artifacts still seem to be sneaking through the screen you might try lowering the Bad Pulldown Level. This is really a threshold of how bad the weave artifacts can be before GreedyHMA decides to deinterlace that frame.

Say you were previously using GreedyHMA(1,0,4,0,0,0,0,0). This is doing Auto Pulldown but the zeros in the last two parms tell it to take the defaults of GoodPD=90 and BadPD=85. But if too many frames were doing pulldown when they should have been deinterlaced you could lower the BadPD level at bit. You could try GreedyHMA(1,0,4,0,0,0,0,75) which would be a lot less forgiving of weave artifacts. Or the same thing with a vertical filter, GreedyMA(1,0,4,0,1,0,0,75).

So lowering the BadPD level causes it to do less pulldown and more deinterlacing. Raising it causes Greedy to do more pulldown (field matching).

I won't go into the Good PD level much as it is subject to change shortly except to say that lowering the Good PD level makes it MORE likely to do pulldown. Raising it makes it do more deinterlace.

And of course for really messed up source you will still be best with just using AutoPD=0 or 4, pure deinterlace, and maybe some filters.

I guess I just wrote another of my long droning posts. Sorry ;)

- Tom

[Faro]

Hi,

i've read all interlacing/IVTC topics so far and now I think that I'm ready to help you as I understand it (maybe I will not help you because of my bad english - but i will try my best).

I have done a few testings with my Akira DVD. It is the digitally remastered and THX certified US-rc1-version, which is the best out there, i think (btw.: don't buy the german version - its only a dvdcopy from an old noisy vhs master!)

As usual I proceed the dvd2avi -> avisynth -> Virtual Dub way and encode with 2pass VBR DivX 4.02.

I previewed some scenes in DVD2AVI and it comes out, that the videostream is this kind of "hybrid-style" you're all talking about. The reason is of course the digitally remastering, because the quality is impressive and the special effects look terrific (the movie was produced in 1986 btw!).

But now to the main part:

I have chosen a small scene (lenght: 300frames) to test your new deinterlace/autoinversetelcine/pulldown filter and compared it to what we've got: The InverseTelecine.dll in Version 2.01

In my opinion it is the best to look at the scenes by yourself, so I've uploaded the 3 parts to geocities

The first file is there original 29,976 ntsc file encoded this way:

LoadPlugin("F:\dvdripping\gknot\mpeg2dec.dll")
mpeg2source("D:\akira\akira.d2v")
crop(0,0,720,480)
BicubicResize(640,352,0,0.75)


you can download the avi (encoded with 1100 vbr) here (http://www.geocities.com/inversetelecine/akira_original_ntsc2.avi ).

The second one is inverse telecined with inversetelecine.dll by wizard. The script :

LoadPlugin("F:\dvdripping\gknot\mpeg2dec.dll")
LoadPlugin("F:\dvdripping\gknot\InverseTelecine.dll")
mpeg2source("D:\akira\akira.d2v")
crop(0,0,720,480)
InverseTelecine(40,10,15)
BicubicResize(640,352,0,0.75)

download here. (http://www.geocities.com/inversetelecine/akira_ivtc_201.avi )

And the last one was made with (you can guess ;)) the new GreedyHMA filter, set to autopulldown


LoadPlugin("F:\dvdripping\gknot\mpeg2dec.dll")
LoadPlugin("F:\dvdripping\gknot\GreedyHMA.dll")
mpeg2source("D:\akira\akira.d2v")
crop(0,0,720,480)
GreedyHMA(1,0,4,0,0,0,0,0)
BicubicResize(640,352,0,0.75)

the video can be downloaded here. (http://www.geocities.com/inversetelecine/akira_greedy_autopull_4.avi )
After looking at the files very detailed (4x zoom and dozents of screenshots) I still can not say which filter works better for this source. They both result in a clear picture without any interlacing effects. The GreedyHMA needs less CPU power and encodes faster.
It also leads to a smaller filesize.

I've done also a few tests with the inversetelecine.dll ver.1 (without the automatic detection algorithm) In that old Version the result for inversetelecine.dll are bad compared to the new one.

But my question is: Where can I see the hard parts of the mixed material?
The filters have done their job very well, but do I have to be complained about this kind of anime dvds? Is Akira really of this type?

And are your differences between the filters so close also?

would be nice if your share your thoughts...

Faro

P.S.: geocities was not a great choise :mad: - such traffic is not allowed as i see - if someone knows a better place to upload to - let me know

[western shinma]

Thanks for the info about good/bad pulldown level. That sounds like the best solution to vlad's problem, since combining field matching and deinterlacing should be higher quality than deinterlacing alone.

Forget about what I said with field order changes, but I think this is a fairly common problem with video captures. I'm not sure if it comes from TV station edits or problems with capturing though. Either way, autopulldown=4 sounds like the ideal setting for this, since it can deal with dropped fields.

[trbarry]

Faro -

Thank you for going to the effort to post those. I can't seem to get them now as it's over that GeoCities bandwidth limit, but I will later.

I can't say whether that was just easy material or not. I've seen Akira on a rented VHS tape but don't own it. Possibly others here can point out a couple of typical torture tests for hard video material. For instance Vlad above's Sex in the City. Or I hear folks complain about the Lain DVD.

I don't have any clips available for download. I wouldn't have the space for it.

One of the hardest things I've found is a DVD I bought only for testing deinterlace. It's call NBA Jam. Someone made a music video of a bunch of basketball clips. It is high motion, extremely and casually edited, and is a total mix of all kinds of video spanning decades.

I am totally sick of watching it. ;)

- Tom

[trbarry]

Thanks for the info about good/bad pulldown level. That sounds like the best solution to vlad's problem, since combining field matching and deinterlacing should be higher quality than deinterlacing alone.

western shinma -

That is probably true for vlad's case. But I think it's usually best to know what we have and not put the burden on automatic if we don't need to. So if we knew we had mostly video we would get the best results with AP=0 or 3 because greedy wouldn't occasionally fall into pulldown.

And if we knew we had almost all film then AP=5 (NTSC) or 2 (PAL) would make sure we allowed the highest detail and never added any deinterlacing artifacts. I would probably use AP=5 whenever I could mostly get away with it, even if it caused a very small amount of combed frames (maybe on some scene changes) just because the rest of it would look so much clearer. And that's true even for TV caps as long as they started out film based. It might not win a contest that way but the viewing experience might be better as long as no one was doing freeze frame just to look for warts.

BTW - I see you've emerged from larval stage.

- Tom

[Faro]

well - we will see

I've just ordered Neon Genenis Evangelion from HongKong (very very cheap!) a few days ago.

:rolleyes:

faro

P.S.: PAL can deliver you a higher resolution and less problems when it comes to an backup...

[western shinma]

After working with this stuff for a while, I've become rather sensitive to interlacing though, even if it only happens once in a while. Not that I would use auto=3 for sources that are mostly telecined, but for me I would prefer using 4 and lower the badpulldown level just enough to get rid of the interlacing. On most sources, however, it looks like using 5 already gets rid of interlacing, even those that TMPGEnc couldn't do perfectly without some deinterlacing.

[vlad59]

to western shinma,
I tried with GreedyHMA(1,0,4,0,0,0,0,75) and no more interlaced frames. In fact the trickiest part of my sample is a really fast motion sequence (3 seconds) in the street with a lot of taxis and the name of the actors appearing from each side. After checking it frame by frame with Tmpgenc, I see that there is 5 consecutive (I'm not sure it's really an english word :confused:) interlaced frames. And here I think GreedyHMA have to deinterlace a frame, I think ??????????

But I must admit that I don't really understand why you prefer GreedyHMA(1,0,4,0,0,0,0,75) to GreedyHMA(1,0,3,0,0,0,0,0) if my source is NTSC 55%. I still have to learn about NTSC (PAL is so easy).

Another thing I tried the InverseTelecine filter from Wizard_FL and after spending 1 hour on tweaking all the parameters, there is still three or four interlaced frame in the tricky part.

I hope I'm clear enough.

[western shinma]

It sounds like your DVD isn't completely telecined, but you shouldn't pay much attention to the NTSC percentage. That only tells you about the encoding on the DVD, not the source material: many DVDs I've ripped with ~50% NTSC or even 100% have been telecined all the way through, with IVTC giving perfect results. The only thing the percent value tells you for sure is whether or not you can use force film (in DVD2AVI, not GreedyHMA).

So the best thing you can do in this case is step through the video for a few frames in some random spots. If you notice everything follows some pattern of 3 noninterlaced frames and 2 interlaced ones, you should probably use IVTC (autopulldown=5). If you notice a few parts with many noninterlaced frames in a row, use autopulldown=1. If there's only a couple spots with a few interlaced frames in a row, try autopulldown=4. Autopulldown=0 or 3 are the best choice when every frame is interlaced, and there is no telecining at all.

[Luxcious]

Ok. I've been capturing video from NTSC TV broadcast for over a year, and have always wanted to find an effective way of IVTC'ing my captures.

When I first started experimenting with IVTC, I used an AviSynth script to SeparateFields, SelectEvery, and recombine the progressive frames. This worked perfectly, until a scene change occured and the interlacing pattern changed slightly. So, it was possible, but very manual.

Then a friend of mine turned me onto AVIUtil. Wow. Almost perfect automatic IVTC. Works great. Occasionally interlaced frames slip by, but otherwise, fairly accurate. This worked fine until I wanted to experiement with CCE for encoding SVCDs. AVIUtil outputs a project file (.aup) which can be opened with TMPGEnc, but in order to be seen by other programs, needs to be converted with VFAPI. Now, since VFAPI has trouble feeding audio, I needed to recombine the VFAPI video stream with the audio stream in order to feed it to CCE (which didn't seem to like the stream without audio). So, it was possible to go from Captured Huffyuv .avi -> AVIUtil -> VFAPI -> VirtualDub -> CCE.

But this process seemed to take a very long time. So, I decided to see what was available for AVISynth again. I tried with no luck using both versions (or all 3?) of the InverseTelecine plug-in for AVISynth. It seemed to decimate frames alright, but many interlaced frames still existed.

Then, on this very forum, I found GreedyHMA.

Well. I'm impressed, so far. I did a test clip last night of 5 minutes of a fairly low action scene. The same clip with AVIUtil took approx. 50 minutes to encode with TMPGEnc. With GreedyHMA, it took 30 minutes. And I was able to feed the script to CCE without using VFAPI or VirtualDub. Total time for encoding with CCE was about 40 minutes. And I haven't seen an interlaced frame in the entire clip.

The only problem that I had, was that TMPGEnc accepted the .avs file no problem. CCE on the other hand, recognized the frame rate as 23.970 (the same as what VirtualDub reports when opening the .avs). So I had to modify the framerate slightly in order to open the .avs in CCE. Here's my script:

------------------------------------------------------
LoadPlugin("C:\video\GreedyHMA\GreedyHMA.dll")
AVISource("h:\cap_0.00.avi")
Trim(5,0)
GreedyHMA(1, 0, 4, 1, 1, 1, 1, 1)
AssumeFPS(23.976)
Crop(0,0,480,464)
BicubicResize(480,480)
------------------------------------------------------

I found that i needed to trim the first 5 frames in order to get GreedyHMA to work with the interlacing patters. Any other trim value (or none) would result in interlaced frames. Also, the cropping of the bottom 16 pixels is to remove the 16 pixels of blackness captured by my ATI All in Wonder.

So, any ideas why I need to modify the framerate? I haven't checked to see if the audio is out of sync yet, but I imagine that it probably is.

Any insight into this would be welcome. Overall, I'm really happy and impressed with GreedyHMA.

[trbarry]

Hi Luxcious -

Are you sure you are using the newest version of Greedy? I put out a fix on the 25'th that corrected the problem of getting the wrong frames sometimes, especially the first one. If you right click on GreedyHMA.dll and look at the properties it should say version 0.3.0. Earlier ones had no version number at all. Is this 0.3?

Otherwise I don't understand the need to trim the beginning. I don't have to do that myself.

Another note of caution, the last two parms should almost always be zero. They don't follow the convention of 1=yes=take the defaults, because they are just a value override when nonzero. The way you have them will cause it to deinterlace almost every frame, which will probably lose you some detail. So maybe try GreedyHMA(1, 0, 4, 0, 1, 1, 0, 0). The Median Filter is currently disabled and ignored anyway. Did you intend to turn on Vertical Filter and Edge Enhancement?

I suspect that for years I will regret this long convoluted parm list full of numbers, but I didn't (don't) know how to properly use keyword default parameters coding under Avisynth. But it is obviously prone to error and hard to explain. :(

As far as the frame rate, I'm not sure I understand. When using the decimate options (AP=4-6) Greedy will multiply the frame rate by 4/5 and then selectively drop 1/5 of the frames. Was the 23.970 not 4/5 of the original rate? Or are you saying I have a rounding or truncation error in there somewhere? (I'll check that)

What does Virtualdub say the rate is if you comment out the GreedyHMA and AssumeFPS statements?

- Tom

[Luxcious]

Hi trbarry.

Thanks for the prompt reply.

First off, the version of GreedyHMA I am using is 0, 3, 0, 0

As for having to cut the 1st 5 frames, I always thought it had something to do with order of progressive and interlaced frames. If I remember correctly, I have to do that with AVIUtil as well. And perhaps it's just because I'm doing test captures, and not actually starting on a blackout. Hmmm ... I just removed the Trim command, and it still appears to be working ... I must have been high or something :D

I tried with 0 for the last 2 paramaters. That seems to work now. I thought I had tried it earlier with interlaced results, but that may have been my start frame problem.

Just opened the following in VirualDub with no problems
GreedyHMA(1, 0, 4, 0, 1, 1, 0, 0)

Actually, I hadn't intended anything ;) I think I had just copied and pasted from somewhere else in this thread.

Now, the framerate thing. I opened my huffyuv captured file with VirtualDub and it reported 29.970 as the framerate. I also commented out those 2 lines in my .avs script, and opened in VirtualDub and got the same framerate. If I omit the AssumeFPS, VirtualDub reads the .avs file as 23.970.

I've only just started testing with CCE, so I'm not sure if other avisynth methods of IVTC produce the same framerate. I know that AVIUtil produces a 23.976 stream.

Once again, thanks for the great plug-in. I look forward to using it more (and turning more people onto it).

lux.

[trbarry]

Luxcious -

Glad to see the first five frames are (hopefully) no longer a problem.

Actually, I hadn't intended anything I think I had just copied and pasted from somewhere else in this thread.

There are a bazillion different combos of parameters, but most people (not adding filters) it should just use one of these 6:

GreedyHMA(1,0,0,0,0,0,0,0) # all video, output 25 or 30 fps
GreedyHMA(1,0,1,0,0,0,0,0) # Auto PAL, output 25 fps
GreedyHMA(1,0,2,0,0,0,0,0) # Force film PAL, output 25 fps

GreedyHMA(1,0,3,0,0,0,0,0) # NTSC video, decimate to 24 fps
GreedyHMA(1,0,4,0,0,0,0,0) # Auto NTSC, decimate to 24 fps
GreedyHMA(1,0,5,0,0,0,0,0) # Force film NTSC, decimate to 24 fps

The first 3 leave the fps rate unchanged, the next 3 decimate (Pentium8?) it by 20%. AutoPD modes 2 & 3 can also be used by NTSC users that want to keep all 30 fps.

Now, the framerate thing. I opened my huffyuv captured file with VirtualDub and it reported 29.970 as the framerate. I also commented out those 2 lines in my .avs script, and opened in VirtualDub and got the same framerate. If I omit the AssumeFPS, VirtualDub reads the .avs file as 23.970.

Okay. I haven't looked at that yet, but it seems I should. I'll have to see how Avisynth is carrying that number but I may be truncating the 3rd decimal somehow. Thanks for pointing that out.

- Tom

[Luxcious]

Originally posted by trbarry


Okay. I haven't looked at that yet, but it seems I should. I'll have to see how Avisynth is carrying that number but I may be truncating the 3rd decimal somehow. Thanks for pointing that out.

- Tom

just about to do a full 1 hour encode, and thought I'd pass on the exact message that I get from CCE.

Frame Rate 2397/100 is not supported. Supported frame rate are 23.976, 24, 25, 29.97, 30, 50, 59.94, and 60.

that's without using AssumeFPS.

And acutally, I'm trying to use the sync_audio feature of AssumeFPS and I get an avisynth error:

when I use AssumeFPS(23.976,sync_audio)
Avisynth Open Failure:
I don't know what "sync_audio" means

This is according to the latest Avisynth docs (on videotools.net), the command is: AssumeFPS(clip,new_fps[,sync_audio])

I am using the latest version, 1.0 beta 5
any ideas about that?

[western shinma]

Try sync_audio=true instead.

Edit: you'll have to resample the audio back to whatever rate you were using before as well.

[Luxcious]

Originally posted by western shinma

Try sync_audio=true instead.

Edit: you'll have to resample the audio back to whatever rate you were using before as well.

thanks. that seems to work.

i'm just encoding the video now anyways, so i'll use that when i feed the audio to the encoder

[trbarry]

Ok, sorry. Some things came up and I've obviously been playing hookey on this for a couple days.

What I changed:

Now, the framerate thing. I opened my huffyuv captured file with VirtualDub and it reported 29.970 as the framerate. I also commented out those 2 lines in my .avs script, and opened in VirtualDub and got the same framerate. If I omit the AssumeFPS, VirtualDub reads the .avs file as 23.970.

I just put out a new mini release GreedyHMA 0.3.1.0 at www.trbarry.com/GreedyHMA.zip to fix the above FPS precision error. Nothing else has changed yet.

I'm not entirely sure this is correct either in light of the error messages Luxcious got above frome CCE. It would be nice if other Avisynth developers could comment here. And this could affect other similar filters.

The problem is that Avisynth keeps the frame rate as an exact ratio of two integers. I was previously changing it by the statement

vi.SetFPS(vi.fps_numerator * 4 / 5, vi.fps_denominator);

but both parms are integer so there can be a truncation error. Now I'm using

vi.SetFPS(vi.fps_numerator * 4, vi.fps_denominator * 5);

but that may not be one of the standard values that CCE accepts if it actually sees these numbers. And I don't have CCE. Hopefully this will be okay, but I'd appreciate someone trying it.

- Tom

[Blight]

Ok, I've tried running the latest version of the filter on the Angel opening sequence, which is simply a massive mixture of film and video sources (or more possibly, lots of film cuts in quick succession).

Using:
GreedyHMA(1,0,3,0,0,0,0,0)
GreedyHMA(1,0,4,0,0,0,0,0)
GreedyHMA(1,0,5,0,0,0,0,0)

I got the strange interpolation effect which you can see in these images:
http://www.inmatrix.com/temp/ghma_source.jpg
http://www.inmatrix.com/temp/ghma_1-0-3-0-0-0-0-0.jpg
http://www.inmatrix.com/temp/ghma_1-0-4-0-0-0-0-0.jpg
http://www.inmatrix.com/temp/ghma_1-0-5-0-0-0-0-0.jpg

Any hints? I'm going to try the smallville opening sequence in a few minutes, I'll post the results here.

[Blight]

I checked smallville, it has the same issue, the opening seems to be comprised entirely of scene-fades and you get the same interpolation issue (that looks like line doubling) practically everywhere, even when using setting "3".

I'm gonna see if I can obtain an actual part of the show to do tests on. As I'm 99% sure the show can be IVTCed.

BTW, I did manual frame advanced on the source, and like every single frame is interlaced, so I doubt IVTC would work on the opening sequence in the first place. The thing is, even setting it to "3" which should deinterlace everything, it still looks bad compared to a standard blended deinterlace.

[Luxcious]

Originally posted by Blight

I checked smallville, it has the same issue, the opening seems to be comprised entirely of scene-fades and you get the same interpolation issue (that looks like line doubling) practically everywhere, even when using setting "3".

I'm gonna see if I can obtain an actual part of the show to do tests on. As I'm 99% sure the show can be IVTCed.

BTW, I did manual frame advanced on the source, and like every single frame is interlaced, so I doubt IVTC would work on the opening sequence in the first place. The thing is, even setting it to "3" which should deinterlace everything, it still looks bad compared to a standard blended deinterlace.

I've found that most TV shows that are shot on film usually have a hybrid of Film and Video for their opening credits, and most always video for the end credits. I tried to IVTC the opening credits for Six Feet Under, and I discovered that some of the clips they used were 29.97, and some were 23.976.

I'm using the new filter today. Unfortunately, the encode I ran as a test last night, I had inadvertantly left the resize in my .avs script to the DivX resolution from my previous test (512x384)

I know have a really nice looking 512x384 mpeg2 file. Also, the video plays back at a faster rate than the audio, but i think that has to do with the AssumeFPS(23.976) that I was using.

[trbarry]

Blight -

Are there really are a bunch of quick scene fades at the beginning of Angel or is Greedy putting them there. I though they were really there though I'm not sure how they should be handled better.

But if they are not really there then I'd need a dozen frames or so of the source to play with to see what's happening.

However I do have reports from one other user that sometimes GreedyHMA appears to deinterlace some sections even when you say Force Film (AutoPD=5).

Also, having (1,0...) for the first two parms is not necessarily best for any logical reason. It just seems to be best for most folks that have tried it so far, but I can't really explain why. It depends upon both your graphics card and source and I really recomend everybody try all 4 combinations at least once before settling into (1,0).

For instance, bring up 4 copies of Vdub at the same time and compare the first few frames.

- Tom

edit: Could you post your filter script? Anything else in there?

[trbarry]

Luxcious -

Do you know yet if the new version today fixes the frame rate problem with CCE? (without the AssumFPS statement)

[Luxcious]

Originally posted by trbarry
Luxcious -

Do you know yet if the new version today fixes the frame rate problem with CCE? (without the AssumFPS statement)

Yes, sorry.

Meant to let you know that. I can open the .avs file in CCE without using AssumeFPS. In the small test encode i did, it appeared to play back correctly as well.

Thanks for this update. I'll let you know if it seems to affect anything else.

[Blight]

Barry, I can probably FXP you the opening sequences to smallville and the first 30secs of the last episode.

However, these are over 100mb each...

The fades in angel were in the source. I think the main issue is the deinterlacing code. TMPEG's deinterlacing seems to give a much smoother image, maybe because it's blending the motion area instead of interpolating them. Or maybe it runs some noise filter on the interpolated areas...

I have checked the source file for an actual part of the smallville show (not opening credits), and there is a clear pulldown structure (3 progressive, 2 interlaced frames). But even with this rather clear pulldown (to my human eyes), it seems that Deinterlacing interpolation is still performed.

That with setting set to 4. With setting set to 5, some frames are still interlaced, but not a lot... under 1%...

[trbarry]

BTW, I did manual frame advanced on the source, and like every single frame is interlaced, so I doubt IVTC would work on the opening sequence in the first place. The thing is, even setting it to "3" which should deinterlace everything, it still looks bad compared to a standard blended deinterlace.


Blight -

One more question...

Did you happen to try any of the standard blended deinterlaces on this particular material? I still can't make up my mind whether I've introduced a new bug here.

BTW - pure deinterlace will indeed make more of a line doubled look, with a bit less detail. But it shouldn't make things look like the samples you showed above.

I don't have any Angel caps handy but I have a couple of this year's Buffy's which have the same type of intro and they don't seem to have this effect.

- Tom

[Blight]

Well, If i'll do the standard deinterlacing, i'll have the ""nice"" old ghosting effect you see when standard dinterlace:blend

I did notice that if I enabled the vertical filter, these aliasing disappear, however, the image is blurred too much.

Here are shots from smallville with: GreedyHMA(1,0,4,0,0,0,0,0)

These are from the acutal show (not opening credit) and can for the most part IVTC nicely when using the "5" setting.
http://www.inmatrix.com/temp/smallville01_1-0-4-0-0-0-0-0.jpg
http://www.inmatrix.com/temp/smallville02_1-0-4-0-0-0-0-0.jpg
http://www.inmatrix.com/temp/smallville03_1-0-4-0-0-0-0-0.jpg

These are from the opening sequence, which contains tons of fades and cuts and by manual observation is nearly 100% interlaced:
http://www.inmatrix.com/temp/smallville04_1-0-4-0-0-0-0-0.jpg
http://www.inmatrix.com/temp/smallville05_1-0-4-0-0-0-0-0.jpg

This is from the actual show (where there seems to be a rathe chear pattern), and here you can see the same line pixelization effect even when the setting is set to "5" (even though there's no real motion in this scene)
http://www.inmatrix.com/temp/smallville01_1-0-5-0-0-0-0-0.jpg

Oh, and with the setting set to 5 on a scene which had what appeared to be a rather clear pattern, there were quite a bit of field mismatches.

[Blight]

Oh, and while the filter is actually very fast, It could be faster for 2-Pass encodes if there was an option to save a log file so some of the data won't need to be processed again on the 2nd pass.

And I forgot to mention, KEEP UP THE GOOD WORK! even though I bitch above stuff, it's still VERY good work.

[Luxcious]

trbarry

Hopefully you can help me with this problem I'm having.

Upon further examination, I have found that GreedyHMA seems to leave interlacing artifacts, most noticably on scenes that contain diagonal lines. I have saved some jpgs and will describe the scripts I used. For some reason, I'm not able to link directly to images on geocities, so here is a link to my svcd test jpgs (http://www.geocities.com/luxci0us/) that you'll need to refer to.


First up, is the script with GreedyHMA for IVTC.


LoadPlugin("C:\video\GreedyHMA3.1.0\GreedyHMA.dll")
SegmentedAVISource("h:\BoB9-SVCD_18.avi")
Trim(4009,102863)
GreedyHMA(1, 0, 4, 0, 0, 0, 0, 0)
Trim(5516,6962)
Crop(0,0,480,464)
BicubicResize(480,480)

The 1st trim is to remove extraneous video from the beginning and end of the capture. The 2nd one extracts 1 minute for testing.

You'll see the diagonal lines on the violin strings. This seems to occur on every 2 frames out of 4. Some scenes look better than others. I think it's mostly when there are diagonal lines in the source.



Second I used the Aviutil method for IVTC. There is no script, because it does not use avisynth. This is a really good method, but very slow, and prone to letting interlaced frames slip by. The framerate from this method is always 23.976. My major problem with this method is that it makes it very difficult to prepare a video/audio stream that CCE will accept.



Third I used a method that I have found to be almost flawless, except for the fact that the interlacing pattern changes throughout the show, causing this method to fail as soon as that occurs. Once, I went through a whole movie, and made note of every change in pattern, and adapted the script to reflect that. What a pain that was, but it looked great :D Heres the script I used for this method:


SegmentedAVISource("h:\BoB9-SVCD_18.avi")
Trim(4009,102863)
AssumeFrameBased
SeparateFields
# 23.976 0,1,5,6 interlaced
SelectEvery(10, 1,2, 4,5, 6,7, 9,8)
Weave
Crop(0,0,480,464)
BicubicResize(480,480)


From what I can gather, this is essentially what the Pulldown command was supposed to do in avisynth. The commented line refers to the frames in the clip. If all frames ending in a 0,1,5 or 6 are interlaced, this will recreate them perfectly. eg: IIPPP IIPPP



And finally, I tried the latest version of the plugin from the doom9 homepage. The InverseTelecine plugin written by Wizard_FL, i believe.


LoadPlugIn("c:\video\IVTCPlugin210\InverseTelecine.dll")
SegmentedAVISource("h:\BoB9-SVCD_18.avi")
Trim(4009,102863)
InverseTelecine(60,40,200)
Trim(5516,6962)


Unfortunately, I've never been able to get this plug-in to recreate the frames for me. Also, I seem to have the same trouble with the frame rate coming out at 23.970 using this method. No matter how I modify the settings, I usually get 1 frame out of 4 that looks like this one.

I hope you or someone else can shed some insight on to this for me.

Thanks.

Lux.

[Blight]

The wizard IVTC filter (one on doom's page), does the same for me, it converts IIPPP to IPPP, which isn't really very useful.

It does it on clearly visible pulldown structures.

[Milkman Dan]

edit: Can't remove post.

[Milkman Dan]

Well, I'm jumping into the testing here with Greedy, and I'm pretty impressed. It seems to give a more consistent result than inversetelecine.dll.

The only material I have trouble with is some anime that was encoded by a doofus. It swaps field order, over and over again, at seeming random intervals. It doesn't happen only on scene edits, or anything like that either. It can be in the middle of a scene, and just swap.

I can tell this is the case, because when I complementParity, the frames that appeared interlaced (in a raw feed of the d2v) look normal, but yet other frames that looked fine are interlaced now. DoubleWeaving makes this even more apparent.

When Greedy hits this material (which left on its own would move forward a few frames, then jump backward a field or three, then jump back to where it was), It admirably cuts through most of the crap, leaving a set of progressive frames, and a periodic interlaced frame in a clear pulldownish order. (usually IIPPI IPPII PPIIP and so on, with two progressive, two interlaced) If I engage a second greedy after the first, with (1,0,2,0,0,0,0,0), the result is slighty less interlacing artifacts, but the order is still there.

So, perhaps Greedy needs to be able to remember more frames? Have a deeper buffer? I can post the field order progression here, with swaps, if it would help you out.

But this is great work, and it's quite fast, which is a treat. Thanks for the work!

[trbarry]

Blight -

Have you tried the other 3 possible combinations of the first two parms? The reason I ask is the artifacts in the close up of Clark from the opening sequence. Look at the horizontal top of his white shirt. With horizontal lines this can't just be blamed on diagonal jaggies but sometime by reversing one or both of the first two parms, either TopFirst or Swapfields.

Greedy still needs better frame by frame decision logic for whether to do pulldown removal or deinterlace. This is true in the DScaler project also but there folks just don't use Greedy's AutoPD; they will use the regular Dscaler Auto Pulldown instead so I haven't fixed it yet but I have some ideas. Talking only about AP=1 or 4 here.

On the speed issue, have you compared to the same filter script with GreedyHMA commented out? Most things I've tried suggest that Greedy isn't the bottleneck anyway. Except for the new IVTC decimation code GreedyHMA can do 720x480 @ 60 FPS (full frames) in DScaler on my 866 P-III.

But for speed I've actually considered building it right into DVD2AVI if I could ever get current source. This whole issue is complicated because deinterlace/IVTC always has to be done before resize or the results are hopeless. BTW, that's not your problem is it?

Anyway, thanks for the constuctive suggestions and encouragement.

- Tom

[Blight]

You misunderstood me on the speed issue.

The filter is VERY fast. The thing is, if you're going to do a 2 or 3-pass encode, say SVCD or DivX4, you're going to be re-calculation pulldown field selection for every pass, something that can be saved if a log file is kept off the first pass indicating which fields were used.

[Blight]

First thing, I sent you a private message with a 4mb sample file I'm using as a source. If you're not familiar with private messages, press on the "user cp" button at the top of this page.

Ok, I checked field ordering and that's not an issue.

However, I did discover something...

I set the code to "2" (force film, no frame drops).

What I noticed is a strange cycle

First Frame - Clean Image
Second Frame - Starting to get some of these Artifacts
Third Frame - Even more Artifacts
Forth Frame - The most Artifacts
Fifth Frame - Clean image and position identical to the Forth frame

In practice, the 5th frame is dropped, while in theory, the 5th image is a clean version of the 4th frame. However, why are the artifacts being added in the first place? If a field is not found, I epected to get an interlaced frame... but this isn't the case! it's as if it finds the field correctly, but somehow slightly corrupts it during the copy.

I included my script in the sample file, simply change the paths and you should be able to see this for yourself. I'm using AVISynth v1.05 and the latest GreedyHMA (0.3.1.0).

[trbarry]

Luxcious -


Upon further examination, I have found that GreedyHMA seems to leave interlacing artifacts, most noticably on scenes that contain diagonal lines. I have saved some jpgs and will describe the scripts I used. For some reason, I'm not able to link directly to images on geocities, so here is a link to my svcd test jpgs that you'll need to refer to.

Jaggies on diagonal lines are the bane of pure deinterlacers. Unless you buy a $20000 Faroudja you can't easily get rid of them in an adaptive deinterlace method without just doing some sort of smoothing to hide them, and that loses too much detail.

But the problem here is that Greedy should not have been deinterlacing in the first place. Like I commented to Blight above, the main (known) weakness is Greedy's choice logic in AP=1 or 4 modes.

Anytime you can get away with using AP=5 you are far better off. It can deal with most cadence changes and dropped frames, but not with video overlays after telecine, or some edits. Many times you are even better using AP=5 and then just deleting a few selected frames from the final output. But of course if there were a lot then you don't have that choice.

I've mentioned before I'm not a fan of the manual IVTC methods since any dropped frame or edit can completely change the pulldown order. But the one manual thing folks might have to do temporarily is use trim and then use completely separate parms for the opening and maybe closing sequences. They are often very different and more apt to have video overlays applied after telecine.

BTW, improving the AP choice logic is a bigger task that I've been putting off. Most of the bug fixes I've been posting here are in new code written for the Avisynth environment only. My next version of Greedy (High Motion) for DScaler will hopefully address the choice problem and be automatically also picked up by GreedyHMA. But it is still in the research stage, no code yet.

- Tom

[Blight]

At least I'm trying to upload the 4mb sample, my ISP is on the fritz again

[trbarry]

Milkman Dan -

I can't help you at all with the dynamic field swaps. I don't understand that and am only beginning to research it. I'm starting to think that some capture card drivers may drop fields instead of frames and you might be better off with different capture software.

But if you are finding a lot of it on a DVD then I don't know what to tell you.

If no one else explains it them someday I might try to write a completely separate filter just to experiment with this but it probably won't be soon and I couldn't yet even tell you what I'd write.

Sorry,

- Tom

[trbarry]

Blight -

Yes, that is too strange to explain. I definitely need that test data.

However I downloaded an empty zip and stupidly deleted your PM before checking.

So, sorry, I need the link again. BTW, I never even noticed the PM. Don't we get a popup when we come on the board or something? Or do I have to go looking for them?

- Tom

Edit: don't need the link again, it was still in history.

[Blight]

Ok, the file is now up (finally!) I posted the url again in a private message.

As for private messages. On some boards it blinks at the top of the page that you have a new message. In this one, you have to guess it.

[trbarry]

I hope I'm not violating forum policy here but, for those of you following GreedyHMA, the first official production release of DScaler that contains the Greedy (High Motion) deinterlace plug-in was released a few minutes ago. See the official announcement for DScaler 3.1.0 over on this AVS thread (http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=89606).

However Greedy/HM's been in DScaler betas since July or so.

- Tom

[Blight]

Question, since the dscaler pulldown detection is quite advanced by now, isn't it something you can import into GreedyHMA? Might be also useful for doing PAL frame reconstruction from video that seems to change the phase every scene change.

[trbarry]

Blight -

That is sort of an embarrassing question. ;)

I thought I had a better way that would handle pulldown issues without relying on a regular cadence. This was intended to handle 3:2, 2:2, or 666:69 pulldown as it mutated.

But I ran into some issues I had not planned for. I have not given up yet but I suspect the Greedy recognition will have to incorporate some of the regular DScaler ideas. And the regular DScaler code gets info direct from the capture card and doesn't have to deal with things like changing Field Dominance or Swap Fields, or brain dead capture drivers.

- Tom

[trbarry]

BTW - I think with AP=2 it can already handle the changing PAL.

- Tom

[Blight]

I have quite a bit of experience with bt878 based capture.

Doing YUY2 capture under Win98 using the VFW drivers switches field order, and it's actually quite easy to catch just by loading the clip.

Doing the same capture using WDM drivers don't have this issue. But then again. There's not a single WDM AVI Capture program that can properly adjust the audio to keep in sync with the video.

In any case, did you manage to get the sample successfully and see the issue I described?

[trbarry]

I got it okay and sent you a PM about it.

I will have to switch to my dev machine to play with it but the dog is nagging me now to take him out for a walk instead. Back shortly, I owe him.

But do I need PICvideo codec, or what? My HTPC says it doesn't have the right 4cc mjpeg codec support. On this box I have only Matrox, for my G400.

- Tom

[trbarry]

Blight -

I can see the file now and easily recreate the problem. Yes, it is likely a (rather ugly) GreedyHMA bug. I don't know what is causing it yet but this should be enough info to find it if I just step the debugger through the whole thing.

Thanks, more later,

- Tom

[Blight]

Even with this bug I'm probably getting the best and most reliable automatic IVTC video encodes at the momemnt (don't ask me what bugs I've experienced trying to automate TMPEG's IVTC, it's quite bad at automation, prone to lots of weird bugs).

[trbarry]

Blight -

I've actually been staring at this stuff for quite awhile. I don't think any frames/fields are out of order but some may be missing, as if the charging thru the door was sped up by edit after telecine, or just a huge number of drops. I could be wrong but I don't think there is any way that those frames could be matched up in IVTC. And I don't see the action go backwards anywhere. I suppose the easy way to check that is to just do a SeparateFields and step through them one at a time. Maybe I'll try that later.

It's true that Greedy fell into deinterlace for some of them. To force film I just set the Bad Pulldown Level to the max. But the weave effects are worse even than that. I could easily change this but I don't think you would like it very much.

I'm still looking at it, so maybe something else will appear but I'm less optimistic. At least it pointed out the max Bad Pulldown level error. I think I'll change it so the Bad Pulldown level parm also applies to force film. It will then default to a huge number, but can be still be overridden for the really extreme cases.

Please feel free to point out where I'm fooling myself here. ;)

- Tom

[Luxcious]

Tom

Well, I'm still getting artifacts using GreedyHMA on this material. I decided to try a manual IVTC, by finding out where the shifts in patterns were, and applying avisynth's native Pulldown command. Here's my pattern changes, and the script I've used:


0 - 20799 PIIPP
20800 - 41538 IIPPP
41539 - 45434 IPPPI
45435 - 58369 PPPII
58370 - 79184 PPIIP
79185 - 98857 PIIPP


SegmentedAVISource("h:\BoB9-SVCD_18.avi")
FullClip = Trim(4009,102863)

Part1 = FullClip.Trim(0,20799).DoubleWeave.Pulldown(0,3)
Part2 = FullClip.Trim(20800,41538).DoubleWeave.Pulldown(1,3)
Part3 = FullClip.Trim(41539,45434).DoubleWeave.Pulldown(1,4)
Part4 = FullClip.Trim(45435,58369).DoubleWeave.Pulldown(0,2)
Part5 = FullClip.Trim(58370,79184).DoubleWeave.Pulldown(0,3)
Part6 = FullClip.Trim(79185,98857).DoubleWeave.Pulldown(0,3)

EditedClip = Part1 + Part2 + Part3 + Part4 + Part5 + Part6

Return EditedClip.Crop(0,0,480,464).BicubicResize(480,480)


It took me about an hour or so to find where the pattern changed by jumping frames in VirtualDub. I'm currently encoding through Aviutil, so I haven't done a test encode of this yet. Just previewed it in VirtualDub, and I believe there is only 1 frame that is interlaced (which I knew about, and was part of 5 frames that had a really strange pattern, but Pulldown(0,3) seemed to be the cleanset). Other than that, there are no blurry frames or diagonal lines, and it looks perfect. Framerate reported in VDub is 23.976.

I noticed that the 6 pattern changes only shifts by 1 frame. What I'm not sure about is if that's how it is broadcast, or how it is being captured. Avi_io didn't report any dropped frames during the capture. All of the pattern changes don't take place on scene change, either. They all occur mid way through a scene.

Also, regarding the openings and closings of shows, I've found the opening of this show to look fine when it's gone through IVTC. It seems that in every group of 5 frames captured, there is 1 interlaced frame, and 1 duplicate frame. Applying IVTC to it seems to deinterlace the 1 frame, and remove the duplicate. However, I always do the credits at 29.97 Interlaced, since I'm burning to SVCD.

So, I guess I'm wondering, does any of this match the way GreedyHMA performs IVTC? Does any of it help in figuring out how I can use GreedyHMA to perform as well as this script?

I'm still very interested in using GreedyHMA. I'm really thankful that people like yourself are willing to create tools for us all to use. And I'm really happy I found this board :D

lux.

[Blight]

Barry, I don't quite understand what you wrote there...

As far as I can tell, there is no missing fields, and you get more and more artifacts every 5 frame cycle, regardless of the source... I'm not even talking field matching here, even on deinterlace...

Even when I set GreedyHMA(1,0,0,0,0,0,0,0), I can still see this 5 frame cycle of ever increasing artifacts.

[trbarry]

I guess I was just saying there does not appear to be any way to match up the fields on the short sample you sent me.

Do you see any combination of Trim(), SelectEvery(), etc. that would work on that short sample? (without Greedy?)

- Tom

[trbarry]

Luxcious -

Now that you know which sections have intact pulldown, is there any pattern to where Greedy screws up?

Later today I'll try to release a new version of GreedyHMA that does not switch to deinterlace in these cases. It likely won't fix your problem but it will at least not try to hide it by deinterlacing when AP=2 or 5.

Beyond that I'm not sure yet, but it will at least give us more info.

The way Greedy does it (for NTSC) assumes a pulldown sequence like that described in Nicky Pages Guide (http://www.digital-digest.com/nickyguides/interlace.htm). Scroll down to the section on NTSC 3:2 pulldown. But Greedy does not assume that sequence starts at the beginning, only that each field can be properly matched by either the field immediately preceding or following it.

- Tom

[Blight]

This picture:

http://www.inmatrix.com/temp/britney_pal_1-0-0-0-0-0-0.jpg

Is from a PAL source, my own system. This system does perfect caps, no frame loss EVER, even on 3 hour captures using HUFFYUV.

The source is interlaced with GreedyHMA(1,0,0,0,0,0,0,0) setting.

As you can see... the same issue as the other encodes. And once again, I'm not talking about an IVTC issue, I'm talking about an interpolation artifact issue. Interpolation deinterlacing on leaves tons of artifacts...

[trbarry]

Blight -

Sorry, I wasn't arguing about whether deinterlacing (including GreedyHMA) creates artifacts, though I try to minimize them. And this was certainly true on the sample clip you sent me. I look at deinterlacing as a numbers game, making the best guess at info that isn't really there.

I even know why Greedy chose to deinterlace that sample clip (against your instructions) and can easily fix that (I think).

But on that clip I don't understand why, if Greedy didn't deinterlace it, it would not have done pulldown matching properly. I'll post a fix for the first part of the problem today and I think it will be pretty obvious what I mean if you run it again against your sample. :(

Again, on your sample clip I just can't see how the fields could be matched up. If you can see any way it could be done properly please let me know and I'll try to incorporate it somehow. But I'm still looking.

BTW, can you post another copy of the above jpg that does not use greedy? What should it look like with properly matched fields, and no filtering?

- Tom

[Blight]

Like I said, this was an interlaced source, so you can't match fields...

As for the smallville sample. (and also enterprise and smallville) how can you explain the 5-Frame cycle of added deinterlace artifacts?

I'm going to upload an encoded enterprise sample which shows this. You'll need DivX4 to decode it and should frame-step it in VirtualDub as the DivX4 post processing can actually hide some of the artifacts.

What I'm asking you to look at is the 5-frame cycle of artifacts...

This file is rather small, and shows post-encoding using the "4" setting. It might take me abit to get the sample up due to my ISP...

I've seen perfect (or near perfect) IVTC encodes of enterprise. Not exactly sure what was used, possibly TMPEG, so it should be possible to match the fields properly.

[trbarry]

I can't really explain the 5 frame cycle on the Smallville sample yet though I'm not sure it is exact. I'm still playing with it, and with another sample with similar problems.

I already have a ATSC digital capture of parts of Enterprise, though I can't state how good the IVTC works on it. This was from the premier and I hadn't added full IVTC to the code yet. I deleted most of it because others had captured it just fine and the digital version I get is windowboxed and heavily filtered.

But thanks. I acknowledge there is a problem and I'm sure we'll figure out something.

- Tom

[trbarry]

Okay. I'm taking a break here and I'll take the opportunity to rant about how stupid I am. Also I'll stop pestering poor Blight about how I should convince him his data is bad. It is not. Sorry.

I took my own advice and used SeparateFields on the test data and then stepped through it (42 frames) 1 at a time. I can more or less match every field without major problem, all with adjacent fields. But GreedyHMA can't.

Yet.

In theory there is nothing there that GreedyHMA shouldn't be able to handle but it still insists matching fields wrong. So I don't need any more test data.

Just a new brain. Grrrrrrrrrrrrrr! Time to go walk the dog and think about this.

- Tom

[Blight]

*wiping forehead*

I've been trying to upload that enterprise clip for a while now, my ISP has packetloss, and the server I'm uploading to doesn't support upload resume, so I wasn't able to upload it.

But I guess now I won't need to, so that's ok. Although ... I suspect that the aliasing I see is regardless of the actual field matching. I think it's partially interpolation based, so the question is, can you make an optional "movement area" blending scheme.

[trbarry]

Just got back, no change in status.

Blight -

I think as you said before, Enterprise and Smallville don't usually need deinterlace so it won't matter as much if I get rid of this strange '5-cycle of death' bug. And no, I don't need the other sample.

But for things that do need deinterlace, Greedy is motion adaptive. It interpolates and horizontally smoothes only in moving pixels. On stationary pixels it weaves. On slowly changing pixels it blends both. The problem is, if it is deinterlacing things that should be telecined then the motion isn't being measured accurately anyway, and it should be doing 100% selective weave (field matching).

But deinterlace is still what it is, never as accurate as actually matching the fields when possible. So without filtering you have to put up with some jaggies, a little sizzling, some loss of detail, and an occasional shimmer or jitter if you bob too much.

Now back to the debugger.

- Tom

[Luxcious]

Originally posted by trbarry

Luxcious -

Now that you know which sections have intact pulldown, is there any pattern to where Greedy screws up?
- Tom

Hi Tom.

The only pattern I can really see when I use Greedy, is 2 progressive frames, followed by 2 frames that look as though they've been deinterlaced. They contain some interpolation artifacts, and diagonal lines contain the jaggies. This seems to occur throughout the entire clip. It does look like it's deinterlacing, as opposed to reconstructing the frames. (in those 2 out of 4 frames at least)

This is with both AP=4 and AP=5. Also tried with Edge Enhance, Vertical Filter, and with GPL, and BPL set to both high and low values (2 - 255). I also tried all 4 variations of the 1st 2 params, and leaving it at (1,0) seems to be best.

Some combinations exhibit the 2 frame problem I describe above. Other's just leave interlaced frames, or combine the fields in an odd way. This may be related to the same problem that blight is experiencing ...

On another note: the SVCD I made with the manual IVTC looks great. Not even sure how long the encode took, cause it was done when I woke up. I know the 1st pass took about 1:20 for :54 minutes of film.

Lux.

[trbarry]

I haven't dropped off the face of the Earth or gotten quite disgusted enough to give up programming altogether. But it was close.

All current versions of GreedyHMA have a very obvious bug. Meaning of course it was completely invisible to me.

Way back in the first post, and in the Readme, I marveled that the consensus was that most clips and capture cards are BottomFirst but GreedyHMA seemed to always give better results with TopFirst, that is GreedyHMA(1,x,x,x,x,x,x,x). Well, that should have rung alarm bells.

THAT IS WRONG, so all (most?) of the AVS scripts with GreedyHMA(1,0,x,x,x,x,x,x) will have to soon be changed to (0,x,...), as soon as I post the fix.

All current versions of Greedy have been processing the fields in the wrong order, but making up for it somewhat by the automatic field matching and occasional retreat into deinterlace. It only appeared that TopFirst worked better because of a stupid typo I had in the proper BottomFirst section of code.

I'll be out for awhile today but later on I should be able to finish testing this and post a fixed v 0.4.0.0 with a new Readme.

Never should have left that TopFirst anomaly go unexplained. This shows again that unexplained computer mysteries ALWAYS come back to bite you. ;)

- Tom

[jarthel]

How well does GreedyHMA work for animes? Thanks Tom :)

[SleepEXE]

trbarry, I just wanted to express some words of thanks for your efforts in producing an IVTC solution for Avisynth. This thread has made evident your exceeding level of skill, intellect, and resolve, and it's a pleasure to read through the thought processes toward the rapid evolution of GreedyHMA. I think we're fortunate that you stepped in to offer your expertise.

At the same time, I'm a little disappointed to find out that the batched runs of The X-Files first season that have been crunching away on my machines (yes, 4 of them) will probably need to be re-done. Of the few episodes that have completed, I've noticed some interlacing and jerkiness that I somehow managed to overlook when testing the scripts. But that was a calculated risk I knew I was taking when being an early adopter. Basically it was either GreedyHMA or AviUtl, whose auto IVTC is pretty much flawless, but so agonizingly slow that I'll be able to perform 2 runs with GreedyHMA in the time it takes to perform 1 run with AviUtl. No biggie, I've learned a good deal from the experience, and as far as I'm concerned, that's what it's all about. Judging by the activity in this thread, apparently I'm not alone.

I'm also itching to try it with a 40GB HuffYUV capture of Real Genius. It's one of my favorite movies of all time, and not available on DVD, so I'm determined to get the best possible encoding. Actually, I already have a pretty good encode with GreedyHMA(1,0,3,0,1,0,0,0), but I understand that's not true IVTC...I had tried just about every conceivable combination of parameters with both Greedy and the Inverse Telecine plugin v2.1, and that combination was most effective in rendering a clean video stream with no interlacing. I'm also hoping Steady will release a beta of his DustPan plugin soon so I can give it a whirl.

Thanks again, I'll certainly be watching with anticipation for the next release. :)

Best regards,
SleepEXE

[trbarry]

How well does GreedyHMA work for animes?

Jarthel -

Much better now than yesterday. See announcement below. ;)

But you may have to force it to deinterlace mode for the very worst ones. The Greedy (High Motion) mode of DScaler was partially designed for that. But if the only problem is changes in pulldown cadence then you are probably okay with ap=4 or 5.

- Tom

[trbarry]

SleepEXE -

Thanks for you kind words. But before redoing all your caps, be sure to test to see if you are affected by the TopFirst problem. (see next post) Any IVTC/Deinterlace method might let some things through, certainly GreedyHMA still isn't perfect even with the new 0.4.0.0.

Note the TopFirst.avs & BotttomFirst.avs scripts. And I'd try at least a short sample of X-files using GreeyHMA(1,0,5...) or (0,0,5,...) first. I think you might now get away with it after downloading the new one.

- Tom

[trbarry]

I've put out a new version, at www.trbarry.com/GreedyHMA.zip

This fixes the TopFirst/BottomFirst bug discussed earlier. That bug would have affected many of you because it would have appeared your captures were stored in TopFirst format, causing you to specify GreedyHMA(1,0,...) which may not be best.

But while you didn't have any choice then it would have caused GreedyHMA to process fields in the wrong order. TopFist only seemed to look better because BottomFirst support was busted.

In the new zip I placed two new AVS files that make it easier to see what kind of capture source you have. See the discussion in the www.trbarry.com/Readme_GreedyHMA.txt file, also in the zip. But anyway, be sure to test before redoing any caps.

Some of you will turn out to have cards or source that really do put out fields Top First. For instance my WinTV-HD digital ATSC captures really are. But with the new Greedy version others of you will find they really should be using TopFirst=0.

Blight: You're samples are included here. With the new Greedy your sample will telecine fine using (0,0,5,...). Yours are BottomFirst.

Be sure to check the readme file. I've also fixed it so GreedyHMA does not fall into deinterlace when you specify Force Film (AP=2 or 5). But it now allows an override to the Bad Pulldown lvl parm in these modes which, if nonsero, will set a maximum amount of interlace to put up with before doing a frame as video. If you leave this value defaulting to 0 then it will completely Force Film no matter what.

As always, need feedback.

- Tom

[jarthel]

Originally posted by trbarry


Jarthel -

Much better now than yesterday. See announcement below. ;)

But you may have to force it to deinterlace mode for the very worst ones. The Greedy (High Motion) mode of DScaler was partially designed for that. But if the only problem is changes in pulldown cadence then you are probably okay with ap=4 or 5.

- Tom

Can you translate that into greedyhma avs line? Thanks :)

[trbarry]

jarthel -

Ok, let's assume you followed the new readme file and determined that you don't need TopFirst, so the first parm = 0. I'll use that for all the examples below, but it may be 1 on your system.

So I'd first try for the best results you could get if you get lucky and your source was fairly nicely telecined (assuming American NTSC):

GreedyHMA(0,0,5,0,0,0,0,0) # best results for pure film

but if it is a little messy then you could try putting a Bad Pulldown Limit on it to, say 150 or less, like:

GreedyHMA(0,0,5,0,0,0,0,150) # next best, with a weave threshold

If your source was mixed, with large video sections in it, then try making it automatic:

GreedyHMA(0,0,4,0,0,0,0,0) # Auto Pulldown switching film/video

And if it's all video or just totally a mess any other way, maybe just deinterlace the whole thing, use:

GreedyHMA(0,0,0,0,0,0,0,0) # All video, output 30 frames / sec
GreedyHMA(0,0,3,0,0,0,0,0) # or decimate video to 24 fps
GreedyHMA(0,0,3,0,1,0,0,0) # or maybe even with a vertical filter

But remember these are just my current but evolving opinions. I'm slowly learning some of this as I write this thing.

- Tom

[Blight]

Barry, If all works well, I'll try writing up a "How-To" tutorial on my site (inmatrix.com).

[Blight]

Question:

You stated that using an autopulldown setting of "5" will never deinterlace. But if you set the GoodPullDownLvl/BadPullDownLvl settings, it can deinterlace.

My question is, at what GoodPullDownLvl/BadPullDownLvl setting does the autopulldown "5" setting, becomes identical to setting "4", or does that never happen?

[Blight]

Ok, after running some tests on, here are my results:

1. Film Source Field matching works A LOT better!
2. There are still minor issues with matching when there's little on-screen movement (like when an actor talks but nothing other than his mouth is moving in the entire frame).
3. At setting "4", there's still quite a few interlaced frames sneaking in on mixed film/video content.

Conclusion: MAJOR improvement! I recommend re-encoding using this update if you still have the source video.

[trbarry]

You stated that using an autopulldown setting of "5" will never deinterlace. But if you set the GoodPullDownLvl/BadPullDownLvl settings, it can deinterlace.

My question is, at what GoodPullDownLvl/BadPullDownLvl setting does the autopulldown "5" setting, becomes identical to setting "4", or does that never happen?

The readme file states that in Auto Pulldown modes (1 & 4) the Good Pulldown lvl default=90 and Bad Pulldown default=85. But that is not true for force film (AP=2 or 5). There, Good Pulldown=0 and cannot be overridden. Bad Pulldown defaults to like a million or something that can't happen, but now may be overridden when coded nonzero. Only values of maybe 0-400 might currently be meaningfull. And yes, even in Force Film if you actually set a Bad Pulldown level then it will deinterlace if that's exceeded for a frame. But it won't exceed a million.

1. Film Source Field matching works A LOT better!
2. There are still minor issues with matching when there's little on-screen movement (like when an actor talks but nothing other than his mouth is moving in the entire frame).
3. At setting "4", there's still quite a few interlaced frames sneaking in on mixed film/video content.


1. Yes! Sigh of relief.

2. Is this using a Bad PD override? That is one of the things the DVD player shootouts test because it's such a trade-off. I think one of the Video Essentials Montage tests has a video interlaced still scene with a single small pedestrian walking across in the distance. At what point do you interlace the whole picture in order to save one small part. And now we are back to the auto pulldown recognition needing work, which it does. ;)

3. Mostly the same answer as above. I've got some ideas but nothing that can be a quick fix, except being willing to deinterlace more by raising the Good Pulldown level or lowering the Bad Pulldown level. Drat! I meant to drop the default for Bad Pulldown to 75 or 80. I forgot, but recommend it, probably 75. This is different from DScaler but here folks have more different modes to choose from. But the Bad PD level is definitely the thing to play with. With the Good PD level the whole algorithm is subject to change in the future.

Conclusion: MAJOR improvement! I recommend re-encoding using this update if you still have the source video.

I'm very glad to hear that. But as far as recoding I'd suggest people verify they really should be using BottomFirst before re-doing anything. Those who need TopFirst anyway will probably see only marginal improvements, mostly from not falling accidentally into deinterlace mode occasionally. But those needing BottomFirst should consider it, since that was fairly messed up.

- Tom

[Luxcious]

Tom

Wow. Looks great so far. Stepped through VDub with a film clip and used:

GreedyHMA(0,0,5,0,0,0,0,0)

doing a test encode right now.

will let you know how it turns out ... looked at 2x and couldn't see the artifacts that were their using previous versions.

and i'm getting about 12fps encoding with CCE right now which is good considering the pure interlaced clip i encoded last night got around 15fps.

Thanks again, Tom. Great work.

Lux.

[Luxcious]

Tom

So, most of my test looked pretty good. There were some places where interlacing remained .. mostly scenes with movement in the distance.

Now here's the weird thing. CCE 3 pass VBR actually does 4 passes. 1st pass creates a .vaf file, and then it does 3 passes. This is the first time I've had CCE say that the CRC doesn't match the previous pass. Strange.

I'm not thrilled with this source material I'm using to test, so I think i'll find something else to cap and test later tonight.

Will let you know how that goes.

lux.

[Blight]

I'm still recommending that a log file be kept so some data won't need recalculating on 2nd passes.

[Blight]

A sort of question and a request...

Have you seen the edge enhancement of the WarpSharp filter written by Avery Lee? It's quite impressive. Is this something you can implement into the filter? (considering the source is out there) and if not, any idea how to implement this filter in AVISynth, I get an error when trying to do something like this:
---
function VD_WarpSharp(clip clip, int "depth")
{
LoadVirtualdubPlugin("c:\Program Files\VirtualDub\plugins\warpsharp.vdf", "_VD_WarpSharp")
return clip._VD_WarpSharp(default(depth, 30))
}
ConvertToRGB
VD_WarpSharp(100)
---

[trbarry]

Now here's the weird thing. CCE 3 pass VBR actually does 4 passes. 1st pass creates a .vaf file, and then it does 3 passes. This is the first time I've had CCE say that the CRC doesn't match the previous pass. Strange.


Luxcious -

Strange indeed, qualifying as one of those unexplained computer mysteries that I get very paranoid about. Non repeatable results often result from processing garbage, and I don't mean in the source file. If you can see any pattern in this I'd be very interested, but I don't have CCE and can't try it.

Do people recommend CCE? I know little about it but if it is commonly used here maybe I should think about it.

- Tom

[trbarry]

Blight -

It won't be first but I've been considering the log file idea since you first mentioned it. But I'll have to run some tests first to see how much GreedyHMA currently adds to the processing time. If a log file could not improve overall FPS by at least 10-20% then I'm not sure it would be worth adding the extra programming complexity. And probably little of Greedy's overhead is spent in aquiring these numbers.

I wonder if it would be possible to add a little pre-processing in DVD2AVI to make various things go faster with multiple pass Avisynth jobs? Not just for GreedyHMA but maybe other information also.

It would be nice to really know where all the processing bottlenecks are. IIRC, the Nandub folks were looking into this.

...

I've never run any of Vdub's filters in Avisynth and didn't know about WarpSharp but I'll look it up. The only filters I've added directly to Greedy are ones that I could get more or less performance free because the proper pixel data is already in MMX registers at the point it's needed. So median filter, vertical filter, and Edge Enhancement are there because they were very easy to get some incremental improvement. And I'll probably also extend Edge Enhancement to allow negative values, turning it into a Horizontal Smoothing filter that might be useful if you were going to be resizing downwards.

If WarpSharp is that good then it would seem useful to have a YUV Avisynth version of it, still as a separate filter. But it probably won't be by me anytime soon. I guess the first step is just to get the Vdub one working but I'm afraid I'm not much help there.

- Tom

[SleepEXE]

I'm still having a problem finding the right combination of parameters to recognize the pulldown pattern in The X-Files. If I step through the 29.97fps material, I can visually verify the pattern of 3 progressive and 2 interlaced in each 5-frame set, but I can't seem to get Greedy to pick the right ones. The field order has been verified to be bottom field first. The cadence changes periodically, so I can't do a simple SelectEvery(...). I tried tweaking the GoodPulldown and BadPulldown parameters like you explained [i.e. GreedyHMA(0,0,4,0,0,0,100,75)], to no avail.

Like Blight mentioned, the residual interlacing is mostly confined to scenes with small areas of motion. For example, panning across a chain-link fence or the leafless limbs of a tree. And of course, the combed interlacing artifacts consume a good deal of bandwith when encoding to MPEG4, so I would really like to get around it.

I wanted to see if AviUtl could handle it, and it does...but I'm wondering if Greedy can be made more sensitive to detecting interlacing artifacts and make it re-evaluate the pulldown pattern. And if so, does the secret lie solely in the GoodPulldown and BadPullDown parameters? In the case of material which has a visually identifiable 3 progressive / 2 interlaced frames, I assume there must be a way.

Can anyone make a suggestion?

Thanks,
SleepEXE

[trbarry]

I wanted to see if AviUtl could handle it, and it does...but I'm wondering if Greedy can be made more sensitive to detecting interlacing artifacts and make it re-evaluate the pulldown pattern. And if so, does the secret lie solely in the GoodPulldown and BadPullDown parameters? In the case of material which has a visually identifiable 3 progressive / 2 interlaced frames, I assume there must be a way.

Greedy is already able to automatically handle changes in the pulldown cadence (usually). I think for something like X-files you should just Force Film but maybe add a sanity check with the Bad Pulldown level at around 150-170. Something like:


GreedyHMA(0,0,5,0,0,0,0,150) # all film, not auto

The artifacts you mentioned are more symptoms of deinterlacing, not bad IVTC. And I'm pretty sure X-files is film based.

- Tom

[SleepEXE]

Thanks trbarry, I had tried AP=5 but not with the BadPulldown level. It was a cursory attempt, since DVD2AVI was reporting some NTSC (non-film) material occasionally...I think during the intro sequence and perhaps closing credits. So I didn't think AP=5 would be a good choice.

The artifacts you mentioned are more symptoms of deinterlacing, not bad IVTC

Ah, I didn't realize that. So you're saying Greedy is probably correctly doing pulldown, but still thinks some deinterlacing is necessary in spots which is causing the diagonal jaggies I mentioned? I'll give your suggestion a try and see if adjusting the BadPulldown parameter fixes things up.

Many thanks! :)

Best regards,
SleepEXE

[trbarry]

I'm going to add another point for use with GreedyHMA that's maybe obvious and doesn't really need elaboration. But it's a mistake I've made so I'll mention it anyway.

That is, don't look at headers, trailers, and commercials as being representative of the shows you're processing. This is especially true of timer captures where you are almost sure to start in the commercial segment, a hodgepodge of film and video stuff unrelated to the show. So, obviously we have to look at the real material.

And don't worry about the cadence. Greedy doesn't rely on knowing it can always drop the 3rd of 5 frames or anything like that. It matches fields one at a time and looks ahead 5 at a time to decide what to drop (optional).

A normal telecine process just splits each frame in two and then weaves the fields (half frames) together in a stream. But it has to add an extra field after every 4 to increase the field rate to 60 fields, 30 frames, with first 3 fields from a frame and then 2, in a 3:2 sequence. The notation I usually use to think about it is something like:

a a b c d e e f g ... (an interlace stream)
_a b c c d e f g g

but if it's then made into frames by a Bottom First capture driver you start with the bottom 'a' and get frames like:

a b c d e e f g ... (as frames)
a b c c d e f g g

So you might just call it the pppii sequence. The first way just shows more info if you're trying to find the problems. But in a sequence like this greedy can usually match up the frames even if one is deleted here and there as the pulldown cadence changes. Either way it should get immediately back in step as long as matching fields are available to it in either the current or preceding frame. So usually you don't have to worry whether it is, say, a pppii, or a piipp, sequence since Greedy doesn't care. That is also why it can do PAL 2:2 pulldown matching using the same code for frames like

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

and still come up with all progressive frames.

- Tom

[Luxcious]

Tom

I have some some source material that I captured that I am certain is PAL. There are the black borders at the top and the bottom of the screen (Like the BBC news is aired), and actually this show is from the BBC. So, every frame appears to Interlaced. A few days ago, I captured a similar program that was from the BBC, and fully Interlaced (without the black bars, though), so I thought I could encode it as an NTSC Interlaced SVCD. Was I ever wrong. It looks great on the PC, but as soon as I burned it and tried it in my Apex, vertical lines get 'wiggly' whenever there is movement. And I no longer have the source for that one. :(

But now I have this new clip, and I don't want the same results as the last one. So, is there a GreedyHMA setting I should use for this?

It's captured as 352x480 NTSC. I was hoping to make an SVCD from it. Will I be able to recreate the PAL frames, or should I be de-interlacing? Enquiring minds want to know.

Anyone else who's had experience capturing PAL shows from an NTSC source, and creating something like an SVCD could respond too.

[Blight]

Lux, that sounds weird.

If your broadcast is PAL, you capture PAL, no matter what the show was originally shot at, and the it was adjusted to be seen in PAL.

If you want to later convert it to NTSC, you'll have to adjust the frame rate and resample the audio.

However, you can also make a PAL SVCD (480x576@25fps).

[trbarry]

Luxcious -

Sorry I can't add any more. I've never made an SVCD. Everything about GreedyHMA is targeting at making progressive video out of various things.

But I sure there are lots of folks here that know way more about it than I do. Maybe some of them can help if Blight's comments didn't already do it.

- Tom

[Luxcious]

Blight

I've never tried capturing PAL. I didn't know I could capture as PAL from an NTSC signal. I'll look into that for the next one.

In the meantime, I'll try and see if I can get something acceptable from this existing capture I have.

Lux.

[h00z]

I am new to the whole AVISynth thing, but after reading this thread I figured I'd give it a shot (I rip a LOT of anime). I don't know if it is just me being a moron or what, but I cannot get AVISynth to work for me at all. I have read the guides here and at Nicky's Pages, but when I try to open my AVS:LoadPlugin("C:\unzipped\Avisynthv105\GreedyHMA\GreedyHMA.dll")
DirectShowSource("G:\VOBs\istillknow\vts_01_1.vob",fps=29.970)
return GreedyHMA(T,0,4,0,0,0,0,0)I just get errors and/or VDub crashes. If I open it without the ",fps=29.970", I get an error stating that VDub can't detect the FPS of my source. If I add the ",fps=29.970", VDub just dumps its error log and exits.

What am I missing here (or am I just an idiot)?

EDIT: It appears that since the first time I looked at this thread there have been multiple new(er) versions of GreedyHMA released. I'm trying the latest now to see if that helps.

[trbarry]

LoadPlugin("C:\unzipped\Avisynthv105\GreedyHMA\GreedyHMA.dll")
DirectShowSource("G:\VOBs\istillknow\vts_01_1.vob",fps=29.970)
return GreedyHMA(T,0,4,0,0,0,0,0)

h00z -

A couple things, don't know if either is the problem.

First, the "T" in the GreedyHMA parm list must be either a 0 or a 1 depending upon whether you want TopFirst. See the newest readme file.

Next, whether you can read a vob file like this depends upon whether you have a registered DirectShow filter for those files on your machine, like the Elecard mpgdec.ax filter. All the different filters from the different vendors handle mpeg2 files differently with Avisynth and I don't know if any of them properly passes all the info like total frame counts needed to properly pass the info on to VirtualDub or whatever. I think you can see which filter is actually being used by dragging the vob file into an open Graphedit window if you have that. I'd be interested in hearing if you get this working with some filter.

But I almost always use DVD2AVI instead of the Dshow approach.

- Tom

[Blight]

From my experience with Zoom Player, all these filters DON'T return the frame count. I think you load a VOB file, you may need that mpeg2avi dll or whatever that was called, I think there were a few sample scripts using it earlier in this thread.

In any case, back to my own agena ;)

Barry, I "believe" there's a bug. It seems that the bottom most line of the video isn't displayed correctly ...

I tested this with my own PAL encode and with 2 NTSC encodes. It's as if the line is "lagged", first few of frames it appear green, then it appears as the source, but lagged a few frames back.

[trbarry]

I tested this with my own PAL encode and with 2 NTSC encodes. It's as if the line is "lagged", first few of frames it appear green, then it appears as the source, but lagged a few frames back.

Blight -

Hmmm... Possible OBO error. Before I go stumble around trying to recreate it, what are your GreedyHMA parms? AP=? Vertical Filter?

Each of those causes a completely different path through the code.

- Tom

[h00z]

So I create my fake AVI with DVD2AVI/VFAPI (just without the "Force Film" option), then load the AVI for the source for my AVS file?

I think I am (slowly) getting the hang of this, but I have one more question. This might be stupid, but how do I know if I need top or bottom first? Be gentle... I am new to this kind of thing :)

[Blight]

GreedyHMA(0,0,1,0,0,0,0,0) was used for the PAL source.
GreedyHMA(0,0,4,0,0,0,0,0) was used for the NTSC source.

Both had the same bug...

[trbarry]

h00z -

Make sure you have the newest v 0.4.0.0 release from www.trbarry.com/GreedyHMA.zip

The Readme_GreedyHMA.txt file in that zip tells how to run 2 test filter scripts, BottomFirst.avs and TopFirst.avs with VirtualDub and find out which value you need for you source. Since the test scripts contain the name of you source file you will have to modify them to include that.

The idea is that if you bring up Virtualdub with one of these scripts and click the >> button a few times the action may appear to go backwoard every other frame. If it goes backward with BottomFirst then try TopFirst and it should be okay, and vice versa.

So if the BottomFirst script looks best, use 0 as the first GreedyHMA parm otherwise use 1, for TopFirst. That is:

GreedyHMA(0,0,4,0,0,0,0,0) # use this if BottomFirst looks better
GreedyHMA(1,0,4,0,0,0,0,0) # use this if TopFirst looks better

Once you get that part decided then you can play with the other parms to try for the best results. Read also about when to use different values for the 3rd parm, the AutoPulldown setting, which can be anywhere now from 0-5.

- Tom

[h00z]

Thanks. I did some reading and figured it out ;)

I am encoding my first anime using GreedyHMA and poopity poop's filter suggestions. It seems to be going well, but I'll have to wait a few hours to tell for sure (It is taking 6 hours/pass instead of my usual 2.5 hours/pass :)).

I'll let you know how it goes.

[trbarry]

h00z -

Yeah, DVD2AVI seems slower than just Directshow source, but at least it works. And Greedy may be slowing it down some too.

Good luck, but usually I'd try a 10-15 minute dry run first to see how the results come out before committing to 6 hrs. It's too frustrating when I have to do it over. Knock wood.

But I guess CPU is cheap these days, and patience is supposed to be a virtue. ;)

- Tom

[trbarry]

Blight -

Your bug appears in your test sample too, but I don't know why yet.

- Tom

[h00z]

I figured I should put those dual 1.2ghz Athlon MPs to the test ;)

It'll give me something to do anyway. I did up the one setting from 4 to 5, so my AVS file now looks like this:LoadPlugin("C:\unzipped\Avisynthv105\GreedyHMA\GreedyHMA.dll")
AVISource("G:\VOBs\Sakura1\sakura_d2v-vfapi.avi")
return GreedyHMA(0,0,5,0,0,0,0,0)I don't think that Greedy is slowing me down too much. I think it is mostly due to the Warpsharp and Smart Smoother filters I am using.

[djan]

Hi,

Firstly, I want to say that your IVTC plugin is very good and that it works very well for me (I only tested it on animes). So, thank you for your work.

I encoded two anime episodes wihout problem but I encountered a problem with the third anime episode. There is a vertical green line all along the episode. See the pic : C:\Documents and Settings\kyodjan\My Documents\My Pictures\GundamEp3.jpg. Sorry if it doesn't work, I don't very well how it works. If it doesn't work, I can mail you the pic.

I used GreedyHMA(1,0,4,0,0,0,0,0) but I tried all others and it's the same problem.

Thx.

-= djan =-

[Calabuig]

Hi, I'd like to use the GreedyHMA filter but I have a problem!
With this script:

LoadPlugin("C:\mpeg2dec.dll")
LoadPlugin("C:\GreedyHMA.dll")
mpeg2source("E:\Buffy\Disc 1\Divx\2\2.d2v")
GreedyHMA(0,0,1,0,0,0,0,0)

I received this error in VirtualDub:

Error fetching frame ######:Avisynth read error: Avisynth: illegal instruction at 0x04a521d0

Can you help me, please?

Thanks in advance!

[trbarry]

djan

I can't see the picture but if it is a line along the right hand border that is probably because the width is not a multiple of 16 pixels. GreedyHMA needs that for performance and historical reasons so I'm afraid you will have to crop it off. If you are cropping before Greedy maybe you want to leave a little extra and crop a 2nd time afterwards.

- Tom

[trbarry]

Calabuig -

I'm not sure about that one. Is that where all the files actually are?

And does it work if you comment out the GreedyHMA statement?

Also, I don't know any reason why Avisynth/DVD2AVI wouldn't work with spaces in a path name, but I've never tried it.

You also have to be careful that the actual mpeg2 file is still where it was when you ran DVD2AVI, since the path is stored in the .d2v file.

- Tom

[Calabuig]

Thanks for the reply, Trbarry!
The files are where they must be!
If I delete the line:

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

Vdub loads the script without problem and I can start to encode.
Any ideas?

Thanks

[trbarry]

What kind of processor are you running? GreedyHMA requires SSE support so you would need at least a P-III, Athlon, Duron, or a Celeron of at least 550 mhz.

- Tom

[Calabuig]

Sorry, that's the problem!
I have a Celeron 433 mhz overclocked to 520 mhz
Thanks anyway!

[djan]

trbarry

Very thanks for your reply, now it works very well for me. But I would like to say other thing. I tested your topFirst and bottomFirst avs and it says me that I have to use bottomFirst but when I use bottomFirst, my video is not ivtced and not deinterlaced and the quality is very poor. When I use topFirst, all is very good.

Can you explain me this? Very thanks.

[trbarry]

djan -

Let me get this correct. You ran the BottomFirst.avs test and stepped though the first few frames with Vdub and the frames seemed in order.

Then you ran the TopFirst.avs script and they seemed out of order, right?

Then you tried actually using GreedyHMA and got better results when using TopFirst GreedyHMA(1,0,...) then when using BottomFirst GreedyHMA(0,0,...). Still right?

There are only 2 things that spring to mind.

First, are you sure you are really pointing to a copy of v 0.4.0.0? This would be a symptom of the older one, that had the bug in the BottomFirst code.

If you are sure then the only thing I can think of is that you have (or need) FieldSwap. Do you have that turned on or defaulting in you capture driver, Vdub, or somewhere?

If you temporarily add a Swap Fields filter to Vdub in the video filters section and look at the output window you can usually see if swapping fields looks better. But I think this is less usual.

Or else I have yet another bug relating to this issue.

- Tom

[jarthel]

Originally posted by trbarry
What kind of processor are you running? GreedyHMA requires SSE support so you would need at least a P-III, Athlon, Duron, or a Celeron of at least 550 mhz.

- Tom

I'm confused. The only ones with SSE builtin are P3s, P4s and the newer Celerons. Also the latest Athlon XP have SSE support. The older Durons and TB don't have this. So does this mean, I can't use GreedyHMA cause I have the older Athlon Thunderbird.

Thanks for the reply Tom. :)

Jayel

[Blight]

The Athlon TBird have partial SSE support, not full like the palomino, but enough for Greedy to work.

[jarthel]

Originally posted by Blight
The Athlon TBird have partial SSE support, not full like the palomino, but enough for Greedy to work.

Thanks ^.^

[jarthel]

Originally posted by trbarry

The idea is that if you bring up Virtualdub with one of these scripts and click the >> button a few times the action may appear to go backwoard every other frame. If it goes backward with BottomFirst then try TopFirst and it should be okay, and vice versa.

So if the BottomFirst script looks best, use 0 as the first GreedyHMA parm otherwise use 1, for TopFirst. That is:

GreedyHMA(0,0,4,0,0,0,0,0) # use this if BottomFirst looks better
GreedyHMA(1,0,4,0,0,0,0,0) # use this if TopFirst looks better

Once you get that part decided then you can play with the other parms to try for the best results. Read also about when to use different values for the 3rd parm, the AutoPulldown setting, which can be anywhere now from 0-5.

- Tom


When I open the bottomfirst.avs file in nandub, It gives me an error. I've edited the .avs file addding the mpeg2dec.dll and my .d2v file.

Any suggestions? Thanks :)

[trbarry]

What error message did you get?

And to clarify CPU SSE support requirements, GreedyHMA needs only integer SSE support not the fancy floating point. Thus you need at least:

- an Intel P3, P4 or higher, or

- an Intel Celeron at least about 550 mhz (before OC'ing), or

- an AMD Athlon, Duron, or higher

[vlad59]

Wahoooo this topic begins to be really big ......

Trbarry, I just have two question :
Will you reintroduce the median filter in GreedyHMA at least for the mode 0 (where the frame rate is not changed and there is just pure deinterlace) ?
because without that for PAL deinterlacing the quality is just good but no more. Without median filter, Smartdeinterlace is better.

Why did you write in the Readme file than 1 - Auto Pulldown is better for PAL source ? With PAL you just have to deinterlace, there is no IVTC to do.

I should miss something......

Thanks in advance.
You make a really good job with GreedyHMA, carry on with that.

[jarthel]

Originally posted by trbarry
What error message did you get?


By the way, this is my .avs script
#--------------

LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\mpeg2dec.dll")
mpeg2source("D:\gundamW2\gundamW6.d2v")
separatefields
HorizontalReduceBy2

#----------

The error is "Error fetching frame 1: Avisynth read error :caught an access violation at....."

Thanks for the reply Tom :)

[Blight]

A setting of "1" for PAL is better for mixed sources.

Unlike NTSC where the source is either film, video or mixed.

PAL sources can be interlaced because of phase shifting. But setting to "1", the greedy filter should (in theory) restore progressive frames from phase shifted sources and deinterlace video sources.

[trbarry]

Trbarry, I just have two question :
Will you reintroduce the median filter in GreedyHMA at least for the mode 0 (where the frame rate is not changed and there is just pure deinterlace) ?
because without that for PAL deinterlacing the quality is just good but no more. Without median filter, Smartdeinterlace is better.

The Median Filter just complicates things because of the 2 field delay but I'll put it back once things seem to quiet down here on the IVTC issues. But if that goes on very long then, yes, I could probably enable it only for AP=0-2 if everybody wanted. I never thought very many folks used it in online DScaler but it might have more value here. To be honest, it would work better with a delay of 3 fields but that was close to noticable lip sync issues in DScaler. Here it could probably be adjusted for.


Why did you write in the Readme file than 1 - Auto Pulldown is better for PAL source ? With PAL you just have to deinterlace, there is no IVTC to do.

Even PAL may use pulldown and I've seen some US video source that also looks suspiciously like 2:2 pulldown. But maybe I'm using DScaler terminology and not the right words here. PAL may be video source with even and odd frames each reflecting a snapshot of a point in time separated by 1/50 of a second, like:

a c e g ... PAL video source GreedyHMA(x,x,0,...)
_b d f


In which case it should be deinterlaced. But if it starts off as progressive film (or some cameras?) then it is possible that each pair of even/odd fields represents the same point in time, 1/25 second apart, so you get:

a b c d e f g ... PAL film source GreedyHMA(x,x,2,...)
_a b c d e f g

and the capture card/driver might give you:

a b c d e f g ...
_ a b c d e f g

And it is possible to match up the fields even though you don't want to drop any frames.

And if you are not sure, or it's mixed, then you can make it automatic with GreedyHMA(x,x,1,...) but for PAL that is Greedy's weakest code. The auto recognition for PAL is not always correct and you may have to adjust the Good & Bad Pulldown levels. Then it's a trade off between too many weave artifacts or to many deinterlacing artifacts.

- Tom

[trbarry]

Blight -

What is phase shifting? How does it work?

Got a link?

- Tom

[Luxcious]

Tom

Just to update you on my testing. Tried Greedy4.0.0 with my capture last night. Here's the script i used.


LoadPlugin("C:\video\GreedyHMA4.0.0\GreedyHMA.dll")
SegmentedAVISource("h:\BoB10_18.avi")
Trim(9726,115772)
GreedyHMA(0, 0, 5, 0, 1, 1, 0, 0)
Crop(0,0,352,464)
BicubicResize(480,480,0,.75)

which produced a beautiful looking SVCD with Tmpgenc. Unfortunately, my estimate for file size was a little off, so I'll be encoding it again. Sure am glad that feeding through Avisynth and GreedyHMA is fast.

will keep you up to date with further testing.

Lux

[Fasola_Jan]

Hi !

Note to PAL shifting:

Imagine perfect progressive PAL (from movie source)

(b - stands for bottom, t- stands for top field)

progressive (no field shift):

b1t1-b2t2-b3t3 ...

Phase shift:

t1b2-t2b3-t3b4 ...

Some capture cards shifts fields in frame, so:

b2t1-b3t2-b4t3 ...


Warnings:
- Some sources are mixed, shifted/non shifted every scene,
sometimes even in the same scene.
- Some sources contain copied fields:
b1t1-b2t1-b2t2 ...
- Some sources contain progressive frames (shifted and non shifted)
AND pure interlaced frames
(different cameras used during shooting the movie ?)
- transitions are REAL problem

All this You can find in PAL versions of X-Files and Friends
aired in Europe.


Solution ?
None.

BUT

Use smart deinterlace filter from Donald Graft (disable motion processig)
OR
(my recomendation)
use Deinterlacer - Auto PAL Movie filter from Simon Walters
(set all options, threshholds to 100)
Auto PAL movie will generate non working avs script,
but You can fix it, modify it, play with it etc.
WITHOUT reencoding source material AND
You must do it only ONCE.
This is solution for multipass, tests etc.)


Thank You.
Fasola

[trbarry]

Fasola -

Thanks. Then it's nothing that's not already covered by Greedy's TopFirst & FieldSwap parameters as long as it doesn't change during the movie (a big if).

I don't think it would be too hard to AutoDetect FieldSwap by looking at a single frame, so maybe I can make Auto FieldSwap an option. But I'm not sure yet about TopFirst. Have to think about that one. :rolleyes:

- Tom

Notes: In case I'm using trbarry'ish non-standard terminology here again, Fieldswap for Greedy means when you swap the even and odd lines within a frame. TopFirst determines which one is dominant (displayed first).

[jarthel]

/me waits for a reply on my question regarding the bottomfirst.avs error

[b0b0b0b]

I just wanted to let everbody know that I also get the messed up bottom scan line with greedyhma 0.4. All parameters are 0 except for auto-pulldown of 1.

Thanks

[trbarry]

jarthel -

Oops, missed your post last time, but I'm not much help here anyway. Maybe it can't open that d2v file, or the file the d2v points to.

Can you use use Avisynth to open that Gundam Wing file in any other way? Have you by any chance moved the mpeg2 file since you ran DVD2AVI?

- Tom

[trbarry]

b0b0b0b -

(and Blight)

I can recreate that garbage bottom line bug and it doesn't even seem to care what the parms are. But I don't know why it's happening yet. Still looking at it. It looks like I'm processing the correct amount of lines, so I'm confused.

- Tom

[b0b0b0b]

My CrystalImage video processor does this too. I have learned to live with it :)

[trbarry]

Yeah, but in this case I'm providing the garbage. It's not there if I comment out Greedy. :(

- Tom

[jarthel]

Originally posted by trbarry
jarthel -

Oops, missed your post last time, but I'm not much help here anyway. Maybe it can't open that d2v file, or the file the d2v points to.

Can you use use Avisynth to open that Gundam Wing file in any other way? Have you by any chance moved the mpeg2 file since you ran DVD2AVI?

- Tom

I can open d2v file in tmpeg and gknot. So it's not the .d2v. Oh well I just ran first pass with topfirst ^.^

[Blight]

Barry,

The "garbage" line, isn't really garbage, it seems like a delayed line, maybe 3-4 frames back. Maybe you're not copying a buffer correctly somewhere, don't know really.

Right now my solution is to crop after the Greedy (since you usually crop 2-3 lines of overscan at the bottom anyhow), but it would be nice if greedy would fix this, as it would save a few clock cycles on every frame.

As for Phase Shifting. The thing about PAL is, it can be completely progressive to begin with, but with some broadcast/commercial breaks, bad editing, the field order may get delayed. The show "Millennium" was like that. I used to use Telecide on it to get it to match the fields properly. Didn't have Greedy back then, it's possible that the current field matching system is enough to make it restore a progressive image, Don't really cap anything like that these days, so I can't verify.

[Blight]

Barry, I have a question about the audio offset when using Greedy.

How does it work? Does it differ between setting 0-2 and 3-5 ? How many fields/frames delay is it?

A nice chart would be ... nice.

[trbarry]

Blight -

Thanks for the extra info on the garbage line. Greedy does keep a 4 field store of it's own. I'll try looking there again.

You don't need a chart for the video delay. It is always one field except when Median Filter is on. Then it's two fields. But the confusing part is, unlike DScaler, video capture drivers give you frames, not fields, so they effectively are all delayed by one field anyway over the average time of arrival of each field.

So, what am I saying? I'm not sure. ;)

I guess if look at it from the point of view of the first (dominant) field in a frame then it is displayed with a 1 field delay. But that is from the viewpoint of DScaler that processes fields one at a time. If you look at it from the point of view of a bunch of progressive frames that GreedyHMA properly matches up then there is no delay, since all Avisynth filters process fields in frames 2 at a time anyway.

I'm afraid this is complicated somewhat because I have seem to have less talent than most folks for seeing and properly adjusting lip sync problems. I can see them and they bother me but I don't seem to have the skill to easily say whether sound is ahead or behind, and by how much. Maybe I'll get better at this with practice if it is an aquired skill. But if my lack of musical talent is any indication then maybe I'll never be able to do this. ;)

All in all I don't think I'd worry about it (assume 0) without Median Filter but then I'd add a 16.6 ms delay (NTSC). But someone else with more talent is going to have to test this and Median Filter is currently disabled anyway for now.

- Tom

[djan]

trbarry

Sorry for the late answer but I don't received reply mail.

Originally posted by trbarry

djan -

Let me get this correct. You ran the BottomFirst.avs test and stepped though the first few frames with Vdub and the frames seemed in order.

Then you ran the TopFirst.avs script and they seemed out of order, right?

Yes, you're right.

Then you tried actually using GreedyHMA and got better results when using TopFirst GreedyHMA(1,0,...) then when using BottomFirst GreedyHMA(0,0,...). Still right?

Yes, you still right.

There are only 2 things that spring to mind.

First, are you sure you are really pointing to a copy of v 0.4.0.0? This would be a symptom of the older one, that had the bug in the BottomFirst code.

I used 0.4.0.0.

If you are sure then the only thing I can think of is that you have (or need) FieldSwap. Do you have that turned on or defaulting in you capture driver, Vdub, or somewhere?

If you temporarily add a Swap Fields filter to Vdub in the video filters section and look at the output window you can usually see if swapping fields looks better. But I think this is less usual.

I use Nandub 1.0 rc2 (lumafix) virtualDub and don't use FieldSwap filter. But I have to say you that my source isn't a capture video but a dvd rip.

Or else I have yet another bug relating to this issue.

Maybe.

Again, very thanks for this plugin.

[trbarry]

I use Nandub 1.0 rc2 (lumafix) virtualDub and don't use FieldSwap filter. But I have to say you that my source isn't a capture video but a dvd rip.

djan -

I wasn't really suggesting you use a FieldSwap filter in Nandub or Virtualdub for your processing. Only to temporarily turn it on and step through a few frames, comparing the input/output windows to see which one looks better. This is suggested in one of the guides, I forget which one. If it actually turned out that you needed it then it would be better (and faster) to turn it on in the GreedyHMA parm list, GreedyHMA(t,1,...). That in turn might change which TopFirst value you need.

But this brings up a very good point. My own testing has almost all been with material from analog and digital capture cards, where TopFirst is not standardized.

But what about DVD rips?

Can a few folks try the TopFirst test on DVD rips? Since they are all from mpeg2 it may well be that it is standardized there and is always the same value. If so that would be very nice to know and document.

Or does anyone already know the answer to this? I don't think I"ve seen it in any of the guides.

- Tom

[djan]

But what about DVD rips?

For all my DVD rip that I tested, I need TopFirst. When I use BottomFirst, IVTC doesn't work well. But I have to say that I only tested on animes.

[western shinma]

Many DVDs are top first, but I've seen several that use bottom first as well.

[jarthel]

Just encoded 4 anime DVDs using greedyHMA. The lines are

#------------
LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\mpeg2dec.dll")
LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\greedyHMA.dll")
mpeg2source("D:\gundamW10\gundamW48.d2v")
GreedyHMA(1,0,4,0,1,0,0,0)
crop(9,0,704,480)
BilinearResize(640,480)
#--------------

I had great success with this one and it was given to me by somebody else. I'm getting some discolored frames at the bottom. I'll try to crop the bottom on my next encodes. It's not really noticeable but cropping the bottom could make it perfect.

Also, it's very fast. I have run Wizard's IVTC using Fast recompress and it takes about 1.5 hours on my 1ghz Thunberbird. Using greedyHMA, it takes about 50mins to an hour. Very fast indeed. :)

Thanks Tom :)

Jayel

ps. Hope greedy keeps on improving. :)

[trbarry]

jarthel -

Thanks.

I haven't given up on Greedy or the bottom line bug but I have had some other things to deal with in the last couple days, and this weekend.

But I will find that bug and I do have some other things planned for it.

- Tom

[Nozomi]

Originally posted by 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

I also tried it here with the film Driven, according to DVD2AVI, it's source format = NTSC, Interlaced, 29.97fps

My .avs as follow:

LoadPlugin("D:\AVISynth105\MPEG2DEC.DLL")
LoadPlugin("D:\AVISynth105\GreedyHMA.DLL")
mpeg2source("F:\Driven\Driven.d2v")
Crop(0,62,720,356)
BilinearResize(672,288)
GreedyHMA(1,0,4,0,0,0,0,0)

I still found interlaced frames while using Driven.avs as input while view with Nandub/VirtualDub. Please advice if my Driven.avs is correct or if it still bugs in your auto-IVTC routine.

[trbarry]

Nozomi -

If you know the source is primarily interlaced (video source) then you would be better just saying so and deinterlacing the entire movie. Try:

GreedyHMA(1,0,3,0,0,0,0,0) # if you want only 24 fps output, or
GreedyHMA(1,0,0,0,0,0,0,0) # to keep all 30 fps

which will do this. You were asking for automatic detection of mixed film and video sections, which is never quite perfect. (yet?)

BTW, I notice from the '1' in the first parm that you are asking for TopFirst. You might want to follow the instructions in the readme file and check if that is correct for your movie, if you haven't already done so. That has also been a source of problems.

- Tom

[Blight]

Barry, I think there's another bug ...

It seems when IVTCing (setting "4"), at certain points during scene changes, the first 1-2 images of a new scene would lose most of it's color, making it nearly B&W.

Here are 3 images right after a scene change:

Image 1 (http://www.inmatrix.com/temp/scenechange01.jpg)
Image 2 (http://www.inmatrix.com/temp/scenechange02.jpg)
Image 3 (http://www.inmatrix.com/temp/scenechange03.jpg)

It looks as if some of the image data is being lost...

Also, Enterprise while I'm 99.9% sure is film source doesn't seem to be IVTCing properly at all! Nearly 50% of the frames are interlaced, at setting "4"...

[trbarry]

Blight -

Yes, that is rather ugly. :(

Do frames like those always occur in pairs? Happen at every scene change, or even with very fast motion?

I'm wondering if it has anything to do with the decimation code. Does it also happen if you use GreedyHMA(0,0,1,0,0,0,0,0)?

What GreedyHMA parms are you using? Could you post the whole script?

- Tom

Edit: Staring at this some more. Image #1 has a large ghost of a mans head in the center, as if Greedy is deinterlacing against an unmatched previous frame. You aren't using any temporal filtering are you?

[jarthel]

I have an .avi file here that was IVTCed using tmpg. Unfortunately there are still some interlacing in the final .avi file.

Tom, can you suggest the greedyHMA parameters I need to use if I want to deinterlace it. The .avi is top first. :)

I was thinking of these parameters

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

Thanks :)

[Blight]

I don't think it happens with every scene change, but it does happen with a lot of them, as if only the Luma value was processed or something. The greedy command was all 0 and 4 for the IVTC

No filtering was done ontop of that, just greedy and resize.

No idea about fast scenes...

I've also got reports that the image appears a lot darker than a VCD encode, haven't seen that myself really.

[trbarry]

No filtering was done ontop of that, just greedy and resize.


Okay. And I hope the resize was after Greedy, right? No IVTC or deinterlace process can really work right after a resize.

This is strange. I don't suppose you could post about 20 frames of the source again around the problem point?

BTW, should I try to fix this or go play with the new Zoom player options? ;)

- Tom

[trbarry]

Tom, can you suggest the greedyHMA parameters I need to use if I want to deinterlace it. The .avi is top first.

I was thinking of these parameters

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


It depends upon how much of the file is from video source. Past a certain point if too much is from video then it's better to just do it all as video, like:

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

But before you go that far you might try decreasing the Bad Pulldown threshhold a bit, say to:

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

This will cause it to deinterlace more hi-weave frames. But if you find you have to decrease this to less than 50 or so then I'd consider just going to all deinterlace.

- Tom

[trbarry]

When I first implemented full IVTC in GreedyHMA (AP modes 2 and 5) I still had a default Bad Pulldown threshhold hidden in it of 255. This would cause it to still deinterlace high weave frames.

But I got called to task for that since I was calling it Force Film mode and some folks said it deinterlaced too much, or shouldn't deinterlace at all in that mode. So, in the interest of honesty, and truth in advertising, I changed the default Bad Pulldown level to 999999 in v 0.4.0.0, a level that can't be reached.

Well, this was honest, but it was also stupid. :(

In any telecined film sourced material that has beed edited or has any dropped frames there may be fields (half frames) that have no match anywhere in the file. These will appear highly interlaced in the final output and the only way I know to properly handle them is to deinterlace or drop them.

I have not changed the code yet, but for those of you using Force Film mode in GreedyHMA (AutoPullDown=2 or 5) I highly recommend setting a Bad Pulldown Level of 160 or less. So, for instance, ignoring the x's, use:

GreedyHMA(x,x,2,x,x,x,x,150) # or
GreedyHMA(x,x,5,x,x,x,x,150) # instead of

GreedyHMA(x,x,5,x,x,x,x,0) #almost never as good

This should usually cause Greedy to deinterlace only one or maybe 2 frames at the point of the edit.

If no one talks me out of it I'll probably change the defaults back to reflect this in the next release. You would still be able to set that level to 999999 if you really didn't want it. But it would work much better for folks that don't want to tinker with the parameters.

- Tom

Blight: not the fix for your bug(s)

[Blight]

I don't have the source for these shows I'm afraid. Living in Israel doesn't really give me access to NTSC material.

I tried capping off my DVD, but macrovision is screwing the capture, so I can't use that as a source material for tests.

[djan]

Originally posted by trbarry


If you are cropping before Greedy maybe you want to leave a little extra and crop a 2nd time afterwards.


ok, can I do this :

crop(8,4,703,474)

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

crop(0,4,703,465)


If I do this it's because I want crop(8,8,703,465) for to have 0% aspect error. Is it correct?

[trbarry]

djan -



I may be misunderstanding Avisynth myself but if crop or resize twice then I believe the second one operates on a clip with the output dimensions of the first one.

So if you wanted to use GreedyHMA but get the best performance, no garbage on the right, and end up with 703x465 you could use:

crop(8,4,704,474)
GreedyHMA(1,0,4,0,0,0,0,0)
crop(0,4,703,465)

or

crop(8,8,704,474)
GreedyHMA(1,0,4,0,0,0,0,0)
crop(0,0,703,465)

Either of these helps in two ways. It feeds GreedyHMA a pixel width that is a multiple of 16 to avoid the garbage and it may also align the data on an 8 byte boundry (16 in this case) to make some of the MMX instructions run faster. I'm still not sure whether the 2nd one is needed in Avisynth. It would depend upon whether the Crop function always copies the data. But it can't hurt.

Now I'm not sure about which compression method you are using but some of them also require multiples of 16. And some graphics cards won't use hardware overlays or acceleration in that case. So I'd check to make sure nobody else requires that.

- Tom

[meleth]

Could this be the longest ongoing discussion ever? 200 replies now.

[ThePanda]

Can someone tell me, am I supposed to crop before or after I apply GreedyHMA? Or does it not matter?

Edit: I guess since it's supposed to be a multiple of 16 and everything, I'll just crop after

[Blight]

Tom any progress on the known bugs?

[trbarry]

None on the bottom line garbage thing. But I may understand the ghost image on some scene transitions. I managed to recreate it and I think there are unmatched fields and GreedyHMA falls into deinterlace but doesn't handle it well. Or else it should fall into deinterlace for one frame but doesn't because I changed the defaults in the last release. If either is the case then I can probably have a fix soon.

Sorry, but I actually have not been debugging as much as trying something new. I'm trying to add a efficient 5-tap vertical sharpening/softening (Un-Filter) feature that hopefully can undo some effects of prior filtering for interlace. It was just a casual question someone asked over on AV Science but it got me interested. And I need this for my upconverted HDTV Buffy captures.

- Tom

[Blight]

Ok, it seems there's yet "another" issue with Greedy. It darkens the image, losing a lot of black-detail.

Here are 4 sample images displaying this effect (before/after on each image):
Image 1 (http://www.inmatrix.com/temp/sample_00.jpg)
Image 2 (http://www.inmatrix.com/temp/sample_01.jpg)
Image 3 (http://www.inmatrix.com/temp/sample_02.jpg)
Image 4 (http://www.inmatrix.com/temp/sample_03.jpg)

On top of this, it seems there is a chroma issue, where the last image's chroma appears to be displayed for the current image. This would explain the "loss of color" during scene changes. It's more obvious on some video, I'm trying to get together a sample for you to experiment on.

[trbarry]

Blight -

I thought once that I had a fix for your ghost problem (which I think it is) but I'm pretty sure it is not just Greedy. Greedy just seems to cleverly make it worse somehow.

I had a bunch of examples where I could see similar problems in my own stuff. I could recreate it easily. But on further study, each one of those examples had the same problem in the source. Greedy just seems to make it worse. Here's what happens...

On many scene changes the source material would have a transition field (field, not frame) that was blended between the old and new scene. This is not an interlace artifact, it will actually show up as a blend, even if you throw away all the non-dominant fields and go to that frame number. Now Divx4 will put key frames on scene changes so when you skip to the next key frame in vdub edit you are apt to notice land there. But since it's a transition frame you can't see it when playing.

But you may not believe me, so here is an experiment. On the source from your 3rd clip above, run the following script:

SomeKindOfSOurce("whateverfilesample3.xxx")
SeparateFields
SelectOdd #or maybe SelectEven
HorizontalReduceBy2

Now go to frame 31809 showing in your vdub sample. Look carefully at both your sample pic above and the vdub screen. Just to the left of the girls mouth you can see some almost horizontal lines sloping downward to the right. I'll bet that on either the preceding or next frame those are part of the image. Note Greedy is not involved here yet.

Greedy will supposedly match each dominant frame to the best preceding or following match so I'm not sure exactly yet what's happening here. (very vexing) But it does appear that the blend is already in a single field of the source. That's why I've been calling them ghosts. GreedyHMA is not changing the color but it's picking up the darker luma from the preceding/next frame.

The only good thing is that if you never pause on scene changes you will probably never see them. It's just a one frame blend. The bad thing is that pause always happens on scene changes, or at least on key frames. :(

Any ideas appreciated here.

- Tom

[Blight]

I think you misunderstood something. The 4 images above are NOT scene changes. The entire video is darkened, every single frame seems to lose black-detail through the entire video.

When encoding "Alias" it was even worse, at certain scenes (not scene changes) there was a weird trailing "purple" motion artifact, as if a previous frame's color data was applied to the current frame. Once again, not on scene changes.

[trbarry]

Ok, I misunderstood. We weren't even chasing the same rabbit. I thought the above was a follow-up on the problem you posted on Nov 12. Please take my post as an answer to that one.

Are you sure these new ones are in YUV (YUY2) format? That's still all Greedy can handle, still no error checking. Otherwise I'm not even sure where to start looking.

I don't suppose you could post about 10-20 frames of one of these somewhere?

- Tom

[Blight]

Ok, this "darkness" issue isn't greedy's fault. However, there does seem to be a major bug in AVISynth, I'm going to post this on the main forum, be sure to check it out.

[Blight]

Ok, I finally found several good samples showing the problem with the color being dispayed one frame behind.

I took screen shots of two scenes, one shows a cut while the other is mid-scene. Both show the same "effect".

And as far as I can tell, these are properly structured IVTC (so the IVTC worked fine without deinterlacing).

Get the sample images here (http://www.inmatrix.com/temp/greedy_issues.rar).

[trbarry]

Hi Blight -

I see that it's incredibly ugly but don't know why. Would it be possible for you to post about 10 consecutive frames of your original untouched source for that second set (with her colored arm by the door).

And also your filter script if you could.

BTW, GreedyHMA is somewhat torn up right now. I implemented 5-tap vertical & horizontal sharpen/soften but I did it with the new DScaler 4.0 code base, so I have to retrofit to the GreedyHMA calling wrapper. Not really a big deal but it means I can't easily ship a quick fix to something even if I had one.

And as far as I can tell you are a MUCH faster coder than I am. ;)

- Tom

[Blight]

Sorry barry, I don't have the source, I'm operating from sources other encode.

The filter only does avi -> greedy (4) -> crop (after greedy) -> feed to vdub -> encode.

But I didn't see any deinterlacing artifacts in these samples, so the field matching seems to be working, it just seems as if the chroma is delayed by a frame.

And I do need this fixed quite urgently :)

[trbarry]

Blight -

There are multiple YUV formats and I suspect that you are using one of them that GreedyHMA does not handle very well. I don't yet know how in Avisynth to check (or even display) which they are but it is probably possible.

For instance as a test you could maybe put the following 2 statements before Greedy. This might put it into a different more standard format or it might not do anything other than slow things down.

ConvertToRGB
ConvertToYUY2

But I'd be interested in knowing since I can't try it myself.

I'm afraid I don't understand at all how Avisynth handles this stuff, but I'll find out.

- Tom

[Blight]

I believe the source is MJPEG encoded from a YUY2 source.

But I'd think no matter what the source was, the MJPEG would output a fixed format.

[trbarry]

Do you know which MJPEG codec it is?

[Blight]

PicVideo

[trbarry]

Blight -

I've been going through tables of YUV formats and as far as I can tell GreedyHMA will work correctly only with YUY2, which is 4:2:2 non-planar format. There is no checking for this but I'll put some in with the next release, and maybe even figure out how to handle some others. I know I saw some sample Avisynth code somewhere that did that but I can't find it now. Anyone?

But I strongly suspect that is not what you have.

- Tom

[Blight]

I'm trying to arrange MJPEG sources for you to inspect and use to fix this issue.

[trbarry]

Thanks, yes, that would certainly be helpful.

[b0b0b0b]

If it only works in 4:2:2, does that mean greedyhma is mistreating dvd content, which is 4:2:0?

Is hdtv typically 4:2:2?

Thanks

[Blight]

Oh man, I've gotten a piece of an Alias capture source, and this chroma delay is part of the source for heavens sake. Sorry for bugging you ...

Although, if you fix that bottom line bug thing, it would be nice ;)

Now I need to try finding a filter that will do 1-frame delay of luma. Wonder if there is such a thing.

[trbarry]

I even captured one Alias show in HDTV 720p for test data, though I no longer have it. But I have to say for a 1280x720p resolution I really didn't think it looked that good.

But it didn't look like yours. ;)

- Tom

[trbarry]

If it only works in 4:2:2, does that mean greedyhma is mistreating dvd content, which is 4:2:0?

Is hdtv typically 4:2:2?

b0b0b0b -

Actually I may have been needlessly spreading alarm. I did some more reading of Ben RJ's doc. As far as I can tell, Avisynth always works internally with YUY2 or RGB format. So as long as it's not RGB then GreedyHMA should be just fine.

But in case there is any doubt, just put in the following:


ConvertToYUY2
GreedyHMA(...)

Or, if you are just curious, cautious, and want an error check ...

Assert(IsYUY2, "GreedyHMA: input clip must be YUY2 format")
GreedyHMA(...)


The Avisynth doc says the ConvertToYUY2 won't do anything if it is already in that correct format, so it shouldn't be a performance hit.

- Tom

[Cmdr. Koenig]

I've got a quick question concerning using Greedy with TMPGEnc...

With Greedy set at 1,0,3,0,0,0,0,0 this will IVTC my NTSC Video source from 29.97 to 23.976, correct? How does this work with sound? Should the sound file be done seperately, for example through AviUtil, before bringing into TMPGEnc or will Greedy take of this in TMPGEnc?

And while I've got your attention, (sorry :D ), if my source video is Film why not use Force Film in DVD2AVI instead of designating in Greedy with AP=5? Is Greedy more reliable in this aspect than DVD2AVI?

If someone could provide some light on this I'd appreciate it.

I will say that I've found Greedy easy to use and a lot less cumbersome than some of the other methods.

Regards,
Cmdr. Koenig

[Schultz]

It don't matter weither you are at 23.97 or 29.97 for sound since they are based on time.. when you have 23.97 fps then you have less frames in your encode so it will be the same time length as the 29.97 and i don't belive Avisynth handles sound very good so i would suggest doing it seperatly but that is just my opinion. and not sure about the force film part since i generally deal with full NTSC or just part FILM.

[b0b0b0b]

You can use force film if your source is a >95%FILM DVD (according to dvd2avi).

Telecining is accomplished in that case by selectively repeating fields and interlacing them by setting special flags in the mpeg stream.

If you have, say, a video capture, then your video stream will not have these flags set, so there's no way to perform IVTC without analyzing the contents of each field, and that's where greedy comes in.

[Blight]

Ok barry, time to bug you again ...

During scene changes, when I presume a field is missing, what happens is, the luma of one field seems to be combined with the chroma of the other field. Usually comes out as the last frame on a scene being really desaturated since the next frame is black.

Is there a possibility of doing a real blend, where both luma and chroma are mixed evenly. Currently the image seems to retain it's luma so it stays bright while losing it's color...

This causes a sort of "flash" just before a frame change...

Any chance of this being fixed?

[trbarry]

Blight -

I tried it a bunch of ways when writing it for DScaler. Most ways that blend chroma in YUY2 seem to sometimes make strange rainbow effects and more chroma jitter, though I'm not sure why.

Right now GreedyHMA on scene changes will deinterlace one frame (or should if you have BadPulldown lvl set) in a way that will effectively deinterlace the luma but bob the chroma values.

I think what I need to do both for GreedyHMA and DScaler is recognize scene changes in otherwise film material and just bob one entire frame. This would happen whenever the best field match is too poor. But I'm not sure yet.

I do know that GreedyHMA always puts its worst foot forward since people analyze the results by pausing on a key frame. And keyframes are much more likely to be scene changes thanks to clever logic in DivX and others.

I should probably just disable pause. ;)

Seriously though I really do need some way to handle scene changes separately, besides just deinterlacing them. And it's not just a chroma problem.

And as I posted above (way above) some scene changes have already been blended with a double image in capture source (DVD also?). I'm not talking fadeins here but a single blended frame by whatever processing was used to transmit/telecine/whatever. I just flat out can't fix those types of ghost images besides maybe recognizing and dropping them.

I haven't notice the flash effect though. Do you have source for one of these? Snaps don't help as much.

- Tom

[b0b0b0b]

everybody should just watch in 60fps :)


what about this.. when you say "just bob one entire frame," you mean bobbing the last field of the scene that's ending, right? So the new scene will have both fields present for keyframing.

I guess my other question is, when you bob that one time, just before a scene change, is that enough to trick divx's scene change detector into sticking in an extra keyframe?

I guess I have a question about bobbing in general. What does it look like where instead of creating each missing scan line by copying the previous scan line, you had a 50/50 chance of copying a pixel from the previous scan line or the next scan line? Or what if you averaged the previous and next scan lines to create the missing ones?

[b0b0b0b]

another bob question:

what if you left the frame at half-height and just asked avisynth to do a bicubic/bilinear resize on it to double the height?

edit: I would guess a bilinear resize of this sort would be the same as averaging the prev/next scan lines.

[trbarry]

everybody should just watch in 60fps

b0b0b0b-

Actually true, or even 72. DScaler and Greedy/HM actually work this way and I'm considering implementing it in GreedyHMA. There are really 60 fields and therefore 60 deinterlaced/IVTC'd frames if we want to output them. And if you don't add any more I frames then DivX4 won't (I think) take up too much more space if I added this as an option. But most folks wouldn't yet be able to play them at any decent resolution without major frame droppage. :(


what about this.. when you say "just bob one entire frame," you mean bobbing the last field of the scene that's ending, right? So the new scene will have both fields present for keyframing.

On a scene change, both the first and last frame have about a 50% chance of being unmatched. Greedy should mostly bob here. By this I mostly mean doing a vertical interpolation from the data from only one field, not just line doubling.


I guess my other question is, when you bob that one time, just before a scene change, is that enough to trick divx's scene change detector into sticking in an extra keyframe?

No, but I'm not trying to trick divx, just make a nice frame with minimum artifacts. Of course, bobbing has jitter, jaggies, & shimmer.


I guess I have a question about bobbing in general. What does it look like where instead of creating each missing scan line by copying the previous scan line, you had a 50/50 chance of copying a pixel from the previous scan line or the next scan line? Or what if you averaged the previous and next scan lines to create the missing ones?

Normal processing GreedyHMA does have about a 50% chance of using a pixel (not line) from either the prev or next field. But it's not random, the pixels (deinterlace only) are chosen to give the lowest weave/comb/deinterlace factor. If the matching field actually exists then this usually selects the best one and hides the problem when it doesn't. That process is actually where the Greedy name came from. It was first just a part of an early version of Greedy/HM that wasn't finished. But I release it separately as Greedy (Low Motion) for slower DScaler machines and then stuck with the name.

You can somewhat see the result of Temporal Blending in DScaler Greedy/HM if you turn on the In-Between Frames option to reduce judder. It causes motion blur with fast motion.

I think there is also a Temporal Smoother around here somewhere.

what if you left the frame at half-height and just asked avisynth to do a bicubic/bilinear resize on it to double the height?


I think GreedyHMA can probably do it faster. But anyway you'd just get a smoothed line doubling. I thing interpolating is a bit better.

- Tom

[Blight]

Well, the "flash" effect usually happens like this:

The last frame of a scene change is brightly lit, the first frame of the new scene is total black (perhaps a fade-in), what happen is, the luma of the last frame of the first scene is used, and the chroma of the first frame of the second scene is used. What you end up with, all of a sudden the color on the last frame drops, and that quick color drops usually tags at the eye.

I think that even a standard deinterlace:blend between the two fields (like the internal deinterlace:blend in vdub) would be better here, more transitional...

[trbarry]

I think that even a standard deinterlace:blend between the two fields (like the internal deinterlace:blend in vdub) would be better here, more transitional...

It maybe would be. b0b0b0b also suggested this above. I had this code and in DScaler it sometimes caused minor rainbow effects like in cheap DVD players and also increase luma jitter on thin horizontal lines in still scenes.

But after explaining above (a couple posts) why I didn't like it I went away and thought about it a bit. There is no jitter problem in Avisynth because we are only doing 25/30 fps anyway. The same field is always dominant and the even/odd jitter problem doesn't occur.

It won't be right away but I'll see if I still have a copy of that code. Maybe I'll just make it an option. I never really understood why it increase the jitter anyway.

Also in deinterlace mode I've notice Greedy can have posterization problems on slow fades. This is probably for the same reason but it screws up heavily edited music videos with fancy colored lighting effects. This is a case where a Temporal Smoother after Greedy might help. But Greedy just hates superimposed images. It will keep trying to choose one or the other in deinterlace.

- Tom

[Blight]

Barry, I found a clip that seems to have a proper IVTC sequence (3 progressive:2 interlaced) but it fails badly with greedy ... I'm sending you a private message so you can grab a small clip (under 1mb).

[trbarry]

Blight -

I got it. Thanks. There are at least 2 issues going on here, one of which I don't understand.

1) I don't know how you are processing this but I assume the main issue is the very bad 1st scene after the scene change. This is an unmatched frame and should be deinterlaced. This would be ok except until I make another release it won't work in Force Film mode because I foolishly set the BadPulldownLVL to infinity in the last release in force film (ap=2 or 5) modes. But it would be handled if you used an explicit override (soon default) of

GreedyHMA(1,0,5,0,0,0,0,120)

2) The other issue is not specific to Greedy. Try running the following avs script on the data you sent me and step through the frames (fields) immediately after the scene change.

avisource("D:\VCR\ivtcfail.avi")
complementparity
separatefields

Each field 0 and 8 out every 10 is washed out with greatly lowered color saturation. Why is that? It will contribute to my chroma ghosting when I fall into deinterlace mode on unmatched frames. Now turn off the color on your display. You can probably no longer notice the problem. Greedy isn't even used here but the chroma wierdness appears, either in the DivX source or somewhere in the conversions.

How did this file get converted to DivX? And what format was it in before? Can you send me some of it? I'm I don't have any answers to this one yet, but I find something similar every time I go try and shoot this bug.

- Tom

[Blight]

I think DVD2AVI was used on the Bab5 disc.

It's not my encode so I don't have the source...

[Kb_cruncher]

Thanks trbarry for agreat filter.Yours worked for me when all else failed.


see this thread:

http://forum.doom9.org/showthread.php?s=&postid=201767#post201767