PDA

View Full Version : Error resilience - what is it?


LigH
11th September 2010, 05:19
I have seen this option in different MPEG (1/2 and 4) decoders. Somehow I have a feeling as if this could be a kind of "crash protection" against faulty streams by adding several checks if the decoded data violates some assertions which might lead to stack/heap overflows when not checked, but will cost CPU time when used, even on compliant video streams.

Due to a lack of documentation in the decoders or players (e.g. ffdshow, MPC-HC) I am not certain which option in the range between "careful" and "very aggressive" is the "safer but slower" or the "faster but unsafe", though...

Reimar
11th September 2010, 11:23
"error resilience" is the old name of what is now called "error recognition" in FFmpeg: http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#cdc1b1330ab250216fee124b95c03a9b
And it decides how the decoder behaves if some value in the input is against the specification: whether it assumes it is a minor encoder mistake and "extends" the standard to give a meaning to that input or whether it assumes the input is corrupted and it should apply error concealment, i.e. assuming this and surrounding data have no relation with what the video really should look like and thus will try to reconstruct something reasonable-looking e.g. from the previous frame.
This is not a speed related option (while error concealment is very slow that is not relevant, if it is used when it shouldn't be or the other way round the result will look very horrible).

LigH
11th September 2010, 11:36
The more interesting part might me the treatment of corrupt entropy code or sanity checks between header related frame dimensions and decoding results of corrupt data.

Let's imagine a decoder reserves memory to decode width*height pixels (or the macroblock data first which they are based on). But the entropy encoded data decodes to virtually much more decompressed data than reserved according to the header dimensions, due to data corruption in a way that the wrong data looks like many more small-compressed (e.g. Huffman) codes. The decoder tries to address more memory than it was allocated. The decoder crashes. And the player with it.

Does the "error resilience" option of the decoder protect you from such issues? And if yes - which value do I have to set to be best protected, "careful" or "very aggressive"?

LigH
16th April 2011, 18:10
This question is still not answered satisfyingly.

Are there no decoder developers available who know what they coded?

LigH
15th November 2011, 14:42
I am still curious if "error resilience" is in any way related to crash protection.