On Thu, Oct 21, 2021 at 4:49 PM Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > --- > All known encoders, etc. expect RPUs in this format, to my knowledge. > (There is no spec for parsing the RPUs, even privately, and not a single > piece of software that would benefit from that
DoVi Profile 5 and 7 rendering requires the data within these RPU entities, AFAIK (as it contains various values to correctly configure the custom color space). So software such as libplacebo where haasn has made efforts towards implementing the non-standard color space utilized would benefit from having the contents. So while there clearly are two separate use cases, I would note that saying "nothing would see any use from the bytes within these structures" is maybe a bit disingenuous. The two use cases being: 1. Just re-encoding the content. The contents of these RPU buffers being unrelated and only passthrough is necessary. 2. Trying to gather the information of these metadata units regarding interpretation of the received image. Both are clearly valid use cases, and we should IMHO support both, at least on the AVFrame level. Not that I mean that you should implement the parsing of these metadata units, since it is clear you want to keep away from that part of the work :) . > - and it is a legal minefield > which I am not going to touch.) While with this I agree with completely. Or at least given the D company's track record :P . That said, just parsing the metadata units is probably much less of a swamp than actually trying to utilize the metadata to properly render Profile 5 or 7 video. For the record, there are at least two known to me OSS implementations of RPU parsing/writing, one being made in Java and the other being made in Rust. 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".