From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 8A8384D6F4 for ; Sun, 1 Jun 2025 20:46:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 2072768D968; Sun, 1 Jun 2025 23:46:06 +0300 (EEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 4E78768D80B for ; Sun, 1 Jun 2025 23:45:59 +0300 (EEST) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-450cf214200so33227245e9.1 for ; Sun, 01 Jun 2025 13:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1748810758; x=1749415558; 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=yfLTOxJ6ZBIhTzRIk0Q96PFU7utjTShfgiTLtz++ROQ=; b=IiSjPwGSm+HSOlh2gDDi9BvckLWZNGK5mzECxpU2rRuPrtQvpLTuaAotaAPTAHDupi wokofb2Vs8iA3Zd5QWGgaQHIf3Pb2c796F0bo9NsDjqoMKTlAF7/ZpCSOZLVu10u6oVv fAURUbMpFoGDI0KXhImOfoLS2mcMyQGF8i/u4yEcwBsvwTuaiJCHhGkqj5lpZYPfpYcl z5sdfVkGGMMlU2tzLOqTACweYVlANdeXcCIdJuHjksgokOqdgXqsdmyhh4z0nKYEK8uH kwaglId8sYOoPRQdgnD2Z7RXm3oZngndesH76pSmlKxpcPHEQvgeArt8ihi8zt8xYXUB 2a3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748810758; x=1749415558; 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=yfLTOxJ6ZBIhTzRIk0Q96PFU7utjTShfgiTLtz++ROQ=; b=utmtwvx606RBcRQo77ANFAKoFcI4RYlrCk3zfyz3rSfErny5nxbMLnT0+v0EOUzUXn zwExjgrblVXR+6G7CQYfmpSWXFMLYXBMIo7WtUnRExbV8uQPWB1u0uuJYq+fLkli9plH FyyxSYY927mBDRi2GNlzHeUz0E6SEzUr2917qVOOxxX2F3xwX7N5Scx+1gu+LsZDeRp9 QD5SVaVxH12XqXVY7Hs9hjBy8cxfpWESTSdero87n/TEVdSVHWb/3F8G+xULZH2CLRdo 8Shn2XZdn2cOl+5KUxfR3GTKDW7kHT+n3HMUBrugCyFvxntyflmkkEzDo/BSdr4X+l0Y Cc9Q== X-Gm-Message-State: AOJu0YyeRCgwyEs3nxccfod1JqVWZJE4NwnhAnZ3x0JHXb7X7+bueJtn jrQaRlw3g1APhenRb2u2qwkWq6kPMkneNDX78PHhJN7kI5RfBXgGjTcIIoiLPMh2MtoWp6WzUWD CCp2j X-Gm-Gg: ASbGncsZjukgE9ofoTzF7nxTAdaxjYCBqaNRioer3aDKnAnvMtqqkxavmNTzF5KYU9u uFcDiTQ5NAIJXUOatYNx3geBVDsU29kMYggcupQ9TT8zfAK30JNMQywTNQQn13MMJqPZLjKR+L6 msS5RBOiTV9LEnLLtdRW2+h9XLut9/W/EU8EFk0COdz98HDm4rj5mObwRBsAfnDwL8BEZBnvprN KA1NC9kMFhlmMiXQVivbvyQslwiOgZMrsNYXPDoNZXEeqrR7uW3Gryv+0fg9o76fnfoWuO12qOE NzNBdRR/8U6dp30RcUzfBuP2OBjqKdsJy7agg2ESbsW9S2nh7DoOBWZJ+XZdSaCYsgB0fjnhJlA dBITVTWQxTZTJKMSrKLBmMoAu X-Google-Smtp-Source: AGHT+IHVITX56UEJjMHOnVXWvA/i/81KcpOCzVdkbbCrtO1OEXws4sx4QM7DnpP1nLvtFw0ls+SehA== X-Received: by 2002:a05:600c:5250:b0:450:d422:2092 with SMTP id 5b1f17b1804b1-450d880bf0bmr80908355e9.8.1748810758019; Sun, 01 Jun 2025 13:45:58 -0700 (PDT) Received: from [192.168.0.15] (cpc92320-cmbg19-2-0-cust719.5-4.cable.virginm.net. [82.13.66.208]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe7440asm12751731f8f.58.2025.06.01.13.45.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Jun 2025 13:45:57 -0700 (PDT) Message-ID: Date: Sun, 1 Jun 2025 21:45:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: From: Mark Thompson In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 01/11] avcodec/vulkan_encode_h264: Fix memleak on error 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 06/05/2025 00:37, Andreas Rheinhardt wrote: > Patches attached. > > - Andreas > > > [PATCH 05/11] avcodec/cbs,cbs_jpeg: Split ff_cbs_append_unit_data() Suggest assert0 for all error cases in cbs generic code, since none of them are inner-loop performance sensitive. Patch looks good. > [PATCH 06/11] avcodec/cbs: Allow to avoid refcounting/data copying Having force_refcounting set to one at init makes me think the sense of it should be other way around? ("disable_refcounting"?) Would it be sensible for the new checks for data_ref to assert that you are not in a refcounting case? Also wondering whether we should have a new helper function something like: int ff_cbs_make_unit_data_ref(SomethingContexty *c, AVBufferRef **ref, const CodedBitstreamUnit *unit) { av_assert0(!*ref); if (unit->data_ref) { *ref = av_buffer_ref(unit->data_ref); if (!*ref) return AVERROR(ENOMEM); } else { av_assert0(c->disable_refcounting); } return 0; } to avoid the repeated code you add in the various codec files. > [PATCH 07/11] avcodec/apv_parser: Don't use dummy AVBufferRef* > [PATCH 08/11] Revert "avcodec/cbs: add an AVBufferRef input argument to ff_cbs_read()" Yes, this ends up being a nicer answer. > [PATCH 09/11] avcodec/av1_parser: Avoid copying data It's not obvious that this does the right thing with the persistent reference to the sequence header object. Can you explain further how that is working? > [PATCH 10/11] avcodec/cbs_bsf: Avoid creating unnecessary references Does this not add a significant new constraint on all bsfs using the cbs_bsf structure? It's unclear to me whether works in all cases such as those where new units are added. > [PATCH 11/11] avcodec/bsf/trace_headers: Avoid creating unnecessary references Same thought as 9 in other codecs, but fine if 9 is. Thanks, - Mark _______________________________________________ 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".