1239510 - [meta] Add native support for 10/12 bits YUV image

Status: NEW

(Core :: Graphics: Layers, task, P3)

Description

[Jean-Yves Avenard [:jya]]

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)

Comment 1

[Vittorio Giovara]

Vimeo could be potentially interested in this feature for h264 and vp9 if available.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 3

[Vittorio Giovara]

(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 :)

Comment 4

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I see value in supporting the 10 bit format ahead of creating a 10 bit render path.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 6

[Thomas Daede [:TD-Linux]]

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.

Comment 7

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Jean-Yves - can this be closed?

Comment 8

[Jean-Yves Avenard [:jya]]

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