Closed Bug 1161349 Opened 9 years ago Closed 7 years ago

Incorrect YUV -> RGB colour conversion on youtube for D3D9

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mattwoodrow, Unassigned)

References

(
URL
)

Details

(Whiteboard: [platform-rel-Youtube])

Attachments

(1 file)

WIP: Use DXVA2 for the colour conversion
14.04 KB, patch
Details | Diff | Splinter Review 
This was reported on reddit (see URL) and seems to be an issue for nvidia cards.

Users can force full range colour conversion in the nvidia settings, but the default is to let the application choose, so we should be able to specify which conversion to use.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb970322%28v=vs.85%29.aspx

In particular, MF_MT_YUV_MATRIX and MF_MT_VIDEO_NOMINAL_RANGE look interesting.

I can't reproduce this on my AMD card, so not sure what we need to set to fix this and the docs aren't particularly clear.

We could try setting the values for these that we want in the output type we create for the decoder and hope that it creates output YUV frames with those properties.

Alternatively we could read the values on the output (using IMFTransform::GetOutputCurrentType), and then copy them across to the input type for the IMFTransform we use for converting YUV -> RGB (in D3D11DXVA2Manager::ConfigureForSize). This path is only used for d3d11 though, not sure how we would control the conversion for d3d9.
Resolved the other two bugs as duplicates since this one looks like it contains more actionable information (though the problem was also acknowledged in bug 1125844).
Version: 29 Branch → Trunk
I can reproduce this on windows 7 with an nvidia card, but only with HD videos, SD videos seem to have the correct colours.

Regardless of resolution, the decoder seems to be outputting frames with MF_MT_VIDEO_NOMINAL_RANGE = MFNominalRange_16_235.

It appears that chrome has the same bug on windows 7, if I force it to use the h264 streams on youtube.

Could someone with windows 8 please test to see if this version converts colours correctly:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-ce2dea83456f/try-win32/
Flags: needinfo?(pike)
FWIW my results on Windows 8.1 64-bit with NVIDIA 350.12 drivers (using "with the video player settings" for colour):

Firefox 38 beta: Wrong colours
Firefox 39 alpha: Wrong colours
Latest Firefox nightly: Correct colours
Try build: Correct colours

So not sure if this is still a problem.
Flags: needinfo?(pike)
That's really interesting, thanks for checking that.

If nightly works, then it was most likely the switch to D3D11 DXVA2 that helped. We should make sure that gets uplifted as soon as possible.

I still have no good ideas for windows 7 though :(
I think we should report Firefox bugs on reddit (see duplicates). Bugzilla is just for dev's chat. I didn't know about this fact before.
The other bugs were seen by others on the media team, I just missed them when filing this bug. Bugzilla is still the preferred method of reporting issues :)

That said, any feedback is better than none.

Try build for windows 7: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-666f7861572f/try-win32/

Can you please test to see if this fixes the issue for you?
Flags: needinfo?(CoolCmd)
Matt,
win7, video drv 341.44
youtube h264 - ok
vimeo h264 (or mp4 from hdd) - black screen, sound ok
Flags: needinfo?(CoolCmd)
I assume vimeo was working fine for nightly?

I guess this patch breaks something there, will investigate.
Ok, I can reproduce the vimeo issue on my windows 7 machine. I'll debug it tomorrow.
This works fine on my Intel and AMD machines, but fails with NVIDIA.

For some reason the VideoProcessBlt call is returning E_INVALIDARG.

I've tried everything I can think of and haven't been able to make any progress, I can't find any way to get more information on the failure either.

