New IVTC for Avisynth

[Guest]

@jugm

What happens if you leave everything else the same but just comment out the Telecide and Decimate calls in your script? If the problem stops then what if you comment out just the Decimate call?

Also, please post your exact Avisynth script here. Do not omit anything. Thank you.

[jugm]

I will post more details. Now I'm holding my breath and don't touch that computer until it finishes at least 1-st pass because it takes about one day.

My script is :

LoadPlugin("c:\divx\dll\MPEG2DEC.dll")
LoadPlugin("c:\divx\dll\Decomb.dll")
MPEG2Source("c:\divx\my.d2v")
Crop(9,0,705,478)
Telecide
Decimate15
FieldDeinterlace


Error won't come up if I keep everything as above but comment out FieldDeinterlace. When FieldDeinterlace is active I had to put DeleteFrame before Crop statement. This is from my head. Can't verify this now sorry.

And if it helps... right after that "problem" frame I had to skip, whole screen is getting full of big blue (like sky) squares for a few seconds.

[Guest]

@jugm

You horizontal width must be a multiple of 4. You have 705. If it doesn't crash, consider yourself lucky! If it doesn't crash *and* it gives good output, consider yourself very very lucky. Change the width to 704 and let me know the result.

[jugm]

Ahh good to feel lucky for few minutes ! Now I'm not lucky again. Setting X size to 704 didn't help. So now it's version 1.9 only. And Avisynth 1.0 beta 3. First I got this error with 1.0 beta5. Then thought that 1.0 beta 3 could be more stable. Avisynth script is :

LoadPlugin("c:\divx\dll\MPEG2DEC.dll")
LoadPlugin("c:\divx\dll\Decomb.dll")
MPEG2Source("c:\my divx\my.d2v")
DeleteFrame(201504)
DeleteFrame(201505)
Crop(9,0,704,478)
Telecide
Decimate(5)
#FieldDeinterlace(false,12)


Error (without DeleteFrame lines) says :

Error fetching frame 161208: Avisynth read error: Avisynth: caught an access violation at 0x011f209e, attempting to read from 0


Same error if I comment out Telecide or Decimate. No error if both are commented out.

[Guest]

How did you know to delete frames 201504 and 201505 and how many total frames are there? What happens if you delete the Crop?

[Guest]

Maintenance release of Decomb. Version 1.91 makes the following fixes:

Symbolic parameters are now supported. For example, you can say Telecide(blend=false,debug=true).

The debug mode of Decimate was fixed; previously no output was generated.

Fixed erroneous blend of the top and bottom lines in frames detected as combed.

Fixed erroneous printing of the frame number in the debug output of Telecide.

Telecide now throws an error if the input width is not a multiple of 4.

Speed tips and other miscellaneous fixes added to help file.

[Guest]

@wmansir

Thank you for the suggestion about porting Antiflicker to Avisynth. That sounds like a good idea. When I finish up the optimized version of Decomb, I will tackle it. I have some ideas for improving it as well (e.g., reset moving luminance average on scene change).

@all
BTW, coding of the optimized version of Decomb is complete and there are significant gains (20%). I have a problem, however. When I turn on the release version (debug off) in VC++, the optimizer ruins things. I'm trying to find a way to avoid this. The debug version cannot be released as it is slower than the release version. Does anyone have any experience with this issue?

[jugm]

@neuron2

Original material has 228494 frames. After deinterlace there are 182793 frames. When I found that error message I opened NanDub stats reader, found where it crashed. Checked time stamp of that frame. Opened original file, found same time in there. And then just matched picture frame by frame to about same moment in interlaced original. To find exact two frames I put like 10 DeleteFrame first to stop crashes. Then removed them one by one until I figured out what exact frames I need to skip.

Deleting Crop doesn't affect anything. Same error if I do not delete those two frames.

[Guest]

@jugm

My best guess is that since it is consistently the same frames, that you have a corrupted VOB. There have been threads describing similar problems that turned out to be that. This kind of corruption does not always have reliable, predictable symptomology.

@blight

Haven't specifically coded your idea, but you can get an idea of it by serving a 3:2 movie into this script (don't apply Telecide and Decimate):

