On Fri, 2 Oct 2015 21:14:57 +0200 Michael Niedermayer <michae...@gmx.at> wrote:
> From: Michael Niedermayer <mich...@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 <mich...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
