2057570 - AV1 "Full range" color HDR videos not working on Windows in Firefox 153

Status: RESOLVED DUPLICATE of bug 2008887

(Core :: Graphics: Color Management, defect, P2)

Description

[MiikaH]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

I noticed that some HDR videos still don't work in Firefox 153 on Windows (Nvidia).

Here is uploaded video that doesn't show up in HDR and instead looks faded out: https://static.miikah.fi/other/tests/av1_hdr/c904cf_av1_6s.mp4

On the other hand another AV1 HDR video works just fine for me:
https://static.miikah.fi/other/tests/av1_hdr/2d9079_av1_6s.mp4

Only difference between the two I can detect is that the working one has "limited" color range. The other one has "full" color range. Otherwise both are BT.2020 PQ with mostly identical encoding parameters.

Actual results:

The first video looks faded out and HDR nor tonemapping to SDR is active. Instead the video looks faded out.

Expected results:

The video should either appear in HDR (if client has HDR screen) or appear properly tonemapped so it doesn't look washed out (if client has SDR screen).

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ashley Hale [:ahale]]

Windows DXGI only has support for narrow range PQ videos (the enum https://learn.microsoft.com/en-us/windows/win32/api/dxgicommon/ne-dxgicommon-dxgi_color_space_type only has DXGI_COLOR_SPACE_YCBCR_STUDIO_G2084_TOPLEFT_P2020 but not a hypothetical DXGI_COLOR_SPACE_YCBCR_FULL_G2084_TOPLEFT_P2020), WMF has both (by way of having separate enums for color primaries, and transfer function - see https://learn.microsoft.com/en-us/windows/win32/api/mfobjects/ne-mfobjects-mfvideotransferfunction), and we internally have both (see https://searchfox.org/firefox-main/rev/589a93df90e7924d92b7a8bd03c773203ee70690/gfx/2d/Types.h#644 which defines BT2100_PQ_Full, and elsewhere this is stored as separate color primaries and transfer function which is also fine).

Currently we treat PQ full as if it was PQ narrow for this reason in the logic at https://searchfox.org/firefox-main/rev/589a93df90e7924d92b7a8bd03c773203ee70690/gfx/layers/d3d11/VideoProcessorD3D11.cpp#110 (this function exists in two places https://searchfox.org/firefox-main/search?q=DXGI+has+no+support+for+PQ&path=&case=false&regexp=false which we should also clean up sometime).

If this case is encountered, the about:support text includes the message GetSourceDXGIColorSpace: DXGI has no support for PQ transfer function with full color range for BT2020 content, treating as studio range.

Since the ShaderBlt code landed in Bug 2037689 we can handle this correctly because we don't need to map things to a DXGI enum to satisfy VideoProcessorBlt when we're not even using VideoProcessorBlt.

I'm rating this bug as S3 because I think that PQ full range content is quite rare on the web but we do need to handle this correctly as soon as we find some time to work on it.

Comment 3

[Ashley Hale [:ahale]]

Attachment: Bug 2057570 - BT2100 PQ Full range video in ShaderBlt on Windows by not translating through DXGI_COLOR_SPACE r?#gfx-reviewers

Comment 4

[BugBot [:suhaib / :marco]]

There is an r+ patch which didn't land and no activity in this bug for 1 week.
:ahale, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 5

[MiikaH]

Looks like this bug has been fixed in nightly (156.0a1) at some point (even though this report doesn't have mentions of fix being applied). So probably another related change fixed this too?

I also tested my recently added HDR video test catalog, and looks like Firefox HDR is finally getting in very reliable state in 155/156: https://miikah.fi/utils/browser_hdr_support

Windows 11 + Nvidia:

• All 10-bit VP9 and AV1 samples play correctly
• Even 10-bit HEVC works, but only 50% of the time. Other 50% of the page reloads video play throws "unsupported" error. Maybe a bug when the browser tires to load multiple HEVC videos at the same time...
• 8-bit and 12-bit HDR is still not rendering in HDR, but that is very rare to see on the web. 8-bit is usually some kind of misconfiguration.

MacOS:

• All 10-bit and 8-bit samples play correctly. Even 12-bit HEVC shows in HDR. So really nice compatibility!

Comment 6

[Ashley Hale [:ahale]]

I've been iterating on the patch because the fundamental issue here is misinterpreting PQ full range as PQ limited range, which causes it it to be higher contrast than intended. While iterating on the patch I am testing the sample on Bug 2061649 because we're making assumptions based on bit depth as well, which seem proximate to this issue.

Comment 7

[Phabricator Automation]

Comment on attachment 9617942 [details]
Bug 2057570 - BT2100 PQ Full range video in ShaderBlt on Windows by not translating through DXGI_COLOR_SPACE r?#gfx-reviewers

Revision D314806 was moved to bug 2008887. Setting attachment 9617942 [details] to obsolete.

Comment 9

[Ashley Hale [:ahale]]

This is being resolved in bug 2008887 as handling full range BT2100PQ is necessary regardless of whether it is P010 or NV12, and DXGI doesn't hvae an enum for full range PQ so we have to do our own thing in ShaderBlt.