FieldDeinterlace(blend=true)

The two frames out of five that are combed will now be blends. Watch the result at normal speed and decide if you can tolerate it. Yes, there are two blends in 5 instead of one, I understand that. Tell me what you think of the result and we'll go from there.

[Leica Man]

Please help me. I am having problems.

I create the script AVS file, which I then open in VirtualDub. I can see the filter doing it's work as I go frame by frame and play the file in VirtualDub. AND IT IS EXCELLLENT! Finally a true inverse telecine filter! BRAVO MR GRAFT!

Then I save the file in VirtualDub (I tried both uncompressed and HUFFYUV compression), using no filters or alterations and then when the VirtualDub job gets to 99.99%, i.e. almost finished the whole program (VirtualDub) crashes!

Then I open VirtualDub again and the file. It then "builds" that file and I get the first 2GB of that file, which is a beautifully done 23.97fps movie without any lines or duplicate frames, again showing the masterpiece that decomb is. Of course I only get the first 2GB of it and so it is useless other than to admire Mr Graft's true genius.

Then I saw that this was a know bug in VirtualDub 1.4.7. and so I upgraded it to 1.4.8. and now if I open the file I get "aggressive" reindexing, which takes a very, very long time and then when that I is done I get an unplayable AVI file!

I am using the 1.91 version of Decomb and my AVISynth is Verion 1 Beta 5. I tried version 0.3 but I get a message saying no support for plugins.

So please help me use this amazing masterpiece by Donald Graft!

Thanks!!!!

P.S. I know the Mr Graft refuses donations. But if there was a package that combined VirtualDub, with all the filters of Donald Graft and was very bug free and very stable, I would happily pay around $200 for it.

[Guest]

@Leica Man

Thank you for your kind words.

Let's get the obvious stuff out of the way first. What OS are you using and are you not just running into the 2GB limitation on standard AVI files? Try saving it in DivX or something that will not exceed 2GB and see what happens.

You say there is a known bug in VirtualDub 1.4.7. Do you mean one that explains the crashing or one that explains the failure to recover the AVI file? If you try processing with version 1.4.8 does that crash at the end too? Or are you just trying to recover this first AVI? If 1.4.8 crashes too on a new attempt at processing, what is the crash data that it provides?

[vinetu]

@Leica Man
Before You pay $200 to Mr. Graft and Avery Lee You beter check
the prises of "discreet logic Edit 5" video editing software.
For more than 2 years of fighting with this "editing" software
I can tell You that edit 5 is a rich of bugs,VERY slow,
unstable,low quality render operations ... and support of
sort of a "...yes we work at that problem..."
Generaly edit5 and VirtualDub are different applications,
but operations like :
Slow Motion at 50%,deinterlacing(lack in edit5),brigthnes-contrast-gamma,collor
corections,resizing,reencoding(in same or different codec format),
import-export of avi files,open large files!!! ... all this simple,but frequently used (by video editors)
actions can be done by VirtualDub(+plugins) MANY times more
precisely,speedily,painless ... so generaly - YOU CAN DO THE JOB
if You use VirtualDub,but if You use Edit 5,that is not so sure ...
BTW I started with Adobe Premiere ver. 1.0 about 10 years ago ...
... so check the prises ...

[jugm]

@neuron2

Thank you for all efforts to help me and of course for your software. I will play with that some more. Strange thing is that I just made one pass WITH those "bad" frames deleted and got same error and in the same place. Have not checked details yet... may be it crashed few frames later.

Are there any way to check VOB integrity ? Err hmm wrong forum sorry.

[Guest]

@vinetu

What is the relevance of "discreet logic Edit 5" to either me, Avery, or this thread? What exactly is your point here?

[Leica Man]

@neuron2

I feel like an idiot (and happy at the same time). I tried everything again and now it works like a charm! So I don't know what was wrong before!

Sorry to have wasted your time and caused you conern.

I am using Windows XP by the way. So there is no 2GB limit, my partitions are NTFS.

Sorry about the confusion of VirtualDub 1.4.7. The bug I believe is that when it repairs an AVI file it only repairs the first 2GBs of it. This is supposidly fixed in 1.4.8.

