From: "Raphaël Zumer" <raphael.zumer@vimeo.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avutil: add HDR10+ dynamic metadata serialization function
Date: Mon, 13 Mar 2023 19:30:41 -0400
Message-ID: <59b9c8fb-0e15-c6f3-f0e4-757cd1b7717c@vimeo.com> (raw)
In-Reply-To: <a4b97b67-82a7-2490-e289-e07e53f77362@gmail.com>
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".
prev parent reply other threads:[~2023-03-13 23:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 21:39 Raphaël Zumer
2023-03-13 22:20 ` James Almer
2023-03-13 22:35 ` Andreas Rheinhardt
2023-03-13 23:19 ` Raphaël Zumer
2023-03-13 23:25 ` James Almer
2023-03-13 23:30 ` Raphaël Zumer [this message]
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=59b9c8fb-0e15-c6f3-f0e4-757cd1b7717c@vimeo.com \
--to=raphael.zumer@vimeo.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