Stabilizing and cleaning up DV [Archive]

zambelli

9th June 2006, 09:18

I have some DV footage that was shot with a cheapo DV camcorder (probably 1/8" CCD) by a person with jittery hands. I'd like to stabilize it, clean it up a bit and encode it for a DVD. My goal is to keep it interlaced on the DVD, too.

Here's a 5 second clip from the DV video:
http://www.citizeninsomniac.com/video/G_DV.avi (18MB)

I'd love to get some feedback on my process and suggestions for improvement.

First, I created this .avs script:

AVISource("Graduation.avi") # Using MainConcept DV codec - YUY2

# Set the correct field dominance
AssumeBFF()

# Correct MainConcept's chroma upsampling bug
ReInterpolate411()

# Equalize histogram so that all usable luma data falls within the 16-235 range
Levels(16, 1, 255, 10, 240, coring=false)

# Bob deinterlace
TDeint(mode=1)

# Convert to RGB before VirtualDub does it anyway
ConvertToRGB24(interlaced=false)

Then I loaded the script into VirtualDub and configured Gunnar Thalin's DeShaker (http://www.guthspot.se/video/deshaker.htm) plugin as follows:
http://forum.doom9.org/attachment.php?attachmentid=5879&stc=1&d=1149839454

I saved the output directly to HuffYUV with RGB-->YUY2 conversion enabled, since that would've been my next step in Avisynth anyway - might as well save some disk space.

Some 20 hrs later, I had a nice stabilized video. :) Now for the cleanup. This is my cleanup script:

LoadPlugin("c:\Program Files\AviSynth\filters\fft3dfilter.dll")
LoadPlugin("c:\Program Files\AviSynth\filters\EEDI2.dll")
LoadPlugin("c:\Program Files\AviSynth\filters\cnr2.dll")
# implicitly loads LimitedSharpenFaster script and plugins

AVISource("Graduation_Deshaked.avi")

# Load audio separately as intermediate file doesn't have it
audio = WAVSource("Graduation.wav")

# Reduce chroma artifacts
CNR2()

# Denoise video
FFT3DFilter(sigma=3.5, interlaced=false)

# Resize 2x in both directions - smoothens aliasing in diagonal lines
EEDI2().TurnLeft().EEDI2().TurnRight()

# Sharpen and resize back to 720x480
LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, dest_x=720, dest_y=480, smode=3, strength=100)

# Reinterlace - BFF
SeparateFields()
SelectEvery(4,0,3)
Weave()

# Dub audio track
AudioDub(last, audio)

# Compensate for Deshaker's 60 field delay
DelayAudio(1.0)

Well, that's all I've got so far. Here's my end result (HuffYUV encoded):

http://www.citizeninsomniac.com/video/G_HFYU.avi (34MB)

Before:
http://www.citizeninsomniac.com/images/G_before.png
After:
http://www.citizeninsomniac.com/images/G_after.png

You'll notice that the interlacing lines are less obvious in the processed video. This is because the video is stabilized, so there is less motion between each 1/60th of a second.

One thing I'd still like to correct is the chroma noise. If you look at the video carefully (I'm not sure the stills reveal it as much), you'll notice stray blue and yellow chroma noise in the flat surfaces such as the red podium and the black gown. This is probably a result of the crappy CCD. Does anyone know of a filter that could fix that?

Well, that's all I've got so far. Comments? Suggestions?

Thanks!

Dark-Cracker

9th June 2006, 09:59

have u try cnr2k instead of cnr2, sometimes give more better result for the chroma artefacts.

zambelli

9th June 2006, 10:50

have u try cnr2k instead of cnr2, sometimes give more better result for the chroma artefacts.
Ah, I was actually wondering about that one. I couldn't find any documentation for it, so I wasn't sure if it was a newer, improved version or not. I'll give it a try.

Boulder

9th June 2006, 11:50