Can I ask you one thing, please. Prior to this I had been using your Telecide filter in VirtualDub. That filter shifted the sound by one frame, as documented in your help file. To compensate for that I adjusted the sound in VirtualDub by 33ms.

Do I need to do the same in this new Decomb filter? Or it the sound not desyncronized?

Thanks for all your help!

P.S. I too don't understand what point vinetu is trying to make. Is he praising your work or slandering it???

[Guest]

@Leica Man

You're into classic cameras, I assume.

I'm glad things are working for you now. Thanks for updating us on the problem.

The Avisynth version of Telecide does not introduce any delay. That is possible because you can easily look ahead at future frames when coding Avisynth filters. In VirtualDub I have to buffer up a frame and lag one behind to get the same effect. I've gained great respect for the basic Avisynth philosophy and implementation since working on this filter. There is great stuff in the Avisynth kernel and it is a real shame that Ben Rudiak-Gould is no longer active. He is a genius extraordinaire and we all miss him.

Vinetu must be confused. :-)

[Blight]

neuron2:

using smart deinterlaced on a 3:2 film gives a smooth picture, although with some ghosting (since fields are being blended). However, this is a bit more complex here since you're only doing 1 frame. I think a 50% blend between the frames is something that should be relatively easy to insert into the decimate filter itself. Instead of cutting the frame, it would just blend it with the next non-duplicate frame.

[manono]

Hi neuron2-

I too had difficulty making sense of vinetu's statement. But I'm pretty sure he's paying you and Avery Lee a backhanded compliment by saying, that compared to the high retail prices of Adobe Premiere and Discreet Logic Edit 5, that the $200 Leica Man was prepared to pay for an integrated bug free version of VDub-DGraft Filters wasn't near enough.

[b0b0b0b]

Supposing I had a source that has telecined and regular interlaced material intermingled.

Is there a way to deinterlace the regular stuff but ivtc the telecined stuff but insert duplicate frames to get that part up to 30fps? This would be so there would be no blending or ghosting.

Thanks!

[Guest]

@manono

Aloha! Hmmm, maybe you're right. If so, that would make me the confused one. (Man, that Kona coffee is good!)

@b0b0b0b

Your question is similar to Blight's, except he wants a blended frame instead of a duplicate. Seems to me that your idea can simply be achieved by omitting the Decimate call. Telecide alone will recover progressives, making duplicate frames out of the extra fields, and its default postprocessing will deinterlace any nonprogressive content. To totally avoid blends, you'd select blend=false, then field match failures would not result in blended frames. Of course, if your fields are blended, you're up the river without a paddle.

@blight

When I complete the current optimization process for Decomb I'll code your idea. I've solved my compiler optimizer problems, BTW.

[vinetu]

manono,

Thanks for explanation !
(the software "Discreet Logic Edit 5" price is ~ $16 000)
... yes neuron2,this is not the thread for such a thoughts ...

[BBWoof]

I recently switched from decomb 1.82 to 1.91 and instead of getting a 20% speed increase, I've experienced a drastic decrease.

The 1.82 values I used were:

Telecine
FieldDeinterlace(false)
Decimate15

For 1.91:

Telicine
Decimate(5)

With 1.82 I was encoding with cce 2.50 at a speed of close to .500,
with 1.91 it's dropped to < .350.

Is there something I'm leaving out of the script.

[Blight]

b0b0b0b:
You're barking up the wrong alley. using a duplicated frame instead of a blended one produces a rather jumpy image, especially on pans. My point was to blend that duplicate frame with the next frame in order to have smoother motion. It mays also be able to interpolate the 2 frames instead, but I'm not sure how good that would be, maybe making a smaller jump but interpolation has more error artifacts and is harder to do, this is why I suggesting 50% blending instead (very fast and easy to do).

[daxab]

Has anyone actually tried this? I've been playing around with it and I find the results quite jumpy. You can't get smooth motion just by inserting one blended frame. You need to do more work than that.

What is happening is that you have 4 frames (from you 24fps source) and you want 5 in the same time interval. Adding one blended frame "X" gives you:

0-000ms @ 000ms 30fps
1-042ms @ 033ms
2-083ms @ 067ms
3-125ms @ 100ms
X-146ms @ 133ms
4-167ms @ 167ms
...

