On Sat, Apr 11, 2020 at 5:49 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Am Sa., 11. Apr. 2020 um 16:08 Uhr schrieb Jun Zhao <mypopy...@gmail.com>: > > > > From: vacinfang <vacinf...@tencent.com> > > > > add dolby vision related header > > Apart from the name of the header file: > Could you explain why it is needed? > > Is the Dolby Vision metadata not a black box that libavformat > has to provide to interested decoders? >
There's usually two different things: 1. Metadata in the file confirming that this is indeed DoVi. This is what is being parsed. Otherwise the player application has no idea how to handle DoVi (many of the profiles are actually just re-brands of already standardized setups, while profiles 5 and I think 7 are the more interesting ones). 2. The kind of "black box" (RPU) metadata within NAL units 62. That is then what (for now) would be passed to a special metadata reader to enable correct rendering of f.ex. profile 5 clips. This patch set enables noting whether a file has the general metadata from 1. I have seen implementations of 2. around, and we might have a patch set for it at some point in the near future as we already have open source code to render the DoVi data w/o the dynamic metadata of those NAL unit 62 entries (see https://code.videolan.org/videolan/libplacebo/-/commit/f850fa2839f9b679092e721068a57b0404608bdc ). So to reiterate: - The container metadata lets a player figure out if the AVStream is flagged as DoVi and in which profile/level/does it have base|extension layer contained within it. - The NAL unit 62 metadata (RPUs) then enable correct rendering in case of a profile that is not backwards compatible with standard color spaces. Best regards, Jan _______________________________________________ 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".
