Open Bug 1239510 Opened 9 years ago Updated 17 days ago

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

Categories

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

45 Branch
task

Tracking

()

Tracking Status
platform-rel --- +

People

(Reporter: jya, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-needed, meta, Whiteboard: [gfx-noted][platform-rel-Vimeo])

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)
Blocks: 1175876
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: ? → +
(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)
Assignee: sotaro.ikeda.g → nobody
Jean-Yves - can this be closed?
Flags: needinfo?(ajones) → needinfo?(jyavenard)
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)
Depends on: 1469711
Summary: Add support for 10 bits YUV support → Add support for 10/12 bits YUV image
Depends on: 1493198
Blocks: 1493762
Summary: Add support for 10/12 bits YUV image → [meta] Add support for 10/12 bits YUV image
Depends on: 1495025
Summary: [meta] Add support for 10/12 bits YUV image → [meta] Add native support for 10/12 bits YUV image
Type: defect → task
Blocks: HDR
Depends on: 1667621
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.