How to simulate VirtualDub's "Blend Fields"?

[Trixter]

I know this is so simple I'm going to smack myself as soon as I see the answer, but for now I'm drawing a blank: What's the script sequence to perform the equivalent of VirtualDub's Filter->Deinterlaced->"Blend Fields"?

[Guest]

Here's one possibility:

FieldDeinterlace(blend=true)

[Trixter]

That's it, thanks! But I don't feel stupid for asking, since I double-checked my avisynth 2.5 docs and there is no mention of FieldDeinterlace().

[Wilbert]

Get the Decomb plugin: http://neuron2.net/decomb/decombnew.html

[IanB]

Blur(0, 1) # Vertical onlyBut why, there are many comb detecting/motion detecting deinterlacers that will give far superior results.

[Guest]

That's why I suggested FieldDeinterlace(). It at least limits the blur to combed areas.

[Trixter]

Blur(0, 1) # Vertical onlyBut why, there are many comb detecting/motion detecting deinterlacers that will give far superior results.

Because my target is 320x240 MPEG-4 and I wanted "free" denoising.

[Guest]

Because my target is 320x240 MPEG-4 and I wanted "free" denoising. Then you don't need a deinterlacer at all!

And that might be free, but it's a very poor denoising approach.

[Trixter]

I'm losing vertical resolution during the resize, so why is field blending (where EVERY field is blended, not just where there's combing) a bad idea? I also lose some aliasing on high-contrast edges by doing it before the resize (whereas if I just discard one field to get down to 240 lines, the top edges of rounded title graphics are jagged).

If your source was 30i, 480 lines (and it really is 30i, it's a live sporting event from broadcast television) and your output target is 240 lines, then what would you do? How would you handle it with minimum impact on processing time?

[foxyshadis]

With as much bitrate as you want, I think that's actually a pretty good way of doing it. You maintain the illusion of motion fluidity as well, which can be important in sporting events. If I had unlimited time and limited bitrate, I'd smart bob+mvflowblur. If I had too-limited both, I'd use leakkerneldeint and pick less-fluid motion over masses of blocks everywhere.

[Mug Funky]

hmm. you could always just go straight for the resize and not bother deinterlacing. any resizer (except point) will give you the same effect as blend deinterlacing if you're downsampling to half height.

[Guest]

Exactly. That's what I was saying. It's still a pretty poor denoiser, though.

[Trixter]

Mug: Ah, I see your point. Yes, a 2x height reduction would probably have given me the same result.

Neuron2: I think "poor" is subjective. For example, the noise reduction it offers, however slight and minimal, is constant (ie. there are no sudden losses of detail, or trails, or anything else that usually happens with typical adaptive denoisers). Just so you think me sane, I did in fact try the long route (mvbob->degrainmedian and/or fft3dfilter) and I lost subtle detail that I retained using the "dumb" route... in addition to taking 20x as long to process.

Sometimes less is more. I wanted consistency of picture in the time domain with minimal processing, so that's what I got.

[Guest]

I did in fact try the long route (mvbob->degrainmedian and/or fft3dfilter Straw men.

[Trixter]

Straw men.

I don't understand what you mean...?

[Trixter]

Okay, I looked up the phrase "straw men". I'll ignore the implications and ask for constructive criticism again: If your source was 30i, 480 lines (and it really is 30i, it's a live sporting event from broadcast television) and your output target is 240 lines, then what would you do? How would you denoise over-the-air broadcast with minimum impact on processing time? Surely there's some way the output size can be used for some advantage or opportunity...

[Guest]

I'd need to see the unprocessed source material to assess the type of noise before making a recommendation.

BTW, I wasn't making any implications.

[Trixter]

Here is a sample:

http://www.badongo.com/vid/261671

While not the exact stuff I was using, it is representative of what I had to deal with: 352x480 input, already MPEG-2 encoded (this is not my conversion, but rather how I get the video off of the device I'm working with), 30i (60 discrete images per second). As for the footage itself, it is also representative of what I was working with: Fast motion of a sporting event, intercut with graphic titles and a few "talking heads" sequences (where you can most easily see the noise).

Deblocking is a given; my only concern was the inherent noise present in the broadcast signal (exaserbated by the MPEG-2 encode, I'm sure). So, any suggestions for cleaning stuff like this up for eventual re-encode to MPEG-2?

[Guest]

While not the exact stuff I was using Why not?

[Trixter]

Because what I was working with isn't ready for public consumption yet. But the sample clip I provided is nearly identical in both technical format and content type, so I'm still interested in hearing opinions...