2068961 - Videos look washed out on macOS unless media.rdd-process.enabled is false

Status: VERIFIED FIXED

(Core :: Graphics: Color Management, defect)

Comment 1

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2039373

:bradwerth, since you are the author of the regressor, bug 2039373, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Jim Mathies [:jimm]]

[Tracking Requested - why for this release]:
Significant regression in video playback on macos.

Comment 3

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Add colour metadata test videos with explicit transfer functions. r?bradwerth

gen_combos.py cross combines a single colour space name into primaries,
transfer and matrix, so the generated corpus cannot express BT.2100 PQ or HLG,
or wide gamut SDR. Those are the cases where a decoder has to report a transfer
function that is not implied by the primaries, which is what the macOS
VideoToolbox path gets wrong.

Add a second, explicit set of combinations for those, signalled through
x265-params and svtav1-params so the values land in the bitstream rather than
only in the container, plus HEVC, which is the codec VideoToolbox most reliably
decodes in hardware on macOS and which the corpus had no coverage of at all.

The samples are transfer converted with zscale rather than merely tagged, so
regenerating them needs an ffmpeg built with libzimg. Within a combination the
samples are identical across codecs, so codec to codec comparisons isolate the
container and decoder rather than the encode.

Comment 4

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Test the colorspace attached to VideoToolbox decoded frames. r?bradwerth

Exhaustive over the cross product of transfer function and colour primaries,
because the rule is a pure function of those two and the combinations codecs
happen to emit are only a subset of what has to be right.

Plus one end to end check per side, decoding through VideoToolbox in process
and inspecting the IOSurface the compositor would receive: an SDR frame keeps
the colorspace VideoToolbox gave it, and a PQ frame still gets an explicit one.

Comment 5

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Only override the VideoToolbox buffer colorspace for wide gamut and HDR content. r?bradwerth

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3e3f1c26c5dd
https://hg.mozilla.org/integration/autoland/rev/cd2c2bcb80b3
Add colour metadata test videos with explicit transfer functions. r=media-playback-reviewers,ahale,azebrowski
https://github.com/mozilla-firefox/firefox/commit/6c455079a76a
https://hg.mozilla.org/integration/autoland/rev/b6b9b30cb25c
Test the colorspace attached to VideoToolbox decoded frames. r=ahale
https://github.com/mozilla-firefox/firefox/commit/a4f192aa6d64
https://hg.mozilla.org/integration/autoland/rev/963c8ed70a98
Only override the VideoToolbox buffer colorspace for wide gamut and HDR content. r=media-playback-reviewers,ahale,azebrowski

Comment 7

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/cd2c2bcb80b3
https://hg.mozilla.org/mozilla-central/rev/b6b9b30cb25c
https://hg.mozilla.org/mozilla-central/rev/963c8ed70a98

Comment 8

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:padenot, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox156 to wontfix.

For more information, please visit BugBot documentation.

Comment 9

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Add colour metadata test videos with explicit transfer functions.

gen_combos.py cross combines a single colour space name into primaries,
transfer and matrix, so the generated corpus cannot express BT.2100 PQ or HLG,
or wide gamut SDR. Those are the cases where a decoder has to report a transfer
function that is not implied by the primaries, which is what the macOS
VideoToolbox path gets wrong.

Add a second, explicit set of combinations for those, signalled through
x265-params and svtav1-params so the values land in the bitstream rather than
only in the container, plus HEVC, which is the codec VideoToolbox most reliably
decodes in hardware on macOS and which the corpus had no coverage of at all.

The samples are transfer converted with zscale rather than merely tagged, so
regenerating them needs an ffmpeg built with libzimg. Within a combination the
samples are identical across codecs, so codec to codec comparisons isolate the
container and decoder rather than the encode.

Original Revision: https://phabricator.services.mozilla.com/D323303

Comment 10

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Test the colorspace attached to VideoToolbox decoded frames.

Exhaustive over the cross product of transfer function and colour primaries,
because the rule is a pure function of those two and the combinations codecs
happen to emit are only a subset of what has to be right.

Plus one end to end check per side, decoding through VideoToolbox in process
and inspecting the IOSurface the compositor would receive: an SDR frame keeps
the colorspace VideoToolbox gave it, and a PQ frame still gets an explicit one.

