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-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". _______________________________________________ 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".
