VP9 yuv444p decoding broken with hwaccel enabled

RESOLVED FIXED in Firefox 64

Status

()

defect
P3
normal
RESOLVED FIXED
3 years ago
7 months ago

People

(Reporter: alloy45224, Assigned: jya)

Tracking

({qawanted})

53 Branch
mozilla64
x86
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(9 attachments)

Reporter

Description

3 years ago
Posted image screenshot.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161205030204

Steps to reproduce:

1. Run Firefox 53.0a1 (2016-12-05) (64-bit).
2. Visit page with vp9 video encoded with yuv444p color format (example: https://dl.dropboxusercontent.com/u/40722/vpx-bug/index.html)


Actual results:

1. Video with yuv444p profile output is corrupt.


Expected results:

1. Video with yuv444p should display normally.

Comment 1

3 years ago
Please provide this video samples on Web or attachments.
Component: Untriaged → Audio/Video: Playback
Flags: needinfo?(alloy45224)
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86
Reporter

Comment 2

3 years ago
(In reply to YF (Yang) from comment #1)
> Please provide this video samples on Web or attachments.

https://dl.dropboxusercontent.com/u/40722/vpx-bug/index.html

Comment 3

3 years ago
(In reply to alloy45224 from comment #2)
> (In reply to YF (Yang) from comment #1)
> > Please provide this video samples on Web or attachments.
> 
> https://dl.dropboxusercontent.com/u/40722/vpx-bug/index.html

Uh, I understand now, I have to manually modify it, because the Dropbox asked me to download the html file.
Flags: needinfo?(alloy45224)
Reporter

Comment 4

3 years ago
Oh, sorry about that. They must have changed how they serve html files recently.

Comment 5

3 years ago

Comment 6

3 years ago
WFM in 53.0a1 (2016-12-05) (32-bit) & 53.0a1 (2016-12-05) (64-bit) with clean profile on Win10 1607.
Reporter

Comment 7

3 years ago
I'll go ahead and delete the Dropbox repo since I see you've added an attachment. Thank you!
Please go to the Help menu > Troubleshooting Information, use the button to copy it and save it to a text file and attach it to this bug. Furthermore, tell us the CPU model of the computer, please. Thank you.
Flags: needinfo?(alloy45224)
Reporter

Comment 9

3 years ago
CPU is Intel Core i5-6200. Computer model is Lenovo ThinkPad Yoga 260. I'll attach the troubleshooting information.
Reporter

Comment 10

3 years ago
Flags: needinfo?(alloy45224)
Reporter

Comment 11

3 years ago
I did some testing and found that installing the latest Intel graphics driver makes the issue go away. I'll attach a new troubleshooting report (TroubleshootingInfo-ThinkPadYoga260-Working.txt).
Reporter

Comment 12

3 years ago
Troubleshooting info after updating graphics driver and issue is gone.
Thank you for the information:

bad:
>    "driverVersion": "20.19.15.4331",
>    "driverDate": "11-18-2015",

good:
>    "driverVersion": "21.20.16.4542",
>    "driverDate": "10-24-2016",

QA: Can you check
A) if you can reproduce the issue on Windows 10
B) what is the first Intel driver version which plays the video from the attached testcase correctly? For this processor, the driver list can be found at https://downloadcenter.intel.com/product/88958/Intel-Core-i5-6200-Mobile-Processor-Series
Thank you.
Keywords: qawanted
Not sure if this is related but


This file plays in Chrome, but not in Firefox, Edge or Safari 
https://bugs.chromium.org/p/chromium/issues/attachment?aid=326593&signed_aid=p3vFCkutpOEv8ru525FWHQ==&inline=1


In Firefox it fails with:

```
Media resource https://bugs.chromium.org/p/chromium/issues/attachment?aid=326593&signed_aid=p3vFCkutpOEv8ru525FWHQ==&inline=1 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005)
Details: auto mozilla::SupportChecker::AddMediaFormatChecker(const mozilla::TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling.
```

see https://webcompat.com/issues/18485
needinfo Jean-Yves about Comment #14
Flags: needinfo?(jyavenard)
Assignee

Comment 16

9 months ago
(In reply to Karl Dubost :karlcow from comment #14)
> Not sure if this is related but
> 

it is not, this is H264 in MP4, the bug is about the VP9 decoder.


> This file plays in Chrome, but not in Firefox, Edge or Safari 
> https://bugs.chromium.org/p/chromium/issues/
> attachment?aid=326593&signed_aid=p3vFCkutpOEv8ru525FWHQ==&inline=1
Windows system decoder, nor Apple VideoToolbox has support for YUV444 content.

Chrome can do it thanks to FFmpeg. We could also play it properly on linux assuming ffmpeg is installed, however we made the explicit choice to disable it there too for platforms consistency.

https://searchfox.org/mozilla-central/source/dom/media/platforms/wrappers/H264Converter.cpp#264


We won't ever be able to play YUV444 H264 content.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jyavenard)
Assignee

Comment 17

8 months ago
We need a fallback from hardware to software decoder should decoding failed.
Assignee: nobody → jyavenard
Assignee

Comment 18

8 months ago
The behaviour is identical in Edge and Chrome when using a nvidia 1080 (which has VP9 hardware decoder).

The decoder doesn't error, it succeeds but output NV12 black frames.

So we wouldn't be able to fix this case anyway
Assignee

Comment 19

8 months ago
Can reproduce with an Intel HD 630
Assignee

Comment 20

8 months ago
Both Edge and Chrome also with the Intel HD 630 shows the same graphic corruption as in the provided screenshot. As with comment 18. Decoding doesn't fail, it just returns a garbage image.
Assignee

Comment 21

8 months ago
For know will only be used with Windows WMF decoders.
Assignee

Comment 22

8 months ago
Continuing on the infrastructure provided by bug 1363668 we will now forcibly disable hardware decoding if the first frame failed to decode with a hardware accelerated decoder.

Depends on D7615
Assignee

Comment 24

8 months ago
The Windows VP9 hardware decoder currently do not support anything else than profile 0 and 2 (YUV420) and return garbage when decoding.

We error on those streams allowing to fall back on the ffvp9 software decoder.

Depends on D7647
Assignee

Updated

8 months ago
See Also: → 1496222
Assignee

Comment 25

8 months ago
We'll need to handle EnumSet in ipdl at some stage.

Depends on D7648

Comment 26

8 months ago
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/49dc3475d6f3
P1. Add option to disable hardware decoding. r=bryce
https://hg.mozilla.org/integration/autoland/rev/ad7f2511596c
P2. When first frame decoding failed with hardware decoder, fall back to software decoding r=bryce
https://hg.mozilla.org/integration/autoland/rev/d0b359a2a15a
P3. Add method to read a VP9 profile from a VP9 bitstream r=TD-Linux
https://hg.mozilla.org/integration/autoland/rev/415c0a43a240
P4. Don't attempt to use Windows VP9 decoder for profile 1 and 3. r=bryce
https://hg.mozilla.org/integration/autoland/rev/ce1b5017a90e
P5. Pass the disallow HW decoder flag to remote video decoder. r=mattwoodrow
Assignee

Updated

7 months ago
Duplicate of this bug: 1389297
You need to log in before you can comment on or make changes to this bug.