DV Codec & Analyzer

[Pollux]

I have extended A. Dittrich's DV Codec "Cedocida" a little in order to analyze DV streams. So the resulting mod has all the capabilities of Cedocida plus analyzing caps.

I needed this in order to detect block errors in my DV footage so I am posting this hoping it will be useful for someone else. Apropos block errors, as far as I have seen Cedocida does not conceal them so they will be more visible than in other codecs even without an analyzer. Whether this is good or not is another question.

Cedocida Analyzer Mod 0.1.6 (http://stud3.tuwien.ac.at/~e0125662/)

What the analyzer can show:

block errors
DCT type
block class
quantization number
quantizer matrix

To complicate matters more the analyzer can show its output on just one colorspace for example "YUY2" while showing the source material on "YV12" channel. Analyzing DV streams in "RGB24" and "RGB32" is also possible although it would not make much sense as chroma and luma planes will not be easy to separate in that case.

Below a screenshot of how the anaylzer shows a buggy DV stream:

http://stud3.tuwien.ac.at/~e0125662/berror.png

The bright blocks are luma block errors, the coloured one is a chroma block error.

[bb]

Thanks Pollux, and welcome to the forum!

Do you provide a binary, too?

bb

[Pollux]

Sorry, no binary.

[Fizick]

With binary:

http://rapidshare.de/files/28530455/cedocida_mod_0.1.6a.zip.html

[WorBry]

Thanks for doing that Fizick :)

[Fizick]

updated temporary link
http://avisynth.org.ru/cedocida/cedocida_mod_0.1.6a.zip

http://avisynth.org.ru/cedocida/

Cross-link :)
http://forum.doom9.org/showthread.php?t=118210

[2Bdecided]

Thanks for that Fizick. I got it working, though the results were slightly surprising.

I used this script...


content=avisource("filename.avi",pixel_type="yv12")
errors=converttoyv12(avisource("filename.avi",pixel_type="yuy2"))

errors=levels(errors,150,1,200,0,255)

both=overlay(content,errors,mode="exclusion",opacity=1)

interleave(content,both)


To compare the errors found by the Cedocida mod to those visible in the decoded image.

Firstly, the decoded image from Cedocida is the same as that seen from any other decoder. There is a comment above that the error handling of Cedocida is different from other decoders, so errors will look different (uncorrected) - does this mean my miniDV camera has already patched this file?

Secondly, there are errors found by Cedocida mod in the same frames as there are visible errors in the video (so far so good!), but the location with the frame isn't always the same! There are some reported errors which are not visible in the video itself, and some small-area errors (found by Cedocida) which cause larger areas of error (i.e. repeated content from previous frame) in the decoded video itself. This doesn't appear to be entirely consistent - it doesn't look like a small area error always causes a specific larger block size to be decoded in error - sometimes it does, sometimes it doesn't.

I can probably make use of this as it is, but it would be interesting and useful to know what's happening. Did my miniDV camera patch the file on playback, or do the errors just not match up anyway?

I'm guessing no one else is using this, which is a shame. If anyone can host it, I can provide a genuine damagde bit of DV to test with!

Cheers,
David.

[JohnnyMalaria]

There are some reported errors which are not visible in the video itself, and some small-area errors (found by Cedocida) which cause larger areas of error (i.e. repeated content from previous frame) in the decoded video itself. This doesn't appear to be entirely consistent - it doesn't look like a small area error always causes a specific larger block size to be decoded in error - sometimes it does, sometimes it doesn't.

There are two types of errors that can show up:

1. Errors that the cam knows about and flags in the DV stream - see my earlier post. These type usually result in a whole macroblock or even segment being repeated. A macroblock in PAL-land is a 16x16 pixel block. A segment is five of this scattered across the frame.

2. Errors that occur on transmission via Firewire. e.g., a single bit will be wrong and, when decoded, the data don't make sense. These usually affect one 8x8 block but can affect the whole segment, depending on the rest of the data.

[2Bdecided]

There are two types of errors that can show up:

1. Errors that the cam knows about and flags in the DV stream - see my earlier post. These type usually result in a whole macroblock or even segment being repeated. A macroblock in PAL-land is a 16x16 pixel block. A segment is five of this scattered across the frame.

