[FFmpeg-devel] ffplay segfaults on invalid h264 stream

Michael Niedermayer michaelni
Fri May 4 12:51:29 CEST 2007


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>

More information about the ffmpeg-devel mailing list