[FFmpeg-devel] [PATCH] avcodec/h264_ps: Fix copying oversized pps data

wm4 nfxjfg at googlemail.com
Fri Oct 2 21:49:29 CEST 2015


On Fri, 2 Oct 2015 21:41:59 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Fri, Oct 02, 2015 at 09:23:04PM +0200, wm4 wrote:
> > On Fri,  2 Oct 2015 21:14:57 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > From: Michael Niedermayer <michael at niedermayer.cc>
> > > 
> > > Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264
> > > 
> > > In the available testcase the actual PPS only uses a few bits
> > > while there are 7kbyte of apparently random data after it
> > > 
> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > ---
> > >  libavcodec/h264_ps.c |    4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> > > index fd16a95..0dca5f0 100644
> > > --- a/libavcodec/h264_ps.c
> > > +++ b/libavcodec/h264_ps.c
> > > @@ -611,8 +611,8 @@ int ff_h264_decode_picture_parameter_set(H264Context *h, int bit_length)
> > >          return AVERROR(ENOMEM);
> > >      pps->data_size = h->gb.buffer_end - h->gb.buffer;
> > >      if (pps->data_size > sizeof(pps->data)) {
> > > -        ret = AVERROR_INVALIDDATA;
> > > -        goto fail;
> > > +        av_log(h->avctx, AV_LOG_WARNING, "Truncating likely oversized PPS\n");
> > > +        pps->data_size = sizeof(pps->data);
> > >      }
> > >      memcpy(pps->data, h->gb.buffer, pps->data_size);
> > >      pps->sps_id = get_ue_golomb_31(&h->gb);
> > 
> > That was quick.
> > 
> 
> > Should the same be done for SPS?
> 
> i dont know
> 

I'd say it would be good for symmetry.

Or we could just switch back to allocating 64K for the data, or maybe
even dynamically allocate it. (I wanted to avoid the latter because
it's a bit messy, but maybe it's the best solution?)


More information about the ffmpeg-devel mailing list