[FFmpeg-devel] [PATCH 1/2] avcodec/avutil: move dynamic HDR metadata parsing to libavutil
James Almer
jamrial at gmail.com
Mon Mar 13 19:10:13 EET 2023
On 3/13/2023 2:05 PM, Raphaël Zumer wrote:
> 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.
Why? The HDR10+ one is useful for libraries like lavf and external
container parsers, the Vivid one isn't.
> What are the specific concerns with making it public (or avpriv), aside from it not being useful without a corresponding serialization function?
You said it, it serves no purpose. Making something public (or exposed
internally as avpriv_) is done only when it will be used by code outside
the library where it resides.
More information about the ffmpeg-devel
mailing list