[Ffmpeg-devel] [BUG] Segfault in h264 decoder on corrupt input

Reinhard Nissl rnissl
Mon Mar 26 13:52:26 CEST 2007


Hi,

Matthias Hopf wrote:

>> The attached patch improves the situation but doesn't fix it. I need
>> some hints whether this is the right way to go ...
> 
> With this patch all my issues are gone. Which do you still see?

When the stream is larger, i. e. it contains more PAFF fields or more
changes between PAFF and non PAFF sections, we still run out of buffers.
And in xine, this leads to a complete lockup.

> Given my understanding of the code, one of the following should be done
> 
> - Apply the buffer release for PAFF only.
>   Only for PAFF s->picture_structure isn't set, so if this field is used
>   for checking whether buffers have to be cleared this is the right way
>   to go.
>
> - Apply the buffer release for *all* return -1 cases (not only PAFF and
>   MBAFF).
>   If the buffers aren't released any more as soon as one slice returns
>   -1 that would be the way to go. But except for PAFF (which changes the
>   picture structure fundamentally) all other cases can be transient
>   AFAICS (meaning, hit only on one slice, but not on the complete
>   frame). So that sounds wrong.

For now, this is not necessary as all slice errors look like this (at
least for me):

[h264 @ 0xb64546b4]PAFF interlacing is not implemented
[h264 @ 0xb64546b4]decode_slice_header error

> - Fix the underlying buffer release code.
>   I have no clue where that code sits, and under which circumstances it
>   is called.

Sure, this is the only correct way to go. It seems like
MPV_frame_start() is a starting point for research as there is this assert:

assert(s->last_picture_ptr==NULL || s->out_format != FMT_H264 ||
s->codec_id == CODEC_ID_SVQ3);

which always fails for my H.264 streams even when they are without PAFF
and do not report any further errors.

As there is no comment in the function regarding this assert(), I've no
idea how to fix this assert(). Does it mean, MPV_frame_start() is not
ready for FMT_H264 so let it fail instead of doing anything wrong, or
does it mean, the caller must assure that s->last_picture_ptr is NULL in
case of FMT_H264?

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de




More information about the ffmpeg-devel mailing list