[FFmpeg-devel] [PATCH] avcodec/options: Add options for inputing HDR10-related metadata

[Kenny McClive]

Lynne,

Please see my responses below.  I am not opposed to taking a different approach, but I could use some guidance on how to go about that.  This is my first contribution to FFmpeg, and I struggled to get this done.

> For HDR transcoding/tonemapping we rely purely on frame side data atm. How would adding
> new metadata to avcodeccontext work with this?

I don’t have enough context to say.  I am only aware of FFmpeg reading side data.  I haven’t seen any options that explicitly write to it.

> Would the avcodec metadata overwrite the
> avframe side data?

I’m not sure.  The code that I modified was retrieving side data from somewhere and writing that to the container.  I thought that might be coming from the source container; I’m not sure how you get frame-level data at the container-level.  The code that I added will override the data retrieved here if the options are set.

> We cannot break existing behavior as its actually used in production.
> Furthermore, considering all codecs which support HDR carry data rather than rely on the
> container, remuxing would break.

I disagree.  The change that I made does not have any effect unless the options are set.

> Some ideas were discussed about adding a bsf to deal with this,
> and if we were to add a bsf, it would make this patch largely redundant, apart from setting
> the container fields, which is only somewhat useful.

What is a bsf? Is that a filter? Is someone else working on that? I don’t care who implements this functionality as long as it gets done.

> For now, what's the problem with just using the AVFrame fields for the container as well?
> Then you'll only need a filter to set the metadata.

Can you access the AVFrame fields from the container functions in movenc and matroskaenc?  If we are talking about using a filter, it seems like it would be more conventional to write the data to the frames instead of the container.  However, I could use some guidance on how to get started with either of these approaches.

Thanks,
Kenny

> On Aug 11, 2020, at 4:19 AM, Lynne <dev at lynne.ee> wrote:
> 
> Aug 11, 2020, 03:47 by kenny.mcclive at me.com:
> 
>> Previously, the only way to input the master display and content light metadata required for HDR10 was through x265-params. Obviously, that only worked with x265. If you wanted to use a different encoder like nvenc, you were out of luck. The options specified are written to the container (mov or matroska) only. Additional work would be required to write it to frames. The default values for the master display options may seem unorthodox, but it allows you to differentiate between 0 (which some movies use) and unspecified. The same was not done for content light metadata because 0 seems to mean unspecified in other systems such as x265.
>> 
> 
> I don't like this as-is.
> For HDR transcoding/tonemapping we rely purely on frame side data atm. How would adding
> new metadata to avcodeccontext work with this? Would the avcodec metadata overwrite the
> avframe side data? We cannot break existing behavior as its actually used in production.
> Furthermore, considering all codecs which support HDR carry data rather than rely on the
> container, remuxing would break. Some ideas were discussed about adding a bsf to deal with this,
> and if we were to add a bsf, it would make this patch largely redundant, apart from setting
> the container fields, which is only somewhat useful.
> For now, what's the problem with just using the AVFrame fields for the container as well?
> Then you'll only need a filter to set the metadata.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".