New IVTC for Avisynth

[Guest]

I have just released the first really good version of my new IVTC for Avisynth. It performs extremely well with default parameters, even on difficult anime such as "Cowboy Bebop". Please be sure to get Decomb Version 1.5 if you have already obtained an earlier version.

Here is a filter chain to use for tough anime:

LoadPlugin("decomb.dll")
AVISource("bebop1.avi") [or mpeg2source]
ConvertToYUY2()
Telecide
Decimate15
FieldDeinterlace

Note that the last step just catches any stray combed fields that might stray through due to input clip problems. It DOES NOT TOUCH clean progressive frames and can be omitted for clean source material (Cowboy bebop is not clean!). The help file in the distribution gives extensive instructions and tips. I think you will find the results to be truly stunning.

MMX/SSE optimizations are under way.

Tom Daniel (manono) assisted extensively with testing.

Get the software at http://sauron.mordor.net/dgraft/

Feedback will be gratefully received.

[Nic]

Im going to try & add this to DVD2AVI if thats ok...As with everything you create Donald....Very Impressive :)

Cheers,
-Nic

[Guest]

@Nic

What would adding it to DVD2AVI entail? Do you just invoke the DLL?

My only concern is if there would be proper credit for my work and that of Tom Daniel who was an important contributor.

Also, the optimized version is under development. Would you be able to upgrade to that easily?

[trbarry]

Originally posted by neuron2
@Nic
What would adding it to DVD2AVI entail? Do you just invoke the DLL?


Donald -

Congrats, I'll check that out.

If you are branching out into Avisynth filters you might want to consider the leverage of also adding the DVD2AVI versions and it could certainly use your talent. DVD2AVI may be going to CVS/Sourceforge. See the DVD2AVI CVS (http://rilanparty.com/vbb/showthread.php?s=&threadid=11442) thread.

- Tom

[TactX]

Thanks Donald.

I've tested Decomp and the result was better than any other IVTC-filter I've tested so far. Great !

Thanks once again :)

[Tri]

Impressive! I tested it on a short part of Gasaraki and it performes extremely well, the image quality is higher than with GreedyHMA! Decomb also doesn't produce choppy output, playback is very smooth.

Good work, I'm waiting for MMX and SSE optimizations :)

[daxab]

Good stuff -- Decomb 1.5 seems to handle some cases that trip up my current favorite, GreedyHMA. But it does seem to have trouble with mostly static scenes where the only movement is an actors lips, during dialog. GreedyHMA is really good with that.

[Guest]

I'm glad to hear that this early version is producing good results. But there is still a lot of room for improvement. So, daxab, can you please make a short clip available to me that shows the problem?

[daxab]

I trimmed things down and recompressed using HuffyYUV. You can get it here:

(=EDIT: Dead link removed=)

(Please let me know when you have the clip so I can free up the space.)

I hope this helps. Also if you want me to do any beta testing for you I'd be happy to -- I am IVTC'ing noisy source material (you'll see what I mean) every week.

[b0b0b0b]

Thanks for your work, I'm really looking forward to trying it out!

[Guest]

I've released a new version of Decomb that does better with small moving mouths, etc. Get Version 1.6 at
http://sauron.mordor.net/dgraft/

[Tri]

OK, there is a problem. After some time of encoding, Windows closes all applications reporting there is too little virtual memory. This happened a several times.

Having a look into the task manager, I see the swapfile is constantly increasing. I have made a swapfile of 700 MB now (with 512 MB RAM) but this still happens.

This is definitely related to Decomb, because it didn't occur with GreedyHMA. It would be great if you could fix that, Donald, as the quality of Decomb is very impressive.

[Nic]

Sounds like a memory leak, but I'd never accuse Donald of anything so scandalous :)

Erm..I'd add DVD2AVI to allow DVD2AVI to have some proper IVTC code. I don't use it personally (I live in UK & only rip PAL stuff) but many people have asked for IVTC in DVD2AVI. You could have any sort of recognition you wanted (Splash Screen, MessageBox, something in the about, etc)

Unfortunatley it wouldn't be easy...id have to do a lot of fiddling with the code (& I know the source is pending so I guess i'd have to wait :) (there isn't a nice easy ->GetFrame(n) in DVD2AVI that I can use, (but im trying to make DVD2AVI more AVISynth friendly)

But if you'd really rather that I didn't try to add it to DVD2AVI than I more than respect that...

Take Care,
-Nic

[Guest]

Version 1.7 with the fix for the memory leak can be obtained from my web site http://sauron.mordor.net/dgraft/

Sorry for the inconvenience. I'm normally not like this. :-)

[dvd2svcd]

Hi neuron2 aka Donald,

It seems to work very well indeed, and I have added support for it in dvd2svcd. I wanted to ask you, if it was ok with you, if I add Decomb to my software bundle. You will ofcourse be given full credits for the software and I will include the entire Decomb package.

[DDogg]

"OK, like, gag me, where's the attachment? I feel oh so newbie. :-("

Not your problem. Attachments have to be approved due to the the problems other boards had with cracks and such. Sorry for the cramp. :)

[Tri]

It works now! Great job! :)

[Guest]

DON'T USE THE ATTACHED ONE!!! It is bad, bad, bad.

Use the one from my web site. Thank you.

[daxab]

Question: What will Decomb do in NTSC IVTC mode (Telecide.Decimate15 and possibly FieldDeinterlace) if given interlaced source? In other words, if I have some source that is 90% real film, but 10% video or whatever, what will Decomb do with that 10%?

[Guest]

@dvd2svcd

That is OK. But realize the package is evolving fast. Keep an eye on it so you always have the latest and greatest. :-)

[Guest]

@daxab

It will detect those frames as interlaced and then perform a smart deinterlace on just those frames. Please let me know if this is not working as advertised or if you want something different.

[daxab]

It will detect those frames as interlaced and then perform a smart deinterlace on just those frames.Cool. Will the Decimate15 then pick 'the two most similar' frames in a group of 5, and delete one of them? I know it won't be perfect -- you can't go from 60 fields/s to 24 frames/s without some consequence -- I'm just curious.

[daxab]

Wow, I just checked out version 1.7 and it catches all of the stray interlaced frames that were sneaking through with version 1.5.

My source material is noisy NTSC TV capture, not the easiest stuff to handle, and Decomb does a great job -- perhaps better than GreedyHMA now. When I combine this with a low-threshold deinterlace -- FieldDeinterlace(false, 3) -- I get very nice results.

[Guest]

@daxab

I don't recommend the low threshold on FieldDeinterlace after
Telecide. You'll touch clean frames doing that. The default of
20 should be OK. You might lower or raise that a bit, but 3 is going to touch most of your good frames. Use the debug option on FieldDeinterlace together with the DebugView utility to see the effect of setting such a low threhsold. It'll tell you that most of the frames are combed when they are not.

In fact, manono found that with Cowboy Bebop he had to raise it to 30.

Yes to your question about Decimate.

Tonight or tomorrow I'll release a version that integrates Telecide and FieldDeinterace, improving peformance and making things a little cleaner for the user.

[Guest]

I've released a new version of Decomb, version 2.0, that integrates the deinterlace postprocessing into Telecide. Forget about FieldDeinterlace; it is gone. Please refer to the help file for the new usage syntax and instructions. Get the filter at:
http://sauron.mordor.net/dgraft/

Note that the threshold is no longer problematic. It is treated exactly the same as the threshold in Smart Deinterlacer.

Your script for dirty source will now look like this:

Telecide(false,true)
Decimate15

[Guest]

Sorry, people, Version 2.0 was bad. It had a blurry look. Get Version 2.1. That is a good release. The default threshold is a bit high, though. If you see interlacing come through, reduce the threshold to 15. I'll make that the default in the next release. I'll let this one sit for a while and get feedback.

[dvd2svcd]

Hi neuron2,

In the past you have made some extremely good VirtualDUB plugins, and I have used some of them quite a lot in the past. It now seems you're moving on to making Avinsynth Plugins. I for one would like to thank you for this. I have never had any problems with your VirtualDUB plugins, and I know that the Avisynth Plugins will be great (as your Decomb already has turned out to be).

I just had a quick look on your homepage, I was searching for a way to donate some money to you, as I find your software developments really deserves it (and since I have used it so much too). Is this possible?

[Guest]

@dvd2svcd

Hi. Please use version 2.1 and threshold 15 for your DVD2SVCD package.

Regarding donations: I appreciate the thought but I do this stuff for my own pleasure and seeking after truth. :-) I am not in need of any funds to continue the efforts.

You can help by sending your feedback and ideas. Thank you.

[jarthel]

Is Convert2YUV line needed if I use a .d2v file? (.d2v file is already YUV)

[Guest]

@jarthel

You can omit the ConvertToYUY2 call in that situation, yes.

[Guest]

I've made my last release for this weekend. :-)

Version 2.2 enables postprocessing by default, changes the default threshold to 15, and adds an option for cubic interpolating the first and last fields if needed. Note that the Telecide parameters have changed, so edit your script files appropriately.

[yangus]

ok this is a really stupid question but how do i use your plugin? i never used avisynth before and so i'm kinda stuck. please give a newbe a helping hand :) and btw is this way better than tmpenc?

[Mentar]

Yangus: Learn to use Gordian Knot and read the HTML helpfile included in the decomb package, it's fairly easy then. And yes, it's way better than having it done by TMPGenc.

Donald, AMAZING filter. Just plain amazing. My kudos, I'm thoroughly impressed. Please keep it up and good luck with the speed optimizations ;)

[Guest]

@yangus

It's really very simple. Download the version of Avisynth linked from my Decomb page at my web site. Put the avisynth DLL in windows\system (or equivalent). Then right click on the .reg file that came with Avisynth and select Install (or Merge). Now Avisynth is installed and
ready to go. Now make a file called test.avs as follows:

LoadPlugin("your_path\Decomb.dll")
AVISource("your_path\video.avi")
ConvertToYUY2()
Telecide
Decimate15

Now simply open that file with VirtualDub. Voila, you have the filtered output of video.avi.

[Blight]

And the last step should be moving decimate into telecide ;)

Save the re-loading of the frame buffer by doing the decimate checksum within telecide and save a few more CPU cycles.

[Taranli Maren]

Excuse my ignorance if this is a dumb question...

If you use this on a pure ntsc source, does it deinterlace each frame seperately, or will it actually reconstruct the film with duplicate frames. My confusion is whether or not it would be a good idea to use the decimate15 to drop it to 24 fps. if it deinterlaces each frame seperately, then each frame would end up different, with no duplicate frames. It seems that it might look smoother (and not give too much of a compression loss) to leave it at 30 fps instead of dropping a random frame every 5. But if there are actually duplicate frames, it seems that it would be better to just get rid of them. Also, if there are duplicates, does the decimate drop the duplicate, or does it just drop an arbitrary frame.

I do recall that the web site said not to use this for pure ntsc video, but I want to see if its possible to use it for this anyway, since its supposed to work so well.

Taran'li Maren

[yangus]

hey yall, thanks for answering the question. btw Mentar, u said learn 2 use gnot and i already do! so are u implying that i can use this in gnot? i thought it got its own seperate ivtc deal. and also neuron2, correct me if i'm wrong, but after installing avisynth, do i make a text file with the script u perscribed ("load dll, etc)? i read this on nicky's guide and i thought this might be what u're refering 2. and one last thing, what do u mean move decimate into telecide? okey-dokey, that's about all. later!

[Mentar]

Hi yangus, please don't take my comment as degrading, it honestly wasn't intended this way :) ... if you're using GK already, here is how to use decomb in GK:

After you hit "Save and Encode" you get the option to apply different filters like resize, noise filter etc. On the bottom of this window there's a "Edit" button. When the rest of your choices are made, hit "Edit", and it will open up a small editor with the avisynth script to edit.

First thing to do here is to comment out any ivtc commands you might have accidentally selected. Then, insert these lines (assuming that you use decomb2.2)

LoadPlugin("your_path\Decomb.dll")
Telecide
Decimate15

To verify that everything is fine, hit "Preview". If it shows clean frames, you're done. Just click on Save&Encode and everything is fine.

Good luck!

PS: Yes, in my humble opinion you should prefer decomb to the standard ivtc. It's slower, but the results tend to be significantly superior.

[dragonlz]

Has anybody tried decomb with anime? It's usually the hardest type of source to IVTC. From what I read about decomb so far, it sounds like it'll handle anime better than anything else.

[Mentar]

Yes, I did. Ran it over BGC2033 first episode and Video Girl Ai for 2 tough nuts to crack. Based on these experiences, it seems that decomb retains at least the sharpness of Greedy HMA without the occasional interlace errors which occur in it. Decomb is slow yet, but it definitely produced the best output of all three.

Everything IMHO of course.

[manono]

Hi boys and girls-

yangus- Do what Mentar said. I threw Decomb.dll in with the other .dlls in the GKnot file. Then you can just cut and paste the correct path for the LoadPlugin("......)Decomb.dll") from the GreedyHMA.dll or Wizard's IVTC or MPEG.dll. Skip that AVI Source and Convert To YUV stuff-that doesn't apply to us DVD conversion-GKnot users. AviSynth was installed when you installed the GKnot Rippack. Then put:

Telecide
Decimate15 (if Region 1 or some other NTSC area)

down in the IVTC area.

Decimate into Telecide-It's not implemented yet (as Blight said, it'll speed things up), but should be before too long (I believe).

dragonlz-I've tried it a lot. It's the best so far (not perfect)-unless the source is simple to IVTC, you'll almost certainly have to keep the deinterlacer(default in Telecide), but its beauty is that it won't screw up good frames while deinterlacing the few interlaced frames that slipped through Telecide.

Mentar-yes it's still a bit slow. It's way slower than GreedyHMA, and about as fast as the default IVTC in GKnot (since you'll need to add a deinterlacer because so many interlaced frames slip through). But if you've looked closely, you've noticed that panning and scrolling scenes are way smoother than the default IVTC, as well as allowing fewer interlaced frames through. And neuron2 hasn't begun work on the speed optimizations yet.

[triffid]

wooohoo! ive been looking forward to this!

i havent tried it yet but this looks like it may finally be the way to knock out IVTC and stray interlaced scenes at once. Like i'm sure many anime encoders are, I am tired of having to both IVTC in TMPG (averaging about 1:30 for every 1hr of video) and then run a deinterlace filter that halves the encode speed.

I haven't used Avisynth yet, as currently i use the standard Nandub method according to the official guide with a few anime-related changes. However, I'm always looking for a better and/or faster way to do things.

Mr. Graft, your v-dub filters are essential to my encode method...please make your avisynth filters essential too. :D

-triffid of DALnet, who is happy today

[ppera2]

I downloaded latest version (2.2) and recommended AVISynth 1.05b.
But I can't use plugin. It always causes access violation.

Here is AVISynth script:

LoadPlugin("F:\WinUtils\AVISynth\MPEG2DEC.DLL")
LoadPlugin("F:\WinUtils\AVISynth\Decomb.dll")
mpeg2source("F:\Tar.d2v")
Crop(24,62,672,360)
Telecide
Decimate15

Machine is OK, everything other work fine...

[dragonlz]

thanks for the info manono & Mentar. I'm encoding some anime right now using decomb to ivtc. From what I can tell by watching the .avs, it produces sharp-looking results and no interlaced artifacts have been left.

This is a really promising program, good work Donald!!

[LotharZ]

Originally posted by ppera2
I downloaded latest version (2.2) and recommended AVISynth 1.05b.
But I can't use plugin. It always causes access violation.

Here is AVISynth script:

LoadPlugin("F:\WinUtils\AVISynth\MPEG2DEC.DLL")
LoadPlugin("F:\WinUtils\AVISynth\Decomb.dll")
mpeg2source("F:\Tar.d2v")
Crop(24,62,672,360)
Telecide
Decimate15

Machine is OK, everything other work fine...
This is the correct format:
--------------
LoadPlugin("F:\WinUtils\AVISynth\MPEG2DEC.DLL")
LoadPlugin("F:\WinUtils\AVISynth\Decomb.dll")
mpeg2source("F:\Tar.d2v")
Telecide
Decimate15
Crop(24,62,672,360)
------------------

Crop after of Telecide and Decimate.

[ooze_21]

So, I live in PAL country. Is there any way of using this plugin to make 25 fps PAL (film) go back to it's original 24 fps? Look at this topic if you don't know what I mean --> http://forum.doom9.org/showthread.php?threadid=14391

Thanks
HJ

[manono]

Hi ppera2-
I don't know where Land Of Confusion is (I'm weak on Geography-near to Germany?), but for the European readers, of course you don't need the Decimate15 line, as it looks for and drops the 1 frame in 5 looking most like a duplicate. But this thing will rebuild the original frames (the way GreedyHMA can) and therefore is way better than a straight deinterlacer.

