[FFmpeg-devel] [PATCH 1/2] avcodec/avpacket: Use av_copy_packet_side_data() in av_packet_copy_props()

[wm4]

On Thu, 4 May 2017 04:00:39 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Wed, May 03, 2017 at 03:28:53PM +0200, Hendrik Leppkes wrote:
> > On Wed, May 3, 2017 at 3:23 PM, Michael Niedermayer
> > <michael at niedermayer.cc> wrote:  
> > > On Wed, May 03, 2017 at 12:54:53PM +0200, Hendrik Leppkes wrote:  
> > >> On Wed, May 3, 2017 at 11:50 AM, Michael Niedermayer
> > >> <michael at niedermayer.cc> wrote:  
> > >> > On Wed, May 03, 2017 at 11:37:35AM +0200, wm4 wrote:  
> > >> >> On Wed, 3 May 2017 11:29:04 +0200
> > >> >> Michael Niedermayer <michael at niedermayer.cc> wrote:
> > >> >>  
> > >> >> > On Wed, May 03, 2017 at 05:29:07AM +0200, wm4 wrote:  
> > >> >> > > On Wed,  3 May 2017 05:21:50 +0200
> > >> >> > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > >> >> > >  
> > >> >> > > > Fixes timeout
> > >> >> > > > Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> > >> >> > > >
> > >> >> > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > >> >> > > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > >> >> > > > ---
> > >> >> > > >  libavcodec/avpacket.c | 3 +++
> > >> >> > > >  1 file changed, 3 insertions(+)
> > >> >> > > >
> > >> >> > > > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > >> >> > > > index 4bf830bb8a..ff7ee730a4 100644
> > >> >> > > > --- a/libavcodec/avpacket.c
> > >> >> > > > +++ b/libavcodec/avpacket.c
> > >> >> > > > @@ -557,6 +557,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >> >> > > >      dst->flags                = src->flags;
> > >> >> > > >      dst->stream_index         = src->stream_index;
> > >> >> > > >
> > >> >> > > > +    if (!dst->side_data_elems);
> > >> >> > > > +        return av_copy_packet_side_data(dst, src);
> > >> >> > > > +
> > >> >> > > >      for (i = 0; i < src->side_data_elems; i++) {
> > >> >> > > >           enum AVPacketSideDataType type = src->side_data[i].type;
> > >> >> > > >           int size          = src->side_data[i].size;  
> > >> >> > >
> > >> >> > > This doesn't look right...  
> > >> >> >
> > >> >> > already fixed the ; locally
> > >> >> >
> > >> >> >
> > >> >> > [...]  
> > >> >>
> > >> >> I didn't see that, I was referring to the fact that you call
> > >> >> av_copy_packet_side_data(), and only sometimes (at least by intention).
> > >> >> That requires at least an explanation in the commit message.  
> > >> >
> > >> > av_packet_copy_props() would add side data to the destination packet
> > >> > it doesnt replace previously existing side data except in case of
> > >> > error.
> > >> > I dont know if that is intended but i didnt want to change it as that
> > >> > would be unrelated to this patch
> > >> >  
> > >>
> > >> This behavior seems odd at best, so maybe we should just change that
> > >> and make the behavior more logical, and fix your issue at the same
> > >> time?  
> > >
> > > That can be done and makes alot of sense after the patch.
> > >
> > > we need to fix this issue in our releases too
> > > a simple bugfix and a seperate behavior change afterwards allows us
> > > to simply backport the bugfix from master.
> > >  
> > 
> > If anything your "bugfix" here is a performance improvement, and I
> > don't think that warrants backporting either way.  
> 
> Before the patch the sample file takes
> 51seconds to decode, after it, it takes 203 milliseconds.
> The difference is caused by only 2 calls to the copy code

All for a situation that shouldn't happen in a sane way anyway, not
even with heavily fuzzed files.

We should limit side data to 1 per type, or have only 1 piece of code
that copies side data (after careful consideration of potentially
changing semantics). Both would fix it, as far as I understand it.

> blocking a machine for 51 seconds for something that decodes in 203ms
> otherwise, is IMO worth backporting a fix for.

Is that needed? Isn't it a fuzzed sample, instead of some real world
case?