I would use FFT3DFilter/FFT3DGPU for chroma denoising. CNR2/CNR2k often lead to weird results.

Chainmax

9th June 2006, 19:30

I was going to suggest just that :). zambelli, simply add plane=4 to your FFT3DFilter line. One thing though: my monitor is about to go kaput so I might not be able to see much stuff, but the source pic looks pretty clean to me, and sigma=3.5 is a pretty high setting, maybe stronger than DeGrainMedian(), I'd recommend you to lower it to 2 or even 1.

I think you have the levels line set wront, by the way. The correct syntax is Levels(black point,gamma,white point,16,235). In order to find out the black point and white point, use CSamp to find out the RGB values of a black part (like the borders) and a white part (bright lights, signposts, etc)

About bobbing, instead of TDeint you should probably use SecureDeint (or maybe even MVBOB, if you have lots of time and a beefy computer) instead of TDeint.

P.S: if you will use AC3 for audio, you might want to try DTS:NEO6 2.0-to-5.1 upsampling with GraphEdit. If you are using WAV, don't bother with it.

zambelli

10th June 2006, 01:23

I was going to suggest just that :). zambelli, simply add plane=4 to your FFT3DFilter line.
OK, I'll give that a shot. I think I tried it at one point but couldn't really notice a difference between plane=4 and the default setting, so I left it at the default (faster?) setting.

One thing though: my monitor is about to go kaput so I might not be able to see much stuff, but the source pic looks pretty clean to me, and sigma=3.5 is a pretty high setting, maybe stronger than DeGrainMedian(), I'd recommend you to lower it to 2 or even 1.
Yeah, sigma=3.5 is stronger than DeGrainMedian, but I think it does a good job of cleaning up the DV noise. I can tone it down to 3.0, but I wouldn't go lower than that. If you look at any solid surface in the video, you'll notice a lot of random noise. I'm pretty sure this is because of the poor CCD. FFT3D does a good job of smoothing it out.

I think you have the levels line set wront, by the way. The correct syntax is Levels(black point,gamma,white point,16,235). In order to find out the black point and white point, use CSamp to find out the RGB values of a black part (like the borders) and a white part (bright lights, signposts, etc)
In a perfect world, yes. :) I based my levels adjustment largely on the histogram (see below). That's pretty representative of the whole video. The entire luma spectrum seems to be skewed to the right. In my Levels() call I tried to shift the luma levels a little bit more to the left. A better way to phrase it would be:
Levels(5, 1, 255, 0, 240)
That compresses the luma and shifts it to the left. The goal is to distribute the usable luma within the 16-235 range. Does that make sense?

Funny enough, I totally forgot that a while ago I adapted one of Didee's functions for a similar purpose: smooth levels adjustment. It's documented here: http://forum.doom9.org/showthread.php?p=709701#post709701

I should use this instead:

function Levels_Smooth(clip clp, int min_before, int max_before, int min_after, int max_after)
{
pc2tv = clp.Levels(min_before, 1, max_before, min_after, max_after, coring=false)
pc2tvd=yv12lutxy(clp,pc2tv,"x y - 4 * 128 +","x y - 4 * 128 +","x y - 4 * 128 +",U=3,V=3)
yv12lutxy(clp,pc2tvd.removegrain(mode=19),"x y 128 - 4 / -","x y 128 - 4 / -","x y 128 - 4 / -",U=3,V=3)
}

About bobbing, instead of TDeint you should probably use SecureDeint (or maybe even MVBOB, if you have lots of time and a beefy computer) instead of TDeint.
Thanks for the tip - I'll give SecureDeint a try. Sometimes it's hard to keep up with all the deinterlacers around here. :)

Chainmax

10th June 2006, 01:40

One more thing: try using SMode=4 in the LimitedSharpenFaster line and/or try SeeSaw, ditch the two EEDI2 calls for a single SangNom one as EEDI2 is useful for resizing and deinterlacing postprocessing, its antialiasing is more of a bonus than anything.

