1768824 - macOS BT2020 colorSpace video with BT709 transfer function does not render correctly

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[bugzilla.mozilla]

Attachment: phsyc-hero.webm

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

View this WEBM file, either on its own or embeded in a page.
https://assets.habito.com/homepage/hero-animation-2021-12-20-tablet.webm

The file is also attached to this issue.

Actual results:

The video looks overly compressed and the colours are wrong.

Expected results:

The video should not look over saturated and compressed. I.e., as displayed by Firefox 99.0.1, or Google Chrome.

Comment 1

[bugzilla.mozilla]

For some reason, the video attachment displays fine embedded within this page. If click the attachment link or copy the video link and open just the video in a new tab, then Firefox no longer renders the video properly.

Comment 2

[bugzilla.mozilla]

Just seen the Hardware has been set to x86_64. I don't know whether it's relevant but I'm on an M1 Mac.

Comment 3

[bugzilla.mozilla]

Attachment: screen-recording

Here's what the video looks like when rendered in correctly.

Comment 4

[bugzilla.mozilla]

Tested on Firefox 100.0 on Linux and there are no issues.

Comment 5

[C.M.Chang[:chunmin]]

Hi, thanks for reporting this.!

(In reply to bugzilla.mozilla from comment #0)

Created attachment 9276048 [details]
phsyc-hero.webm

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

View this WEBM file, either on its own or embeded in a page.
https://assets.habito.com/homepage/hero-animation-2021-12-20-tablet.webm

If I open the video via the link directly, the color seems ti match the video in comment 3 in my MBP M1Max. However, the color of the video embedded in this page is different from the one in comment 3, so something goes wrong here. Does the video

The file is also attached to this issue.

Actual results:

The video looks overly compressed and the colours are wrong.

Expected results:

The video should not look over saturated and compressed. I.e., as displayed by Firefox 99.0.1, or Google Chrome.

1. just to make sure, so the problem starts from FF100, right? Can you use the https://mozilla.github.io/mozregression/ to help us find out which version causing the problem?
2. Google Chrome 101 on my MBP M1Max has the same problem (key's color is yellow rather than orange). Does the Chrome works as expected on your mac?

In addition, can you share the information in your about:support page? This might be helpful for us to do further debugging.

Comment 6

[C.M.Chang[:chunmin]]

(In reply to bugzilla.mozilla from comment #2)

Just seen the Hardware has been set to x86_64. I don't know whether it's relevant but I'm on an M1 Mac.
Just test this on a intel x86_64 mac and the problem can be reproduced.

Comment 7

[C.M.Chang[:chunmin]]

Hi Brad, do you have any idea what the problem might be?

Comment 8

[bugzilla.mozilla]

If I open the video via the link directly, the color seems ti match the video in comment 3 in my MBP M1Max. However, the color of the video embedded in this page is different from the one in comment 3, so something goes wrong here.

Nice, that's the same as my experience

1. just to make sure, so the problem starts from FF100, right? Can you use the https://mozilla.github.io/mozregression/ to help us find out which version causing the problem?

Yep, it starts from 100. Or at least I have tried a version of FF99 that worked and a version of FF100 that doesn't.

Here's the output from mozregression after finding the build with the issue:

DEBUG : Found commit message:
Bug 1745492 Part 8: Update reftest expectations. r=media-playback-reviewers,alwu

Differential Revision: https://phabricator.services.mozilla.com/D140661

2. Google Chrome 101 on my MBP M1Max has the same problem (key's color is yellow rather than orange). Does the Chrome works as expected on your mac?

I didn't have the issue with either Google Chrome 100 or 101. Not sure if this is your understanding already, but the key should be yellow rather than orange.

Would you mind sharing the information in your about:support page? This might be helpful for us to do further debugging.

Yup, I'll attach a json file

Comment 9

[bugzilla.mozilla]

Attachment: about-support.json

Comment 10

[Brad Werth [:bradwerth]]

This is an in-the-wild sighting of Bug 1765187. Here's the MediaInfo output "Video" section:

Video
ID                                       : 1
Format                                   : VP9
Codec ID                                 : V_VP9
Duration                                 : 6 s 13 ms
Width                                    : 678 pixels
Height                                   : 1 024 pixels
Display aspect ratio                     : 0.662
Frame rate mode                          : Constant
Frame rate                               : 29.970 (30000/1001) FPS
Color space                              : YUV
Writing library                          : Lavc58.134.100 libvpx-vp9
Language                                 : English
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.2020 non-constant
VENDOR_ID                                : [0][0][0][0]

The video uses BT2020 primaries with the BT709 transfer characteristics. Firefox doesn't handle that correctly. We had thought this was an uncommon encoding that wouldn't be encountered by users, but here we are. I'll add this video to the other bug and raise its priority.

Comment 11

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #10)

The video uses BT2020 primaries with the BT709 transfer characteristics. Firefox doesn't handle that correctly. We had thought this was an uncommon encoding that wouldn't be encountered by users, but here we are. I'll add this video to the other bug and raise its priority.

Changed my mind. This shows that BT2020 matrix coefficients are overwriting the BT709 transfer characteristics, which is slightly different than the other bug and may be able to be fixed more easily. We'll keep this as a separate bug.

Comment 12

[Brad Werth [:bradwerth]]

Attachment: Bug 1768824 Part 1: Track transfer characteristics for BT709.

BT709 transfer characteristics may be specified in videos even if they don't
use the BT709 colorSpace. This change also makes BT709 the default, since it
is the safest option for unspecified cases.

Comment 13

[Brad Werth [:bradwerth]]

Attachment: Bug 1768824 Part 2: Set macOS transfer functions independently of colorSpace.

This creates a helper function in a new class gfxMacUtils that makes the
software and hardware decoders use the same logic. The new class was
necessary because gfxUtils is included in many files that don't include
CoreFoundation headers and would hit namespace collision if it was included
there.

Depends on D146734

Comment 14

[C.M.Chang[:chunmin]]

(In reply to Brad Werth [:bradwerth] from comment #10)

The video uses BT2020 primaries with the BT709 transfer characteristics. Firefox doesn't handle that correctly. We had thought this was an uncommon encoding that wouldn't be encountered by users, but here we are. I'll add this video to the other bug and raise its priority.

This sounds like a platform-independent bug. I guess other platforms will have the same problem as well?

Comment 15

[Brad Werth [:bradwerth]]

(In reply to C.M.Chang[:chunmin] from comment #14)

(In reply to Brad Werth [:bradwerth] from comment #10)

The video uses BT2020 primaries with the BT709 transfer characteristics. Firefox doesn't handle that correctly. We had thought this was an uncommon encoding that wouldn't be encountered by users, but here we are. I'll add this video to the other bug and raise its priority.

This sounds like a platform-independent bug. I guess other platforms will have the same problem as well?

You're correct, but macOS is the only Firefox platform that attempts to render HDR videos (with the BT2020 colorSpace). So other platforms are getting an acceptable fallback by assuming BT709 colorSpace.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ce078616e4eb
Part 1: Track transfer characteristics for BT709. r=media-playback-reviewers,alwu
https://hg.mozilla.org/integration/autoland/rev/587a07bf5f39
Part 2: Set macOS transfer functions independently of colorSpace. r=media-playback-reviewers,alwu

Comment 17

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/ce078616e4eb
https://hg.mozilla.org/mozilla-central/rev/587a07bf5f39

Comment 18

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on Firefox 102.0(build ID: 20220623063721) on macOS 11. Verified as fixed on Firefox 103.0b4(build ID: 20220703190044) and Nightly 104.0a1(build ID: 20220703213709) on macOS 10.12 and macOS 11.