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 <d...@lynne.ee> wrote: > > Aug 11, 2020, 03:47 by kenny.mccl...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
