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