This is jumpy. You want to generate 4 new frames, A, B, C, and D, replacing 1, 2, and 3, like so:

0-000ms @ 000ms 30fps
A~033ms @ 033ms
B~067ms @ 067ms
C~100ms @ 100ms
D~133ms @ 133ms
4-167ms @ 167ms
...

This will be perfectly smooth because the time stamps match exactly. It's more compute intensive but we want quality, right :)? Assuming we have some high quality frame blending code, all we have to do is 4 partial blends:

A = 0.8 x frame 0 blended with 0.2 x frame 1
B = 0.6 x frame 1 blended with 0.4 x frame 2
C = 0.4 x frame 2 blended with 0.6 x frame 3
D = 0.2 x frame 3 blended with 0.8 x frame 4

(Ratios are computed from time stamps, so for frame A, we have 0.033333... / 0.041666... = 0.8)

[Blight]

that will cause quite a bit of ghosting ... I think one blended frame should be the best here, but there needs to be some actual code to test this.

[trbarry]

Blight -

I didn't make the option available in GreedyHMA but if you use DScaler you can try the Greedy/HM deinterlace method and turn on In-Between-Frames to see the results of trying to 50% blend every 5'th frame to reduce judder.

It was just experimental and I never got back to it because it caused too much ghosting and people didn't like it that much. But I decided that if I ever really did try to fix it then it should probably only try to do if for slowly changing scenes where the judder is noticeable but the ghosting is not. So maybe you could compare the candidate two frames that were to be merged and only do it under some arbitrary motion threshold.

But I think even that would cause annoying ghosting when, say, someone moves their arm rapidly in an otherwise still scene. I've seen that effect in DScaler and am not sure what to do with it. I pretty much dropped the idea but maybe Don or someone can make it work better.

But simple temporal interpolation is never what I expected. When scenes change, pixels don't really change through a range of values. Instead they tend to be replaced by other pixels from different locations on the screen. So without good (and expensive) motion compensation you are often blending two things that have no real relationship. But machines are getting faster and I guess someday we can get away with it.

Or we can all go buy one of those Teranex things. ;)

- Tom

[Guest]

@BBWoof

My testing does not confirm your timing result and I don't see any theoretical reason for it either. Are you sure nothing else has changed? For example, a clip that has more combed frames will spend more time being deinterlaced. I suggest you test a single file using Decomb standalone. You should measure each run several times to try to average out disk caching effects, etc. If your results still show 1.9.1 being slower please let me know.

BTW, the first cut at an MMX optimized version will be released within a few days. The new version will also add an option that makes the deinterlacing use chroma as well as luma. With some clips, especially animation, you can have areas that are different colors but have close luminance, causing the combing detection to fail. Including chroma solves the problem but takes a little longer to process. Most clips seem to do just fine with luma only, but for those tricky clips, you'll be able to turn on chroma. This option is equivalent to "compare color channels" in Smart Deinterlacer.

[BBWoof]

Thanks very much for the response. And you're right. I should have done more research. I will try to do that this evening on several different clips with both versions of the plugin.

[Blight]

trbarry:
My reception is PAL, so I don't have this issue myself. I'm trying to resolve it for others as I had people contact me about issues with hybrid 24/30fps content. Trying to force that content to 24fps make for a very jumpy video on the 30fps content. That's why I think blending the duplicate frame should look better.

[Guest]

@daxab

Your point about the temporal inaccuracies is well taken. Interesting of course, in that regard, is the fact that even a straight 3:2 pulldown of 24fps content will produce such inaccuracies, yet we do not hear complaints about 3:2 material looking bad. Is the issue then how great the inaccuracy can be before it becomes objectionable to the viewer?

[ppera2]

neuron2:

Unfortunatelly I must confirm that IVTC with Ver. 1.91 is much slower than with 1.81.

I have about 10-11 fps with 1.91 and 14-15 fps with 1.81.

All with same settings, video is Tom and Jerry cartoon, pretty interlaced NTSC from Cinese DVD, but decomb does IVTC very well, output is perfect. If you need more details - tell me.

[Guest]

