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 4B5AA45A5F for ; Mon, 13 Mar 2023 23:30:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 980D468BD50; Tue, 14 Mar 2023 01:30:50 +0200 (EET) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 719D668B2EB for ; Tue, 14 Mar 2023 01:30:44 +0200 (EET) Received: by mail-qt1-f173.google.com with SMTP id l13so15096284qtv.3 for ; Mon, 13 Mar 2023 16:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimeo.com; s=google; t=1678750243; 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=33CJTStaRtbpNMUfjhxtwBxNx0wll91TAgf4IqTwwFQ=; b=o6YRXPsxVXBxlWbgC/eaz3l3YbvNSngDTKMybvk7O7kzlJQNWKDwSpuGb2t0sUwhs3 2BQygm51gJGb28zhWx21As7361q1bad9YbLBYL49moXB+pP3lyXywv5HI+W1yumGoxPR FzZDSKx+QoSknEOQgMSIxPYRgav0lhffO4Xvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678750243; 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=33CJTStaRtbpNMUfjhxtwBxNx0wll91TAgf4IqTwwFQ=; b=wdGnezXYPVCWltnmbEyI8J6uKv2btOFiThWKKU2PL6Nq9ogHPjg9Sv7Pmwo2GgU6hM NWD7AEnTnF8u4Is6WbZx+t8VJqvgwz4AORuK2X42J3s7REBdBpnZ639Q7erC9clfHKV3 AbvKNGsZnbgkJbWhUhCSgzTgLN4GHHMwfl9hWpYtTGVXMmy6CUwLr04PtrgVDYZHY46t X1JU+b42KuGaOyOiIuIg6C64lzkwrBas1JVZmAN20NCoxhipKHtBvrBPqZHc1hrmP6Dx Blo8GG8hVnTXsJ27yeg6JDC4L19kzWaJyzyhiE675tbDhNa752HZrVeh+YTWV4/7Fr2c bIiA== X-Gm-Message-State: AO0yUKWlxhapwfQ7+4HSujU48iKkseiU7LPdDN9t9cETe8Uady5hVodT U14bHG2+siZaKeFdXjGeK+aBjpBzRCUoNyVc1fq5vw== X-Google-Smtp-Source: AK7set9c2eJNkBPYy8L0u9Zz9SDGMXKMU2WxYAwCMuqU9dVnoZm0p4aBs5i2ils4vdzr1rU+HDWFJg== X-Received: by 2002:ac8:5fc1:0:b0:3ab:ceb9:10fd with SMTP id k1-20020ac85fc1000000b003abceb910fdmr61395446qta.25.1678750242524; Mon, 13 Mar 2023 16:30:42 -0700 (PDT) Received: from ?IPV6:2600:4041:6c:7000:1f01:20c:8ba9:815b? ([2600:4041:6c:7000:1f01:20c:8ba9:815b]) by smtp.gmail.com with ESMTPSA id p19-20020ac84093000000b003bfaae103f6sm719040qtl.89.2023.03.13.16.30.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 16:30:42 -0700 (PDT) Message-ID: <59b9c8fb-0e15-c6f3-f0e4-757cd1b7717c@vimeo.com> Date: Mon, 13 Mar 2023 19:30:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US, fr-FR To: ffmpeg-devel@ffmpeg.org References: <6f3fc186-0b7f-052c-ecfb-b884eace4fed@vimeo.com> From: =?UTF-8?Q?Rapha=c3=abl_Zumer?= In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avutil: add HDR10+ dynamic metadata serialization function 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 3/13/23 19:25, James Almer wrote: >>> You are allocating without any padding. This implies that one could not >>> use this buffer with our GetBit-API or in other places where one needed >>> a padded buffer. >> Is there any comparable code that does that? I feel like padding a buffer should be the responsibility of the caller for a public function, otherwise the user has to be aware of the padding to avoid embedding extra payload bytes accidentally (even though it is negligible in size), it is an extra manipulation if padding is not needed, and requires including an extra file to access the padding size. > The returned value in *size would not take the padding bytes into > account, so no way to include them accidentally anywhere. You either > know the size of the serialized data and trust the buffer is complete as > Andreas mentioned, or you read the size returned by the function. In > either case, the padding bytes are never considered. Right, I did not think it through. Will do. RZ _______________________________________________ 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".