cc: Ensure that video color conversion matches in overlay and non-overlay modes |
|||||
Issue description
DrawQuads that come from video are sometimes not composited using the GLRenderer, but rather, are promoted to "overlays".
The meaning of "overlay" differs across platforms:
- on CrOS this refers to hardware overlay support
- on Mac, this refers to CALayers or AVSampleBufferDisplayLayers
- support also exists (or should exist) on Android
The issue here is as follows
- the GLRenderer is capable of color conversion from any media color
space to any output device color space
- these overlay systems sometimes have less or no color conversion
support
- if the appearance of the media element differs between these two
modes, then this can result in a frame-to-frame "flickering" as we
enter and leave low power mode
It needs to be ensured that this flickering not happen. This can happen by:
Option A: Not promoting media to an overlay if the overlay hardware
(whatever it is on that platform) cannot perform color
conversion itself
Option B: Doing incorrect color conversion in the GLRenderer, so that
it will match what the hardware overlay will do
,
Dec 21 2016
I think doing no color conversion in GLRenderer will result in Option B on Android. +liberato@?
,
Dec 21 2016
+1 option B, +1 c#1. android has no color space support that's available in a user-exposed API that i know about. lots of "vendor defined" parts. also, "not promoting" isn't really an option anyway on android. the decoder either puts the decoded frame into a SurfaceView for overlay that's inaccessible to chrome, or it puts it somewhere that GLRenderer can read it but cannot be promoted with any power savings
,
Dec 21 2016
I guess we need to make a per-stream decision on how to display it. If overlays are possible, and we decide to (try) to use it, we can make sure that the fallback path matches what the overlays do for any frame that doesn't end up using the overlays.
,
Jan 3 2017
,
Jan 3 2017
Re c#1, I think that depends on the colorspaces involved. For Rec.709 SDR content, even on "wide gamut" displays which in practice are generally <= 100% DCI-P3, I tend to agree. For Rec. 2020 or HDR content, if we can't color manage this content we might as well indicate that it is not supported at all, and refuse to play it. I have the "joy" of a display device that will take Rec.2020/HDR input but requires manually switching modes, so there's always some period where there's a mismatch. sRGB content treated as Rec.2020/HDR input is a special brand of horrible. (The inverse is pretty bad too).
,
Jan 4 2017
Typed up rules for when, and when not to apply color correction here: https://docs.google.com/document/d/1hAr9WPYbWyOxjIKA8YbKDHX4GwM5mY6WHDvpQdjO2z0/edit Feedback welcome.
,
Jan 13 2017
WRT WCG+Battery+NoOverlayColorCorrection: I believe that we should have no correction here. Battery life trumps everything.
,
Feb 27 2017
,
Mar 8 2018
This has been working for a long time on macOS. Windows has separate issues for DCOverlays that are currently open. Closing this as stale. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ccameron@chromium.org
, Dec 20 2016