zambelli

10th June 2006, 08:24

I'm having some trouble with MVBob() and SecureDeint(). They both give me highly visible artifacts, and I'm not talking about just regular combing. The artifacts occur in still areas, which makes me think this might be a bug.

http://www.citizeninsomniac.com/images/MVbob_artifacts.png

I'm using all the same DLLs as contained in scharfis_brain's package, except for mvtools which I updated to the latest 1.3.0 version.

Tweaking the parameters doesn't help, and I wouldn't expect it to, as the combing is occuring in non-moving areas.

Here's my current pre-deshake script:

function Levels_Smooth(clip clp, int min_before, int max_before, int min_after, int max_after)
{
pc2tv = clp.Levels(min_before, 1, max_before, min_after, max_after, coring=false)
pc2tvd=yv12lutxy(clp,pc2tv,"x y - 4 * 128 +","x y - 4 * 128 +","x y - 4 * 128 +",U=3,V=3)
yv12lutxy(clp,pc2tvd.removegrain(mode=19),"x y 128 - 4 / -","x y 128 - 4 / -","x y 128 - 4 / -",U=3,V=3)
}

Import("C:\Program Files\AviSynth\filters\mvbob.avs")

AVISource("Graduation.avi") # Using MainConcept DV codec - YUY2

# Set the correct field dominance
AssumeBFF()

# Correct MainConcept's chroma upsampling bug
ReInterpolate411()

# Bob deinterlace
MVbob()

# Convert to YV12 with scharfis_brain's function
ReYV12()

# Equalize histogram
Levels_Smooth(5, 255, 1, 239)

# Convert to RGB before VirtualDub does it anyway
ConvertToRGB24(interlaced=false)

Another interesting thing is that if I switch the order of ReYV12().Levels_Smooth() with MVbob(), Avisynth crashes. Clearly something bad is going on, but what?

zambelli

10th June 2006, 08:47

One more thing: try using SMode=4 in the LimitedSharpenFaster line and/or try SeeSaw,
Should I use SeeSaw in conjunction with FFT3DFilter(), or should I go with the more common DegrainMedian()?

ditch the two EEDI2 calls for a single SangNom one as EEDI2 is useful for resizing and deinterlacing postprocessing, its antialiasing is more of a bonus than anything.
But wait... Isn't SangNom a deinterlacer?

Alain2

10th June 2006, 15:58

SangNom is a deinterlacer yes but work a bit like eedi2 I think, it takes only 1 field of the frame and reconstruct the other one (so you loose half the resolution vertically, which may be not the case of eedi2). It includes an anti-aliasing post-process (to compensate the aliasing created by dumping a field).

I wouldn't recommend SangNom anymore, it produces artefacs sometimes on small details..

Chainmax

10th June 2006, 17:18

Should I use SeeSaw in conjunction with FFT3DFilter(), or should I go with the more common DegrainMedian()?

But wait... Isn't SangNom a deinterlacer?

SeeSaw is a sharpener and is intended to bring out details. The idea would be that SeeSaw brings out details and LSF(SMode=4) will enhance them. And don't use DeGrainMedian on this, it's better for animated content or very noisy sources. FFT3DFilter is more than enough here, just remember to lower sigma to 3 like you said and set plane=4 so that both luma and chroma are filtered. By the way, I don't know what SangNom is, just that it does antialiasing.
By the way, thanks for the DeShaker config screenshot, it will help me a great deal on some digicam clips I'm trying to convert to DVD :).

zambelli

10th June 2006, 23:03

SeeSaw is a sharpener and is intended to bring out details. The idea would be that SeeSaw brings out details and LSF(SMode=4) will enhance them.
Are you suggesting that I should use SeeSaw and LSF?

