Thomas Daede [:TD-Linux] Reporter
	Description • 9 years ago

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.

	Avi Halachmi (:avih)
	Comment 1 • 9 years ago

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.

	Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)
	Comment 2 • 9 years ago

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

	Jan Gerber Assignee
	Comment 3 • 9 years ago

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.

	Matt Woodrow (:mattwoodrow)
	Comment 4 • 9 years ago

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.

	Jan Gerber Assignee
	Comment 5 • 9 years ago

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

	Jean-Yves Avenard [:jya]
	Comment 6 • 9 years ago

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

	Thomas Daede [:TD-Linux] Reporter
	Comment 8 • 8 years ago

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

	Pulsebot
	Comment 9 • 8 years ago

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

	kagami
	Comment 10 • 8 years ago

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.

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 8 years ago
bugherder

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