On Thu, 4 May 2017 04:00:39 +0200 Michael Niedermayer <mich...@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 > > <mich...@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 > > >> <mich...@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 <mich...@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 <mich...@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 <mich...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
