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