Closed Bug 1229304 Opened 10 years ago Closed 10 years ago

Significant H264 playback quality issues & regressions

Categories

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

44 Branch
x86_64
Windows 10
defect
Not set
major

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 ~
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.
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.
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)
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?
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/
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?
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.
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!
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: