New IVTC for Avisynth

[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’ve got interference. Usually the chroma variance is lower, but the chroma signal is also less. In general you’re better off using both chroma and luma, since both contain useful information.

For the most part, the brightness of the scene doesn’t matter — I’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’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 — 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. =)