@ppera2

Hmmmm. Very strange. Let me investigate.

[Guest]

@ppera2

I'm away from home and have only a small test file. But my retest just showed 1.91 to be running slightly faster than 1.81, as expected! Can you please do a few things for me? First, use the debug mode of Telecide to be absolutely sure that the versions are what you think they are. The filter will print a version number on startup. Second, please give me the scripts you are using. Finally, what are you serving it into? Thanks.

@BBWoof

Please, also verify the version numbers using debug and let me know what you find.

[ppera2]

@neuron2

Script is:

LoadPlugin("F:\WinUtils\AVISynth\MPEG2DEC.DLL")
mpeg2source("F:\Tom.d2v")
Crop(16,16,704,464)
LoadPlugin("F:\WinUtils\AVISynth\Decomb.dll")
Telecide
Decimate(5,true)
BilinearResize(640,480)

For Vers 1.81 stays Decimate15 . AVISynth is 1.0 beta 5.
I make fast recompress of it in Virtual Dub with DivX 4.12.

[Guest]

@ppera2

I wish you'd have given both scripts! You leave me wondering if you maybe run the 1.81 script without FieldDeinterlace, since the only change you mention is the Decimate call. If you omit FieldDeinterlace with 1.81, the equivalent for 1.91 would be Telecide(postprocess=false), which runs a whole lot faster. Please clarify.

[ppera2]

Well, that's right. I didn't use FieldDeinterlace in 1.81.
Didn't read whole documentation carefully. It's a bit confusing that in one version it is default in other isn't (at least in documentation itself).
Anyway, without postprocessing 1.91 is really little faster :)

[Blight]

Em, I'm not sure if anyone is aware of this, but if you're encoding AVI using VirtualDub, make sure to set it to "fast recompress" and have all the processing within the AVS file.

This makes sure the video is not converted to RGB and you gain about a 10-20% speedup.

[Guest]

I have released version 3.0 of Decomb. Version 3.0 contains coding optimizations and new information (see the help file) that lead to large speed gains. Also, a new parameter has been added to Telecide and FieldDeinterlace that optionally enables chroma comparisons in the deinterlacing step. To obtain the maximum speed gains possible with this version, be sure to read and apply the tips in the help file, especially the one about using null parentheses!

Version 3.0 requires an MMX-enabled processor.

I'll tell you about the null parentheses issue here because it is very important and very interesting. If you have a script like this where the parentheses are omitted:

Telecide
Decimate

...you can speed it up by as much as 25% simply by changing it to:

Telecide()
Decimate()

Apparently there is a quirk in Avisynth's parameter processing that causes it to waste large amounts of time in the first case. This works with previous versions as well. Believe me, I was blown away when I discovered this!

If you apply this and other tips described in the help file, you will find that Decomb is now as fast as GreedyHMA.

The new version can be obtained at http://sauron.mordor.net/dgraft/decomb.html

[SleepEXE]

:( Haven't been able to reach your site, Donald. Seems you mentioned a changeover in internet service so hopefully it will be fixed soon. Anyone happen to grab v3.0 before the site went down and willing to post it as an attachment?

Best regards,
SleepEXE

[DDogg]

I'll attempt to do the attachment.

Edit: Sorry, I could not get it to work

[b0b0b0b]

attachment came through as 0 bytes for me.

[Blight]

Anyone done a speed comparison between GreedyHMA (Setting 4, IVTC adaptive deinterlacing+field reconstruction) against Decomb 3.0 with comparable setting?

[Guest]

@Blight

Yes, I have. They are comparable. :-)

@all

Sorry, but the filter site server main disk died. Must have been an IBM. It probably won't be back online until tomorrow.

When I get home, I'll put the zip onto an alternative site and post the URL here.

[Blight]

your site is back up ;)

Several things, reading the docs for 3.0 ...

I'm not aware of any setting in HUFFYUV to force YUY2. There is a setting to force RGB and by default it suggests YUY2.

There is a setting in PicVideo to force YUY2.
Maybe someone should add one to huffyuv as well.

I've tested the following scripts:


