1976233 - [HDR/Linux] Video is not composited directly on YT

Status: RESOLVED DUPLICATE of bug 1978356

(Core :: Graphics: WebRender, defect, P3)

Description

[Martin Stránský [:stransky] (ni? me)]

I see green video on HDR mode:
https://ct24.ceskatelevize.cz/clanek/domaci/vyssi-pokuta-i-vice-bodu-za-nebezpecne-odbocovani-jsou-nove-tvrdsi-tresty-362725

Comment 1

[Martin Stránský [:stransky] (ni? me)]

It's because direct rendering of external surfaces is not used and we create texture over it instead which is disabled now.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

According to my local logging we push NV12 as external surface but WebReneder decides to blend it anyway so tries to lock RenderDMABUFTextureHost as texture. Glenn, do you have any idea where I shall look to? Why the video content is not directly composited?

I can reproduce that on YT too, for instance for video previews.
Thanks.

Local logging:

External image!
DMABUFTextureHostOGL::CreateRenderTexture()
RenderDMABUFTextureHost::RenderDMABUFTextureHost()
DMABUFTextureHostOGL::PushResourceUpdates NV12
aPipeline->mUseExternalImage
DMABUFTextureHostOGL::PushDisplayItems format NV12 
RenderDMABUFTextureHost::Lock()
RenderDMABUFTextureHost::Lock() !aGL
RenderDMABUFTextureHost::Lock()
RenderDMABUFTextureHost::Lock() !aGL
AsyncImagePipelineManager::UpdateImageKeys 1

Comment 5

[Glenn Watson [:gw]]

There are a few reasons that can cause a surface to not be promoted - it may be hitting one of those. There is code in picture.rs which will return / log the reason [1]. I suspect that's what is happening here?

[1] https://searchfox.org/mozilla-central/source/gfx/wr/webrender/src/picture.rs#1894

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Thanks, looks like I found it. If CompositorSurfaceKind::Underlay is used the direct video scanout works.

But if CompositorSurfaceKind::Overlay is used, it fails immediately as self.sub_slices.len() is 1:
https://searchfox.org/mozilla-central/rev/ac81a39dfe0663eb40a34c7c36d89e34be29cb20/gfx/wr/webrender/src/picture.rs#2631
so we fail right here even for sub_slice_index = 0.

So it looks like CompositorSurfaceKind::Overlay is disabled on Linux/Wayland then?
Thanks.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

It also looks like surfaces with color_depth != ColorDepth::Color8 are always promoted to avoid washed out colors:
https://searchfox.org/mozilla-central/rev/ac81a39dfe0663eb40a34c7c36d89e34be29cb20/gfx/wr/webrender/src/picture.rs#3472
so we'd need to ensure we report the colors correctly for HDR surfaces on Wayland.

Comment 8

[Glenn Watson [:gw]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

It also looks like surfaces with color_depth != ColorDepth::Color8 are always promoted to avoid washed out colors:
https://searchfox.org/mozilla-central/rev/ac81a39dfe0663eb40a34c7c36d89e34be29cb20/gfx/wr/webrender/src/picture.rs#3472
so we'd need to ensure we report the colors correctly for HDR surfaces on Wayland.

Yes that's a deliberate choice, for now, at least.

Comment 9

[Glenn Watson [:gw]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Thanks, looks like I found it. If CompositorSurfaceKind::Underlay is used the direct video scanout works.

But if CompositorSurfaceKind::Overlay is used, it fails immediately as self.sub_slices.len() is 1:
https://searchfox.org/mozilla-central/rev/ac81a39dfe0663eb40a34c7c36d89e34be29cb20/gfx/wr/webrender/src/picture.rs#2631
so we fail right here even for sub_slice_index = 0.

So it looks like CompositorSurfaceKind::Overlay is disabled on Linux/Wayland then?
Thanks.

That shouldn't be the case, it sounds like a bug. Could you add some logging to find out why sub_slices is only 1 in this case? (I'd expect it to be 2). It may suggest a logic mismatch between how it's calculating the number of surfaces to promote and what strategy to use vs. what it actually uses when trying to do the promotion.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

The log says (if I force more slices):

[WARN  webrender::picture] promotion_attempts:
[WARN  webrender::picture] can_promote_to_surface: is_root_tile_cache false surface_kind underlay
[WARN  webrender::picture] !is_root_tile_cache
[WARN  webrender::picture] promotion_attempts:
[WARN  webrender::picture] can_promote_to_surface: is_root_tile_cache false surface_kind overlay
[WARN  webrender::picture] CompositorSurfaceKind::Overlay
[WARN  webrender::picture] !is_root_tile_cache

so it's fails due to !is_root_tile_cache in both cases (underlay / overlay).

Comment 11

[Glenn Watson [:gw]]

!is_root_tile_cache implies that the video was encountered as a child of an off-screen surface (for example, some kind of CSS filter, or mix-blend-mode, or similar to that) which means we can't currently promote these as they would affect the correctness of rendering the off-screen effect (which will need to read back pixels from the video surface as inputs). It's possible that some of the work I have planned for https://bugzilla.mozilla.org/show_bug.cgi?id=1826576 may be able to handle some of these cases better. Are you able to check what kind of surface is being created that the video is under?

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Will look at it. It can be easily reproduced on YT, when you play main clip and mouse over other video titles - then the main clip becomes green (i.e. failed to composite).

Comment 13

[Martin Stránský [:stransky] (ni? me)]

YT throws "failed with: overlay not allowed for prim with mask".

Comment 14

[Martin Stránský [:stransky] (ni? me)]

We may force direct compositing for fullscreen only and also set that run-time to texture host.