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