Add support for 10 bits YUV support

NEW
Unassigned

Status

()

Core
Graphics: Layers
P3
normal
2 years ago
a month ago

People

(Reporter: jya, Unassigned)

Tracking

45 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel +)

Details

(Whiteboard: [gfx-noted][platform-rel-Vimeo])

(Reporter)

Description

2 years ago
Codec using 10 bits YUV are becoming increasingly more common (YUV420P10, YUV422P10 or YUV444P10)

In particular because bluray 4K videos are using it.

VP9 profile2, h264 (and soon hevc) all support it and we're starting to see videos in the wild.

We should be able to render images coming from the media decoders using 10 bits YUV (and also 12 bits if possible)
Whiteboard: [gfx-noted]
(Reporter)

Updated

2 years ago
Blocks: 1175876

Comment 1

a year ago
Vimeo could be potentially interested in this feature for h264 and vp9 if available.
Assignee: nobody → sotaro.ikeda.g
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted][platform-rel-Vimeo]
(In reply to Vittorio Giovara from comment #1)
> Vimeo could be potentially interested in this feature for h264 and vp9 if
> available.

Is there any advantage to using this feature if all of the browser rendering is still done in 8bit?
Flags: needinfo?(vitto.giova)
platform-rel: ? → +

Comment 3

a year ago
(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
> (In reply to Vittorio Giovara from comment #1)
> > Vimeo could be potentially interested in this feature for h264 and vp9 if
> > available.
> 
> Is there any advantage to using this feature if all of the browser rendering
> is still done in 8bit?

Well yes, it allows services to start encoding at 10 bit, which offers a very nice bitrate saving right away, and allows for a much higher color fidelity even if you just shift the last two bits awat. Also 10 bit is a requirement for HDR, so the sooner 10 bit and new colorspaces are supported, the quicker this technology will be adopted.

Finally, I might be wrong, but I think Chrome internally uses the same bitdepth of the input video, see https://bugs.chromium.org/p/chromium/issues/detail?id=445071#
The real question should be about monitors, and their 6-8bit panels, but one step at a time I'd say :)
Flags: needinfo?(vitto.giova)
I see value in supporting the 10 bit format ahead of creating a 10 bit render path.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #4)
> I see value in supporting the 10 bit format ahead of creating a 10 bit
> render path.

I agree. That presumably means this bug should not block bug 1175876 right?
There are two paths forward for 8-bit RGB output:

a) convert 10 bit YUV -> 8 bit YUV in software, then hand to compositor for RGB conversion (would not block bug 1175876)

b) convert 10 bit YUV -> 8 bit RGB in the compositor directly (would then block bug 1175867)

There are obviously performance advantages to b), but also the dynamic range of 8 bit YUV is actually less than 8 bit RGB, so there is a quality improvement for using the full bit depth with the RGB conversion.

However, a) doesn't require changes to every compositor, so it's obviously faster to implement, and maybe could be used to piecemeal convert compositors over.
Flags: needinfo?(ajones)
Priority: -- → P3

Updated

3 months ago
Assignee: sotaro.ikeda.g → nobody
Jean-Yves - can this be closed?
Flags: needinfo?(ajones) → needinfo?(jyavenard)
(Reporter)

Comment 8

a month ago
this is a meta bug... 10 bits video isn't supported really. We still don't do D3D11 and we only convert to RGB8... far from proper HDR support
Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.