On Wed, 21 Nov 2012, Janne Grunau wrote:
> On 2012-11-16 18:14:29 -0800, Ronald S. Bultje wrote:
> > On Fri, Nov 16, 2012 at 8:43 AM, Janne Grunau <janne-li...@jannau.net>wrote:
> >
> > > Fixes a crash in fuzzed file nasa-8s2.ts_s20033 caused by a too large
> > > has_b_frames value. low_delay keeps getting re-enabled from the the
> > > presumely broken SPS.
> > > ---
> > > libavcodec/h264.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> > > index c30c478..7935fe6 100644
> > > --- a/libavcodec/h264.c
> > > +++ b/libavcodec/h264.c
> > > @@ -2346,8 +2346,10 @@ static int h264_set_parameter_from_sps(H264Context
> > > *h)
> > >
> > > if (s->flags & CODEC_FLAG_LOW_DELAY ||
> > > (h->sps.bitstream_restriction_flag &&
> > > - !h->sps.num_reorder_frames))
> > > + !h->sps.num_reorder_frames)) {
> > > s->low_delay = 1;
> > > + s->avctx->has_b_frames = 0;
> > > + }
> > >
> >
> > So I'm going to have to wonder what happens to the delayed frames already
> > cached in h->delayed_pics[]? Are they still output?
>
> yes, delayed pictures are returned as long as h->delayed_pics[0] is not
> NULL.
And when you return something from delayed_pics[] instead of the new
frame that just got decoded, the new frame gets delayed, so that you
don't ever actually switch to low delay mode?
--Loren Merritt
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