And don't use DeGrainMedian on this, it's better for animated content or very noisy sources. FFT3DFilter is more than enough here, just remember to lower sigma to 3 like you said and set plane=4 so that both luma and chroma are filtered. By the way, I don't know what SangNom is, just that it does antialiasing.
Cool, thanks for the tips! Well, if I can get MVbob to work, that will hopefully get rid of aliasing because it uses EEDI2.

By the way, thanks for the DeShaker config screenshot, it will help me a great deal on some digicam clips I'm trying to convert to DVD :).
No problem. If you find that your footage is being zoomed in too much, too often - reduce the Zoom Correction Limit from 25 to 20 or 15. There's a tradeoff between stability and bluriness (introduced by digital zooming) that is controlled by that factor.

@ Everyone:
Any idea why MVbob isn't working for me? :(

Chainmax

10th June 2006, 23:08

Try LSF(SMode=4) first, then SeeSaw with Pookie's suggestion (http://forum.doom9.org/showthread.php?t=104701&highlight=seesaw) and then both. As for why SecureDeint() doesn't work, try asking scharfis_brain to read this thread and give you some feedback.

Pookie

11th June 2006, 03:33

I've found LS Smode=3 to look a bit better after seesaw(ing), but YMMV.:p

scharfis_brain

11th June 2006, 09:47

I don't have any problems deinterlacing your clip.
Pleas assure, that you set the field order properly.

Please provide a sample of that scene.
How does the output of securedeint look like?

Also never use ReYV12() this way. It is intended to do something like reinterpolate411() directly AFTER loading the avi. Also it is ONLY for PAL-DV.

FredThompson

11th June 2006, 10:30

You could also follow scharfis_brain's method of B&W for the first pass of deshaker.

Your source is interlaced. Why are you deinterlacing? There's no perfect way to stabilize handheld camcorder source. The camera is always moving a little in space. One result of that is stationary objects...aren't. That little jiggle combined with chroma shared on adjacent pixels is going to make deinterlacing less than "perfect."

zambelli

11th June 2006, 11:17

I don't have any problems deinterlacing your clip. Pleas assure, that you set the field order properly. Please provide a sample of that scene.
How does the output of securedeint look like?
SecureDeint had the same problems. Rest assured, this is not a content specific issue. The combing artifacts seen in that image occur even in perfectly still scenes, so something else is going on.
I've figured out a workaround for the issue - but I still haven't figured out the root of it.

Also never use ReYV12() this way. It is intended to do something like reinterpolate411() directly AFTER loading the avi. Also it is ONLY for PAL-DV.
Ah, good to know.
BTW, if I'm going to be converting my YUY2 DV output (MainConcept codec) to YV12, should I use Reinterpolate411 prior to ConvertToYV12 at all? Will the chroma quality be affected at all? Or should I just ditch MainConcept and switch to Cedocida and avoid all the unnecessary YUY2-YV12 conversions?

Your source is interlaced. Why are you deinterlacing? There's no perfect way to stabilize handheld camcorder source. The camera is always moving a little in space. One result of that is stationary objects...aren't. That little jiggle combined with chroma shared on adjacent pixels is going to make deinterlacing less than "perfect."
There's no way to stabilize interlaced video without separating it into fields first. Even though DeShaker supports interlaced video input/output, I'm sure it does some form of bobbing internally. Remember, it works by panning, rotating and zooming into the image when motion due to shaking is detected. You can't zoom unless you deinterlace first, right? I'm just improving the quality of DeShaker's output by using a better deinterlacer/bobber than whatever DeShaker has implemented internally.

@ Everyone:
OK, so I've figured out a workaround for the MVbob/SecureDeint issue. Apparently something in my plugins autoload folder is causing the artifacts to appear. What exactly though - I can't figure out. I've gone through my plugins folder and renamed every single DLL to .bak one by one, running the avs script after each rename. The artifacts never went away. However, when I renamed the entire plugins folder - the artifacts went away! WTF? Here's all I've got in my plugins autoload folder:

