VLC ignores MKV color transfer tag and sets it to HD content transfer function for SD content

changed the description

assigned to @robUx4

changed title from [MAJOR] VLC ignores MKV color transfer tag and sets it to HD content transfer function for SD content to VLC ignores MKV color transfer tag and sets it to HD content transfer function for SD content

Do you have a sample file ?

While trying to cut a video to give you I noticed that most of these tags are not support in Matroska v2. This is the version ffmpeg outputs. The tags not in v2 are

TransferCharacteristics
Primaries
Range
Colour

These are dropped when running mkclean on the file.

The issue now is that VLC is reading some of these incorrect tags, but not all of them. The samples below show it is reading the Primaries tag and setting the wrong transfer function. I need to figure out how to convert the container to Matroska v4 to test proper tagging with VLC and I'll update you then. Regardless, VLC should read all or none because it causes color shift.

These are the samples. https://www.dropbox.com/s/h0cp1edx2os61rs/NoTags.mkv?dl=0 https://www.dropbox.com/s/3amnzbnm9acwgeb/Tags.mkv?dl=0

It would seem as though VLC does not support Matroska v4 yet. I created a file and it just doesn't play. The ffmpeg created file has these properties

Document type version 4
Document type read version 2

When using mkclean to clean and optimize it with the --doctype set to v4, it gets these properties

Document type version 4
Document type read version 4

I'm using MKVToolNix Info Tool to see this information. According to this, the file is fine, but VLC refuses to play anything with Document type read version as 4. Media Player Classic also cannot play this file, so I have no idea how to create a v4 matroska container successfully, or nothing even supports it.

This is as far as I can go. I've linked the version 4 file that I cannot get to play in case you want to look at it. It's the same as Tags.mkv, just ran through mkclean with doctype 6 (v4)

https://www.dropbox.com/s/8u1xrak64nm1lgt/Tagsv4.mkv?dl=0

added Component::Demuxers: MKV label

This is not really a bug. The smpte170m and BT.601 values are the same. That's why mediainfo reports BT.601. And the transfer function are the same between BT.601 and BT.709. In VLC we use the 709 value and so we report that. But in the end it's all the same values.

There is a color shift when the transfer function is reading as BT709 and primaries as BT601. Maybe there is a bug with how the transfer function is implemented?

...

On Mon, May 23, 2022, 04:10 Steve Lhomme (@robUx4) gitlab@videolan.org wrote:

Steve Lhomme commented:

This is not really a bug. The smpte170m and BT.601 values are the same. That's why mediainfo reports BT.601. And the transfer function are the same between BT.601 and BT.709. In VLC we use the 709 value and so we report that. But in the end it's all the same values.

-- Reply to this email directly or view it on GitLab: #26999 (comment 326368) You're receiving this email because of your account on code.videolan.org.

VideoLAN code repository instance

Our ISO_23001_8_TC_BT_601 (6) value is mapped to TRANSFER_FUNC_BT709 internally. Looking at FFmpeg, it seems for 601 they use AVCOL_TRC_SMPTE170M:

AVCOL_TRC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 or 625 / ITU-R BT1358 525 or 625 / ITU-R BT1700 NTSC

But then if you look in their colorspace filter, the transfer function is exactly the same

static const struct TransferCharacteristics transfer_characteristics[AVCOL_TRC_NB] = {
    [AVCOL_TRC_BT709]     = { 1.099,  0.018,  0.45, 4.5 },
...
    [AVCOL_TRC_SMPTE170M] = { 1.099,  0.018,  0.45, 4.5 },

Same thing in this function

avpriv_trc_function avpriv_get_trc_function_from_trc(enum AVColorTransferCharacteristic trc)
{
    avpriv_trc_function func = NULL;
    switch (trc) {
        case AVCOL_TRC_BT709:
        case AVCOL_TRC_SMPTE170M:
        case AVCOL_TRC_BT2020_10:
        case AVCOL_TRC_BT2020_12:
            func = avpriv_trc_bt709;
            break;

This is also what I remember when I went through all the specs to find all the values.

So whether you use SMPTE 170M, BT.601 or BT.709 for the transfer function, the result should be exactly the same.

mentioned in merge request !1957 (merged)

mentioned in merge request !1971 (merged)

After reading the documentation below

https://dri.freedesktop.org/docs/drm/media/uapi/v4l/colorspaces-details.html

I can see that you are right about the functions being the same.

Although the functions are the same, I believe a more accurate label for the transfer function within the Codec Information tab would be best. Not everyone would know the functions are the same, and like me, would assume there was something wrong.

I managed to get Matroska v4 with mkvmerge, and it reads the same with no problem. I'm guessing VLC's default behavior for SD content isn't set as BT601 as default when no tags are set, which is why I am seeing color shift. I'm not sure what the proper way of handling that would be.

Anyways, thanks for clearing this up.

mentioned in commit f9f802a4

BT.709 and BT.601 and BT.2020 (only for 10 bit, not for 12 bit) are all the same SDR transfers. Sigh.

This wouldn't be an issue, but it is setting the transfer function to BT709 for SD content, which is wrong.

No, that does not matter at all.

Regardless, VLC should read all or none because it causes color shift.

In fact it is you who did not tag the matrix is what caused a color shift. We do not support transfers or primaries anyway, so it does not matter (we do support HDR transfer functions PQ and HLG, not SDR ones and we support BT.2020 primaries, but not SMPTE C (which is what BT.601 NTSC is)).

VLC ignores MKV color transfer tag and sets it to HD content transfer function for SD content

Child items 0

Activity