Also-do you have a Resize line in there somewhere after Crop?

As for going back from 25fps to 24fps-I don't know-maybe neuron2 can answer that one, or modify it to handle what you want, but have you tried Decimate125? I don't know if that'll work, though.

Edit: I just tried that-Access violation. So, as of now, you can't go from 25fps to 24fps. I'm not sure you want to anyway, as you'll be dropping an original frame out of every 25, and it may become a bit jerky (I think).

[Guest]

First, the entire 2.x line of revisions was simply a bad idea and I withdraw them! Please get version 1.75 from my web site. The quality on the 2.x line was simply not up to snuff. I have to confess that I implemented a new and improved algorithm for 2.x that was in fact new and degraded.

An important note on color spaces: YUV and YUY2 are not the same! The YUV you get from DVDs and the default mode of HUFYUV has the following byte ordering:

U Y1 V Y2

whereas YUY2 has:

Y1 U Y2 V

This is really unfortunate for the current code. If you feed your YUV into Decomb, it will start working on color when it should be working on luma and vide versa. Therefore, 1.75 enforces YUY2, and this will continue until I recode for native YUV and YUY2.

Finally, I plan to integrate the functions (as I had started in the 2.x line), but using the better 1.7 algorithm.

Sorry for leading people astray with 2.x, but if you think *you* went astray, think about me! For days I've been unaware of the color space issue and you can imagine what that did to my debugging.

[ooze_21]

Well, The reason I want to go from 25-24 is that I'm not happy with the quality of current deinterlacers. Ghosting and artifacts. The picture gets jerky when I use them. Don't know if converting the frame rate to it's original would help much but...

HJ

[Guest]

@ooze_21

Yes, I know about the requirement as I do support it in the VirtualDub Decimate filter. There are two ways to show 25 fps from 24 fps: you can just speed it up or you can add two extra fields per 24 frames. The latter requires a 1-in-25 frame decimation.

The problem in doing this for the Avisynth version is that I would have to look ahead 25 frames, which is rather a lot. (The VirtualDub filter does two passes and so only needs too look ahead one frame, storing all the comparison results and then deciding every 25th frame what to output to the script.) I am thinking about possibilites here. But for now it is not supported.

Changing the frame rate to 24 would not remove the stutter.

[Guest]

Originally posted by Taranli Maren
Excuse my ignorance if this is a dumb question...

If you use this on a pure ntsc source, does it deinterlace each frame seperately, or will it actually reconstruct the film with duplicate frames. My confusion is whether or not it would be a good idea to use the decimate15 to drop it to 24 fps. if it deinterlaces each frame seperately, then each frame would end up different, with no duplicate frames. It seems that it might look smoother (and not give too much of a compression loss) to leave it at 30 fps instead of dropping a random frame every 5. But if there are actually duplicate frames, it seems that it would be better to just get rid of them. Also, if there are duplicates, does the decimate drop the duplicate, or does it just drop an arbitrary frame.

I do recall that the web site said not to use this for pure ntsc video, but I want to see if its possible to use it for this anyway, since its supposed to work so well.

Taran'li Maren

"Pure NTSC source" is ambiguous as it doesn't tell me whether the source is telecined progressive, simple interlaced, or a hybrid thereof. I assume you mean simple interlaced video. If so, then there are no progressive frames to recover. Using Decomb rather than Smart Deinterlacer buys you nothing. Only when there are progressive frames in the stream should you use Decomb. If I haven't understood you properly, please clarify your question.

[ppera2]

Originally posted by manono
Hi ppera2-
I don't know where Land Of Confusion is (I'm weak on Geography-near to Germany?), but for the European readers, of course you don't need the Decimate15 line, as it looks for and drops the 1 frame in 5 looking most like a duplicate. But this thing will rebuild the original frames (the way GreedyHMA can) and therefore is way better than a straight deinterlacer.


Is it so strange that someone in Europe performs IVTC on R1 DVD's ?

[manono]

Hi-sorry-I didn't know they were readily available. I'm just a provincial American.

[yangus]

ok people, i tried decomb out using the gnot way Mentar provided. however when i tried to preview it, all it did was give me an error message. first time, it played a short avi file that said "... command not valid" or something like that. then the second time it just gave me an error. this is basically what it said when i clicked edit: (sorry for the long post)
#
# Created with Gordian Knot
#
# http://thewef.nav.to
#
# PLUGINS
# get them from http://users.win.be/dividee
LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\mpeg2dec.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\InverseTelecine.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\Avisynth_Spatial.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\GreedyHMA.dll")
#LoadPlugin("C:\WINDOWS\System32\vobsub.dll")
#
# SOURCE
mpeg2source("C:\Documents and Settings\Angus\Desktop\Dvd Rip\Emperor and Assasin\emperor.d2v")
#
# TRIM
#trim(startframe,endframe)
#
# IVTC
#InverseTelecine(40,10,15)
# or use
#GreedyHMA(1,0,4,0,0,0,0,0)
#
# CROPPING
crop(0,8,720,461)
#
# DEINTERLACING
#SmartDeinterlace(2,15,true,true,true)
# or use
#VerticalReduceBy2
# or maybe
#GreedyHMA(1,0,0,0,0,0,0,0)
#
# SUBTITLES
#VobSub("FileName")
#
# RESIZING
BicubicResize(544,288,0,0.75)
#
# DENOISING: choose one combination (or none)
# 1) little noise (fast)
#TemporalSmoother(2,1)
#
# 2) medium noise (slow)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#TemporalSmoother(2)
#
# 3) heavy noise (very slow, you have been warned)
#SpatialSoftenMMX(2,4,6,false,false,4,4,6,8)
#TemporalSmoother(3)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#
# BORDERS
#AddBorders(left,top,right,bottom)
#
# COMPRESSIBILITY CHECK
# !Snip Size has to be 13 for use in GKnot!
#SelectRangeEvery(260,13)
#
# FOOL CCEnc
#ResampleAudio(44100)

so my question is do i delete the line about loading the greedhma plugin and replace that with decomb? and under ivtc do i delete that line altogether? and where do i insert telecide and decimate? i'm sorry, but i'm kinda slow at this. and just to double check, i tried the vdub way by loading the test.avs file. it also gave me an error message! what to do, what to do... oh one last thing, is it possible to perform decomb as a seperate job instead of part of the encoding. the reason i ask this is b/c i usually do audio and ivtc (using tmpenc) on one day and encoding while i'm gone at school. this is a lot better than doing this all at once since i usually need to use my computer after school and encoding on a duron650 takes hours. u get my drift? it would be good if i can do ivtc seperatly and allowed to resume (tmpenc once again) anyway sorry for the long post but i really needed to get this answered!!:confused:

[hakko504]

It should look like this:

#
# Created with Gordian Knot
#
# http://thewef.nav.to
#
# PLUGINS
# get them from http://users.win.be/dividee
LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\mpeg2dec.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\InverseTelecine.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\Avisynth_Spatial.dll")
#LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\GreedyHMA.dll")
#LoadPlugin("C:\WINDOWS\System32\vobsub.dll")
#Put the Decomb filter in the same directory as the other plugins
LoadPlugin("C:\DOCUME~1\Angus\Desktop\DVDRIP~1\GNOTON~1\GORDIA~1\Decomb.dll")
#
# SOURCE
mpeg2source("C:\Documents and Settings\Angus\Desktop\Dvd Rip\Emperor and Assasin\emperor.d2v")
#
# TRIM
#trim(startframe,endframe)
#
# IVTC
#InverseTelecine(40,10,15)
# or use
#GreedyHMA(1,0,4,0,0,0,0,0)
# or in this case
Telecide
Decimate15
#
# CROPPING
crop(0,8,720,461)
#
# DEINTERLACING
#SmartDeinterlace(2,15,true,true,true)
# or use
#VerticalReduceBy2
# or maybe
#GreedyHMA(1,0,0,0,0,0,0,0)
#
# SUBTITLES
#VobSub("FileName")
#
# RESIZING
BicubicResize(544,288,0,0.75)
#
# DENOISING: choose one combination (or none)
# 1) little noise (fast)
#TemporalSmoother(2,1)
#
# 2) medium noise (slow)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#TemporalSmoother(2)
#
# 3) heavy noise (very slow, you have been warned)
#SpatialSoftenMMX(2,4,6,false,false,4,4,6,8)
#TemporalSmoother(3)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#
# BORDERS
#AddBorders(left,top,right,bottom)
#
# COMPRESSIBILITY CHECK
# !Snip Size has to be 13 for use in GKnot!
#SelectRangeEvery(260,13)
#
# FOOL CCEnc
#ResampleAudio(44100)

[manono]

If for some reason you can't do it in Edit while still in GKnot, then you can open the .avs later with notepad or something, and insert the lines hakko504 provided you (I guess you saw the note from neuron2 above that says to go back to an earlier version, so you'll need the FieldDeinterlace command if you want to deinterlace (after putting the v 1.75 .dll in GKnot)).

Funny-I just encoded The Emperor And The Assassin a week ago. A wonderful movie (Gong Li should have had more on screen time, though).
I'm in love with Gong Li.

As for doing it separately, you have to do it while encoding (not like TMPGEnc). I might suggest doing the first pass one one day, and the second pass on the next day, or overnight. That's such a long movie that it'll take longer than usual.

[ppera2]

Hi manono,
actually we have here lot of Chinese DVD. It's NTSC, and force film works in rare cases.

I moved crop line after decomb ones, and now it works...

However I don't like it. It should be faster when work with smaller size. IVTC plugin work fine when crop is before.

[Guest]

Version 1.8 has been released. It greatly improves deinterlacing of frames detected as combed, and offers an option for forcing interpolation of the first and last frames.

NOTE: PLEASE DISCARD VERSION 2.x. IT HAS BAD QUALITY!!!
Version 1.8 is the cat's meeow for output quality and faithfulness to the original progressive frames.

@ppera2

What is the size of your cropped frame?

[ppera2]

neuron2:

Size after crop is 672x360. I tried also with 352 vertical (div. by 32), but got same access violation error.

[Krajensky]

Donald,

Wonderful job...I have tried every IVTC out there today (on TV episodes...Star Trek: Voyager to be precise), and yours is the first to do the job without an explicit deinterlace...they change the IVTC pattern on every single scene change and it gets to be rather annoying when there's one that sneaks through as interlaced. I have yet to notice stray frames getting through (I was using 2.2, just now upgraded to 1.8 ), which easily compensates for the speed. The only question I have is this: With other filters, you could seek over a given area of video, to make it cache it, then you could play that segment back very quickly...your filter seems to not cache its decoded frames...is this on purpose?

Krajensky

[TactX]

I got an access violation too when cropping before telecide.

I thought this was caused by cropping odd values.

btw: Windows 2000, Avisynth 1.05...

[b0b0b0b]

I have 2 questions for neuron2:

1) decomb is faster than smartdeinterlace because it works in the YUV colorspace, right? Thus, when encoding a dvd through avisynth there's no need to go to RGB and back at any stage.

2) when deinterlacing, suppose that at a scene change, the frame is composed of fields from disparate scenes. For example, the top field is from scene a but the bottom field is from scene b. Does smartdeinterlace simply merge the two? Doesn't this force the divx codec, which is downstream, to mark this as a keyframe? Isn't this a bad thing because either a) this is the keyframe for scene b, meaning that the next delta frame will need to make up for the munged information from scene a, or b) this frame is a keyframe, but so is the subsequent frame which is composed entirely of fields from scene b.

Thanks very much!

[Guest]

@ppera2

I am investigating this issue. Please standby...

@Krajensky

The frame cache is maintained by Avisynth. It is a limited size. If you scan around within a reasonable range of your current frame, then you'll get cached frames. You can see the cache behavior by enabling debug in Telecide and using the DebugView utility (from my web site). Start the video and then stop. Backup one frame and you won't see Telecide recalculate. Keeping backing up and you'll run out of cache and Telecide will recalculate. The filters don't do any caching; it is all the Avisynth kernel.

@b0b0b0b

I'm still investigating color issues. But yes, Decomb operates in YUY2 space. The VirtualDub Smart Deinterlacer runs in RGB32 because all VirtualDub filters must be RGB32. So Decomb will be faster (even though it is doing a little more work to decide whether frames are combed before deinterlacing them). It appears that in the VOB files, the coding is UYVY and that mpeg2source() converts to YUY2. That means you don't need a ConvertToYUY2 when doing rips (though it will be ignored and has no effect on speed). The only time you need ConvertToYUY2 is when the source is in RGB32 or RGB24 format. When encoding a DVD from a VOB, there is no RGB conversion. But NEVER use DVD2AVI to save the VOB content as an RGB AVI file, because then you will have the conversion to YUY2 to do. Clear?

When there is a field that can't be matched, then the frame is smart deinterlaced (either by blend or interpolate). I do not know anything about the keyframes issue. But I don't think that the YUY2 coming out of Decomb has keyframes. Won't DivX decide what to make keyframes? Pease investigate and tell me. Thank you. :-)

[Krajensky]

@neuron2:
I tried debugview on 1.8: I get about 37 frames cached, when going forward then seeking back until I see a new request for a set of frames. Using the InverseTelecine v2.101 plugin, I get 62-ish frames cached...any ideas?

Here's my script for decomb
LoadPlugin("c:\avisynth\decomb18.dll")
SegmentedAviSource("voy_3.avi")
Telecide(false, false, true)
Decimate15

and for inversetelecine
LoadPlugin("c:\avisynth\inversetelecine2101.dll")
SegmentedAviSource("voy_3.avi")
InverseTelecine(40,10,15)

If Avisynth is keeping all the necessary frames in the cache, why is it so much smaller? Is this due to the fact that your plugin uses two commands, and the other only uses one? Wouldn't it still cache either the input or output frames, which are of the same number?

Krajensky

[Guest]

I've released version 1.81 at my web site:
http://sauron.mordor.net/dgraft/

This version fixes ppera2's Crop bug and is about 10% faster.

When a source frame is cropped, the Crop filter simply reduces the row size but leaves the row pitch as is! That means when Telecide gets a source frame from Crop it has the pitch of the original uncropped frame. But frames allocated within Telecide get a pitch equal to the cropped size. So my loops had to use separate pitches and the previous code just assumed that they would both have the same pitch. Something for you Avisynth coders to watch out for.

Some simple changes gained me 10% in performance. I haven't really tried to optimize seriously yet, because I think it's a mistake to paint oneself into a corner too early.

I'm really happy with this version.

[Guest]

@Krajensky

