Valerii Zapodovnikov

> YUV444_10 which at least minimizes color space loss For 8 bit RGB 10 bit should be enough (if no dither is applied), DITHER_NONE.

> , it might default to 0.005 nits for output in PQ. At least that's the behaviour in `plplay`. That is horrible. BT.709 is scene refferred, so no black point...

A test sample where CLL SEI changes as scene changes to test part of the standard that allows to change static metadata. MDCV does not change though, at least here....

> `sig_peak` seems to be the peak used to convert to when mpv converts to pq/hlg. Yeah this is this commit https://github.com/mpv-player/mpv/commit/ef6bc8504a945eb6492b8ed46fd5a1afaaf32182 and is from ITU-R report BT.2408. Please note...

Why BT.709 transfer does not turn off peak calculation if HDR10 metadata is present?? See sample here (NO, IT IS not PQ and NOT HDR, you can forse PQ it...

> Edit: [we do](https://github.com/mpv-player/mpv/blob/master/video/mp_image.c#L902) Yeah, but warnings are still there.

> That has nothing to do with HDR peak calculation. Okay then. I just thought that those warnings are extra calculations when they are not needed.

> Having support for NV30 (10-bit 4:4:4) would be great but is not trivially implemented I'm afraid. What about P016? https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/ https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/ Of course outputing 4:2:0 is imho a bad...

> --target-prim=dci-p3 This is wrong. No one uses dci-p3. All of it is display-p3 or actually p3-d65. Wow.

Yeah, well. That is fake info, libplacebo does the render not counting for this. > Colormatrix: bt.2020-ncl That would be false in any case scenario. It does not have any...