1190939 - VP9 4:4:4 playback (profile 1)

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P5)

Description

[Thomas Daede [:TD-Linux]]

Attachment: tos444.webm

VP9 content with 4:4:4 chroma subsampling (profile 1) decodes correctly but is not correctly displayed (it is converted to RGB as if it was 4:2:0). Attached is a small file to reproduce it, from the CC-BY licensed Tears of Steel video.

This profile is currently rare but is useful for some types of content, like screencasting.

Comment 1

[Avi Halachmi (:avih)]

On windows 8.1 with current Firefox nightly, the test clip shows with correct colors, but with an "extra" green chroma pixel on the right side, top to bottom.

However, if I disable HW acceleration via options->advanced->uncheck "use hw accel when available", then I also get broken colors.

Comment 2

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

Matt - is this a graphics issue same as the Theora bug?

Comment 3

[Jan Gerber]

Attachment: Decode VP9 4:4:4 properly

For the software VP9 decoder this patch is needed to decode 4:4:4 properly.
However it still gets displayed as 4:2:0 during playback, but looks correct if paused.

Comment 4

[Matt Woodrow (:mattwoodrow)]

It could be, yeah.

Can you copy the graphics section of your about:support page from the system where you see the broken colours during playback?

I see the same results as Avi on OSX.

Comment 5

[Jan Gerber]

The green pixel is fixed with the patch posted above. Verified on OS X (without patch: green pixels, with patch: no green pixels).

Issues during playback are on Linux and also happen with Theora 4:4:4 (from Bug 640073):

Graphics
Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Mobile
Asynchronous Pan/Zoom	none
Device ID	Mesa DRI Intel(R) Ivybridge Mobile
Driver Version	3.0 Mesa 10.6.3
GPU Accelerated Windows	0/1 Basic (OMTC)
Supports Hardware H264 Decoding	No;
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Mobile
windowLayerManagerRemote	true
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
CairoUseXRender	1

Comment 6

[Jean-Yves Avenard [:jya]]

Comment on attachment 8652254 [details] [diff] [review]
Decode VP9 4:4:4 properly

Review of attachment 8652254 [details] [diff] [review]:
-----------------------------------------------------------------

At no time does this tell the compositor that it will not be be I420.

it only allows to read the planes properly.

So we'll probably want to either fully convert the image to I420 ; or create an I444 image : which would be much more work

Comment 8

[Thomas Daede [:TD-Linux]]

For reference, bug 1195152 fixed this same problem for Theora.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/13bed93876f2

Comment 10

[kagami]

Comment on attachment 8652254 [details] [diff] [review]
Decode VP9 4:4:4 properly

Review of attachment 8652254 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/platforms/agnostic/VPXDecoder.cpp
@@ +133,5 @@
> +
> +      b.mPlanes[2].mHeight = img->d_h;
> +      b.mPlanes[2].mWidth = img->d_w;
> +    } else {
> +      LOG("VPX Unknown image format");

Note that VP9 also supports yuv422p, yuv440p, yuv420p10, yuv420p12, yuv422p10, yuv422p12, yuv444p10, yuv444p12, yuv440p10, yuv440p12. See https://bugzilla.mozilla.org/show_bug.cgi?id=1215089 for details.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/13bed93876f2