DVR Resizing Errors / Rainbows / Aliasing

[koopa]

I have a DVR setup that is meant to be capable or rendering fullly independent 704x576 pixels (in good light, with no motion), but is actually falling far short of that, with many video distortions.

http://www.2shared.com/file/6345303/97bdc1a2/sample.html

The worst thing is that the inputs off this DV cam are completely clean, but when it comes in and out of the DVR box, it gets all aliased and rainbowy.

Two questions:
1) What is a good script to de-antialias this vid, and
2) What causes this error, is it the worlds worst resize?

This is my best attempt to fix it so far:

**********************************************
LoadVirtualDubPlugin("C:\1Drv\VirtualDub-1.7.8\plugins\msu_smartdeblock.vdf","MSU_Smart_Deblocking", 0)
directshowsource("sample.avi")
converttoyv12()
spline36resize(352,288)
Bifrost(scenelumathresh=2,altclip=SSIQ(11,300,false),interlaced=false)
spline36resize(704,576)
source=directshowsource("sample.avi").converttoyv12()
MergeLuma(source, 1)
ConvertToRGB32.MSU_Smart_Deblocking(1, 1, 1, 1)
ConvertToYuy2()
saturation_v = 1.12
cv = - (1-saturation_v)*256
ColorYUV(gain_y=-26,cont_y=50,cont_v = cv, opt="coring" )
NNEDI().turnright().NNEDI().turnleft()
source=last
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
smooth = last
smooth.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
LimitedSharpenFaster(SMode=4,LMode=3,Strength=120,wide=true)

**********************************************

It uses Bifrost to de-rainbow, but because the rainbow effect is so bad, I separated the luminance and chrominance, decreased the resolution of the chrominance, then Bifrosted it, then spline36'd it back to the original res and replaced the colour of the original video. There has been some loss of colour resolution, but the tradeoff seems worth it.

I then fixed the colour/luminance levels, antialiased the whole thing with NNEDI (seemed much better than EEDI2), temporal denoised it, and sharpened it.

There has been some blurring of the colour, some oversharpening of contrasts and over-smoothing of flat surfaces, but otherwise it has cleaned up the video quite a lot.

Please suggest anything that would help further, or suggest what the hell did this to the footage of some nice DV cams!

Cheers

[thewebchat]

The URL you provided is invalid.

[Guest]

How are you connecting the DV cam to the DVR? If you are using composite video, then you are introducing the problem there. Why not capture the DV digitally to your PC and transcode there?

[10L23r]

link broken :D

replace the upsizing part with nnedi2. it should work much better than spline36 for upsizing.
it may help to use nnedi2 for the antialiasing part too..

[koopa]

Sorry guys, URL now fixed! Changed NNEDI to NNEDI2, and have taken out MVdegrain2 (lossy codec has taken out most of the noise anyway)

[koopa]

Oh, and yes Neuron2, I am using the composite output to connect the DV cam to the DVR (it is the only output). However, that same output looks nice when inputed to my laptop via an ADVC-300 box.

[Guest]

Oh, and yes Neuron2, I am using the composite output to connect the DV cam to the DVR (it is the only output). However, that same output looks nice when inputed to my laptop via an ADVC-300 box. The latter device may simply have a better comb filter.

Why don't you capture the DV digitally and transcode on your PC?

[koopa]

Oh, because this is ongoing surveillance on a bus, I don't plan on leaving my laptop with the general public! I was just using it for diagnostic purposes. But that's a good idea about the ADVC having a better comb filter, I will try bringing some other devices to capture the video to see if they fare any worse/better.

Current script looks like this:

LoadVirtualDubPlugin("C:\1Drv\VirtualDub-1.7.8\plugins\msu_smartdeblock.vdf","MSU_Smart_Deblocking", 0)
directshowsource("sample.avi")
converttoyv12()
spline36resize(352,288)
Bifrost(scenelumathresh=2,altclip=SSIQ(11,300,false),interlaced=false)
NNEDI2_rpow2(rfactor=2,qual=3)
source=directshowsource("sample.avi").converttoyv12()
MergeLuma(source, 1)
ConvertToRGB32.MSU_Smart_Deblocking(1, 1, 1, 1)
ConvertToYuy2()
saturation_v = 1.12
cv = - (1-saturation_v)*256
ColorYUV(gain_y=-26,cont_y=50,cont_v = cv, opt="coring" )
converttoyv12()
NNEDI2(qual=3).turnright().NNEDI2(qual=3).turnleft()