I believe the frame cache difference is explained by the fact that Telecide opens three input frames from its source whereas IVTC and Greedy open only 2. The ratio of 37/62 is not too far from 40/60, which would be 2/3. The reason Telecide opens three frames is because he wants to match against the previous, current, and next frames. This allows the field matching to live through many strange things at cuts and scene changes, as well as eliminating the need for specifying top first/bottom first. This is one of my little secrets.

I haven't looked at the Avisynth code to verify this theory, but it seems reasonable.

Greedy came from the real-time DScaler world, where the extra field matching would be serious for sustaining the frame rate. My perspective is to seek the highest quality encodes, so the extra time is acceptable. As it is I am currently at about 80% of the speed of Greedy and I haven't applied a few obvious code rearrangements and MMX/SSE optimization yet, so things look promising on the speed front.

[samfchen]

Hello,

I read the past posts pertaining to getting the Decomb filter to work with Gknot, but I am still a little confused. Source is of Asian origin (Anime'ish), NTSC, Interlaced, 29.xxxfps. ForcedFilm under Dvd2Avi does not produce good results.

Thus to use Decomb for DVD2AVI (to feed into Gknot), do I simply leave the video field operation to be none and create the .d2v, then feed into Gknot. And in Gknot, do I select 23.976 (though it is shown as 29.xxx)? Do I need to (can I) use any resize filters or does the Decomb package take care of that with Telecide and Decimate15?

Sorry for the questions, but help is greatly appreciated.

Thank you,
Sam:)

[DJ Bobo]

1) When you have NTSC Interlaced 29,97fps showed in DVD2AVI, you CAN'T use Forced Film, so leave it unchecked!

2) You should select 23,976fps in GKnot (but it's not that important)

3) Decomb doesn't resize, so you must use resize filters.
NB: you should crop and/or resize after Decomb

[samfchen]

Thanx for the help, bobotns.
Greatly appreciate it.

you mentioned at the end Crop and Resize AFTER Decomb (when used with Gknot + Decomb), why? Why can't I simply resize it with the Gknot interface and simply apply Decomb via editing the Gknot file? And if I don't resize via Gknot, doesn't that mess up the filesize approximation built into Gknot? Assuming I didn't resize via Gknot, what program do I resize the Decomb'ed Divx avi with?

Thanx in advance,
Sam:)

[Blight]

I would like to make a feature suggestion.

Some sources have hybrid 24/30fps sources. At times even progressive 30fps (CGI Video like in Babylon 5).

Now, the problem is thus, if you decimate 1:5, you may lose actual progressive frames from the 30fps portion and the video will become jerky. If you don't decimate, the fields on the 24fps portion will match and then you'll have a duplicate frame and now your 30fps video will be jumpy since you'll have duplicate frames on the 24fps portion.

The solution ... add a switch that once a duplicate frame is detected in a 5 frame segment, instead of keeping 2 duplicated frames, you dump one of the duplicated frames and cubic interpolate between two frames so that motion will maintain fluidity.

[DJ Bobo]

@ samfchen
You better use Decomb before resizing for optimal quality.
You can edit your AVS file so that the crop and/or resize commands come after Decomb. For example:

LoadPlugin("path\mpeg2dec.dll")
LoadPlugin("path\decomb.dll")
mpeg2source("path\project.d2v")
Telecide
Decimate15
crop(8,0,704,480)
BilinearResize(640,480)

[Guest]

@samfchen

You can crop before Decomb but you can't resize. Decomb needs the original line spacing to detect the combing artifacts.

@Blight
If you mean make a temporally interpolated frame, that opens a giant can of worms. It is a really expensive computation. And from what I have seen of such interpolators, they are not good enough, especially with 1 in 5 frames being done; it would be very noticable. It's a great idea in theory, but the practice is sobering.

[western shinma]

Having some problems with 1.81. It always gets an access violation after 8000 frames or so, encoding in VirtualDub. Here's the avs:
LoadPlugin("MPEG2DEC.dll")
LoadPlugin("Decomb.dll")
MPEG2Source("temp.d2v")
Crop(0,57,720,366)
Telecide
FieldDeinterlace(false)
Decimate15
BicubicResize(640,272,0,0.5)
2.x worked fine in this case, although the new version is noticeably faster.

[ppera2]

I tried Ver. 1.81 . IVTC with cropping before. It worked fine with sample of ~11000 frames.
I will try whole movie 2 pass during night...

[daxab]

Did a 5-pass with 1.81, no problems.

[western shinma]

Yes, it works fine if I don't crop first. It is a bit slower this way however.

[Guest]

@western shinma

I duplicated your problem and fixed it, I believe. Also, I added a decimate 1-in-25 function.

Please get Version 1.82 from http://sauron.mordor.net/dgraft/

Thank you for your feedback and sorry for the trouble it has caused you. We are converging on a clean, stable release, methinks.

[western shinma]

No trouble really :D, just testing some things out. I'll give it a try tonight.

[Blight]

neuron2, even doing a 50% blend between the two frames would be better than a duplicated frame (as far as fluid motion goes).

[Guest]

@Blight

OK, I'll run an experiment and see how it looks.

[Guest]

I had a user submit a clip that had been captured with a bad capture card that was delivering many out-of-sequence fields, but fortunately always in the top field. Decomb in its default behavior vomited on it because the field matching failed. FieldDeinterlace could have been used, but there was a better way! Following is my response to the user. I will add this situation and resolution to the help file.

----------
Hi Jussi,

I got your file and diagnosed the problem. Your capture card or software is broken. But you are in luck as Decomb can work around the problem! First the analysis...

The card is not delivering fields in correct and reliable order. You can see that from separating fields and examining them.

Here is an analysis of a short section I looked at. The number 1 refers to a picture where a man sits at his desk. 2 refers to the next picture which is a closeup of him. b and t refer to top and bottom fields. These are the five frames:

b1/t1 b1/t1 b2/t2 b2/t1 b2/t2

The field t1 is wrong in the fourth frame. It should be t2. How t1 got there is anybody's guess, but most likely a capture card problem, unless you've processed this with some other software. It so happens that all the bad fields are in the top field, so you can trick Telecide into matching on the bottom instead of the top, and that makes your clip play correctly. Here is the script:

LoadPlugin("d:\don\programming\c++\avisynth\mpeg2dec.dll")
LoadPlugin("d:\don\programming\c++\avisynth\decomb\release\decomb.dll")
mpeg2source( "decomb_problem.d2v" )
ConvertToYUY2
SwapFields
Telecide(true)
Decimate15
##FieldDeinterlace(false,15,false)

Thank you for submitting this interesting problem. It extends my knowledge and experience. :-)

best regards,
Don

[DDogg]

We are going to have to start calling you, "Gentleman DG" :)

BTW, that is a compliment lol

[Guest]

@DDogg

My mommy taught me to treat others as I would like to be treated. LOL

Actually, it is just a result of the awe and deference that I feel is merited by such an august group of people as yourselves.

[daxab]

If you have 24fps source material that has been telecined and then run through telecide, you get 30fps material with one duplicated frame out of every 5. The frames, in time, look like this:

|----|----|----|----
0....1....2...3,4...

3 and 4 are the duplicates, in this example.

Decimate15 deletes the duplicate and gives you this:

|----|----|----|----
0....1....2....3....

The frames are spaced evenly in time.

If, instead, the duplicate frame is deleted and a blended (or interpolated) frame is inserted, you get this:

|----|----|----|--|--
0....1....2....3..x..

Frame x, the blended frame, is not evenly spaced in time. When you play these frames back at 30fps, you will get a glitch every 5 frames.

[DDogg]

"Actually, it is just a result of the awe and deference that I feel is merited by such an august group of people as yourselves."

I could never spell galoshes :D

[Guest]

@daxab

That doesn't look right to me. Would you not get from Telecide:

|----|----|----|----|----|----
0....1....2....3....3....4....

and then if you decimate normally:

|----|----|----|----|----
0....1....2....3....4....

if you "decimate" with blend:

|----|----|----|----|----|----
0....1....2....3....3/4....4....

[daxab]

@neuron2

Yes, I agree -- I tried to say that but my notation was confusing. I am a poor ASCII artist.

I think the problem with the decimate+blend idea is that the timestamps will be off.

Starting with 24fps film, we have:

0-000ms @ 000ms 24fps
1-042ms @ 042ms
2-083ms @ 083ms
3-125ms @ 125ms
4-167ms @ 167ms
...

On the left is the timestamp of each frame when it is supposed to play, to recover the original motion. On the right is the timestamp when it will play. Since we haven't don anything yet everything matches up. During telecining, this is split into fields, recombined , and comes back out as 30fps. I won't draw this but most people can picture this in their heads.

Telecide reconstructs the original frames and yields a duplicate. So we have:

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

This won't play right, as is, because the timestamps are wrong -- they don't match our original film frame timestamps.

Decimate15 deletes one of the extra frames numbered 3 and adjusts us back to 24fps, so we get the original picture again, which does play correctly.

0-000ms @ 000ms 24fps
1-042ms @ 042ms
2-083ms @ 083ms
3-125ms @ 125ms
4-167ms @ 167ms
...

But if, instead, we do a decimate with blend, we'd get something like this:

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

X is the new frame, interpolated between 3 and 4, so it has a timestamp between that of 3 and 4.

This might be marginally better than using the result of Telecide (with no Decimate) but not much -- all frames still are playing at the wrong time. I think the result would be very similar to viewing the output of Telecide, but the periodic hitch in the motion would look different (but still be there).

[yangus]

hey yo thanks for all your help! sorry for the late reply, since i just finished finals today and i'm dead tired (yea i pulled a couple of nighters...) anyhow i'm gonna try out the suggestion tomorrow on this particular anime title (anyone heard of kenshine?) :D btw someone mentioned that chinese films rarely looked good with force film but isn't that not true? when i did preview under dvd2avi, it was 95% film most of the time, so doesn't that mean ivtc's not necessary? well anyway i'll let u guys know how it turns out. later!

[Tri]

I have a problem... When I use 'FieldDeinterlace' I get some frames with strange lines. This only happens with decomb 1.8 and later, but 1.7 works fine.

Also, it doesn't happen without the 'FieldDeinterlace'-command.

[Guest]

@tri

You're not giving me enough data to help you. "Strange lines" tells me nothing. You need to mail me a short clip that demonstrates the problem, including the script you are running. Make sure you send the input file, not the processed file. Better yet, make it available for download and post the URL here.

[Tri]

Ah sorry, it's nothing to do with decomb, it's just that avisynth suddenly doesn't want to resize anymore and the spatialsmoother doesn't work anymore... :angry::confused:

[Guest]

There is a new release of Decomb. Version 1.9 combines Telecide and FieldDeinterlace to give a small speed increase and prepare the ground for optimizing. Also, Decimate now supports 1-in-N, where N can be set from 2-25. Please note that the syntax changes, so read the new help file carefully and revise your scripts accordingly. You will no longer need to follow Telecide with FieldDeinterlace, and Decimate15 will become simply Decimate (add a parameter if your decimation differs from 1-in-5).

Get the new release from http://sauron.mordor.net/dgraft/

A few speed tips: 1) If not required, omit ConvertToYUY2 from your scripts. If it is needed, Telecide will tell you. Read the help file for more details, and for how to make HUFYUV convert to YUY2. 2) When serving to VirtualDub (or similar applications), disable display of the input and output frames during processing. You can do this via the Options pulldown menu.

[hakko504]

@neuron2

Would it be possible to extend Decimate to also handle NTSC <=> PAL conversions? I'm thinking 3 distinct options:

1 NTSC interlaced => PAL progressive

Bob(height=576)
Decimate(NTSC2PAL,i)

or maybe

Bob(height=576)
Decimate(NTSC2PAL)
Decimate(2)


2 NTSC progressive => PAL progressive

Decimate(NTSC2PAL)
BicubicResize(720,576)


3 PAL interlaced => NTSC progressive

Bob(height=480)
Decimate(PAL2NTSC)


For the last conversion, PAL progressive => NTSC progressive, I think it should be possible to just use ChangeFPS(29.97) to gain speed.
So what do you think, would this be possible?

[Blight]

hakko: that has nothing to do with decimate.

Once you get a progressive NTSC, you just speed up the video to 25fps (without adding any frames) and then run a pitch correction algo on the audio to make it match the new video length without making people sound like chipmunks.

[hakko504]

@blight

First note that I do not talk about film (23.976fps/24fps) content here. I mean genuine interlaced (or progressive) NTSC 29.97 content.

Secondly, Decimate is just a filter that removes the frames that will yield the most jerky video. NTSC2PAL could be done like this: ChangeFPS(30)
Decimate(6)but I've had some trouble with ChangeFPS and it should be faster and more reliable to do the decimation on the original content.

Thirdly, I don't like speeding up video's and messing with pitch correction. It just doesn't sound good.

[ppera2]

hakko504

ChangeFPS is not good idea - it inserts or drops frames to get given value, what will cause choppy movement.
For example when I used it to get 25 fps from 23.976 it caused every second short stop - because of repeating aprox. one frame per second.
In your example it will be much rarer, but will happen.

Better is AssumeFPS, but it changes duration - nothing is perfect.

And as I observed there is bug - ChangeFPS doesn't change framecount but duration, at least not in file information of VDub, but same error is visible in TMPGenc.

Speeding up is used by Film to PAL conversion. It is 4% what is not too noticable. Of course speeding from 25 to 30 is too much.

And I think that in AVISynth it should be simple (NTSC to PAL) -
ChangeFPS(25). Other thing is how this function is realized.
It should drop out every sixth frame, and ocassionally seventh to maintain 29.97 fps rythm.
Even better would be if it worked field, not frame based.

Anyway, there is a way to make such conversion good. Perhaps we expect too much from programmers here.

[Mental]

One thing that would be really useful is a feature to restore a progressive NTSC stream that has been converted to PAL.
Because a lot of material that is shot for TV is recorded on FILM at 30fps. This makes for easy NTSC convertion, but introduces some nasty interlacing when converted to PAL.

I myself have no idea on how this should be accomplished, I've read some discussions on other forums, but noone seemed have a good method for dealing with these kind of streams.

[Blight]

I did notice that a lot of music videos originating from the U.S. and aired in PAL have blended fields. They basically do 30fps -> 25fps by blending the fields.

I doubt there's a way to restore a good signal other than doing smart deinterlace.

BTW neuron2, have you had a chance to test my suggesting on blending the duplicate frame to mainain a smoother 30fps video with progressive reconstructed fields?

[wmansir]

@Mental
The NTSC(telecided material) -> PAL -> Original Film conversion is tricky. If the production company did it the right way they would IVTC the telecided material back to 24fps progressive frames and then speed it up to 25fps for PAL systems, but often they take the cheap route and just blend the fields of the 29.97fps telecided material when converting to PAL by running it thru a quick and dirty NTSC->PAL converter. Since the result is blended from two frames it's just about impossible to recover the original frames.