Original Revision: https://phabricator.services.mozilla.com/D323304

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Broken rendering of SDR (non-HDR, meaning, the common case) videos: colors are washed out (blacks are grey, whites are grey). macOS only.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Open random videos (e.g. youtube is just fine) on macOS, Apple Silicon or regular, especially if they have dark regions: the blacks should be black. Safari or Chrome should have similar colors.

If on mac that is HDR capable, https://paul.cx/public/test-videos/test-videos.html?video=bt2111-hlg-3840x2160-libsvtav1-yuv420p10.webm should render super bright.

• Risk associated with taking this patch: medium
• Explanation of risk level: Reviewed by 2 people, well tested.
• String changes made/needed?: none
• Is Android affected?: no

Comment 12

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Only override the VideoToolbox buffer colorspace for wide gamut and HDR content.

Original Revision: https://phabricator.services.mozilla.com/D323305

Comment 13

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Add colour metadata test videos with explicit transfer functions.

gen_combos.py cross combines a single colour space name into primaries,
transfer and matrix, so the generated corpus cannot express BT.2100 PQ or HLG,
or wide gamut SDR. Those are the cases where a decoder has to report a transfer
function that is not implied by the primaries, which is what the macOS
VideoToolbox path gets wrong.

Add a second, explicit set of combinations for those, signalled through
x265-params and svtav1-params so the values land in the bitstream rather than
only in the container, plus HEVC, which is the codec VideoToolbox most reliably
decodes in hardware on macOS and which the corpus had no coverage of at all.

The samples are transfer converted with zscale rather than merely tagged, so
regenerating them needs an ffmpeg built with libzimg. Within a combination the
samples are identical across codecs, so codec to codec comparisons isolate the
container and decoder rather than the encode.

Original Revision: https://phabricator.services.mozilla.com/D323303

Comment 14

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Test the colorspace attached to VideoToolbox decoded frames.

Exhaustive over the cross product of transfer function and colour primaries,
because the rule is a pure function of those two and the combinations codecs
happen to emit are only a subset of what has to be right.

Plus one end to end check per side, decoding through VideoToolbox in process
and inspecting the IOSurface the compositor would receive: an SDR frame keeps
the colorspace VideoToolbox gave it, and a PQ frame still gets an explicit one.

Original Revision: https://phabricator.services.mozilla.com/D323304

Comment 15

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Broken rendering of SDR (non-HDR, meaning, the common case) videos: colors are washed out (blacks are grey, whites are grey). macOS only.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Open random videos (e.g. youtube is just fine) on macOS, Apple Silicon or regular, especially if they have dark regions: the blacks should be black. Safari or Chrome should have similar colors.

If on mac that is HDR capable, https://paul.cx/public/test-videos/test-videos.html?video=bt2111-hlg-3840x2160-libsvtav1-yuv420p10.webm should render super bright.

• Risk associated with taking this patch: medium
• Explanation of risk level: Reviewed by 2 people, well tested.
• String changes made/needed?: none
• Is Android affected?: no

Comment 16

[Paul Adenot (:padenot)]

Attachment: Bug 2068961 - Only override the VideoToolbox buffer colorspace for wide gamut and HDR content.

Original Revision: https://phabricator.services.mozilla.com/D323305

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/ec31063b1183
https://hg.mozilla.org/releases/mozilla-beta/rev/4829695b73fc
https://github.com/mozilla-firefox/firefox/commit/8c65133f84bc
https://hg.mozilla.org/releases/mozilla-beta/rev/df35c7e3506f
https://github.com/mozilla-firefox/firefox/commit/2017d3e1c703
https://hg.mozilla.org/releases/mozilla-beta/rev/a0ec873327d7

Comment 18

[Negritas Sergiu, Desktop QA]

Hello! I can confirm that the issue is fixed with firefox 157.0a1(2026-09-07) and 156.0b4 on MacOS 15.6.7.

I will update the flags and status of this issue accordingly.

Have a nice day!

Comment 19

[Donal Meehan [:dmeehan]]

Fx156 is now in release and 156.0 RC builds today