2. Errors that occur on transmission via Firewire. e.g., a single bit will be wrong and, when decoded, the data don't make sense. These usually affect one 8x8 block but can affect the whole segment, depending on the rest of the data.

John,

I re-read http://forum.doom9.org/showthread.php?t=118210

I realised I couldn't see the exact size of the block errors clearly in the content itself, so changed the script as follows...

content=avisource("005.1998-08-01_11-45-58.avi",pixel_type="yv12")
errors=converttoyv12(avisource("005.1998-08-01_11-45-58.avi",pixel_type="yuy2"))

contentonefield=selecteven(bob(content))

contentdiff=levels(Subtract(contentonefield.Trim(1,0),contentonefield),100,1,150,0,255)

StackHorizontal(crop(contentdiff,360,0,360,576),crop(selecteven(bob(errors.Trim(1,0))),360,0,360,576))


In the left hand part of the output is the current frame minus the previous one. This shows very clearly where blocks have been replaced with blocks from the next/previous frame - there's no difference (pure grey).

In the right hand part of the output is the detected error.

Both the left and right parts of the output frame are generated from the right hand part of the original, so are directly comparable.

I've attached some images. They're downrezed 2:1, but since the smallest error is 8x8 this doesn't matter.

Now I can see the block sizes you mention very clearly. Both 8x8 quantisation data errors, and 16x16 replacements, are visible in the subtracted video output.

The problem is that, while the 8x8 quantisation data errors are correctly predicted by the error data itself, there are loads of 16x16 areas replaced in the content which are not predicted by the error data itself.

In the attached images you can see that the bottom right of the frame is often replaced, but no error is flagged in this region.

What could be happening? Is there a solution?

Cheers,
David.

[JohnnyMalaria]

In the attached images you can see that the bottom right of the frame is often replaced, but no error is flagged in this region.

What could be happening? Is there a solution?

Cheers,
David.

I can't see the images - they are still pending approval :(

EDIT - Now I can!

It's hard to tell from those images. There is another kind of error that can occur and different codecs seem to treat them differently. Like many compression formats, DV takes an 8x8 block of pixels and converts them to an 8x8 discrete cosine transform (DCT). I know from your homepage that you're probably very familiar with this (or at least the DCT's close cousin, the FFT). Anyway, the DCT data are quantised and then Huffman run length encoded. Obviously, the first thing the decoder does is reverse the Huffman encoding. If, for any reason, one bit of the data is wrong, it can through the entire decoding off and you can end up with DCT blocks that either contain illegal values or nonsense values. The subsequent inverse DCT process can then lead to some of the peculiar blocks that you see that resemble mutant chess boards. A decoder can detect when an illegal block has been created (because of a bad bit, say) and there are two obvious things to do. 1. Just present it as-is. Our decoder does that and you can see illegal blocks usually when the camcorder is in fast play mode or if playback has just started and the mechanism hasn't settled. 2. Ignore all the AC coefficients of the DCT block and just use the DC coefficient. This helps hide the error - upon close inspection, though, it will appear as an 8x8 block of uniform grey/colour. Depending on how much the rogue bit throws off the rest of the decoding, it can, in theory, affect an entire segment (5 lots of 16 x 16 pixels for PAL) and each 8x8 block could have the bad chess board look.

[Fizick]

2Bdecided,
try send private message to Pollux

[2Bdecided]

John (or Pollux!),

So is it possible that the reported errors are the single bits within a single block, but what I see in the video output are the (up to) 5 blocks in error? Seems strange that all 5 blocks wouldn't be "reported" in this case. I wonder how the Cedocida mod works?

I don't see any uniform blocks (DC coefficient only), or that much mutant chessboarding in the normal output - I just see repeated blocks. (There are a few mutant chessboards, but you have to look very hard at a still frame to see them).

What I've shown in my pictures are frame N minus frame N-1 - i.e. the difference. The grey areas are repeated blocks.

I was surprised to see mutant chessboards appear by subtracting one frame from the previous one. It suggests that blocks are being repeated, but with DCT errors - very strange!

Thanks for all your help - I can tell that this interests you just like it does me!

(Still can't access enosoft.net here)

Cheers,
David.