LoadPlugin("decomb.dll")
AVISource("test-huffy.01.avi")
#
# (swapfields, blend first/last frames, deinterlace non-matching frames, threashold, blend instead of interpolate, use chroma search, use debug info)
Telecide(false , false , true , 15 , true , false , false)
#
# (Remove 1 in [n] Frames, 5 = [1 in 5] = IVTC)
Decimate(5)


and ...


LoadPlugIn("GreedyHMA.dll")
AVISource("test-huffy.01.avi")
GreedyHMA(0,0,4,0,0,100,0,40)


It's a 123 frame 720x480 clip that has about 3 missing fields on scene changes with the rest of the scene being proper 3:2 material.

Both encoded in 20 seconds, doh. Guess I'll have to look for a longer clip.

[BBWoof]

Sorry I didn't get back to you. I've been somewhat overwhelmed at work.

Version number was confirmed as 1.91 with the debugview utility.

Here's the script I used.

LoadPlugin("d:\program files\avisynth\MPEG2DEC.dll")
LoadPlugin("d:\program files\avisynth\decomb.dll")
LoadPlugin("d:\program files\avisynth\SimpleResize.dll")
video = mpeg2source("h:\blade\blade.d2v")
audio = wavsource("h:\blade\blade.wav")
audiodub(video,audio)
Telecide
Decimate(5)
Crop(4,0,716,480)
SimpleResize(480,360)
AddBorders(0,60,0,60)

And I'm frameserving to cce 2.50

As you can see, the telecide doesn't have null (). And maybe that was my problem. I'll give it a try tonight.

[Guest]

@Blight

20 seconds for 123 frames? Time for a new computer my friend! My XP Palomino 1900+ with Soyo Dragon Plus and 512K DDR RAM arrives tomorrow. Should keep me going for about 6 months.

On the YUY2 thing: If you apply some filters in VirtualDub and then encode to HUFFYUV without changing the defaults and save to AVI and then send the AVI into Telecide, it declares it as RGB and needing ConvertToYUY2. If you select the HUFFYUV right-hand pulldown menu and select that arrow thing that says "Convert to YUY2" then the resulting AVI does not require ConvertTOYUY2. This is what I mean. I assumed that the intermediate format offered to HUFFYUV by VirtualDub is RGB and if you don't select the convert option, it leaves it that way. This would not apply for Fast Recompress. Am I deranged or just confused?

Um, how do you make smilies?

[DDogg]

off topic: You are going to love the dragon plus. Pop the fsb to 142. That should be rock solid and push you to xp2000. You might have to upgrade the bios depending on when the mb was made. Excellent mb.

[Guest]

@BBWoof

>Sorry I didn't get back to you.

Don't be sorry, you just did. Thanks for the update. Yes, the parentheses thing could well account for everything. It is a really strange result but easily duplicatable. When I get a little disposable time, I'm going to dig into Avisynth and find out why this happens. Just think if it is affecting some other common scenarios and people have been needlessly wasting time!

I was scrounging for 8-10% with MMX code and then just offhand I noticed when doing some timings that "Telecide(postprocess=true)" was much faster than "Telecide". But they are supposed to be functionally identical! I thought maybe I had the sense of the postprocess option reversed but it wasn't. Then I concluded you had to have at least one option there and then I thought why not try just empty parentheses. Probably this is invoking some kind of C++ virtual function craziness. I hate C++. You never know for sure what's going on. I don't go as far as Avery; he says he feels most at home just coding in MMX! C is just fine for me.

Oops, I'm starting to ramble.

[trbarry]

I don't go as far as Avery; he says he feels most at home just coding in MMX! C is just fine for me.

Listen to Avery.

Continuing the ramble ... I used to hang out on an assembler language board. Don't remember who, but on of the guys had the sig "Assembler means never having to say you can't".

The problem is that assembler is so politically incorrect these days that no one will put up with it unless they need fast video. ;)

I'll go away now.

- Tom

[Guest]

@trbarry

Don't go, come back!

Watch out for those symbolic, optional parameters I told you about. If users start leaving off the parens, etc., they might start complaining that your filter has become very slow!

I thought I was really clever because I figured out how to do abs() in MMX code. Then I found out later instruction set extensions add intrinsic abs instructions. Dilettante alert!