Season five of Buffy was subjected to this treatment on Sky One and after receiving some negative feedback promised to do it right for season six. (unfortunately, I hear they are now editing content out of the season six eps, but that's another issue.)

@neuron2
First, let me say great work, on both this plugin and your vdub filters, which I use often.

I would like to nominate your Antiflicker filter for consideration to be ported to Avisynth. I believe it makes a good canidate because it's usablilty would be greatly increased over it's current vdub implementation, as would it's speed when operating in the YUV colorspace. Of course, you are working on this project now, but if you find yourself looking for something to do I just wanted to throw in this suggestion.

Again, thanks for your work.
wes

[jugm]

Not sure if it is a problem at all and if it is in Decomb or somewhere else... I'm doing NTSC interlaced rather old movie with VOB -> DVD2AVI -> Avisynth -> NanDub. Avisynth does just a standard deinterlace (there are lots of examples in this thread how to do it right). Somewhere close to the end Avisynth produces (in NanDub status line) error msg like "error read 0x..." I dont have exact text now, but I will reproduce it tomorrow. So I had to insert DeleteFrame statements to delete two frames at the very beginning of my .avs file (before Decomb lines). This fixed the error.
Now I dont know how to give you example of my frames so you could reproduce it (its ~4 Gb of VOB files). I tried to use DVD2AVI to feed frames to NanDub and save problematic frames but it didn't work - I can't reproduce my error with result AVI.
So question is - is it something worth to mention like an error or DeleteFrames is good enough fix ? Do you want me to send those "bad" frames and what is better way to do it ?

Yes I tried both 1.82 and 1.9 - same result.

[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!

[Blight]

Yeah, I'm still on a p3/733. I keep delaying the purchase. I feel the athlons at their current mhz and die size are just too hot. I think i'll wait for the 0.13m shrink which is due in the next 2-3 months.

Might grab some GF4 while I'm at it.

Also, what do you think of SSE. Anywhere to implement it to improve speed? I know most of the code is probably integer so SSE won't be as useful, but maybe in some places... Also, SSE2 should be useful as well, although you probably lack the P4 to do it.

BTW, Just for kicks I encoded some episode of Xena with v1.91 last week. Even though it was mostly blended fields (I hate those 30->25 fps blend conversion) the resulting image was very nice...

Oh, and regarding the comparison I ran last night. Here's a weird thing. Both videos were encoded using DivX 4.12 1-pass quality based (100 quality). The Greedy file came out at 3mb while the Decomb file came out at 2mb. I think this is due to greedy's deinterlacing not blending on missed fields. Not entirely sure though.

I'll try running longer comparisons this weekend.

P.S.
I still think adding decimate into the telecide filter would speed things up even further ...

[western shinma]

I've only done one such comparison but with Nandub at 3x constant quantizer. Decomb clocked in at 25 megs, and Greedy was only 20. This was with default postprocessing in Decomb and force film with vertical filter enabled for Greedy. With Decomb's postprocessing disabled and Greedy's vertical filter deactivated, both files turned out almost exactly the same size, but there was a considerable amount of interlacing left over.

[Blight]

Ok, took another try at benchmarking...

Same parameters as last test. Used a 1 minute clip of high-motion from Andromeda.

I did multiple encodes to rule out caching improving speeds.
Encoded (video only) DivX 4.12 one-pass quality at 100%

GreedyHMA = 3:09 - 77.0mb
Decomb 3.0 (blend:on) = 2:54 - 50.0mb
Decomb 3.0 (blend:off) = 2:54 - 51.5mb

Speed difference = 8-9% in favor of Decomb 3.0

I'm not quite sure how to explain the differences in size, My guess would once again be that the field blending in Decomb compresses better than the Interpolation in GreedyHMA. It's very hard to know which gives the better quality.

Also, blending on/off didn't seem to have any effects on speed, at least not on this one minute clip.

[Guest]

Thank you, Blight, for the results. That is good news!

One little point. Decomb will do either blend or interpolate. You obviously know that but for others I point it out in case they think they need to use GreedyHMA to use interpolation.

On the file size difference: yes, the blending may compress slightly better, but it is unlikely to be responsible for the results you see, because you'd expect a big difference between the blend on and blend off cases for Decomb. I wonder if GreedyHMA is letting any combed frames go through to the output, as its combing detection is not as effective as Decomb's and it takes a lot of bits to encode combed areas.

I'm working on the Decimate-Blend experiments now.

[Guest]

@Blight

Just had another thought. Since the times for Decomb blend on and blend off are so similar, it probably means that Decomb did not detect very many frames as combed and so did not deinterlace many frames. If GreedyHMA is deinterlacing a lot more frames, then this could salvage your theory about blending versus interpolation being responsible for the size difference. I do know that GreedyHMA tends to deinterlace more frames than it should, because the combing detection is not as effective as that of Decomb.

You could test your theory by just running FieldDeinterlace(full=true) with blend on and blend off. If there is a big file size difference then your theory would stand up.

[trbarry]

I wonder if GreedyHMA is letting any combed frames go through to the output, as its combing detection is not as effective as Decomb's and it takes a lot of bits to encode combed areas.

That was also the first think I thought of when reading this. If so there are probably some obviously combed frames to be found in the output. But it may also be a question of filtering. Softer material always compresses better, so adding any filter including just turning on Greedy's vertical filter options would correct this.

From my DScaler background I personally like large resolutions and very crisp detail and much of my programming reflects it. But obviously that does not make material that compresses very well, at least without some additional filtering. That should be moot if I ever release the version with variable sharpen/soften.

Of course now after Blight's results I'm going to have to go back and tune the darn thing to go faster so that might take longer, even when I do get back to GreedyHMA. ;)

On another topic, I believe that GreedyHMA and Wiz IVTC decimation is broken towards the end of the clip (when the filter requests frame numbers greater than the decimated number, which it must do to determine which frames to decimate).

I thought I had a check in the decimation code to not read past the end but just not try do drop non-existent frames. Don't I? Or do you have reason to believe I forgot that (easily possible)? Have you seen it make blank/garbage frames at the end?

The decimation code was actually added by request for Avisynth only. There is no equivalent in GreedyHM/DScaler, so it probably hasn't been tested as much. But I wasn't aware of any other reported problems there.

- Tom

[ssjbrolly]

I mainly encode from PAL DVD sources using GKnot, I tryed some time ago to encode a NTSC source and got bad results with GKnot.
So I was curious on trying Decomb as it seems to be working preety well, I have a couple of questions tough...

If I have a NTSC source (From DVD2AVI), I should use Telecide and then Decimate15 to perform IVTC right? But should I still use FieldDeinterlace after that or wouldn't this be necessary?

If I have a FILM > 95% (From DVD2AVI), should I even bother to use Decomb or a simple Forced FILM on DVD2AVI and a deinterlace method of GKnot would be enough? Or even only using FieldDeinterlace method of Decomb(If I do this should I still use Force Film on DVD2AVI?)

I don't have many experience with IVTC since as I said I usually don't encode from NTSC sources so if you could give some hints I'd appreciate it.

[Guest]

@ssjbrolly


If I have a NTSC source (From DVD2AVI), I should use Telecide and then Decimate15 to perform IVTC right? But should I still use FieldDeinterlace after that or wouldn't this be necessary?
Just because the source is NTSC, that doesn't necessarily mean that you need to apply IVTC. What matters is whether or not there are telecined progressive frames in the stream. If you don't know what that means, you should find out before attempting to deal properly with your clips. Otherwise, it's like trying to do medicine without an MD degree!

Here's how you can tell if you have progressive frames. Find a high-motion part of your clip (look at the clip without any processing!). Step frame by frame. If you see *some* frames that are moving relative to their previous frame, AND they do not show combing, then you most likely have a telecined stream. Once you have established that the stream has progressive frames, you can apply Telecide() to recover as many of them as possible. You apply Decimate() if the original material was 25fps and you want to return to that frame rate. You should never use FieldDeinterlace after Telecide because the exact same thing is achieved through Telecide's default behavior (postprocess=true).
If I have a FILM > 95% (From DVD2AVI), should I even bother to use Decomb or a simple Forced FILM on DVD2AVI and a deinterlace method of GKnot would be enough? Or even only using FieldDeinterlace method of Decomb(If I do this should I still use Force Film on DVD2AVI?)
Assuming you do in fact have progressive source (!), I would try Forced Film and then look at the result of that alone. If you see no combed frames, then do nothing else. If you see some but not a lot of combed frames, you could apply FieldDeinterlace(full=false). If you see a lot of combed frames, then you might want to turn off Forced Film and use Telecide(postprocess=true).

If your source is not in fact telecined progressive source, then just apply FieldDeinterlace(full=true).

I don't know whether the Gordian Knot deinterlacer is adaptive so I cannot advise you about it.

Decimate15() is from an earlier version of Decomb. You should upgrade to Version 3.0. You won't regret it. :-)

Looks like I need to add a Wizard (decision flowchart) to my help file.

[Guest]

@trbarry

Hi Tom. I'm looking at your code and behavior now and will report back soon. Quite possibly you are doing something different from the vi.num_frames trick that solves the problem I mentioned. I should have checked before commenting. Sorry.

[Guest]

@trbarry

I thought I had a check in the decimation code to not read past the end but just not try to drop non-existent frames. Don't I? Or do you have reason to believe I forgot that (easily possible)? Have you seen it make blank/garbage frames at the end?
Tom, your code is just fine! It is all my fault and I am sorry for making that comment (I've edited to remove it from the post). The thing is I had a miscoding in one part of my code and the little trick I described canceled it out, but I attributed it to an inability of Avisynth to read past the declared num_frames. But as you so cogently observed [:-)], that would mean that the frames would appear blank or garbage, and they don't! So hearing you LOUD AND CLEAR on that I inspected *my* code and found the problem. There is no misbehavior in anyone's released code; that is the bottom line. Again, so sorry.

To possibly regain some respect... :-) I suggest that your decimation code appears needlessly complex, with the tests for out-of-sync and random access, etc. Can't you just do this:


PVideoFrame __stdcall Decimate::GetFrame(int inframe,
IScriptEnvironment* env)
{
int dropframe, useframe;

/* Determine the correct frame to use and get it. */
useframe = inframe + inframe / (cycle - 1);
dropframe = FindDuplicate((useframe / cycle) * cycle, env);
if (useframe >= dropframe) useframe++;
PVideoFrame src = child->GetFrame(useframe, env);

return src;
}

where FindDuplicate(frame, env) inspects 6 frames, (frame - 1) through (frame + cycle - 1), and returns the right frame to remove. Of course, it caches the result and only recalculates for each new cycle.

[Guest]

@Blight

I have coded your idea about not removing duplicates coming out of Telecide, but rather replacing them with an interpolated (blended) frame as discussed earlier in this thread. It doesn't look so bad! In fact, it looks surprisingly good.

You can download it at http://sauron.mordor.net/dgraft/decomb301.zip

I have not officially released it so if anyone gets it to play with, please do not re-distribute it or otherwise publish it. If people think it is worth including in the official release I will do so. Please comment here on what you think of this feature. Thank you.

[trbarry]

To possibly regain some respect... :-) I suggest that your decimation code appears needlessly complex, with the tests for out-of-sync and random access, etc. Can't you just do this: ...

Yes, that might be better but I actually added the Decimate code with the intention it would be temporary. It would be much more efficient embedded into the Update_Fieldstore function deep inside the Greedy code. But I wanted a quick and simple add-on for the moment that didn't require me to regression test everthing else that Greedy does.

And besides, I am under an ancient curse. No matter what language I program in, it is destined to come out looking like I wrote it in assembler. I've learned to live with that and try to make up for it with lots of comments. ;)

- Tom

[ssjbrolly]

Thanks for the reply, it really helped to clarify somethings, this might sound dumb, but I still have a doubt regarding progressive/telecined streams...

Originally posted by neuron2
Here's how you can tell if you have progressive frames. Find a high-motion part of your clip (look at the clip without any processing!). Step frame by frame. If you see *some* frames that are moving relative to their previous frame, AND they do not show combing, then you most likely have a telecined stream.


I usually use DVD2AVI to check for interlaced frames, so if I see any combing artifacts on the clip that stream is interlaced and theres no need to IVTC right? But what exactly do you mean by a frame moving relative to the previous one? (I think I'm totally missing the point of what's a progressive and telecined progressive frame...)

Originally posted by neuron2
You apply Decimate() if the original material was 25fps and you want to return to that frame rate.


Wouldn't this be 23,976 fps if I have a 29,970 fps NTSC source?

Originally posted by neuron2
Looks like I need to add a Wizard (decision flowchart) to my help file.


That might be useful :D

I've downloaded Decomb 3.0 now and have been reading the help file, wich brings me to another question... what exactly are the advantages of using Progressive Frame Recovery instead of IVTC? I thoght that when there are progressive frames we should allways IVTC...

Thanks again for the help.

[Blight]

neuron2:
You already coded it, so keep it in ;)

[Guest]

@Blight

OK.

@ssjbrolly

I usually use DVD2AVI to check for interlaced frames, so if I see any combing artifacts on the clip that stream is interlaced and theres no need to IVTC right? But what exactly do you mean by a frame moving relative to the previous one? (I think I'm totally missing the point of what's a progressive and telecined progressive frame...)
I don't know what you are setting for DVD2AVI. You need to look at the raw clip as I described. Just because you see combing you can't conclude that it is pure interlaced video. It is the pattern of the combing that will give you the clues you need. By a frame moving I mean you are viewing a series of frames in which there is consistent motion in the scene, such as a car traversing the screen. A progressive frame is one in which both fields are from the same temporal moment, so there is no combing. Telecined progressive frames are progressive frames that have been passed through a 3:2 pulldown process to increase their frame rate to match broadcast rates. Some of the frames resulting from this appear combed but the original progressive frames can be recovered through a process called field matching. The extra fields added by the telecining result in a duplicate frame for every 4 original frames, and the duplicates can be removed with Decimate.
Wouldn't this be 23,976 fps if I have a 29,970 fps NTSC source?
Yes.
I've downloaded Decomb 3.0 now and have been reading the help file, wich brings me to another question... what exactly are the advantages of using Progressive Frame Recovery instead of IVTC? I thoght that when there are progressive frames we should allways IVTC...
In Decomb, IVTC simply is Telecide() + Decimate(). Telecide does the progressive frame recovery as described above. Decimate removes the resulting duplicate frames. Your last guideline is not universally valid: for example, you can have a PAL 24fps stream of progressive frames that is phase shifted by one field and therefore appears combed. You don't want to do a classic IVTC. You only want to undo the phase shift. Decomb can do this by applying only Telecide and omitting Decimate. In this case, Telecide does the field matching and restores the original frames, but no duplicates are produced, so Decimate is not required.

[Blight]

neuron2:

Here's a first Draft (http://www.inmatrix.com/articles/ivtcsynth.shtml) of an article I've written.

I'd appriciate any comments.

[b0b0b0b]

Originally posted by Blight
neuron2:

Here's a first Draft (http://www.inmatrix.com/articles/ivtcsynth.shtml) of an article I've written.

I'd appriciate any comments.


Is it the case that you should always crop after ivtc, but you may crop before regular deinterlace?

When you enumerate the decomb options, maybe it would help to put either true or false in all caps to illustrate what the defaults are.

[Blight]

I tried to write it full-proof, so I didn't discuss defaults at all and instead wrote the defaults as recommended settings.

And as for cropping. That's a bit of a problem since you don't want people to accidently put the wrong width before the telecide.

Which brings up an interesting question for me.

If a frame gets removed by Decimate, does any processing occur on it (i.e. crop/resize) if they were listed further down the list?

If so, it might be faster to resize/crop after telecide and before decimate as you would be comparing less video data. But this would only be faster if the resize/crop are being called even though the frame is discarded.

Can anyone verify this?

[Guest]

Decimated frames never make it past the Decimate call.

[Uli]

Just wanted to report:
I've coded the anime 'gun smith cats' RC1. It's a weird stream of about 80 - 90% NTSC and FILM with agressive interlacing artefacts. Made the following script using decomb301:

LoadPlugin("MPEG2DEC.dll")
LoadPlugin("decomb.dll")
Mpeg2Source("GSC.d2v")
Telecide()
Decimate(5)

The resulting 23.976 FILM stream is absolutly perfect :D
Never before i've seen such a perfect reconstruction of a partially telecined anime.