AddGrain.dll
DGDecode.dll
DirectShowSource.dll
ffavisynth.dll
mt_masktools.dll
RemoveGrainSSE3.dll
SSIM.dll
TCPDeliver.dll

Like I said, renaming them individually didn't help - but renaming the whole folder did. Has anyone experienced anything like that before?

scharfis_brain

11th June 2006, 11:37

Like I said, renaming them individually didn't help - but renaming the whole folder did. Has anyone experienced anything like that before?
yeah. That is the reason, why I never do plugin autoloading!
mvbob.avs already has its own plugin loading calls implemented. Maybe there are some conflictls loade one plugin twice or so.

Ah, good to know.
BTW, if I'm going to be converting my YUY2 DV output (MainConcept codec) to YV12, should I use Reinterpolate411 prior to ConvertToYV12 at all? Will the chroma quality be affected at all? Or should I just ditch MainConcept and switch to Cedocida and avoid all the unnecessary YUY2-YV12 conversions?

why do you wanna go to yv12? yv12 is only really needed, if you are encoding with HCenc, QUenc. All other encoders will accept YUY2 only.

So please stay yuy2 through the whole filterchain.

anyway if you still need yv12 here is the optimal solution:

avisource("xxx.avi")
reinterpolate411()
any_bob()
deshaking, sharpening, denaising etc.
converttoyv12()
reinterlace()

zambelli

11th June 2006, 21:47

why do you wanna go to yv12? yv12 is only really needed, if you are encoding with HCenc, QUenc. All other encoders will accept YUY2 only.
I will be using HC for MPEG-2 encoding, so yes, YV12 is my ultimate output format.

avisource("xxx.avi")
reinterpolate411()
any_bob()
deshaking, sharpening, denaising etc.
converttoyv12()
reinterlace()
It's a bit more complicated than that. Deshaking requires VirtualDub which requires RGB, so I have at least one lossy conversion regardless of my filter chain order.
All those filters using MaskTools and MVTools... Don't they work in YV12 only anyway? It would seem like the earlier I can get into the YV12 space, the better.

Here's what I'm currently thinking:

AVISource("DV") # YUY2
Reinterpolate411() # YUY2
MVbob() # YUY2
ConvertToRGB24(matrix="PC.601") # RGB, preserve range
DeShaker - VirtulaDub # RGB24
save to HuffYUV RGB # RGB24
AVISource("HFYU") # RGB24
ConvertToYV12(matrix="PC.601") # YV12, restores original full range
Levels_Smooth() # fix shifted range to better align with 16-235
cleanup, denoise, sharpen # YV12
reinterlace # YV12
HC encode # YV12

Sound reasonable?

dosdan

12th June 2006, 01:29

avisource("xxx.avi")
reinterpolate411()
any_bob()
deshaking, sharpening, denaising etc.
converttoyv12()
reinterlace()

So for handheld and tripod-mounted PAL DV via Cedocida codec I should use:
AviSource("Test.avi") #YV12 source

sep = SeparateFields()
even = sep.SelectEven().Convolution3D(preset="MovieLQ")
odd = sep.SelectOdd().Convolution3D(preset="MovieLQ")

even=LimitedSharpenFaster(even)
odd=LimitedSharpenFaster(odd)

Interleave(even,odd).Weave()
ConvertToRGB24(interlaced=true) #going to TMPEGenc

rather than

AviSource("Test.avi") #YV12 source

sep = SeparateFields()
even = sep.SelectEven().Convolution3D(preset="MovieLQ")
odd = sep.SelectOdd().Convolution3D(preset="MovieLQ")
Interleave(even,odd).Weave()

LimitedSharpenFaster()

ConvertToRGB24(interlaced=true) #going to TMPEGenc

Boulder

12th June 2006, 06:50

Like scharfi said, bob-process-reinterlace is the way to go. Not SeparateFields-process-Weave.

