Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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