thanks again, Uli

[daxab]

I'm a big fan of Decomb, which seems to work really well with clean source (i.e., DVD). However, I'm still having trouble with noisy source. For instance, a recent capture of "24" stutters quite a bit with Decomb, but is relatively smooth with GreedyHMA.

Any tips for noisy source?

The other question I have is about jaggy diagonals in frames that have gone through Telecide().Decomb(). The source is anime DVD, so the diagonal line should be clean, and it is on non-reconstructed frames. Is this to be expected?

[Guest]

@daxab

If you can make an input (unprocessed) clip that shows the problems available to me, I can answer your questions. Failing that, I have no way to address them. Please get in touch with me by email.

[hakko504]

Originally posted by daxab
The other question I have is about jaggy diagonals in frames that have gone through Telecide().Decomb(). The source is anime DVD, so the diagonal line should be clean, and it is on non-reconstructed frames. Is this to be expected?
Sometimes, yes. Some anime have the background and all drawn parts filmed in 23.976fps and then the CGI is added at 29.97 i.e. after telecining. That would produce something like this:

back: 1t1b 1t2b 2t3b 3t4b 4t4b (film telecined)
front: 1t1b 2t2b 3t3b 4t4b 5t5b (NTSC interlaced)

Now, if you IVTC this then you remove the superfluous half frames and put the others together making this:

back: 1t1b 2t2b 3t3b 4t4b (original film)
front: 1t1b 3t2b 4t3b 5t5b (fields missing from NTSC)

In this case frame 2&3 could produce the jagged lines you mention, but some of it could be removed by using a deinterlace.

[Blight]

Like I said once in a post regarding Telecide (the VDub filter), it had aweful problems with a noisy VHS cap ... stuttering like crazy. Sadly, I no longer have the source (it was a PAL cap btw and I was trying to use telecide to phase shift).

[Guest]

@Blight

All the more reason for daxab to get me a clip! It's quite possible that I can make things better, but I have not seen this problem in my own testing, and without a clip, what can I do?

Looking forward to your assistance, daxab! :)

[daxab]

@neuron2

I have sent you an email with a link to the clip. Please let me know if you have any trouble getting it. It's compressed with the Indeo 5.1 codec.

@hakko504

Yikes! Hence the notorious difficulty of anime. I guess in that situation you just do a 29.97 fps interlaced encode.

In my case I don't think there is any CGI, but I could be wrong. It's Battle Athletes Victory, and what I notice is a series of frames like so:

a b X d

where a, b, and d have clean lines, and X looks good but the same lines that are clean in a, b, and d are jaggy. I'll try to put together a clip that shows the effect.

[manono]

Hi daxab-

Regarding the anime-you should always check the source material for these anime DVDs to make sure they're not screwed up. I was complaining once to neuron2 about the exact same thing and he told me to check the source, and by golly, while scrolling through the .d2v, there it was. Or check the .avs before applying Decomb.

If Decomb was responsible, you might try and weaken the deinterlacing algo with something like this:

Telecide(false,false,true,30)
Decimate(5)

15 is the default value, and I found that with certain anime material it was too strong and sometimes deinterlaced good frames (although I was testing with an older version some time ago). Isn't BAV wonderful?

[Guest]

@manono

Thanks for pointing that out, manono. Of course, I'm always willing to inspect people's problem clips because there is always the potential there to learn something new and improve the tool. Notwithstanding that, people really *do* need to carefully determine the nature of their source material before deciding on the appropriate processing, and especially before raising any queries about the tool's behavior.

[BBWoof]

I'm really happy to report that with v3.0 and putting the ( ) at the end of my functions, I'm running at at least 10% faster then before I ever complained in the first place :cool:

[Gamblor]

Hello everyone,

Mr. Graft, thank you for your effort in developing a filter that is in such high demand. It's fun to use something with so much heart.

Meanwhile, I am hoping to get some help with the 'postprocess' in Telecide() of Decomb version 3.0. I would like to turn it off to test the effects, but when I set the value to false,

"Telecide(false,false,false,15,true,false,false)"
or
"Telecide(false,false,false)" ,

I still see deinterlace blending. When I set 'postprocess' to false, shouldn't I see the original intensity of combing wherever combed frames sneaks through?
Right now, when I look at a combed output frame, it is still being blend-deinterlaced but I don't want it to.

Has anyone else tried to turn OFF 'postprocess' but without effect?
Please let me know if screenshots are wanted.

Thank you for everyone's time.
Cheers!

Cal

[Guest]

@Gamblor

You probably have blended *fields*. Do a SeparateFields() and see if there are blended fields. Then report back. I can assure you that the postprocess option is not broken.

[Gamblor]

Hi Mr Graft,

Thanks for your swift reply. Very impressive. :)
I am looking at SeparateFields() right now but I'm not sure I understand how to look for blended fields after doing SeparateFields(). Could you please give me a few more pointers?

Cal

[Guest]

Just look at the fields and see if any are combinations of two pictures, as if the two pictures were overlayed on each other. If not, then you will have to make an input clip available for inspection.

[Gamblor]

Thank you for your time. I am so sorry to be keeping you but I don't believe I am seeing any blended fields.

I am preparing screenshots and an MJPEG clip for you to examine.
Should I email you the information pertaining to the site hosting these files of mine?

Cal

[Guest]

Yes, please, mail the link to me. Just make sure to send the INPUT clip, not a processed clip. And also please explain in your mail how I should duplicate your problem. You are aware that the field matching process can remove combing that is apparent in the input clip even if postprocessing is off, right?

[Krajensky]

@daxab:

My local FOX station comes in badly also...I just (blatantly) stole the medium denoising algos from GordianKnot:

TemporalSmoother(3)
SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
(Required libraries are mpeg2dec.dll and avisynth_spatial.dll)

I had a really messed up CBS cap that this cleared up quite well - though it leaves some amount of gray artifacts on black backgrounds, so I added a levels to fix that, and add contrast.

One other thing I can think of is maybe the field order is somehow wrong? Did you crop before using decomb?

Krajensky

[Gamblor]

Hi Mr Graft,

From my understanding, I am aware that ideally when postprocessing is disabled, the field matching process will remove combing. My dilemma is that when postprocessing is disabled, I should not be seeing any blending when a combed frame sneaks through because that's not what the field matching process does.

I am in the middle of preparing a package containing my material for you to examine.
Cheers!

Cal

[jarthel]

hi. I'm getting errors in decomb when I open the avs file in nandub. It keeps on saying "telecide:width must be multiple of 4; use crop" and it's on the resize line in avisynth. The resize parameters are 640 by 480. I'm sure 640 is a multiple of four.

The crop parameters is also multiples of four.

here the avs file -->>

--------------
#
# Created with Gordian Knot
#
# http://thewef.nav.to
#
# PLUGINS
# get them from http://users.win.be/dividee
LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\mpeg2dec.dll")
#LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\InverseTelecine.dll")
#LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\Avisynth_Spatial.dll")
LoadPlugin("D:\DOWNLO~1\windows\UTILIT~1\divx\GORDIA~1\decomb.dll")
#LoadPlugin("C:\WINDOWS\System32\vobsub.dll")
#
# SOURCE
mpeg2source("D:\dvdrips\kenshin27\kenshin27.d2v")
#
# TRIM
#trim(startframe,endframe)
#
# IVTC
#InverseTelecine(40,10,15)
# or use
#GreedyHMA(1,0,4,0,0,0,0,0)
#
# CROPPING
crop(12,4,698,476)
Telecide()
Decimate(5)
#
# DEINTERLACING
#SmartDeinterlace(2,15,true,true,true)
# or use
#VerticalReduceBy2
# or maybe
#GreedyHMA(1,0,0,0,0,0,0,0)
#
# SUBTITLES
#VobSub("FileName")
#
# RESIZING
BilinearResize(640,480)
#
# DENOISING: choose one combination (or none)
# 1) little noise (fast)
#TemporalSmoother(2,1)
#
# 2) medium noise (slow)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#TemporalSmoother(2)
#
# 3) heavy noise (very slow, you have been warned)
#SpatialSoftenMMX(2,4,6,false,false,4,4,6,8)
#TemporalSmoother(3)
#SpatialSoftenMMX(1,4,6,false,false,4,4,6,8)
#
# BORDERS
#AddBorders(left,top,right,bottom)
#
# COMPRESSIBILITY CHECK
# !Snip Size has to be 13 for use in GKnot!
#SelectRangeEvery(260,13)
#
# FOOL CCEnc
#ResampleAudio(44100)

------------------------------------

Any suggestions? Thanks

[Guest]

@jarthel

My calculator tells me that 698 divided by 4 is 174.5, which means it is not a multiple of 4. Appearances can be deceiving. :)

[Guest]

@daxab

Thank you for the noisy clip that exposes a weakness in Decomb. :)

I have determined that the problem here is in Decimate and not in Telecide. I made some changes that make it handle this clip properly but I need to regression test the new version before releasing it. Also, my web site is going down for maintenance this weekend.

Decimate doesn't check every pixel; it subsamples the frames for speed. My subsampling was a little too aggressive (trying to match GreedyHMA for speed!). Also, my threshold for ignoring noise was a little low.

Watch here for a new release.

If you'd like to send me your jaggy clip, I'd be happy to take a look at it. Thanks again and sorry for the earlier confusion on my part about the nature of your clip.

[Guest]

Ok, I've placed a test release on
http://buehlerbreakers.net/decomb302.zip

This appears to work better with your noisy clip. Please give me your feedback. Thank you.

[Guest]

@Gamblor

You sent me a clip ostensibly demonstrating that the postprocess option was not working, i.e., that setting postprocess=false did not stop frames that fail field matching from being deinterlaced. You pointed me to one particular frame. I analysed your clip and determined quite easily that the frame was removed by Decimate and that is why you did not see it in the output. In fact, you were looking at the following frame when you thought you were looking at the combed frame that failed the field match. I then pointed out to you two other frames that failed the field match, and which showed combed as expected with postprocess=false and blended as expected with postprocess=true. Conclusion: the postprocess option is working as expected and your complaint is groundless.

[Gamblor]

Yes, Mr. Graft, I believe we are still addressing my inquiry via email. I have chosen not to reply to the forum clarifying the issue yet because I do not understand your email reply to me. I imagine it's only fair to me and everyone else that I only post a follow-up message on here if and only if I actually understand what is happening. Of course I do not doubt that there is no problem at all, and it is simply am oversight in the usage of this filter on my part. In which case, I would sincerely regret taking up your time.

Furthermore, I apologise if my ignorance is bothering you. I am seeking to enlighten myself with your project as it is a very exciting production indeed. Please excuse my lack of technical knowledge since I am unfamiliar with low-level details.

Yours truly,
Cal

[Guest]

I clearly demonstrated to you that the postprocess option is not broken, which you began this thread by asserting. You refused to accept my demonstration for unstated reasons and instead deflect the issue with some new nebulous complaint about how a frame "looks". [Your quotation marks.]

Let's resolve the first issue first. Do you still think the postprocess option is broken? Then we can address your new issue.

You know what they say, ignorance is no excuse. :)
It is not my responsibility to educate you, but it is your responsibility not to make unfounded allegations about people's carefully tested tools, and to correct them when proven to be unfounded.

[daxab]

@Krajensky

Thanks for the tip. I have tried the SpatialSoftenMMX filter with, for me, mixed results. I don't mind the speed penalty, but I do mind the detail loss. I know, I know -- can't do noise reduction without some detail loss (possibly with the exception of careful filters on anime source).

@neuron2

Thanks for the new build. In my original clip, there were 3 stutters in the first 60 seconds. With the 302 release all 3 stutters are fixed -- oustanding work.

[Guest]

@daxab

Great! Thanks again, daxab; your feedback has been invaluable in improving Decomb.

[Gamblor]

Dear Mr. Graft,

I wish to start by saying that your latest email of only one-sentence has clarified much of my confusion, thank you, and I will acknowledge that 'postprocess' is working properly.

In response to your last post to me, I think you are wrongfully making the assumption that people are easily educated in a technical field. You are also discriminating against less fortunate and lesser educated people who are putting up the courage to make observations. If I don't understand how your project works, should I not have dared to ask any questions? If it is my responsibility to not make "unfounded allegations" yet I do not have the understanding to ask proper technical questions, then what a vicious cycle this must be.

Please take note that my initial question was not addressed to you directly, Mr. Graft. I was seeking enlightenment from everybody and anybody in this forum. However, you chose to respond to me, hence I was under the impression that you were indeed here to help educate me. If a forum is not there to aid in education, I'm afraid I do not see the point of a forum. In retrospect, your latest email finally addressed my lack of understanding and I appreciate that.

Furthermore, it seemed to me all along that you didn't understand my query in the private email so I was merely attempting to clarify my position in subsequent emails. I've stated several times that I simply do not understand your explanation, which does not imply I am refuting it. I couldn't even reproduce the examples you've given me, and as the uneducated person that I am, I became fearful of telling you that your example seemed to be faulty. Instead, I expressed my lack of understanding and wished to seek further advice from you by attempting to clarify my original query.

My degree of doubt on 'postprocess' was never to the point of a strong, cogent complaint. I was asking questions "hoping to get some help" with it because obviously I was uncertain about my own observations. It seems clear though that you strongly believed that I actually understood your explanation and it was my impolite nature that I haven't acknowledged your conclusion. In fact, it was not until your latest email of only one sentence that I finally understand your explanation! I thank you for that.

Initially I had intended to try this filter as part of my hobby but as a hobby, I don't have enough time to spend on it to "educate" myself in all its glory. I will now acknowledge that 'postprocess' is NOT broken due to reasons stated earlier by you. To save everyone grief, I will keep my questions to myself now and not post to this forum anymore. So please forget everything I asked because it was all bogus, and Decomb 3.0 is just as spiffy as ever.

Cheers to you all. Although I am at a loss, I really do appreciate everyone's time.

Good day.

Cal

[Guest]

Now, now, Gamblor, there's no need to overreact.

I think most here will agree that doing good rips and encodes is a highly technical art and that you cannot just use these complex tools in a casual hobbyist mode and then come post questions based on a very low degree of expertise and prior research. People regularly get flamed for that here. :)

It is very easy for posts like yours to take on a life of their own, with people saying "Oh, I read on the doom9 forum that Decomb's postprocessing is broken". So you will please understand a tool developer's concern that issues are treated fully and the resolution properly documented.

And you never actually *told me* that you didn't understand my response and what you didn't understand about it.

So, no need to go away. We can still both learn from each other.

And, oh, no need to keep calling me Mr Graft. It makes me feel old. You can call me neuron2. :)

Let's smoke the peace pipe and move forward from here.

[Krajensky]

@daxab:

Sorry, I forgot one thing...using SpatialSoften before Decomb will probably confuse it more than it will help...if you use it be sure to place it after the deinterlacing/decombing.

TemporalSmoother-Decomb-Decimate-SpatialSoften is a good order for really noisy sources. Otherwise skip the spatialsoften.

Krajensky

[daxab]

@Krajensky

Agreed about putting SpatialSoftenMMX after Decomb. In another thread, it was also advised to put TemporalSmoother after your ivtc filter, so as not to smooth out the interlacing data. But I think you can put it before if it's not too strong.

[Guest]

Decomb version 3.1 has been released at my web site:
http://sauron.mordor.net/dgraft/

This version adds the new Decimate mode for frame interpolation suggested by Blight, and makes Telecide and Decimate more reliable with noisy clips, thanks to feedback from Daxab.

Watch the web site if you are interested in the source code; it will be released within a day or two.

[Blight]

Here's something logistical for you to consider:

