[FFmpeg-devel] [PATCH] fftools/ffplay: 240M matrix is not the same as BT.601

[Valerii Zapodovnikov]

вт, 8 июн. 2021 г., 5:28 Michael Bradshaw <mjbshaw-at-google.com at ffmpeg.org
>:

> I'll just chime in and say:
>
> FIXME comments aren't that helpful. It would be more helpful to av_log when
> you detect you've hit an unsupported situation.
>

How should I know what are unsupported situations? I mean sure, sYCC
(BT.709 primaries with BT.601 matrix and sRGB transfer) is such a case, but
I am not sure what else and it is impossible to detect it (also BT.601
matrix with classic BT.601/709/2020 transfer and SMPTE C primaries, like on
trac)). Because were it possible, I would have JUST FIXED IT.

Also, that will still be not enough as primaries must be also color
managed, except ffplay does not support color managment. BT.601 matrix vs
BT.709 matrix vs BT.2020-ncl matrix is not all, I hope you understand that.
With the case BT.2020-ncl it is not it that make it that bad for BT.2100
(HDR). It is PQ transfer function. Not even primaries.

As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But
> SDL doesn't support SMPTE 240M. It only supports:
>

Yes, I know that. Can you imagine?? Oh, my.


> SDL_YUV_CONVERSION_JPEG,  /**< Full range JPEG */
> SDL_YUV_CONVERSION_BT601, /**< BT.601 (the default) */
> SDL_YUV_CONVERSION_BT709, /**< BT.709 */
> (and automatic, but that's just BT.601 + BT.709)
>
> It's probably better to fall back to using BT.709 matrix for SMPTE 240M
> (with a warning log) since BT.709 is closer to SMPTE 240M than BT.601 is.
>

No. This uses sRGB transfer. sRGB transfer is not close BT.709 OETF (or its
BT.1886 EOTF) because sRGB is an EOTF in by itself. Please do not say it
again.

_______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>