Closed
Bug 1229304
Opened 10 years ago
Closed 10 years ago
Significant H264 playback quality issues & regressions
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: kael, Unassigned)
References
()
Details
(Whiteboard: [2016-GBT-Y])
Attachments
(3 files)
Over the past month or so, video playback quality for h264 (at least on Windows) has regressed to the point that it is visibly obvious to me on Twitter. Some side-by-side comparisons for a screen capture I recorded demonstrate a number of issues, one of which is definitely new - the others I'm not sure about. This is most easily observed by looking at video and animated GIF embeds in tweet feeds, but I see it with h264 video elsewhere and it even appears when opening an mp4 file directly.
Warning: The content of the video in the URL (a random twitter user's tweet feed) is work-safe but may be offensive to you, so feel free to just use the first frame of it as a comparison. Playback merely makes the issues more obvious.
I've attached a screenshot showing a comparison of first-frame rendering for the test URL, between Firefox 44.0a2 (2015-11-27) and Chrome Version 46.0.2490.86 m on the same machine. I'll also attach a high-contrast image showing the difference between the two renderings of the video. You can take a look at it to see the two main issues, which I will enumerate below:
* The color space and overall brightness of the videos differs. Chrome's rendering is much closer to correct. (The source video is a raw desktop capture encoded at high h264 quality settings in full range mode.) Firefox appears to be rendering the full-range video as limited-range, so the 0-255 range is being crushed to 16-235.
* The dimensions of the video are incorrect; in particular, the bottom portion of the playback region contains many repeated rows of pixels and the overall video's aspect ratio is incorrect. This is most obvious in the contrast image. I have also seen this effect on the right-hand edge of videos but was not able to reproduce it here.
* Overall image fidelity seems to be slightly lower in Firefox. This may be due to the size/aspect ratio issues. This is visible in the contrast image as ringing and other artifacts around edges.
Relevant parts of about:support follow.
----
Application Basics
------------------
Name: Firefox
Version: 44.0a2
Build ID: 20151127004007
Update Channel: aurora
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Multiprocess Windows: 0/2 (default: false)
Safe Mode: false
~snip~
Graphics
--------
Adapter Description: NVIDIA GeForce GTX 980 Ti
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um
Adapter RAM: 4095
Asynchronous Pan/Zoom: none
Device ID: 0x17c8
Direct2D Enabled: true
DirectWrite Enabled: true (10.0.10240.16430)
Driver Date: 11-13-2015
Driver Version: 10.18.13.5900
GPU #2 Active: false
GPU Accelerated Windows: 2/2 Direct3D 11 (OMTC)
Subsys ID: 19963842
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x10de
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 980 Ti Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
(#0) Error: [D2D1.1] 4CreateBitmap failure Size(64,16400) Code: 0x80070057 format 0
Important Modified Preferences
------------------------------
~snip~
gfx.crash-guard.d3d11layers.appVersion: 44.0a2
gfx.crash-guard.d3d11layers.deviceID: 0x17c8
gfx.crash-guard.d3d11layers.driverVersion: 10.18.13.5900
gfx.crash-guard.d3d11layers.feature-d2d: true
gfx.crash-guard.d3d11layers.feature-d3d11: true
gfx.crash-guard.glcontext.gfx.driver-init.direct3d11-angle: true
gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle: true
gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-d3d11: false
gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-warp: false
gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-try-d3d11: true
gfx.crash-guard.status.d3d11layers: 2
gfx.crash-guard.status.d3d9video: 2
gfx.crash-guard.status.glcontext: 2
gfx.direct3d.last_used_feature_level_idx: 0
gfx.driver-init.appVersion: 42.0a2
gfx.driver-init.deviceID: 0x17c8
gfx.driver-init.driverVersion: 10.18.13.5582
gfx.driver-init.feature-d2d: true
gfx.driver-init.feature-d3d11: true
gfx.driver-init.status: 2
gfx.font_rendering.cleartype_params.cleartype_level: 40
gfx.font_rendering.cleartype_params.force_gdi_classic_for_families:
gfx.font_rendering.directwrite.enabled: true
media.gmp-eme-adobe.abi: x86_64-msvc-x64
media.gmp-eme-adobe.lastUpdate: 1446729582
media.gmp-eme-adobe.version: 16
media.gmp-gmpopenh264.abi: x86_64-msvc-x64
media.gmp-gmpopenh264.lastUpdate: 1447436855
media.gmp-gmpopenh264.version: 1.5.1
media.gmp-manager.buildID: 20151127004007
media.gmp-manager.lastCheck: 1448839189
media.hardware-video-decoding.failed: false
media.webrtc.debug.aec_log_dir: C:\Users\Katelyn\AppData\Local\Temp
media.webrtc.debug.log_file: C:\Users\Katelyn\AppData\Local\Temp\WebRTC.log
~ snip ~
| Reporter | ||
Comment 1•10 years ago
|
||
Here is a comparison image. I overlaid the Chrome version of the first frame onto the Firefox one using the GIMP 'Difference' mode and then increased the contrast.
Comment 2•10 years ago
|
||
I can't see a difference in "quality"; the colours in chrome do appear more vivid and it may be a case of PC vs TV levels.
Comment 3•10 years ago
|
||
If the issue is "the bottom portion of the playback region contains many repeated rows of pixels and the overall video's aspect ratio is incorrect"
then this is bug 1222201 and is already available in Nightly (45)
| Reporter | ||
Comment 4•10 years ago
|
||
1222201 is half of this then, yes. I looked through recently filed video bugs and didn't see it :( Is there a specific way I can do these searches in the future?
Comment 5•10 years ago
|
||
We do have a bug related to PC vs TV ranges when using software decoding.
However, when using HW decoding, this is dependent on your graphic card. nvidia are known to use TV ranges by default. You can modify it in the nvidia settings
A quick search yield this: that may be of interest to you:
https://forums.geforce.com/default/topic/523992/tip-for-nvidia-users-using-hdmi-and-getting-accurate-color-format/
| Reporter | ||
Comment 6•10 years ago
|
||
Is there a pref I should try to determine whether this is specific to NVIDIA's hardware h264 decoder, so we can close this bug?
Comment 7•10 years ago
|
||
unfortunately no... You can disable HW decoding, however then you will fall back to our software decoding which may or may not use TV levels (it depends then on the platform software decoder).
Chrome uses ffmpeg instead which will use PC levels.
| Reporter | ||
Comment 8•10 years ago
|
||
I determined that there is a preference that forces full-range decoding from NVIDIA hardware in Firefox, regardless of output device (my monitors are connected via DisplayPort so they already defaulted to full range in the resolution settings).
Making this switch causes the color reproduction in Firefox to match Chrome (the correct appearance).
It's not clear to me why this works in Chrome without the option change though (Chrome looks the same with or without this override). I suspect it is possible to detect what color format you are getting from the hardware decoder, and potentially compensate based on that - Chrome is almost certainly doing that somehow, and other media players like MPC-HC are able to detect it and compensate too (when using either DXVA or CUVID). I assume this topic is covered in the existing bug, though.
Based on this test it sounds like both of the primary issues that motivated this report already have other bugs open. Thanks!
Comment 9•10 years ago
|
||
Apparently we can't fix this on NVidia. They provide no API to control the output range for hardware video decode. We could add a filter to bump the contrast in the compositor, but that would also increase noise.
It can only be fixed it in the settings, as you discovered.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Whiteboard: [2016-GBT-Y]
You need to log in
before you can comment on or make changes to this bug.
Description
•