Imagine a hybrid 30/24fps source.
The 24fps is 3:2 telecined.
The 30fps is 30fps progressive, possibly phase shifted (CGI/Animation)

You run Telecide, it matches all the fields.
Now you run Decimate with the blend setting.

The 24fps video is field reconstructed and the duplicated frame is blended so it's not as choppy.

And here's the problem. The 30fps progressive video isn't known to the decimate filter, it assumes it's a 24fps source since it was given then 1 in 5 parameter. So it blends a progressive frame...

The only way I can think of bypassing this issue is if decimate was part of Telecide and won't be called if the "blend duplicate" paramater was given and all fields in a 5-frame sequence matched perfectly.

Don't you just love these kind of posts ;)

[Guest]

@Blight

Suppose Decimate mode=1 had a threshold for similarity. When the frame differs by more than the threshold, it is passed through, otherwise it is blended. Usually, the 30fps frames will differ by more than threshold and not get blended. If a static scene comes, blending will occur but it won't matter because the frames are the same. The problem is making a reliable threshold that is insensitive to the scene brightness level, noise, etc. It might be worth playing around with. What do you think of this possible approach?

[Dali Lama]

I am using the latest version of Decomb and when I use it with an anime: Rurouni Kenshin it has totally messed up frames that are like unrecognizable??

What would cause this?

I am using the default IVTC settings.

I lowered the threshold for interlacing and it helps, but then avisynth crashes and gives cannot read error?

Man! This program worked beautifully on Crouching Tiger. I hope I can figure this out.

Thanks,

Dali

[Guest]

@Dali

You've got to give me more to go on.

1. Are you ripping it from a DVD? If so, how do the frames look before processing with Decomb?

2. What do you mean by "totally messed up"? Can you post an URL to a frame grab?

3. Can you provide a short input clip (before processing) that I can use to duplicate your problem?

[Blight]

neuron2:
That may work. I think doing a comparison on chroma-only might be better as noise is usually more noticable on luma (I think).

Instead of adding a third parameter you can have it at 0=off and 1-255 = threshold. No point in having too many parameters.

[High Speed Dubb]

Originally posted by Blight
I think doing a comparison on chroma-only might be better as noise is usually more noticable on luma (I think).It varies a lot from source to source, especially if you&rsquo;ve got interference. Usually the chroma variance is lower, but the chroma signal is also less. In general you&rsquo;re better off using both chroma and luma, since both contain useful information.

For the most part, the brightness of the scene doesn&rsquo;t matter &mdash; I&rsquo;ve found that almost all the noise is additive. The exception comes with really bright or (especially) really dark scenes, where you get an edge effect. An easy workaround is to ignore differences at dim or very bright pixels, normalizing if necessary. (Though this will fail if the whole picture is really dim.)

Making the threshold insensitive to noise is harder. You may need to explicity estimate the amount of noise. If you&rsquo;re working with 3:2 pulldown, you can use the repeated field for a good estimate. To figure out which field is repeated, you could use a rough noise estimate, or just take Min(recent field differences).

[Dali Lama]

Sorry for the late reply...I appreciate your concern.

Well, I managed to "fix" the problem by not using "Bilinear Resize" in Avisynth. For some reason When I use that resize, The frame distorts in a horizontal direction. I fixed this by using Barry's Simple Resize filter which works well with Decomb.

I think perhaps you did not know of this conflict...but it occurs in certain movies, like the one I am encoding.

I did another encode with a different movie and Bilinear Resize and Decomb were compatable.

If you are still interested in screen shots I will post them.

Dali

[trbarry]

Hi Lindsey -

I'm glad you finally showed up here. ;)

I think there is probably a lot more valuable crossover that could be done between the DScaler & Avisynth worlds.

- Tom

[High Speed Dubb]

Hello Tom,

Yes, no doubt -- The two architectures are attempting pretty much the same thing.

Now I just need to get AVISynth up and running to try it out... :)

[OUTPinged_]

DG, can we have a bit more control over the postprocessing deinterlace option? A variable thresh would be nice (9 doesnt turn out as ideal one in some cases) and motion map denoise wouldnt hurt either.

More question: is postprocessing using chroma values too?

[Guest]

@OUTPinged_

I'll consider exposing the deinterlace threshold.

There is already a minimal sort of denoising there. I don't want to do the full one for performance reasons.

The chroma option affects only the determination of the motion map during the postprocessing phase.

[OUTPinged_]

Hmm. How big could perfomance drop ever be if chroma would be taken fully into account during deinterlacing together with luma?

[Guest]

You've misinterpreted my "only". The chroma option is fully taken into account during deinterlacing. But it is not necessary and not used during field matching. I hope that is clear now.

[OUTPinged_]

Sure. I have some source which has FILM-over-pure NTSC mastering. Field deinterlace just picks a lot of frames which are not interlaced and skips some frames with minor interlaced areas.

[Guest]

@OUTPinged_

The only way I can help when people have problems with specific clips is if they post a link where I can download a sample input clip that demonstrates the problem.

[Blight]

neuron2:

New problem ...

Say I have a 60fps (59.xx) HDTV progressive stream. Now, I want to decimate it to 24fps ... Can I do that with only 1 call to decimate?

Right now it requires 2 calls, one to cut down to 30fps and one to cut down to 24fps ...

[OUTPinged_]

hmm...

long ago i saw a program which could rebuild frame if neighbourg frames existed. of course it interpolated stuff, but it was purely progressive frame based. you gave it two pictures and it produced an avi where one image will become another like in a movie.

it was building a perfect horisontal and vertical pans, etc.

is it possible to build a 30->24fps transition tool using that algo? that would be slow of course, but people will apply it at selected frames only and will be excellent at rendering CG scenes in ivtc'ed anime. speed doesnt matter really, as it will be used on 1-5 second sequences.

[Guest]

I've released a new version of Decomb. Version 3.2 improves the field matching algorithm and adds a "reverse" parameter that allows the sense of the field matching to be reversed (see the help file for details). Get the new version at http://sauron.mordor.net/dgraft/

The next version will include improved handling of blended frames (by adding the "desperation mode" of the VirtualDub version of Telecide), and will enhance Decimate's mode=1 as suggested by Blight in this thread.

[Blight]

Are you sure reverse does anything?

I disabled post-processing, then loaded a clip with reverse enabled and disabled and there wasn't any difference...

[Guest]

@Blight

What difference were you expecting? :)

If the clip is clean you may not see anything. But try it on a clip that has blended fields. If there is a blend in the top of a frame and Telecide tries to match on it, it will fail. If you then reverse the matching, the frame will be matched properly.

The next step is for Telecide to reverse automatically on a per-frame basis.

BTW, this new reverse parameter just replaces what we used to do:

SwapFields()
Telecide(swap=true)

...because that isn't an entirely correct thing to do.

Finally, to answer your question directly: yes, I am sure the option is working, because I have a test clip with blends only in one field, and they either do or don't show up in the output from Telecide depending upon the setting of the reverse option.

[Blight]

btw, this new parameter broke all scripts that didn't use the naming convensions as the parameter order was changed. No biggy, I just updated my tutorial to use the naming convesion.

[Guest]

Oops, forgot to warn about that. :(

Yes, I have taken out all positional syntax from the help file as well, and positional parameters are now deprecated.

Finally, the "postprocess" option is now the "post" option. Less typing. :)

[Guest]

I've made a new version of Decomb, version 3.3, that adds Blight's fine suggestion for enhancing Decimate(mode=1). A threshold is added that allows you to set things up so that film content generates blends while nonfilm content is passed through. Please read the help file for detailed instructions. With this useful finesse, it becomes feasible to render hybrid material at original frame rate.

Get the new version at http://sauron.mordor.net/dgraft/decomb33.zip

I find that a threshold around 25-50 works well for DVD rips, but please check your clip with the DebugView utility to determine the best threshold given the difference metrics that you observe, especially if you have noisy analog captures.

Thanks, Blight, for this interesting idea. Keep thinking. :)

[opp]

I got a big request, something sorta similar to what tmpeg does. It is more of a whole program. I would be willing to bet most people use multipass, and everytime there is a new pass, decombing it each time can make using avisynth almost as slow as vfapi. A program that would pre-process movies and create a sorta stat file on fields or whatever info it needs during the encoding would be awesome. Then using avisynth, it can just read the stat file and serve the right frames, and could speed up encoding quite a bit. If others notice a considerable change in speed with decombing this could be well worth it.

[meleth]

Originally posted by neuron2

@meleth





So then if you have:





A B C D E





You want to make (say):





A B C+D E





That is an interesting idea. I will try it and see what it looks like. Thank you for your clarification.





Of course, you could take this to its extreme, reduce the frame rate to 6fps, and output:





A+B+C+D+E





:)



Yeah that's exactly what i meant :P

[Blight]

opp:
when doing multi-pass encodes, it's faster to do 1-pass to save to HUFFYUV lossless, then encode the multi-pass from that.

neuron:
you need to put the link on your page, tsk tsk, where are your priorities ;)

[Guest]

@Blight

Will do. I like to get some testing by doom9'ers before I release to the wider world. :)

[daxab]

@opp

>> off topic

This is exactly what IVTC4 (and the upcoming IVTC5) does -- described in another thread.

Another plugin that does this is the TPRIVTC plugin. It takes a TPR file generated by TMPGEnc and uses that to serve up frames. If you like the output of TMPGEnc inverse telecining, you can use that.

[Snike42]

@neuron2

I've been using decomb for a while on PAL video captures and this works really great! But I've noticed something on my Buffy captures. The thing is that the video is progressive, but every other scene it shifts one field, making one scene look interlaced and the next non-interlaced. This is perfectly fixed by decomb, altough on some scene changes there a interlaced frame comming through (which is fixed in the postprocessing).

Now I'll get to the problem. There are also (dutch) subtitles, and these are true interlaced. This only becomes noticeble where the subs fade in and out (which is only 1 or 2 frames). But at this point decomb is trying to match fields so that the subtitles no longer look interlaced, but the rest of the picture does. Postprocessing fixes this, but it's makes the final movie jump a little.

Do you think you could add a feature in decomb to ignore the subtitles? Maybe like specifing a vertical range to scan, instead of the whole picture?

Snike42

[High Speed Dubb]

For dealing with animated station logos, it might make sense to ignore a rectangle.

[Guest]

@Snike42

Make a test clip available and I will see what I can do.

[Guest]

@Snike42

Thank you for sending along your test clip and giving me the opportunity to improve Decomb. This problem could be resolved if you were able to define an exclusion band for the field matching analysis. Fortunately for you, it is easy to code and I had a few spare moments. :)

Please get Decomb version 3.4 from http://sauron.mordor.net/dgraft/ and apply the following script to your test clip:

Telecide(y0=430,y1=550)

@High-Speed

I agree about confining to an x band as well but I am not thrilled about implementing it (extra tests per x iteration or messy dual loops). Usually the logos are not very tall, so an exclusion band will be fine.

[Snike42]

@neuron2

I tried decomb 3.4 on my sourceclip and it works perfectly!

Thank you very much Donald!

Snike42

[Guest]

@Snike42

You're lucky it was for Buffy, otherwise I'd have blown you off.

Just kidding. :)

[trbarry]

A very large amount of my video programming has been motivated by wanting better Buffy captures. ;)

- Tom

[daxab]

...add a feature in decomb to ignore the subtitles? Maybe like specifing a vertical range to scan, instead of the whole picture...I was going to implement that exact feature in IVTC5. But I was going to do it for that little 30fps "Enterprise" logo that slides in from the right. Since it's white, typically on a black background (...space...), it generates a huge interlacing metric. Plus since Enterprise is letterboxed, processing could be sped up 25% by ignoring the top and bottom 60 pixels of each frame.

[b0b0b0b]

Originally posted by daxab
Plus since Enterprise is letterboxed, processing could be sped up 25% by ignoring the top and bottom 60 pixels of each frame.

Why wouldn't you just crop before deinterlace/ivtc in this case?

[daxab]

{Yes. I'm lazy so I've been using Letterbox, but a faster way would certainly be

AVISource(...)
Crop(...)
IVTC5(...)
TemporalSmoother(...)
AddBorders(...)

This would speed up the TS too.}

[High Speed Dubb]

Originally posted by neuron2
I agree about confining to an x band as well but I am not thrilled about implementing it (extra tests per x iteration or messy dual loops). Usually the logos are not very tall, so an exclusion band will be fine. Yeah, that is a better solution &mdash; better speed without a significant loss of information.

[jarthel]

I encoded some anime DVDs recently. And I'm getting some very weird problems.

On some of the episodes I encoded, I'm getting a very distinct line at the bottom. I was thinking it could be that I didn't crop the height properly so I checked in nandub. The line not there. The other episodes where perfectly encoded.

I had a look at the ,avs file and compared the good and bad avi. They have the same content except for the obvious differences (different .d2v file and etc...).

Here's the bad .avs

---------------
LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\mpeg2dec.dll")

LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\decomb.dll")

mpeg2source("D:\dvdrips\gasaraki24\gasaraki24.d2v")

crop(10,3,700,477)
Telecide()

BilinearResize(640,480)
------------------
Good .avs
-------------------
LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\mpeg2dec.dll")
LoadPlugin("D:\downloads\windows\utilities\divx\GordianKnot\decomb.dll")
mpeg2source("D:\dvdrips\gasaraki25\gasaraki25.d2v")
crop(8,0,704,480)
Telecide()
Decimate(cycle=5)
BilinearResize(640,480)


I removed the comments inserted by gknot (I was careful not to delete used lines.)

Any suggestions?

[Krajensky]

Your bad avs is missing the Decimate directive...if that doesn't help, try switching around your Telecide and Crop statements, sometimes Crop before Telecide will cause access violations for me.

I do notice that the crop statements have different values...I haven't see that particular dvd, but the "good" one has all 480 lines, but the other crops to 477 when it seems it should be 474 to be symmetrical.

Krajensky

[Guest]

@jarthel

Thank you so much for pointing out this bug in Decomb. :)

It seems Telecide does not like to see a height that is not even. It is an easy fix and I'll very soon release a fixed version. Until then, just crop it to height 476 instead of 477.

Please forgive this inexcusable lapse on my part. :)

[jarthel]

thanks Donald :)

Since I haven't read the reply before I ran first pass last night, I put the IVTC lines after resize. It seems to work. Should I rerun first pass with the correct even height and IVTC lines before resize?

Thanks

[Guest]

You should never resize vertically before doing IVTC or deinterlacing. Your final result will be much poorer than it could be.

[Guest]

I've released a new version. Version 3.5 fixes a bug that caused a spurious bottom line in Telecide's output when the height of the input clip is odd. This version also has a further improved field matching algorithm that now succeeds on several "torture" clips that it previously failed on.

[meleth]

@neuron, Have you had time to test that blending thing we talked about a week ago?

[Guest]

Not yet, sir. Soon!

[Guest]

Sorry for the new release so soon, but I work fast. :)

Several people have asked for the deinterlacing threshold to be exposed in the user interface, so this new version does that. Please see the help file for details. Get the new version from the web site in my signature below.

[OUTPinged_]

DG, you da man!

now there is only motion map denoising left. =)

[Blight]

Nah... now it's time to integrate decimate into telecide so you'd save around "30*Height*Width*16bit/Second" of frame-buffer copies and speed things along further.

[Guest]

As you know, Decomb 3.6 and before used only blind field matching, and did not consider any prevailing patterns. However, as IVTC4 showed, the field matching can be guided by consideration of the prevailing pattern. Since the author of IVTC4 has chosen not to release his source code, I invented my own implementation of this useful idea.

