New GreedyHMA deinterlace filter from DScaler

[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).