Strange artefacts with PAL DV (with advc-100)

[bREAkDoWN]

Hi!
I'm converting to DV the analog composite output of a satellite receiver (PAL) with a Canopus advc-100.
I'm still at the beginning but i've noticed some strange artefacts occuring on borders of objects with an high contrast.
I've uploaded on this page (http://spazioinwind.libero.it/breakdown) a full dv frame decoded with the latest MainConcept codec. I get the same artefacts with the Microsoft dv codec too. The frame hasn't been modified in any way and the video obtained from the advc-100 seems to be progressive (i mean that both fields of each frame make up a single progressive frame; and that could make sense to me, since i'm dealing with a movie).
The artefacts i'm talking of are visible on the tail of the red dress and on the arm of the woman looking at the painting on the right.
I have even considered that it could be the satellite receiver that suffers from the chroma upsampling bug like some dvd players do, but i don't know if i'm totally out of track ;)


PS: the .png image is all messed up in internet explorer. I don't know if it's normal or if the .png exported from virtualdub is someway broken; anyway ifranview showed it correctly.

[scharfis_brain]

familar with avisynth?

try this:

avisource("yourDV.avi")
converttoyuy2(interlaced=true)

[bb]

Try searching for "chroma upsampling bug".

Cheers,
bb

[bREAkDoWN]

Originally posted by scharfis_brain
familar with avisynth?

try this:

avisource("yourDV.avi")
converttoyuy2(interlaced=true)

I've investigated further, and now i've got some more points to analyze.
First of all your suggestion is good, but it has taken some time for me to make it work. At first i didn't understand it very well, because the output from avisource was already in YUY2 (either with the MS, MainConcept or Canopus DV codecs) so i was a little confused about converttoyuy2(interlaced=true). Then i found this thread http://forum.doom9.org/showthread.php?s=&threadid=62650. Quoting from a message of Mug Funky in that thread:




a lot of decoders have a chroma upsampling bug much nastier than the one fixed by fixbrokenchromaupsampling(), which just does the equivalent of a field-swap on the chroma channels in yuy2 space.

what i've been doing recently is using ffdshow to decode DV (you can set it to do this in the config panel), and using directshowsource(seek=true) in avisynth.

you'll need the latest version of avisynth for this, where directshowsource is way more powerful.

so a sample script would be:

directshowsource("c:\capture.avi", seek=true).converttoyuy2(interlaced=true)



So i tried to enable dv decoding in ffdshow and i enabled the ffdshow osd too to be sure that ffdshow was used to decompress the DV file. Then, with the Avisynth info() command i found out that ffdshow outputs the decoded dv in yv12 (4:2:0) and here i can succesfully insert converttoyuy2(interlaced=true) to obtain an image that doesn't show the blocky artefacts on borders.

Well, i went further and forced ffdshow to output to rgb instead of yv12 doing no colorspace conversions with avisynth, and the artefacts came back.

So, as Mug Funky said, it seems that these chroma blocks are introduced with the upsampling done by the various codec (and also by ffdshow if it has to produce rgb output) when they convert the internal 4:2:0 format of dv to 4:2:2 YUY2 or to RGB.
On the contrary, the upsampling made by avisynth with converttoyuy2(interlaced=true) seems to be ok.

I'd like to hear someone else's opinion on this. Is it possible that all the dv codecs (at least M$, MainConcept and Canopus) upsample chroma so bad?

PS: I've uploaded two new pics at http://spazioinwind.libero.it/breakdown (goodframe and badframe) to show the difference between the normal method (opening the avi in vdub and letting the MainConcept codec handle decoding and upsampling) and the ffdshow-convertoyuy2 method.

[Mug Funky]

in my experience M$ (or panasonic, whichever) doesn't do things too badly.

good ones i've found are:

Pinnacle DV25 (vfw)
Panasonic (vfw)
M$

the ones that not only upsample wrong, but do it in such a way that i cannot correctly fix it are:

mainconcept (okay, i haven't tried the new versions)
canopus

one's not worth mention are:

matrox

but i prefer ffdshow because it doesn't convert the sodding colourspace (you shouldn't need to do this unless you're using after effects or doing more than straight cutting in premiere).

generally it's best to leave it in YV12 - a good deinterlacer will work in YV12 and respect the colour sampling, so there's no worries there. the only problem would be recompressing to DV, because i'm not sure if ANY of the codecs will accept YV12 as input (why are DV codecs so damn stupid? they all end up in YV12 anyway...)

[bREAkDoWN]

Originally posted by Mug Funky
in my experience M$ (or panasonic, whichever) doesn't do things too badly.

good ones i've found are:

Pinnacle DV25 (vfw)
Panasonic (vfw)
M$

the ones that not only upsample wrong, but do it in such a way that i cannot correctly fix it are:

mainconcept (okay, i haven't tried the new versions)
canopus



I've just tried the panasonic dv codec (version number: 2.64.119.1600, according to the properties of its .dll) to decode the video i'm doing my tests with, but it also presents almost the same blocky artefacts you can see in badframe.bmp on my site.
You say "in such a way that i cannot correctly fix" so i'm asking you how do you fix things when it's possible to do it? And in which cases is it?
I've tried Avisynth fixbrokenchromaupsampling() but it changes things just a little and the result isn't comparable at all with the ffdshow-converttoyuy2 procedure.



but i prefer ffdshow because it doesn't convert the sodding colourspace (you shouldn't need to do this unless you're using after effects or doing more than straight cutting in premiere).

generally it's best to leave it in YV12 - a good deinterlacer will work in YV12 and respect the colour sampling, so there's no worries there. the only problem would be recompressing to DV, because i'm not sure if ANY of the codecs will accept YV12 as input (why are DV codecs so damn stupid? they all end up in YV12 anyway...)
Nor do i know if these codecs will accept YV12 as input, but as long as you're working with good yv12 data within avisynth, you can upsample to rgb or yuy2 in avisynth without any problem and send the output to vdub for recompressing.