Bas, do we have any contacts at nvidia that would be able to help us with this?
Flags: needinfo?(bas)
It is not only color, it's also playback. For example: https://youtu.be/aE4Y8RcSoYY
In IE it's fluid, in FF it's "jerky". This is not only with this example, this also is an overall issue with video playback on FF.
That has nothing to do with this bug, but rest assured that the implementation is still very much being worked on, so performance should improve in time.
(In reply to Menno555 from comment #14)
> It is not only color, it's also playback. For example:
> https://youtu.be/aE4Y8RcSoYY
> In IE it's fluid, in FF it's "jerky". This is not only with this example,
> this also is an overall issue with video playback on FF.

Video playback is hardware dependent so which browser works best can differ between machines. If you are having performance issues then file a separate bug and include the graphics section of about:support. Alternatively you can use the ☰ -> ? -> Submit Feedback... to provide feedback and include technical information.
I did that but you/somebody did combine it with this Bug 1161349 while my problem I did submit was about video in general, not YouTube specific.
(In reply to Menno555 from comment #17)
> I did that but you/somebody did combine it with this Bug 1161349 while my
> problem I did submit was about video in general, not YouTube specific.

I was referring to the "jerky" compared to IE. This bug is about colour conversions.
Media Player Classic HC use 0-255 as expected when output to DirectShow EVR. Other output DirectShow methods use 16-235.
I just noticed the same problem on my machine and wanted to contribute screenshots at least. :-)

Windows 8.1, Geforce 353.30, Firefox 39, Chrome 43.

http://imgur.com/a/TFVbO

The first screenshot is from Firefox always, HTML5 player. It can be noticed the most with 2.35:1 material.
Matt, have you had any word from Bas on this IRL? Any way to get his attention? I'm happy enough using the workaround through the Nvidia settings, but a lot of people aren't going to ever know about that.
Flags: needinfo?(matt.woodrow)
Matt - would it make sense to use the integrated graphics card (in the Intel case) to work around this issue? It may be feasible if we can use the optimised read-back mechanism.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #22)
> Matt - would it make sense to use the integrated graphics card (in the Intel
> case) to work around this issue? It may be feasible if we can use the
> optimised read-back mechanism.

This problem only affects users with NVIDIA cards.

We don't have any control over which GPU gets used in the dual-GPU case, so we can't forcibly use the intel chip.
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #23)
> We don't have any control over which GPU gets used in the dual-GPU case, so
> we can't forcibly use the intel chip.

That is annoying. How painfully inefficient is it to read back from nVidia GPUs in this case?
Likely bad enough that we'd be better off just using software decoding.
Component: Audio/Video → Audio/Video: Playback
No longer blocks: MSE
Flags: needinfo?(ajones)
https://code.google.com/p/chromium/issues/detail?id=333619 Chrome track ticket for this same bug for anyone is interested.
Crazy that this is still an issue. Both Edge and Chrome expand to 0-255 without having to work around it using the Nvidia drivers (which I won't to do because I don't want it to touch my desktop video playback.)

Firefox 43.0.4
Windows 10
Nvidia GTX970 with 361.43 drivers

Same problem on Vimeo.
Sorry Matt, didn't see this, do you still want info from NVidia here?
Flags: needinfo?(bas)
Nah, I don't think we need to. We've moved a lot of users over to d3d11 where it works correctly.
Lets call this good enough and deprioritise it on the basis that D3D11 covers most of the problem space.
Flags: needinfo?(ajones)
Priority: -- → P5
Summary: Incorrect YUV -> RGB colour conversion on youtube → Incorrect YUV -> RGB colour conversion on youtube for D3D9
(In reply to Matt Woodrow (:mattwoodrow) from comment #31)
> Nah, I don't think we need to. We've moved a lot of users over to d3d11
> where it works correctly.
Matt, are you sure that d3d11 works correctly?

Example: https://vimeo.com/channels/staffpicks/162496594
Select 1080p
MediaInfo:
Color range                    : Limited
Color primaries                : BT.709
Transfer characteristics       : BT.709
Matrix coefficients            : BT.709

Firefox 45 HWA on: video have dark gray "background".
Firefox 45 HWA off: video have black "background".
Media Player Classic HC: video have black "background".

Windows 7 == dx11, right?
@ CoolCmd
The same here with that video:
FF 45.0.2 HWA On: the black is kind of dark grey and colors overall are kind of washed out
FF 45.0.2 HWA Off: the black is black and colors are more vibrant.

In one of my own videos it's even more apparent: https://www.youtube.com/watch?v=0OlrLzNj4z0
This all on a Windows 10 64 bit system, i5-4690K CPU, MSI Geforce GTX 970 4Gb graphics card. All software and drivers up to date.
The Direct3D 11 bindings to DXVA2 are only available on Windows 8+.

Menno555: Check the 'Supports Hardware H264 Decoding' value in about:support to see which decoder you're getting.
(In reply to Matt Woodrow (:mattwoodrow) from comment #35)
> The Direct3D 11 bindings to DXVA2 are only available on Windows 8+.

Just to confirm: the platform update for Windows 7 (KB2670838 [1]) backported a lot of features from Windows 8 to Windows 7. I take it this wasn't in there?

[1] https://support.microsoft.com/en-us/kb/2670838
Hm, i think i'm on d3d11 (see about:support screenshot) and it's still not working correctly for me, see the appended screenshots from vimeo and youtube: http://imgur.com/a/Enxqy

Win10 x64, GTX 970 (364.72)


(In reply to CoolCmd from comment #33)
> (In reply to Matt Woodrow (:mattwoodrow) from comment #31)
> > Nah, I don't think we need to. We've moved a lot of users over to d3d11
> > where it works correctly.
> Matt, are you sure that d3d11 works correctly?
@ Matt Woodrow
All it is saying is "Yes" behind the Supports Hardware H264 Decoding.
Here is the whole graphical part. It is in Dutch:

Adapter-RAM 4095 
Adapterbeschrijving NVIDIA GeForce GTX 970 
Adapterstuurprogramma’s nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um 
Asynchroon pannen/zoomen geen 
ClearType-parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100  
Datum stuurprogramma 3-7-2016 
Device-ID 0x13c2 
Direct2D ingeschakeld true 
DirectWrite ingeschakeld true (10.0.10586.0) 
GPU #2 actief false 
GPU-versnelde vensters 1/1 Direct3D 11 (OMTC) 
Ondersteunt hardwarematige H264-decodering Yes 
Stuurprogrammaversie 10.18.13.6451 
Subsys-ID 31601462 
Vendor-ID 0x10de 
WebGL-renderer Google Inc. -- ANGLE (NVIDIA GeForce GTX 970 Direct3D11 vs_5_0 ps_5_0) 
windowLayerManagerRemote true 
AzureCanvasBackend direct2d 1.1 
AzureContentBackend direct2d 1.1 
AzureFallbackCanvasBackend cairo 
AzureSkiaAccelerated 0
Btw, just updated to FF 46.0 but the same problem persist.
Ah, apparently the DXVA reporting code is part of 48. Would you mind trying Firefox dev edition or Nightly and then see what about:support shows?
Okay, did download the Nightly version (49.0.0.5960) and in there the videos are shown correct with HWA set to On: black is black and no "washed" colors.
Here the about:support part of the Nightly:

Graphics
Features
Compositing	Direct3D 11
Asynchronous Pan/Zoom	wheel input enabled; touch input enabled
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 970 Direct3D11 vs_5_0 ps_5_0)
Hardware H264 Decoding	Yes; Using D3D11 API
Direct2D	true
DirectWrite	true (10.0.10586.0)
GPU #1
Active	Yes
Description	NVIDIA GeForce GTX 970
Vendor ID	0x10de
Device ID	0x13c2
Driver Version	10.18.13.6451
Driver Date	3-7-2016
Drivers	nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um
Subsys ID	31601462
RAM	4095
Diagnostics
ClearType Parameters	Gamma: 2200 Pixel Structure: R
AzureCanvasAccelerated	0
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
ClearType Parameters	Gamma: 2200 Pixel Structure: R
I can confirm that videos look "as intended" on the Firefox Nightly (49.*) and the current Dev build.

Screenshots of about:support and Vimeo playback: http://imgur.com/a/U7jkD
D3D11 DXVA wasn't enabled until 47 (current beta), so this will be fixed on release when that ships.
platform-rel: --- → ?
Whiteboard: [platform-rel-Youtube]
platform-rel: ? → ---
This is still broken here - any chance to fix it?

Tested with Nightly 56.0a1, Win 7 (so I assume D3D9), GTX 660 (DVI output).

This is the video I used to test: https://my.mixtape.moe/brponk.mp4 (the background is supposed to be white, but it shows grey here).
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Why was it closed?
It works with D3D11.
We don't intend to add new features such as this code is only used on Windows 7.

The alternatives proposed are:
-change the colorspace using the Nvidia utility
-upgrade to Windows 10
-disable hardware acceleration
-Use Intel or AMD GPU instead.
Ok, I understand.
(In reply to Jean-Yves Avenard [:jya] from comment #46)
> It works with D3D11.
> We don't intend to add new features such as this code is only used on
> Windows 7.
> 
> The alternatives proposed are:
> -change the colorspace using the Nvidia utility
> -upgrade to Windows 10
> -disable hardware acceleration
> -Use Intel or AMD GPU instead.

Correct me if I'm wrong, but on my Win7 computer it shows 

"Features
Compositing	Direct3D 11 (Advanced Layers)"

Does it mean it's not D3D9 any more? The video color is still wrong though.
While compositing is done via D3D11, it uses a D3D9 decoder. There's no D3D11 decoder on windows 7.

Different D3D11 components.

In any case, our colorspace support is far from being complete... plenty of combinations where things aren't right yet :(
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: