On Fri, Dec 13, 2019 at 5:56 PM Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Fri, Dec 13, 2019 at 12:24:04PM +0100, Andreas Rheinhardt wrote: > > On Fri, Dec 13, 2019 at 3:07 AM Michael Niedermayer > <mich...@niedermayer.cc> > > wrote: > > > > > No testcase > > > > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > > --- > > > libavcodec/hevc_mp4toannexb_bsf.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c > > > b/libavcodec/hevc_mp4toannexb_bsf.c > > > index baa93628ed..e0d20a550c 100644 > > > --- a/libavcodec/hevc_mp4toannexb_bsf.c > > > +++ b/libavcodec/hevc_mp4toannexb_bsf.c > > > @@ -152,7 +152,9 @@ static int hevc_mp4toannexb_filter(AVBSFContext > *ctx, > > > AVPacket *out) > > > extra_size = add_extradata * ctx->par_out->extradata_size; > > > got_irap |= is_irap; > > > > > > - if (FFMIN(INT_MAX, SIZE_MAX) < 4ULL + nalu_size + extra_size) > { > > > + if (FFMIN(INT_MAX, SIZE_MAX) < 4ULL + nalu_size + extra_size > || > > > > > > > Up until now I thought that FFmpeg has some implicit assumptions: int > > having 32bit being one of them (the log2 functions depend on this). And I > > yes, that was from POSIX > > > > also thought that size_t being able to hold all the values of an unsigned > > was one of these implicit assumptions, too. Am I wrong on this? > > I was asking myself the same, and i couldnt really find anything where we > stated that previously so i added a FFMIN. > > In this case we would have to add lots of checks before av_malloc and other allocation functions that use size_t parameters in order to ensure that no loss of information happens when an int (or unsigned) is converted to size_t. In other words: We should not support such systems. > > > > > A testcase for the last condition is easy to produce by simply > manipulating > > the size field of a NAL unit. > > yes, do you think we should create such a testcase for this fix ? > You mean a fate test? Why not? - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".