On Fri, 2 Oct 2015 21:41:59 +0200 Michael Niedermayer <michae...@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 <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? > > 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?) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