The idea is that Decomb still uses blind matching unless instructed to use pattern guidance. That means it can still be used for PAL and other pathological telecines. But if your material is known to be NTSC 3:2 pulldown, you can set guide32=true and the prevailing pattern will be used to guide the matching. This means that a predicted match can overrule a calculated match, if the discrepancy is not above a configurable threshold (thresh32). If the discrepancy exceeds the threshold, the pattern is reset.

This feature can make field matching more accurate for some clips. It successfully eliminates the last bad matches that I had in my torture test clip, and should be a useful enhancement for processing NTSC 3:2 pulldown material.

Please get the new version at http://sauron.mordor.net/dgraft/decomb37.zip

[daxab]

I wondered when you were going to come over to the dark side ;)...

[Guest]

Nice sense of humor, Daxab!

I couldn't get rid of the last few field match failures with blind matching, which I suppose is not surprising. The tweaking came to an end and there were those pesky few frames, laughing at me. Your efforts convinced me that a hybrid approach was valuable, and when I realized that I could add it without abandoning the blind mode for PAL and pathological telecines, well, there was no way to avoid it. I'll still be curious one day to see your implementation, as there are still a few interesting issues. For example, I wait until I see 5 successive frames with a good pattern before I allow overrides. But maybe it is better to try to sync up earlier. I'm conducting experiments on this right now. Another example: how to support random access efficiently.

Congratulations on conceiving this useful idea. Thank you for the inspiration and I'm happy to credit the hybrid approach to you.

[Guest]

Thought I'd report my results encoding episodes of the anime Lain using the blend methodology suggested by Blight. These episodes have a lot of 30fps content mixed with 24fps content. Here is the script I used:

LoadPlugin "decomb.dll")
LoadPlugin("mpeg2dec.dll")
mpeg2source("Lain.d2v")
Crop(8,0,704,480)
Telecide(chroma=true,dthreshold=13)
Decimate(mode=1,threshold=25)

The result is highly satisfactory! I've watched several episodes at normal speed and never noticed any of the blends.

[Blight]

Does enabling pattern matching slows down decomb? If so, by how much?

[Guest]

@Blight

The amount of extra processing is insignificant. I doubt whether you could measure it. BTW, I am about to release pattern guidance for PAL.

[Blight]

Actually, in PAL, pattern guidence should work backwards.

It should try pattern guidence first and if it fails switch to blind matching.

The thing with PAL is, that if your video is phase shifted, it's usually phase shifted in the same order till a scene change (or in case of most movies, commercial break), so it's faster to do pattern match.

[Guest]

I've released Decomb 3.8 to my web site. It adds pattern guidance for PAL. Also note that the syntax for the guide options has changed. Please refer to the help file for details.

As Decomb is now mature, I don't have any plans for new releases unless bugs are found. I plan now to port some VirtualDub filters to Avisynth. I was thinking to start with Hue/Saturation/Intensity. Any other suggestions before I get started?

@Blight

There isn't really any "backwards", because you have to do the full matching on every frame to detect pattern changes. It would be faster to do *only* pattern-predicted recovery, but then you wouldn't be able to detect pattern changes.

[Roginator]

I vote "yes!" on porting hue, saturation and intensity to avisynth.

[Dali Lama]

The Hue/Saturation/Intensity filter is a good idea to port :)

hmm...

I think in order of a lot ot people's importance (including mine):

1. 2D Cleaner Optimized
2. Warp Sharp
3. Smart Smoother Hi Quality
4. Levels

Those are pretty important ones I think, except for levels though, but that is useful in some anime encodes to help 2D Cleaner "clean" the dark areas.

Thanks for your work and I tested the latest version of Decomb with the pattern matching. It works on that anime clip that it didn't do so well before.

Bye,

Dali

[Blight]

There already is a levels filter...

I vote for WarpSharp, a native YUY2 version should speed things up.

[DDogg]

Well in the "for what it is worth" category:

The one thing nearly all users of AviSynth have in common is compression. We have filters like TS that help via adjacent frame random noise reduction, but I wonder if a filter with a fuller holistic approach towards maximizing "compressability" without distortion might pay big dividends to the creator and this community? Perhaps there is nothing more that can done? I only bring this up because, to my knowledge, nobody has ever addressed this subject directly with a concerted effort.

DD

[Blight]

Actually, the codec writers themselves apply pre-filtering, and I'm not talking about the DivX5 stuff.

For Example, try encoding a non-anti-aliased text and encode that, you'll see that it's slightly blurred. All encoders (be it MPEG1/2/4) seem to do some sort of FIR filter to knock-out the high frequency ranges which make it harder to compress video.

It's not really anti-noise, but they all seem to do it to some degree.

[DDogg]

Blight, you know I have never been bashful about saying I am just an advanced tool user and not much on theory like you guys. I am always cheerful to admit I may be full of beans :), but:

For conversation purposes let's take the two extremes of bicubic 0.00,0.75 and something like bilinear with TS 2,1. Of course the latter produces a softened, and many would say distorted, image but the ability to compress is drastically better.

So, my thinking is a filter designed to resize with some type of integral specialized noise reduction targeted toward maximizing compression with the least amount of distortion could, perhaps, do a better job [and faster] than the individual bits and pieces we have now.

Does that make any sense to you guys? If it were possible, it would make a very large impact on both the Mpeg and the Divx community.

Edit: Actually DG was talking about converting existing filters to AviSynth so I guess I am way off topic the off topic with the suggestion of a new filter. If so I apoligize.

[Mentar]

I wanted to strongly second what DDogg wrote. What I'm always looking for is a filter which is created in order to remove noise and mpeg artifacts out of an imperfect source in order to achieve optimal compressability. Especially for encoding of anime this would be the perfect too. Decomb was a massive improvement in this area (my biggest kudos to Donald :D), this would be the biggest entry on my wish list.

I'm aware that I'm dreaming into the blue here - noise reduction, artifact reduction, and please keep the picture from blurring out too much ... sounds like the uber-filter.

Well, one can dream ...

[Blight]

ddogg:
I don't think there's a point.

When you scale, you sub-sample pixels, which blurs. The way bicubic scaling looks better is because it actually sharpens, and sharpen image has higher frequencies which are harder to compress.

The more the image is soft/blurred, the easier it is to compress as there are less high frequencies. But that's less pleasing to the eye.

There's no way you can make a sharp image that compress well.

If you're talking noise reduction, there are plenty of available filters, if you run them prior to scaling, you get a little less blurring than running them after scaling, but that's pretty much it.

[Mentar]

Blight: I see your point, but I respectfully disagree. There are tons of sources who are very sharp and still compress well. Unfortunately, running current smoothing filters over mediocre sources with noise and small artifacts tends to blur the picture much more than it's good for the picture.

So my dream would be to have some kind of "smart" noise/artifact filter which identifies areas with very sharp contrasts (for example lines in anime) and only smooths the contents within the areas encompassed by these lines, while keeping the lines fully intact. Most of these areas are either single-coloured or have a very slow progression, so it should be possible to identify noise and artifacts by having just very few pixels out of "base colour", and those are usually bound to "blink" on the time axis too.

So some kind of hybrid of normal smoother which also checks suspected noise on the time axis would be the dream of all anime fans. Like a blend of SmoothHIQ and Temporal Smoother.

Dreaming again :D

[Blight]

There already is a noise cleaner that is perfect for anime and pretty much does what you describe. There's a link to in on graft's page, don't recall it's exact name.

It's for virtualdub though.

[DDogg]

When you scale, you sub-sample pixels, which blurs. The way bicubic scaling looks better is because it actually sharpens, and sharpen image has higher frequencies which are harder to compress.
Yes, of course. Even I know that :)
The more the image is soft/blurred, the easier it is to compress as there are less high frequencies. But that's less pleasing to the eye.
Again
There's no way you can make a sharp image that compress well. Hmmm...Isn't that out of context? Certainly a sharp image with more of the adjacent frame, random, small radius noise reduced will compress better than without..which leads to:
If you're talking noise reduction, there are plenty of available filters, if you run them prior to scaling, you get a little less blurring than running them after scaling, but that's pretty much it.

So, I think you are saying a couple of things here. Tell me if I got it right. One is you feel there can be no further reduction in adjacent frame random noise over what is available now [that is non-destructive to image quality].

Second, you do not feel an approach combining some type of specialized noise reduction and resizing into one hybrid approach would make much of a difference in compression ability or speed. In other words, are you are saying you don't feel it would be worth the time and effort as the results would not be much, if any, better than what we have now?

Well maybe. Not for me to know as I can't do it, but it just made sense to me that a combination of these elements done together "in process" would be better than done separately.

[Blight]

I think someone could come up with a better noise reduction code, who knows what the future stores. I just don't think that the image scaling will factor into it.

[trbarry]

Someone (not me) should come up with an Avisynth version of Lindsey Dubb's new DScaler Adaptive Noise filter. Or talk him into it.

It's been getting pretty good reviews over on AVS.

- Tom

[DDogg]

I motion we all volunteer Tom to talk with Highspeed, do I hear a second? :)

[High Speed Dubb]

I&rsquo;ll probably wait on an AVISynth port until summer. Odds are, a conversion of the Gradual Noise filter won&rsquo;t be too difficult &mdash; Adaptive Noise is a different matter.

Hmm... Tom -- do you think a generic &ldquo;Run this DScaler filter&rdquo; AVISynth filter would be possible? That might make more sense than porting each one.

Heck if I know how these noise filters will affect compression. Both my noise filters (purposefully) preserve a small amount of noise, which might well increase the compressed size.

I do think there is something to be gained by a joint spatial/temporal noise filter. That should be more efficient (i.e., a better use of the data) than doing both separately.

[Roginator]

If you are brainstorming a filter for animes, how about this idea...

Write a filter that first analyzes the anime. It is allowed to use the colors black, white and "n" other user-specified colors, but no more. How many colors could animators use anyway? (assuming they aren't using blends). You would simply tell the filter to assume up to "n" colors. During the analysis phase it would select the "n" most likely distinct colors.

Let's assume the animators used 12 colors plus black and white. The filter would then examine each pixel and determine which of those 14 was the closest match. You would get perfectly solid colors and lines. If a pixel of noise was surrounded by 8 pixels of another color, it should be easy to assume that pixel should also be the same color as the 8 surrounding ones.

Maybe this is too simplistic.

[High Speed Dubb]

@Roginator

That&rsquo;s a good idea for any animation which uses only a small number of unshaded colors.

Here&rsquo;s a formal description of the method

Given a set S of colors (described as a Y, U, V triplet), each s_i in S with frequency F_i, the noise variance, and (incorrectly) assuming independence among pixels, the likelihood of the s_i, F_i is

Probability(Movie data | s_i's, F_i's, noise variance)
=
Product over all pixels of
Sum over states s_i in S of
F_i*Probability(Color at that pixel | s_i, noise variance)

With that equation, you can evaluate the likelihood for each set of parameters{s_i's, F_i's, variance}, choose the s_i, F_i, and noise variance which maximize the likelihood, and at each pixel choose the color which contributes the most to the likelihood.

Problem is, that&rsquo;s an enormous search space. You could make the math easier by using a 2^16 bucket lookup table of color frequencies, but it&rsquo;s still a big space. You could probably handle the search with importance sampling, but that isn&rsquo;t simple stuff.

There&rsquo;s also the issue of adding and removing members from S. There are ways to deal with that, though.

Maybe there&rsquo;s some good clustering heuristic for this. But it definitely qualifies as a difficult problem.

If you&rsquo;re willing to require careful user input, you could have the user manually input the color set. That would make the search much easier.

[Edited to correct the optimization method description]

[DDogg]

I guess Tom works fast. ;)
I do think there is something to be gained by a joint spatial/temporal noise filter. That should be more efficient (i.e., a better use of the data) than doing both separately.
Do you think there could be any benefit adding resizing into the process? I guess I am saying in layman's terms, "Would knowing where you are coming from and where you are going, size wise, be an additional slice of data that could be used to assist the efficiency of the process or the speed of the process of a joint spatial/temporal noise filter?". Gee, that's a mouthful :)

[High Speed Dubb]

Any process which is really sensitive to noise would potentially gain from being run jointly with noise reduction. To me, that means pulldown detection, noise reduction, and probably deinterlacing would optimally be handled together. The advantage here would be that uncertainty in the noise estimate could be used to inform pulldown and deinterlacing decisions.

In other words, the noise reduction could produce the result &ldquo;I&rsquo;m almost certain this brightness value is 23&rdquo; or it could determine &ldquo;My wild guess of the brightness value is 23.&rdquo; Those are very different statements, and a clever pulldown or deinterlacing routine could take advantage of that.

So yes, a scaler could benefit in a similar way. Simple scalers like bicubic interpolation don&rsquo;t change depending on the uncertainty of the data. But you could design a scaler which did. My hunch, though, is that the payoff wouldn&rsquo;t be that great.

There is a lot to be said for keeping the steps separate, even when a joint approach would be a better use of the data. (When I said &ldquo;efficient,&rdquo; I only meant it in the statistical &ldquo;best use of the data&rdquo; sense.) Separate steps are much easier to deal with as a programmer, and will tend to give script writers more flexibility.

[Dali Lama]

I'm just a little confused about Tom's statement, "Someone (not me) should come up with an Avisynth version of Lindsey Dubb's new DScaler Adaptive Noise filter."

Where can I download this new filter. I have never heard of it before. Is it a type of spatial filter, or temporal filter, or static noise reduction filter?

Thanks,

Dali

[High Speed Dubb]

It&rsquo;s a temporal noise reduction filter.

(What do you mean by static noise reduction? &mdash; &ldquo;static&rdquo; has two possible meanings in this context.)

[High Speed Dubb]

@Dali Lama

I forgot to answer the other half of your question...

It&rsquo;s a filter for the DScaler real time video processing program. So it won&rsquo;t run in AVISynth scripts. A version for DScaler 3.1 is at

http://students.washington.edu/ldubb/computer/Noise_filters.zip

[Lord Sandwich]

I've been having trouble getting perfectly decimated output from a 3:2 pulldown source (specifically, Transformers The Movie). The animation jerks and stutters in a number of scenes, but only when the entire movie is processed. When I trim the footage down to the specific scene before using Decomb, things seem to work fine.

So anyway, I was thinking about this scenario:

ABBCD, ABBC; AABCD, AABCD

This is a Telecided NTSC source, and the semicolon marks a scene change as well as a pattern change. As I understand it, Decimate only searches for duplicates within groups of x frames, as specified by the user. But in this case it means that the third group onwards contains no duplicate frames, because Decimate(5) would process it as:

ABBCD, ABBC|A, ABCD|A, ABCD|A ... and so on.

Thus, Decimate is forced to remove non-duplicate frames, and the animation ends up stuttering until the next pattern change.

Perhaps a solution to this would be some sort of "look-ahead" option, where the fifth frame in one group is compared with the first frame in the next group? That way it can reset the groupings if the two frames are a match.

This make any sense at all? I'm fairly new to this theoretical stuff. :D

[Krajensky]

Using that nearest-to-lookup filter on any sort of anime will result in serious aliasing - the black lines aren't perfectly black, especially if a resize has come before this filter in the script.

There is bound to be some sort of blurring/antialiasing applied beforehand...do we really need to get rid of that?

Krajensky

[trbarry]

Hmm... Tom -- do you think a generic “Run this DScaler filter” AVISynth filter would be possible? That might make more sense than porting each one.

That might make a whole lot of sense if there was interest in the other DScaler filters. That is basically what I did for the first version of GreedyHMA, before I added full IVTC into it.

GreedyHMA already contains much of the needed code but DScaler is in the process of changing calling architectures for DScaler R4.0 (to be much more like Avisynth). If this were done it should probably be done with the R4 version in mind but the current version of GreedyHMA out there in the zip still assumes R3.1 calling conventions.

