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

[James Almer]

On 2/27/2023 2:33 PM, Raphaël Zumer wrote:
> Resending this patch set due to my mail client messing with the line wrapping in the messages I sent earlier today.
> 
> Below is a copy of the initial explanation.
> 
> This patch set implements serialization for HDR10+ dynamic metadata
> (AVDynamicHDRPlus), which is the inverse operation of the existing
> ff_parse_itu_t_t35_to_dynamic_hdr10_plus() function. It also moves both
> functions from libavcodec to libavutil and makes them public. For
> consistency, the equivalent vivid HDR parsing function is also migrated,
> but I did not implement serialization for it. Finally, the patch renames
> those functions to av_dynamic_hdr_plus_from_t35() (for parsing) and
> av_dynamic_hdr_plus_to_t35 (for serialization), with the equivalent
> change being made for vivid as well.
> 
> The motivation for this change is to allow users to easily convert
> HDR10+ side data (which is parsed into AVDynamicHDRPlus) to a standard
> ITU-T T.35 payload that can be passed directly to applications that
> expect HDR10+ dynamic metadata in that format (e.g. x265 and rav1e
> encoders).
> 
> The return value of the serialization function is AVBufferRef*, which I
> expect to be contentious. Payload size is not embedded in the T.35 data,
> so it must be calculated, used to allocate a buffer, and returned along
> with that buffer to the user. As far as I'm aware, AVBufferRef is the
> simplest way to do that, but I will be happy to consider alternative
> solutions.
> 
> Please let me know if it is preferred to bump libavutil with the first
> commit, or with both of them, considering there are public API changes
> associated with each one.
> 
> Raphaël Zumer

Could you resend this patch and the last version of second one in a new 
set with proper commit messages for each of them? The text above would 
apply to a cover letter (patch 0/2) as it mentions the changes for the 
whole set plus review requests, instead of just the changes for this 
specific patch.

The single version bump in the second patch is ok, but you should also 
add an APIChanges entry to it listing all three functions you added.