dosdan

12th June 2006, 10:41

Like scharfi said, bob-process-reinterlace is the way to go. Not SeparateFields-process-Weave.

OK, so LSF be applied before reinterlacing?

Boulder

12th June 2006, 10:43

Again, see scharfi's post.

any_bob()
deshaking, sharpening, denaising etc.
converttoyv12()
reinterlace()

zambelli

13th June 2006, 04:11

OK, here are my current scripts:

Pre-DeShake:
Import("C:\Program Files\AviSynth\filters\mvbob.avs")

AVISource("Graduation.avi") # Using MainConcept DV codec - YUY2

# Set the correct field dominance
AssumeBFF()

# Correct MainConcept's chroma upsampling bug
ReInterpolate411()

# Bob deinterlace
MVbob(bobth=6, th=5, ths=0)

# Convert to RGB while preserving full range
ConvertToRGB24(matrix="PC.601")

<--- DeShake and save to HuffYUV RGB24 --->

Post-DeShake:

# Smooth levels function adapted from Didee's PC2TV function
function Levels_Smooth(clip clp, int min_before, int max_before, int min_after, int max_after)
{
pc2tv = clp.Levels(min_before, 1, max_before, min_after, max_after, coring=false)
pc2tvd=yv12lutxy(clp,pc2tv,"x y - 4 * 128 +","x y - 4 * 128 +","x y - 4 * 128 +",U=3,V=3)
yv12lutxy(clp,pc2tvd.removegrain(mode=19),"x y 128 - 4 / -","x y 128 - 4 / -","x y 128 - 4 / -",U=3,V=3)
}

LoadPlugin("c:\Program Files\AviSynth\filters\fft3dfilter.dll")

Import("c:\Program Files\AviSynth\filters\SeeSaw.avs")

AVISource("Graduation_Deshaked.avi") # HuffYUV RGB24

# Load audio separately as intermediate file doesn't have it
audio = WAVSource("Graduation.wav")

# Convert to YV12 while restoring original range
ConvertToYV12(matrix="PC.601")

# Equalize histogram and distribute valid range within 16-235
Levels_Smooth(5, 255, 1, 239)

original = last

# Denoise video (luma + chroma)
denoised = FFT3DFilter(sigma=2.5, plane=4)

# Sharpen with SeeSaw
SeeSaw(original, denoised, NRlimit=3, Sstr=1.4, Spower=5, Sdamplo=6, Szp=16)

# Restore chroma from denoised sample
MergeChroma(denoised)

# Reinterlace - BFF
SeparateFields()
SelectEvery(4,0,3)
Weave()

# Dub audio track
AudioDub(last, audio)

# Compensate for Deshaker's 60 field delay
DelayAudio(1.0)

How does everything look?

Boulder

13th June 2006, 06:21

Chainmax

13th June 2006, 18:17

One has to select "Force output format" and the "YV12*" option on the decoder side for that, right? What other settings on either section can be set independently from the source?

Boulder

13th June 2006, 18:22

I've set chroma sampling to MPEG2 interlaced since I convert the colorspace to YUY2 for encoding with CCE. The option is probably necessary even when using an encoder with native YV12 support, I suppose that the DV option is for those applications in which you can load DV files and edit them.

zambelli

14th June 2006, 06:10

You might want to try installing the Cedocida DV codec. It will give you YV12 output (when you set it to do so, by default it outputs the 4:1:1 data) which will make MVBob faster and you wouldn't need to use Reinterpolate411 any longer.
http://forum.doom9.org/showthread.php?t=94458
Thanks, I was considering that, too. It certainly makes sense.

Done and done. My new pre-DeShaker script is:

Import("C:\Program Files\AviSynth\filters\mvbob.avs")

AVISource("Graduation.avi") # Using Cedocida - YV12 4:2:0 interlaced

# Set the correct field dominance
AssumeBFF()