I'm not at all an expert on DScaler filters, I've mostly stuck to deinterlacing. And right now I'm seriously considering trying my hand at some XviD assembly optimization for XviD playback instead, for my HDTV stuff.

Neuron2? You've become pretty much an expert in this area. Any interest? ;)

- Tom

[Nic]

Tom,

I was just going to come looking for you about helping with XviD assembly and I find this.... :)

Cheers,
-Nic

[Divine]

I plan now to port some VirtualDub filters to Avisynth. I was thinking to start with Hue/Saturation/Intensity. Any other suggestions before I get started?


A port of the logo filter would be nice :)

[Divine]

I've tried the filter for some interlaced pal stuff which i have captured from tv/vhs source.
But i cannot seem to get a perfect result out of it.
I have tried Telecide() , which had stuttering left. After that i have tried Telecide(guide=2). That was alot better, but i still noticed some little stuttering.
Ofcourse the stuttering ain't in the original source and i had no frame drops.

Settings:

720x576 @ YUVY uncompressed.

Script:

#LoadPlugin("MPEG2DEC.dll")
Loadplugin("Decomb.dll")
SegmentedAVISource("d:\test\capture.avi")
ConverttoYUY2
Telecide(guide=2)
#TemporalSmoother(2)

Anything i am doing wrong? Or can't decomb handle my stream :)

---
edit:

Well i'm using FieldDeinterlace(blend=false) now, seems to work fine.

[High Speed Dubb]

@Krajensky

Yeah, that&rsquo;s a very good point. Worse yet, some pixels in an antialiased area might be falsely interpreted as one of the image&rsquo;s other colors.

[Guest]

@Divine

Of course, use Telecide() only on progressive (film) material. It is likely that your material is pure interlaced PAL video if Telecide() gives poor results but FieldDeinterlace() works well.

[Brougs78]

Hi!

I've read most of the replies in this topic, but I am not sure how to solve my problem.
I live in 'PAL-Land' :D and I'm a big Seinfeld-Fan so I record mostly every episode. But I've problems to encode it in a proper quality. It seems that the 24fps from the original are telecided up to 30fps and than blended down to 25fps. I tried to use the decomb filter with and without dropping frames. In the first case the filter works very well (according to the high quality of every single frame), but the duplicates result into stutter. The latter with decimate(5) also stutters. It is somehow logical, because I think the only way to handle this kind of movies (to get the 24fps) would be the reconstruction of 30fps and then IVTCing, or am I wrong about this?

So my question now: Do I get the best out of it, if I only use FieldDeinterlace() like you (@ neuron2) suggested Divine? Or is there an other way?

cu,
Brougs78

[daxab]

@Brougs78

That's funny, I'm currently testing with Seinfeld episodes. And I can tell you, they're a mess. I'm in North America so I'm getting 24fps telecines to 30fps. They've done edits after telecining. I wish they wouldn't do that. (I think they produce a film master, telecine it to 30fps on video, and then broadcast that. Later, in syndication, they edit the video to trim out 5 seconds here, 5 seconds there, etc., so they can squeeze in yet another 30 second commercial spot. That's my guess, at least.)

I don't even want to think about working with the 25fps version.

[srwalker]

Brougs78: It sounds like those Seinfeld conversions were done with the same method as the Widescreen Buffy S5 episodes the BBC are broadcasting.
There is no way to undo this. Even if you separate the fields you will find ghosting on moving objects where blending has occurred. Stuttering is another side effect of the conversion.

[Krajensky]

@srwalker:

Could you post about 10 consecutive framegrabs (as jpegs) of this "ghosting" where it is most prominent in the clip (either to a website or to my email account krajensky@myrealbox.com ) I have a scheme that is still in its infant stages that might be able to help, if it still has full frames every once and a while.

Krajensky

[srwalker]

Originally posted by Krajensky
@srwalker:

Could you post about 10 consecutive framegrabs (as jpegs) of this "ghosting" where it is most prominent in the clip (either to a website or to my email account krajensky@myrealbox.com ) I have a scheme that is still in its infant stages that might be able to help, if it still has full frames every once and a while.

Krajensky

I'll upload to some webspace as soon as I can, but I can't connect to the FTP at the moment.

[High Speed Dubb]

It struck me that Roginator&rsquo;s color reduction idea is algorithmically really similar to the selection of an adaptive palette. The good news is that lots of work has been done on this &mdash; The bad news is that it&rsquo;s NP-Hard. That means an optimal solution in a useful amount of time is right out. A good enough approximate solution might be possible, though.

Here&rsquo;s an alternative idea for cartoons &mdash; Try to identify flat regions. Something similar to Photoshop&rsquo;s magic wand tool (with a threshold chosen based on the noise level) might do the trick.

[edited for typos]

[srwalker]

ftp is fixed, so here is a sequence of frames saved as jpgs.

http://website.lineone.net/~angelcuts/doom9/

There's a zipfile of all the frames at the top. Total 35 frames, 1.3Mb

Watch Buffy as she crosses the frame. The PAL conversion has been done by blending fields from the NTSC, instead of speeding up a film source or IVTC & Speedup of the NTSC. The artefacts this process produces I think are not removable

Stephen

[kramerdog]

I've been converting TV caps to SVCD for a while now. I've experimented with all the IVTC filters. IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've had excellent results with ...

Telecide(guide=1,gthresh=85)

This seems like an extremly high threshold, but lower values allowed combed frames to sneek through. Closer examination reveiled that the pattern had not changed, but decomb thought that frame was not interlaced, when indeed it was. Setting the gthresh high fixed it. It now looks great.

I know you are always looking for ways to improve decomb, and this isn't really a problem, but I thought you might want to see why the "normal" telecide wasn't working as well.

Its a very nosiy clip and that may be what's throwing it off. Would you like me to send a clip?

Thanks again for all the great software you've developed.

[droolian01]

@srwalker and krajensky

I have noticed this field blending on my '24' caps off bbc2 too. I think it will be impossible to do an 'inverse telecine' of whatever it would be called on this stuff. Seems to me that legitimate telecine/ivtc involve duplicating/discarding fields, the second one is blended then that process is irreversible as data is lost. I had strange ideas of doing a pal to ntsc convertion, then doing an ivtc but if the fields are blended the original progressive film is lost. All you can do is de-comb (or any other equivalent thing), so i agrre with srwalker and think krajensky will only create another de-comb method if he is succesful.

Only just started doing this stuff, and just got sky1 added to my cable package too. I did a cap of buffy 'double meat palace' and although only 4:3 (and has anoying advderts to edit - i love the beeb!) i did notice that there is no field blending, so telecide() should work like a dream when i get around to doing it. Now - does the beeb get the same source as sky, because if it does the beeb will be starting season 6 soon - widescreen and no field blends - could it be true!?

[daxab]

@kramerdog

IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've been working on an new plugin that outperforms IVTC4 on TV caps. Everyone seems pretty happy with what's out there, so I'm taking my time. Also I get the impression that few people do TV caps and many do anime, and I'm not happy with the anime performance yet.

[Divine]

Originally posted by kramerdog
I've been converting TV caps to SVCD for a while now. I've experimented with all the IVTC filters. IVTC4 did a good job, but I came back to decomb after you implemented the guide feature.

I've had excellent results with ...

Telecide(guide=1,gthresh=85)

This seems like an extremly high threshold, but lower values allowed combed frames to sneek through. Closer examination reveiled that the pattern had not changed, but decomb thought that frame was not interlaced, when indeed it was. Setting the gthresh high fixed it. It now looks great.




I have simular problems with decomb and my TV/VHS captures. (they're quite noisy as well)
The IVTC of the video part goes well, but decomb seems to have problems with overlay logo's/text or simular.
I get 'jumpy frames' around some still-TXT or still-LOGOS.
I also have had some sources with moving logos, (they move in a certain range/direction all the time) and they stayed interlaced after ivtc'ing with decomb. (everything else(the video) processed fine, except that logo)

Now you would think these logos have been overlayed after the telecine (23>29) progress, but i don't think thats the case.
Because when i run the source through tmpeg (and then eventually an area based deinterlacer) everything 'seems' fine. There are no jumpy frames or whatsover.

Unfortunately i won't be able to upload any sample.. as i am on a very slow modem connection atm :( (lost my cable connection weeks ago)

[manono]

Hi Divine-

neuron2 is on Sabbatical for awhile, so he won't be able to help. I've never done a vid cap in my life, so I may not be able to help. However, neuron2 added a feature to Decomb recently, designed for your problem. This may help with some, if not all of the problems you describe. Anyway, this is a quote from the Help File included with Decomb:

y0 and y1 (integer, default 0) define an exclusion band for the field matching. If y0 is not equal to y1 this feature is enabled. Rows in the image between lines y0 and y1 (inclusive) are excluded from consideration when the field matching is decided. This feature is typically used to ignore subtitling, which might otherwise throw off the matching. y0 and y1 must both be positive integers and y0 must be less than or equal to y1; if this is violated an exception will be thrown.

And I'm sure there are others that have dealt with this problem first hand and may be able to offer some advice.

[h00z]

I can't thank you enough for making Decomb. I tried it on my own Cowboy Bebop rips and I have to say that it is the nicest rip that I have ever done of the series. Kudos man... I can't wait to see where this ends-up if it's this good already.

[Divine]

Thanks for your reply manono.
I have already played around with these y0 & y1 integers before, but it didn't seem to help in my case :(

[wmansir]

I hate to dig up such an old thread, but I just have one decomb question simple unworthy of it's own thread, and it's on the topic that this thread ended on.

Do the y0 and y1 values start at the top of the frame or the bottom? So is y0=0 (or 1) refer to the top line or the bottom line?

I'm encoding "Ran" and it has hard coded, interlaced subtitles on the bottom 100 lines, as an example could someone give me the y0 and y1 values to exclude this section of the frame?

[Guest]

Hmmm, maybe that's why it didn't work for Divine. :)

I just checked the code and I don't subtract the values from the frame height. Since I believe y=0 is the bottom line, that would mean it is referred to the bottom. Ooops. I'll double check this on my test files tonight and post again. Meanwhile, can you try an experiment and let me know? Try y0=0,y1=100. If it works, I'll probably just revise the help manual to say it is referred to the bottom. :p

[wmansir]

I haven't tried encoding the movie yet. I noticed the interlaced subs while preparing the source and remembered this feature of decomb, but was unclear how to configure it. However, after some searching I did find a few frames that were incorrectly pulled down because of the interlaced subs and y0=0, y1=100 gave the correct pulldown.

However, just to be sure I tried y0=380,y1=479 and it also gave the correct pulldown on the problem frames I encountered. I checked the results several times, because I don't understand why both settings would work. If anything I would expect the incorrect settings to make a bad pulldown more likely. Here are the instructions I used :

Telecide(post=false)

Telecide(post=false,y0=0,y1=100)

Telecide(post=false,y0=380,y1=479)

All were followed by:
Decimate(cycle=5)

I usually use 3.8, but I also tried these settings with 3.91, with identical results.

[Guest]

Stranger and stranger! :eek:

Can you make available the part of the source clip that shows this? Thank you.

[wmansir]

You've got PM.

I'm still trying to upload the file to the address provided. I'll send you another PM when it's available.

However, I was surprised at the speed hit from using exclusion, not that I would expect you to optimize for a very infrequently used option like this. I normally get 0.5 to 0.6 RT in CCE with Decomb, but using y0 I'm got 0.23 RT.

I think instead of using the y0 option I will process the sections seperately (since my subs are on a black boarder and do not overlay the video) and then stack vertical. Like this:

top=Crop(0,0,720,380).Telecide(guide=1).Decimate(cycle=5)
bottom=Crop(0,380,720,100).FieldDeinterlace().Decimate(cycle=5)
stackvertical(top,bottom)

With this method I get 0.20 RT, but I don't have to worry about the subtitles triggering unnecessary postproccessing on the video.

[Guest]

Please do get me the clip, as I'd like to get this capability working properly, even if you do have a workaround. Thank you.

[Guest]

@wmansir

Please try this test version and let me know how it works. The numbers are referenced to the bottom.

[wmansir]

Did you get the ran clip from my PM?

Using the examples from that clip, it seems you have worked out whatever bug was causing y0 and y380 to give the same results. However, it appears that y=0 is the top line.

Example 1, y0=0,y1=100, version 4.01
http://www.imgmag.com/images/wmansir/Ran_4_Y0_401.jpg

Example 1, y0=0,y1=100, version 4.02
http://www.imgmag.com/images/wmansir/Ran_4_Y0_402.jpg

Example 1, y0=380,y1=480, version 4.01
http://www.imgmag.com/images/wmansir/Ran_4_Y380_401.jpg

Example 1, y0=380,y1=480, version 4.02
http://www.imgmag.com/images/wmansir/Ran_4_Y380_402.jpg

Example 2, y0=0,y1=100, version 4.01
http://www.imgmag.com/images/wmansir/Ran_14_Y0_401.jpg

Example 2, y0=0,y1=100, version 4.02
http://www.imgmag.com/images/wmansir/Ran_14_Y0_402.jpg

Example 2, y0=380,y1=480, version 4.01
http://www.imgmag.com/images/wmansir/Ran_14_Y380_401.jpg

Example 2, y0=380,y1=480, version 4.02
http://www.imgmag.com/images/wmansir/Ran_14_Y380_402.jpg

I had hoped to put those images inline, but it doesn't matter. If you check them out you will see that for each example of the four versions only y0=0,y1=100 version 4.02 gives bad results. The other three are exactly the same, even the p,c,n numbers.

[Guest]

The clip I downloaded was corrupt for some reason.

Thank you for the results. I'll investigate the numbering issue more but it appears to be working now, no?

[wmansir]

Yes, it appears to be working fine, with y0=0 referencing the top line.

I just dowloaded the clip again and it seems to work fine for me. If it's a RAR problem, it may be because they are 3.0 rars and need Winrar 3.0 or higher to open. The clip uses the Huffyuv 0.2.2 codec available from doom's downloads.

But anyway, thank you for your help.

[reddragon72]

does this work with cce2.5? I cannot get it to load if it does. I have tried several ways and nothing. I don't have enough drive space to create big AVI files so I was triing to frame serve into CCE like I do with avisyth normally, but when I add the lines for this it crashes CCE.

LoadPlugin("c:\windows\system32\mpeg2dec.dll")
LoadPlugin("C:\Program Files\AviSynth2\plugins\Decomblegacy.dll")
mpeg2source("D:\dvdeditedvideo\dvdxcopy\van\van.d2v")
#AVISource("D:\dvdeditedvideo\dvdxcopy\van\van_d2v-vfapi.avi")
#ResampleAudio(44100)
Telecide
Decimate15


thanks for any help.

[scmccarthy]

Why do you have lines that are commented out? Also, trust me, you should always use parenthesis, even when they are empty.

Stephen

[lark]

i agree with the parenthesis.
most probably the avisource is commented out,
because there's already mpeg2source.

don't ask me about the resampleaudio.

regards
t :)

[manono]

Hi-

Before plugging your scripts into CCE and having them crash, you should probably open them first in VDub for testing. Then when they crash (as yours certainly will), at least you'll get an error message to point you in the right direction for fixing them. So, what is this:

Telecide
Decimate15 ? Do you really mean to say:

Telecide()
Decimate(5) ?

[hakko504]

AFAIK you need to uncomment the Resampleaudio line to make CCE accept the .avs

[Guest]

Originally posted by manono
Telecide
Decimate15 ? Do you really mean to say:

Telecide()
Decimate(5) ? He must have grabbed a REALLY OLD beta from that old thread.