Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
11th September 2010, 05:19 | #1 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Error resilience - what is it?
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... |
11th September 2010, 11:23 | #2 | Link |
Registered User
Join Date: Jun 2005
Posts: 278
|
"error resilience" is the old name of what is now called "error recognition" in FFmpeg: http://ffmpeg.org/doxygen/trunk/stru...ee124b95c03a9b
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). |
11th September 2010, 11:36 | #3 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
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"? |
Thread Tools | Search this Thread |
Display Modes | |
|
|