[FFmpeg-devel] ffplay segfaults on invalid h264 stream

[Michael Niedermayer]

Hi

On Fri, May 04, 2007 at 10:35:04AM +0200, Panagiotis Issaris wrote:
[...]
> > h.264 spec says:
> > ----
> > adaptive_ref_pic_marking_mode_flag selects the reference picture marking mode of the currently decoded picture as
> > specified in Table 7-8. adaptive_ref_pic_marking_mode_flag shall be equal to 1 when the number of frames,
> > complementary field pairs, and non-paired fields that are currently marked as "used for long-term reference" is equal to
> > Max( num_ref_frames, 1 ).
> > ----
> > 
> > so the h->short_ref_count>0 seems wrong its an error condition if its false
> > not a no-op condition
> 
> I see. Should the decoder just bail out if the stream is invalid, or
> should it try to decode it anyway (thus adding some error tolerance)? I
> am not sure how difficult it will be to have true error tolerance: With
> the patch above my broken bitstream keeps decoding although the image is
> "a bit" corrupted. But, the decoder segfaults somewhere later in the
> stream where another null pointer is dereferenced. In that case the
> pointer that is dereferenced is not always zero when it is corrupted;
> it's sometimes 10 or some other obviously wrong value.

the decoder should of course be error tolerant though its better to
fail than to randomly dereference near null pointers ...


> 
> 
> 
> > the h->short_ref[h->short_ref_count-1] check also seems wrong as 
> > h->short_ref_count of X implicates that there are X entries in h->short_ref
> 
> Isn't it possible that a corrupted stream has an invalid
> h->short_ref_count? And if so, how should I handle it?

by allocating a dummy picture so there are no missing reference pictures
(the dummy should be a copy of some other available picture if possible
to reduce the amount of "green" blocks)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070504/1083d46a/attachment.pgp>