From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E5D544976D for ; Mon, 19 Feb 2024 02:07:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1D48D68D29E; Mon, 19 Feb 2024 04:07:28 +0200 (EET) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4C86A68C92E for ; Mon, 19 Feb 2024 04:07:20 +0200 (EET) Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1db51e55023so19122145ad.1 for ; Sun, 18 Feb 2024 18:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708308437; x=1708913237; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9vUu5jID+o/bhL7Ly20J7GB/yCv2jD7W4/PUXNp3xTQ=; b=l2AkseCicG84n3p7fIjQ0cDCXVHuVViN/mKmgAWhvTdSFDFIyJc9xoqDKkWB/RSoD9 N9nxVjrqicJC6cbLhQzkjoyEw+QzQ4rTgIyI+/OK6RQO5uV6x7xSyqsynrSZy2AiteeS VYo5OGk6l27XXFO9hkSy3lt8aRN6HePUMsP2QGGERTwpqywsAZMfhHeoGf9VXy1fM268 F1MlYuP2ttH4Qxmt5ZcXgmxaHeal3HuRn82RvC4uSNuxmcVGZngUqM16Vhsg626ZkDns kmdpg/D60kLFIM7FKgr5DAjpmAnQtI4ApDiq4nQ/hWc3JVYCohPEWAhJ/zBUb5OiS7UW 1N4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708308437; x=1708913237; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9vUu5jID+o/bhL7Ly20J7GB/yCv2jD7W4/PUXNp3xTQ=; b=xNmLOdes6UDyvCGRB4e0iKoiufGBbqtKgJtT3XtQ0Ob5qMEjpknX+zmCCAmZG4aGaw LkYGD8kO3e0T2hTSWQipi6Qt/B3JPdQmBYveKsDEAs0ac7jXgddds7q7LnJ7C9EbeBHG V1o+E7wxJWYuW17n58brxfY/vTrDbTxLxm74TjzVLPpfrdZsl9pQ6OdmKyfjKmPYlPoj Q5VCKyGCvW7hZ8XuodeRDDlD31vRT3utOtbvg3Eik8LiZpGVcDD9n12OoHWl0qNcKHlU FYgfreZZpRDut80s4nM/zHCLAhbP9RKEDoLbymvNNiUo4nyYKKOYnJlmjMgbYhMLgMJ5 /zcg== X-Gm-Message-State: AOJu0YyQtqaXggom4YCl05KFiII+1exzJZtz9tRYoxZV7/FTbfL4Lmi+ uIc8A/MvuZvPVornpkPQBAyqYZJYVDkuI+UZJpDYD+8Hoh3clHOGpZo/4I+U X-Google-Smtp-Source: AGHT+IEg8SyqEqjXZLIIsHZSVrLR8ez+rO93AIom/dYoM1crpHaO2mmKuG7rb0cWVmZsGz3/R0ipEQ== X-Received: by 2002:a17:902:b905:b0:1db:4f01:bcc8 with SMTP id bf5-20020a170902b90500b001db4f01bcc8mr9099839plb.54.1708308436589; Sun, 18 Feb 2024 18:07:16 -0800 (PST) Received: from [192.168.0.16] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id j6-20020a17090276c600b001da1ecb05f9sm3224079plt.240.2024.02.18.18.07.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Feb 2024 18:07:16 -0800 (PST) Message-ID: Date: Sun, 18 Feb 2024 23:07:16 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 3/5] avcodec/bsf/hevc_mp4toannexb: Don't realloc when creating new extradata X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 > --- > 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".