Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avutil: move dynamic HDR metadata parsing to libavutil

[James Almer <jamrial@gmail.com>]

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