Open Bug 2057759 Opened 1 month ago Updated 32 minutes ago

Frames decoded in the RDD process lose their color space metadata when sent over the video bridge

Categories

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

defect

Tracking

()

People

(Reporter: david.torcivia, Assigned: chunmin, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: correctness, parity-chrome)

Attachments

(9 files)

Every video frame decoded in the RDD process and sent to the content process over the video bridge loses its color space metadata: RemoteVideoDecoderParent::ProcessDecodedData only fills YUVColorSpace, primaries, transfer function, and range in the shmem fallback path, and the texture path (which is what runs in practice on all desktop platforms) sends the defaults. The content side's GuessColorSpace for GPUVideoImage then reconstructs a color space from those defaults, which currently aliases to bt709 regardless of the stream.

Visible effect: VideoFrame.colorSpace in WebCodecs reports guessed values instead of the decoder's, for every software-decoded frame on Linux, Windows, and macOS (verified against current nightlies on all three). Chrome reports the decoder's values. This is the metadata sibling of bug 1969762 (which covers the pixel format and copyTo; see comment 9 there for the mechanics).

The one-line fix (hoist the extraction above the texture/shmem fork) is straightforward, but I prototyped it while working on bug 1969762 and it cannot land alone: forwarding the decoder's real values turns webcodecs/full-cycle-test.https.any.js?av1 "w/ stripped color space" red, because

  1. our encoders write no color info into the bitstream (bug 2057758), so
  2. the decoder falls back to display-size heuristics (DAV1DDecoder and VPXDecoder label SD streams BT601/BT470BG; the heuristic-primaries problem is bug 1869825), and
  3. the test then correctly observes that the decoded metadata contradicts the encoder's claimed color space.

In other words the test passes today only because the metadata is lost in transit. Landing order that keeps everything green and honest: bug 2057758 first, then this forwarding, with the heuristic-vs-signaled distinction from bug 1869825 (or a signaled-only forwarding rule) resolving the remaining canvas-sourced cases.

See Also: → 2057760
Severity: -- → S3
Priority: -- → P3
See Also: → 2056028
See Also: 20560282048686
Depends on: 2066869
Assignee: nobody → cchang
Attachment #9631302 - Attachment description: WIP: Bug 2057759 - Test remote decoded color metadata transport → Bug 2057759 - Test remote decoded color metadata transport
Attachment #9631303 - Attachment description: WIP: Bug 2057759 - Preserve decoded color metadata across remote image transport → Bug 2057759 - Preserve decoded color metadata across remote image transport
Attachment #9631304 - Attachment description: WIP: Bug 2057759 - Preserve FFmpeg decoded frame color metadata → Bug 2057759 - Preserve FFmpeg decoded frame color metadata
Pushed by amarc@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/5b0924fd3114 https://hg.mozilla.org/integration/autoland/rev/83742e9e5d33 Revert "Bug 2057759: apply code formatting via Lando" for causing build bustages @ FFmpegVideoDecoder

Backed out for causing build bustages

Flags: needinfo?(cchang)
Pushed by nfay@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/c9a0c82e582e https://hg.mozilla.org/integration/autoland/rev/2d9eabacbd54 Revert "Bug 2057759: apply code formatting via Lando" for causing reftest failure 720p.png.bt709.bt709.pc.yuv420p.av1.webm / 720p.png

Backed out for causing reftest failure 720p.png.bt709.bt709.pc.yuv420p.av1.webm / 720p.png

Backout link

Push with failures

Failure log

Blocks: 1869825

Preserving FFmpeg's decoded color metadata reduces the pixel differences for the full-range 8-bit and 10-bit AV1 cases. Update their draw-snapshot expectations to match the corrected output.

macOS, Firefox 155. Colors are washed out in video. Setting media.rdd-process.enabled=false immediately restores correct colors. Firefox 154 did not have the problem. Safari renders the same video correctly.

Pushed by cchang@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/01c45e1d0b91 https://hg.mozilla.org/integration/autoland/rev/a55bf6b19120 Test remote decoded color metadata transport r=media-playback-reviewers,alwu https://github.com/mozilla-firefox/firefox/commit/37d56c6540e4 https://hg.mozilla.org/integration/autoland/rev/4e1023a31f03 Preserve decoded color metadata across remote image transport r=media-playback-reviewers,alwu https://github.com/mozilla-firefox/firefox/commit/4f2697323872 https://hg.mozilla.org/integration/autoland/rev/0525781bc921 Test FFmpeg decoded frame color metadata r=media-playback-reviewers,alwu https://github.com/mozilla-firefox/firefox/commit/8765bd0c42d3 https://hg.mozilla.org/integration/autoland/rev/6fc26ec48e18 Preserve FFmpeg decoded frame color metadata r=media-playback-reviewers,alwu https://github.com/mozilla-firefox/firefox/commit/bb863e4e7ac2 https://hg.mozilla.org/integration/autoland/rev/26ece526d91a Update draw-snapshot AV1 color-quads fuzziness r=media-playback-reviewers,alwu
Pushed by abutkovits@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/edb890e8a3e4 https://hg.mozilla.org/integration/autoland/rev/7dd0886c03a3 Revert "Bug 2057759 - Update draw-snapshot AV1 color-quads fuzziness r=media-playback-reviewers,alwu" for causing failures at full-cycle-test.https.any.worker.html?av1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 2068961

Keep the existing behavior by default until encoder color-space signaling is complete. Enable the new behavior for the color-quads reftests.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: