Re: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function

["Raphaël Zumer" <raphael.zumer@vimeo.com>]

On 3/12/23 17:52, James Almer wrote:
> On 3/12/2023 6:50 PM, Raphaël Zumer wrote:
>> I expanded on this in another email in the chain, but the buffer size needs to be communicated to the user, as it is not embedded in the payload. It seems needlessly convoluted to me to create a separate function solely to calculate the size of the buffer so that it can be allocated by the user and passed to the serialization function, and I cannot think of another solution that would not be even more convoluted and awkward for the user.
>>
>> I don't understand how going from AVBufferRef to uint8_t* is more complicated than the reverse. The buffer in the AVBufferRef is allocated via av_malloc() and is directly accessible through the data field. Am I missing some detail?
>>
>> Raphaël Zumer
> You can do it like how the AVDynamicHDRPlus struct is allocated and its 
> size returned to the user in av_dynamic_hdr_plus_alloc(). That is
>
> uint8_t *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s, size_t *size);
>
> The function would then store the calculated size of the array on *size.

OK great, I will do that and address the remaining comments tomorrow.

Thanks

>> On 3/12/23 15:48, Anton Khirnov wrote:
>>> Quoting Raphaël Zumer (2023-03-02 22:43:29)
>>>> +/**
>>>> + * Serialize dynamic HDR10+ metadata to a user data registered ITU-T T.35 buffer,
>>>> + * excluding the country code and beginning with the terminal provider code.
>>>> + * @param s A pointer containing the decoded AVDynamicHDRPlus structure.
>>>> + *
>>>> + * @return Pointer to an AVBufferRef containing the raw ITU-T T.35 representation
>>>> + *         of the HDR10+ metadata if succeed, or NULL if buffer allocation fails.
>>>> + */
>>>> +AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s);
>>> Why is this an AVBufferRef rather than a plain av_malloced() uint8_t
>>> array? You can very easily turn the latter into the former, but the
>>> reverse is a lot more annoying.
>>>
>> _______________________________________________
>> 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".
> _______________________________________________
> 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".
_______________________________________________
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".