# Bob deinterlace
MVbob(bobth=6, th=5, ths=0)

# Convert to RGB while preserving full range
ConvertToRGB24(matrix="PC.601")

FredThompson

14th June 2006, 09:30

@Zambelli, bobbing and deinterlacing are not the same thing just as field and frame are not the same thing.

Yes, you most certainly CAN resize interlaced content a la scharfis_exposed_brain: http://forum.doom9.org/showthread.php?threadid=74906

Ihaven't tried supersizing, deshaking and finally, reducing. It's an interesting idea.

zambelli

14th June 2006, 19:56

@Zambelli, bobbing and deinterlacing are not the same thing just as field and frame are not the same thing.
Oops, that somehow got left in there after multiple edits. :)

Yes, you most certainly CAN resize interlaced content a la scharfis_exposed_brain. Ihaven't tried supersizing, deshaking and finally, reducing. It's an interesting idea.
I really do think it's the right way in this deshaking scenario. Deshaker performs rotating and zooming, and I've learned that any zooming to an interlaced field should be done on an interpolated full-frame image and not just the odd or even lines.

scharfis_brain

14th June 2006, 20:08

You might want to try installing the Cedocida DV codec. It will give you YV12 output (when you set it to do so, by default it outputs the 4:1:1 data) which will make MVBob faster and you wouldn't need to use Reinterpolate411 any longer.

http://forum.doom9.org/showthread.php?t=94458

Boulder, sorry that I say it that harsh. But this is nonsense.

Because, YUV 4:1:1 has a totally different chroma layout compared to YUV 4:2:0

currently you CAN put out 4:1:1 native, but you'll only get a horrible messy chroma, because AVS interpretes it as YUV 4:2:0.

please stay with YUY2 and Reinterpolate411.
do the conversion to YV12 after deinterlacing.
converting chroma before deinterlacing or using native 4:1:1 will lower the Quality a lot.