Any tips? Perhaps there's a smarter way to remove the rainbows without reducing the colour resolution by half, or loading the clip twice?

[Guest]

You should not have to load the clip twice. Why are you doing that?

[koopa]

I only wanted to reduce the resolution of the chroma, leaving the luma intact, but I couldn't find a routine to split them, so I just processed the whole clip, then reinserted the luma from an untouched source.

[Guest]

Use MergeChroma like this example:

# This will do a Spatial Smooth on the Chroma channel
# that will be mixed 50/50 with the original image.
mpeg2source("c:\apps\avisynth\main.d2v")
chromavid = SpatialSmoother(2,3)
MergeChroma(chromavid,0.5)

[Gavino]

I only wanted to reduce the resolution of the chroma, leaving the luma intact, but I couldn't find a routine to split them, so I just processed the whole clip, then reinserted the luma from an untouched source.
There's no need to load the clip again to get an 'untouched source' - just re-use the original. Instead of

source=directshowsource("sample.avi").converttoyv12()

just set source=last after the earlier converttoyv12().

[2Bdecided]

Your DVR is doing nothing wrong.

It's just taking a composite input, decoding the analogue composite video in a very normal way (giving rainbows), and then taking individual fields, interpolating them into full frames, and storing these.

The interpolation is simple line averaging, hence the jagged edges. You do still have the original lines from the original field though - just interspersed with interpolated lines.

As such, what you're doing with the resizing and NNEDI is wrong.

The correct, and very simple way, of taking a 704x576 image where every other line is interpolated, and keeping the original lines while doing a new smart interpolation to replace the original interpolation, is this:

nnedi(dh=false,field=0)

That's it! So just AVIsource, followed by that single NNEDI line, will give you full resolution. All that extra resizing you're doing, and especially resizing horizontally, is just making the quality far worse.

Hope this helps.

Cheers,
David.

P.S. - NNEDI2 if you like - I haven't had time to test it yet, but it seems better.

[koopa]

Man, that's just excellent, thanks guys.

Source=last, of course!

And the camera is feeding the DVR a 50 fields a second source that it is being written down at 6 line doubled frames a second, by taking one 352x576 field and doubling the horizontal lines and throwing away the rest of the data. Makes sense!

Current script:

LoadVirtualDubPlugin("C:\1Drv\VirtualDub-1.7.8\plugins\msu_smartdeblock.vdf","MSU_Smart_Deblocking", 0)
directshowsource("sample.avi")
converttoyv12()
source=last
Bifrost(scenelumathresh=2,altclip=SSIQ(11,300,false),interlaced=false)
ConvertToRGB32.MSU_Smart_Deblocking(1, 1, 1, 1)
ConvertToYuy2()
saturation_v = 1.08
cv = - (1-saturation_v)*256
ColorYUV(gain_y=-26,cont_y=50,cont_v = cv, opt="coring" )
converttoyv12()
nnedi2(qual=3,dh=false,field=0)
MCTemporalDenoise(settings="very low", flat=true, AGstr=12, temp=0, stabilize=true)

Adding just a little bit of wildly fluctuating fine grain suddenly fixed some of the plastic look the overcompressed footage had too, w00t!

The only think I'm wondering though is, why is it normal for the DVR box to give rainbows? Is there a technical article I can read (or the usual ezy-anime guide, heh) that explains why this happens mathematically?

Now I must work out a way to get whole progressive frames to my DVR box to double its resolution, and also histogram() reveals that its AGC leaves something to be desired banding-wise.

Thanks guys, your feedback is really appreciated!

[Guest]

In a composite video signal the luma and chroma are combined and they have to be separated by the receiving device. This cannot be done perfectly. When luma contaminates chroma you have rainbows, and when chroma contaminates luma you have dot crawl. This is why composite video connections should be avoided where possible.

Do a google search on "video comb filter" to learn about the issues and the separation technology.

[2Bdecided]

And the camera is feeding the DVR a 50 fields a second source that it is being written down at 6 line doubled frames a second, by taking one 352x576 field and doubling the horizontal lines and throwing away the rest of the data. Makes sense!704x288, not 352x576. But yes, that's it.

Cheers,
David.