From: James Almer <jamrial@gmail.com> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH 3/5] avcodec/bsf/hevc_mp4toannexb: Don't realloc when creating new extradata Date: Sun, 18 Feb 2024 23:07:16 -0300 Message-ID: <e84728bd-09a6-4695-83e0-2f7fdaf51967@gmail.com> (raw) In-Reply-To: <AS8P250MB07442EDE41C074347931302B8F522@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM> On 2/17/2024 11:44 PM, Andreas Rheinhardt wrote: > AVCodecParameters.extradata is supposed to be allocated with > av_malloc(); av_realloc() and its wrappers do not guarantee > the proper alignment. Therefore parse the extradata twice: > Once to check its validity and to determine the eventual size > and a second time to actually write the new extradata. Why would av_malloc alignment be needed for extradata? I see the doxy says "Must be allocated with av_malloc()" but I'm fairly sure that was meant to be "Must be allocated with av_malloc() family of functions", like its AVCodecContext counterpart. The idea is that library users don't use normal malloc as extradata will be freed with av_free(), and not because it will be accessed by SIMD code. > > (Of course, not reallocating the buffer is beneficial in itself.) > > Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> > --- > libavcodec/bsf/hevc_mp4toannexb.c | 44 +++++++++++++++---------------- > 1 file changed, 22 insertions(+), 22 deletions(-) > > diff --git a/libavcodec/bsf/hevc_mp4toannexb.c b/libavcodec/bsf/hevc_mp4toannexb.c > index a695cba370..f5424e95b8 100644 > --- a/libavcodec/bsf/hevc_mp4toannexb.c > +++ b/libavcodec/bsf/hevc_mp4toannexb.c > @@ -38,13 +38,11 @@ typedef struct HEVCBSFContext { > } HEVCBSFContext; > > static int hevc_extradata_to_annexb_internal(void *logctx, GetByteContext *gb, > - uint8_t **new_extradatap, > + uint8_t *new_extradata, > size_t *new_extradata_sizep) > { > int num_arrays = bytestream2_get_byte(gb); > - uint8_t *new_extradata = NULL; > size_t new_extradata_size = 0; > - int ret; > > for (int i = 0; i < num_arrays; i++) { > int type = bytestream2_get_byte(gb) & 0x3f; > @@ -54,8 +52,7 @@ static int hevc_extradata_to_annexb_internal(void *logctx, GetByteContext *gb, > type == HEVC_NAL_SEI_PREFIX || type == HEVC_NAL_SEI_SUFFIX)) { > av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit type in extradata: %d\n", > type); > - ret = AVERROR_INVALIDDATA; > - goto fail; > + return AVERROR_INVALIDDATA; > } > > for (int j = 0; j < cnt; j++) { > @@ -64,26 +61,19 @@ static int hevc_extradata_to_annexb_internal(void *logctx, GetByteContext *gb, > if (!nalu_len || > nalu_len > bytestream2_get_bytes_left(gb) || > 4 + nalu_len > FFMIN(INT_MAX, SIZE_MAX) - AV_INPUT_BUFFER_PADDING_SIZE - new_extradata_size) { > - ret = AVERROR_INVALIDDATA; > - goto fail; > + return AVERROR_INVALIDDATA; > } > - ret = av_reallocp(&new_extradata, new_extradata_size + nalu_len + 4 + AV_INPUT_BUFFER_PADDING_SIZE); > - if (ret < 0) > - goto fail; > - > - AV_WB32(new_extradata + new_extradata_size, 1); // add the startcode > - bytestream2_get_buffer(gb, new_extradata + new_extradata_size + 4, nalu_len); > + if (new_extradata) { > + AV_WB32(new_extradata + new_extradata_size, 1); // add the startcode > + bytestream2_get_bufferu(gb, new_extradata + new_extradata_size + 4, nalu_len); > + } else > + bytestream2_skipu(gb, nalu_len); > new_extradata_size += 4 + nalu_len; > - memset(new_extradata + new_extradata_size, 0, AV_INPUT_BUFFER_PADDING_SIZE); > } > } > - *new_extradatap = new_extradata; > *new_extradata_sizep = new_extradata_size; > > return 0; > -fail: > - av_freep(&new_extradata); > - return ret; > } > > static int hevc_extradata_to_annexb(AVBSFContext *ctx) > @@ -100,10 +90,20 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx) > bytestream2_skip(&gb, 21); > length_size = (bytestream2_get_byte(&gb) & 3) + 1; > > - ret = hevc_extradata_to_annexb_internal(ctx, &gb, &new_extradata, > - &new_extradata_size); > - if (ret < 0) > - return ret; > + while (1) { > + GetByteContext gb_bak = gb; > + ret = hevc_extradata_to_annexb_internal(ctx, &gb, new_extradata, > + &new_extradata_size); > + if (ret < 0) > + return ret; > + if (new_extradata || !new_extradata_size) > + break; > + new_extradata = av_malloc(new_extradata_size + AV_INPUT_BUFFER_PADDING_SIZE); > + if (!new_extradata) > + return AVERROR(ENOMEM); > + memset(new_extradata + new_extradata_size, 0, AV_INPUT_BUFFER_PADDING_SIZE); > + gb = gb_bak; > + } > > av_freep(&ctx->par_out->extradata); > ctx->par_out->extradata = new_extradata; _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-19 2:07 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-18 2:41 [FFmpeg-devel] [PATCH 1/5] avcodec/bsf/(hevc|vvc)_mp4toannexb: Ensure extradata_size < INT_MAX Andreas Rheinhardt 2024-02-18 2:44 ` [FFmpeg-devel] [PATCH 2/5] avcodec/bsf/hevc_mp4toannexb: Factor creating new extradata out Andreas Rheinhardt 2024-02-18 2:44 ` [FFmpeg-devel] [PATCH 3/5] avcodec/bsf/hevc_mp4toannexb: Don't realloc when creating new extradata Andreas Rheinhardt 2024-02-19 2:07 ` James Almer [this message] 2024-02-19 10:56 ` Andreas Rheinhardt 2024-02-18 2:44 ` [FFmpeg-devel] [PATCH 4/5] avcodec/bsf/vvc_mp4toannexb: Factor creating new extradata out Andreas Rheinhardt 2024-02-18 2:44 ` [FFmpeg-devel] [PATCH 5/5] avcodec/bsf/vvc_mp4toannexb: Don't realloc when creating new extradata Andreas Rheinhardt 2024-02-18 2:50 ` [FFmpeg-devel] [PATCH 1/5] avcodec/bsf/(hevc|vvc)_mp4toannexb: Ensure extradata_size < INT_MAX James Almer 2024-02-18 12:16 ` Andreas Rheinhardt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e84728bd-09a6-4695-83e0-2f7fdaf51967@gmail.com \ --to=jamrial@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git