On 3/13/2023 8:19 PM, Raphaël Zumer wrote:
On 3/13/23 18:35, Andreas Rheinhardt wrote:
size being mandatory is different from similar APIs. There is even a
usecase without size: If you simply feed this to something that expects
the data to be serialized and trust the data to be complete, you don't
need the size.
OK, I'll amend that.
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.
And since av_dynamic_hdr_plus_from_t35() uses GetBitContext to parse the
buffer you feed to it, the output of the serialization function should
ideally work with it without issues.
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-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