native YV12 currently can only be used with PAL DV. And even there you have to take care for chroma offsets afterwards :(

Boulder

14th June 2006, 20:50

I thought that the author of Cedocida handles the situation correctly for NTSC so that there will be no problems, at least that's what I gathered from the release thread.

EDIT: or should the output colorspace in Cedocida's properties be forced to YUY2 then?

Wilbert

14th June 2006, 23:06

@all, including Boulder:

I've set chroma sampling to MPEG2 interlaced since I convert the colorspace to YUY2 for encoding with CCE. The option is probably necessary even when using an encoder with native YV12 support, I suppose that the DV option is for those applications in which you can load DV files and edit them.
The chroma sampling option only does something when your input is YV12. In that case it denotes your source and it resamples it to DV YV12. If your input is RGB or YUY2, it will always be sampled to DV YV12.

Similarly for the decoding options. It only does something when you request YV12 from it and it denotes the output sampling.

http://forum.doom9.org/showthread.php?p=748783#post748783

I thought that the author of Cedocida handles the situation correctly for NTSC so that there will be no problems, at least that's what I gathered from the release thread.
"correctly" is not the correct word. The situation is similar as with pointresize vs bilinear. The former is what all decoders do. It's possible that Cedocida uses bilinear sampling (what you call "correct sampling") when requesting YUY2, BUT you will have to check that. Perhaps henryho_hk looked at that in one of his posts, so ask him about it :)

In any case, AviSynth v2.6 supports YV411, then you will be able to use this 4:1:1 output (for NTSC of course).

zambelli

15th June 2006, 00:50

http://forum.doom9.org/showthread.php?p=748783#post748783
"correctly" is not the correct word. The situation is similar as with pointresize vs bilinear. The former is what all decoders do. It's possible that Cedocida uses bilinear sampling (what you call "correct sampling") when requesting YUY2, BUT you will have to check that. Perhaps henryho_hk looked at that in one of his posts, so ask him about it :)
Doesn't converting 4:1:1 to 4:2:0 simply require chroma re-mapping? Cedocida supports interlaced 4:2:0 output, so I'm assuming it's performing the chroma re-mapping in some intelligent way. I don't see how outputting DV as YUY2 (via MainConcept or other DV codec) and ReInterpolating411 can be any better than Cedocida doing the 4:1:1 to 4:2:0 conversion internally.

Boulder

15th June 2006, 06:59

Maybe it's time to do a screenshot comparison. I don't have any NTSC DV on my hands so I cannot do that at the moment.

scharfis_brain

15th June 2006, 07:19

You CAN'T re-map YUV411 to YUV420.

zambelli

15th June 2006, 08:38

You CAN'T re-map YUV411 to YUV420.
So do you think Cedocida is just upsampling to 4:2:2 and then downsampling to 4:2:0? Is there no lossless way to convert between 12-bit YUV formats?

foxyshadis

15th June 2006, 08:38

Here's how the chroma differs between them.

411: 4x1 subsampling
C - - - C - - -
C - - - C - - -
C - - - C - - -
C - - - C - - -
420: 2x2 subsampling
C - C - C - C -
- - - - - - - -
C - C - C - C -
- - - - - - - -

Reinterpolate411 just linearly interpolates to YUY2:

C - I - C - I -
C - I - C - I -

Where I is interpolated.

Wilbert

15th June 2006, 09:55

So do you think Cedocida is just upsampling to 4:2:2 and then downsampling to 4:2:0?
Yes, ok.

Is there no lossless way to convert between 12-bit YUV formats?
No (at least not these two), see foxyshadis' post.

edit: i corrected my post, because zambelli is correct.

Boulder

15th June 2006, 09:57

How about outputting YUY2 with Cedocida and an NTSC DV clip? Does that do the same as Reinterpolate411()?

scharfis_brain

15th June 2006, 10:15

try it out!

Boulder

15th June 2006, 11:51

OK, a very quick-and-dirty test:

http://www.saunalahti.fi/sainki/dv_yuy2.png (forced YUY2 in Cedocida, no Reinterpolate)
http://www.saunalahti.fi/sainki/dv_yuy2reinterpolate.png (same as above but with Reinterpolate)
http://www.saunalahti.fi/sainki/dv_yuy2reinterpolate_ffdshow.png (ffdshow decoded stream, pixel_type="YUY2" used)
http://www.saunalahti.fi/sainki/dv_yv12interlaced.png (interlaced YV12 forced in Cedocida)

To me it looks like ffdshow + Reinterpolate is correct. The first two images look exactly the same and in fact have the same filesize. The YV12 image shows some bleeding.

I stand corrected:stupid:

Wilbert

15th June 2006, 20:41

Since there is no difference between the two pics, it means that Cedocida also interpolates when requesting YUY2 or YV12. (I corrected my post above, because zambelli was right.)

Why do you think the third pic is correct and the first two are not?

Boulder

15th June 2006, 20:52

To me the third pic has the least bleeding, in the first two pics the yellowish, orange and blue areas look like they bleed slightly.

I'm known to make mistakes at times so I could be totally wrong :p

zambelli

16th June 2006, 00:18

This DV sample is probably too complex to easily spot the difference. We need one of those DV clips with blinking red LEDs. Those always show chroma sampling bugs nicely.

scharfis_brain

16th June 2006, 16:43

I made some test and found that it would be better to use a dumb kind of bob for deshaking, or a global motion compensated deinterlaced clip without motion adaption (I hacked my mvbob).

Motion adaption won't gain anything with shaky clips, cause it tries to 'denoise' by keeping areas static.

so you may try eedibob() instead of mvbob().
It will speed things up, increase stability oy uniform areas after deshaking. You won't loose that much with this sample clip due to the noise.

maybe I'll release an updated version of mvbob next week, which will be usable as proprocessor for deshaker.

Until then you should use eedibob()