On 3/13/23 12:58, James Almer wrote: > On 3/13/2023 1:56 PM, Raphaël Zumer wrote: >> On 3/13/23 12:09, Andreas Rheinhardt wrote: >>>> >>>> +/** >>>> + * Parse the user data registered ITU-T T.35 to AVbuffer >>>> (AVDynamicHDRVivid). >>>> + * @param s A pointer containing the decoded AVDynamicHDRVivid structure. >>>> + * @param data The byte array containing the raw ITU-T T.35 data. >>>> + * @param size Size of the data array in bytes. >>>> + * >>>> + * @return 0 if succeed. Otherwise, returns the appropriate AVERROR. >>>> + */ >>>> +int av_dynamic_hdr_vivid_from_t35(AVDynamicHDRVivid *s, const uint8_t >>>> *data, >>>> + int size); >>> Who has an interest in this function being public? >>> >>> - Andreas >> I have no need for it so can change it to avpriv_ considering there's no >> serialization function available for it, if there's no objection to that. >> >> Raphaël Zumer > No, just don't move it out of libavcodec. Unless it's needed elsewhere, > it can stay there as is.
The inconsistency between HDR10+ and Vivid will be confusing IMO if one of them is left in libavcodec and the other is moved to libavutil. What are the specific concerns with making it public (or avpriv), aside from it not being useful without a corresponding serialization function? 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".
