Closed
Bug 1314458
Opened 8 years ago
Closed 7 years ago
YouTube video playback is jittering/micro-stuttering
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
platform-rel | --- | + |
firefox49 | --- | unaffected |
firefox50 | --- | unaffected |
firefox51 | --- | unaffected |
firefox52 | + | fixed |
firefox-esr52 | --- | fixed |
firefox53 | + | fixed |
firefox54 | --- | fixed |
firefox55 | --- | wontfix |
People
(Reporter: josh.tumath+bugzilla, Assigned: jya)
References
Details
(Keywords: perf, regression, Whiteboard: [platform-rel-Youtube])
Attachments
(3 files)
59 bytes,
text/x-review-board-request
|
ajones
:
review+
jcristau
:
approval-mozilla-aurora+
jcristau
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release+
|
Details |
4.08 MB,
text/plain
|
Details | |
4.78 MB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161101030207 Steps to reproduce: Watched a YouTube video. Actual results: The video stuttered/jittered throughout playback. (CPU usage was not higher than usual, so that isn't the cause of the issue.) Expected results: The video should have played back at a normal framerate. Here are my graphics details from about:support, if that helps: Features Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0) WebGL2 Renderer Google Inc. -- ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding Yes; Using D3D11 API Audio Backend wasapi Direct2D true DirectWrite true (10.0.14393.351) GPU #1 Active Yes Description NVIDIA GeForce GTX 960 Vendor ID 0x10de Device ID 0x1401 Driver Version 21.21.13.7570 Driver Date 10-25-2016 Drivers C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2umx C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvd3dum,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_848dea456d3c865e\nvwgf2um Subsys ID 140110de RAM 4096 Diagnostics AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo Decision Log D3D9_COMPOSITING disabled by default: Disabled by default
Assignee | ||
Comment 1•8 years ago
|
||
Is this happening with all videos? Have you tried rebooting your machine see if that fixes anything.
Comment 2•8 years ago
|
||
Since the opener is on Windows 10, has a GTX 960 and recently VP9 GPU decoding got enabled for Nightly, it might be the issue with the renderer you described in Bug 1292374?
Assignee | ||
Comment 3•8 years ago
|
||
Not all GTX 960 cards have VP9 decoding.
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #1) > Is this happening with all videos? > > Have you tried rebooting your machine see if that fixes anything. Rebooting does not prevent the issue. I have tried to see if this happens on other websites. The issue does not seem to occur on Buzzfeed or Vimeo. (In reply to Jean-Yves Avenard [:jya] from comment #3) > Not all GTX 960 cards have VP9 decoding. That patch was checked in four days ago, which is around the time the bug started occurring. How would I find out if my card supports VP9?
Assignee | ||
Comment 5•8 years ago
|
||
Install this extension: https://addons.mozilla.org/en-US/firefox/addon/about-media/?src=api Once done, open a new tab in the same window where the video is playing and go to about:media Below the youtube URL, you'll see the type of decoder being used and "hardware video decoding", it will show yes or true if it is, then the graphic card is used for vp9 decoding. But I'd be surprised if a GTX 960 returned true. Do you know which chipset it is using? GM204 or GM206? only GM206 (maxwell) have vp9 decoding to test if this is the hardware decoding, then go into about:support search for media.wmf.vp9.enabled preference and set it to false. Then reload the page and play it again. So far all my testing had shown that the issue was only noticeable with 60fps video. For 30fps it was okay. Most youtube videos are 15fps or 30fps, so I didn't think it would cause a problem.
Comment 6•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #3) > Not all GTX 960 cards have VP9 decoding. All GTX 960 (and 950) cards have the GM206 GPU, which always offers VP9 decoding support on Windows 10 Redstone with relatively up to date drivers.
Assignee | ||
Comment 7•8 years ago
|
||
Well, on a dell xps 15 here, is a GM204. Same with a gigabyte Aero 14 GTX 965... So obviously not all. GM206 is only in 2016 updated cards according to a quick internet search.
Reporter | ||
Comment 8•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #7) > Well, on a dell xps 15 here, is a GM204. > Same with a gigabyte Aero 14 GTX 965... > > So obviously not all. > GM206 is only in 2016 updated cards according to a quick internet search. That's because it's a GTX 960M, so that would indeed be a slightly different GPU. (In reply to Jean-Yves Avenard [:jya] from comment #5) > Install this extension: > https://addons.mozilla.org/en-US/firefox/addon/about-media/?src=api > Once done, open a new tab in the same window where the video is playing and > go to about:media https://www.youtube.com/watch?v=TEdsQmjLMKs blob:https://www.youtube.com/d629767b-f0d7-4807-9ac0-b26ef2670390 currentTime: 10.593666 readyState: 4 Quality: 100% (total:320 dropped:0 corrupted:0) Buffered ranges: [(0, 50.001)] SourceBuffer 0 start=0 end=50.001 SourceBuffer 1 start=0 end=64.063 Internal Data: audio decoder: opus audio decoder audio frames decoded: 635 audio state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:132 out:132 qs=0 pending:0 waiting:0 wfk:0 sid:55 video decoder: wmf hardware video decoder hardware video decoding: enabled video frames decoded: 324 (skipped:0) video state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:324 out:324 qs=0 pending:0 waiting:0 wfk:0, sid:53 Dumping data for demuxer 23adcace000: Dumping Audio Track Buffer(audio/webm; codecs=opus): - mLastAudioTime: 12.701000 NumSamples:2500 Size:1246417 Evictable:280513 NextGetSampleIndex:635 NextInsertionIndex:2000 Buffered: ranges=[(0.000000, 50.001000)] Dumping Video Track Buffer(video/webm; codecs=vp9) - mLastVideoTime: 10.810000 NumSamples:1920 Size:3036431 Evictable:351118 NextGetSampleIndex:324 NextInsertionIndex:960 Buffered: ranges=[(0.000000, 64.063000)]
Comment 9•8 years ago
|
||
In reply to walmartguy from comment #6) > (In reply to Jean-Yves Avenard [:jya] from comment #3) > > Not all GTX 960 cards have VP9 decoding. > All GTX 960 (and 950) cards have the GM206 GPU, which always offers VP9 > decoding support on Windows 10 Redstone with relatively up to date drivers. Wrong. GeForce GTX 960 (OEM) with GM204 codename has VP6 and "E" VDPAU feature set, so no VP9 HW decoding support. GeForce GTX 960 with GM206 codename has VP7 and "F" VDPAU feature set, so VP9 HW decoding support. (In reply to Josh Tumath from comment #8) > (In reply to Jean-Yves Avenard [:jya] from comment #7) > > Well, on a dell xps 15 here, is a GM204. > > Same with a gigabyte Aero 14 GTX 965... > > > > So obviously not all. > > GM206 is only in 2016 updated cards according to a quick internet search. > > That's because it's a GTX 960M, so that would indeed be a slightly different > GPU. GTX 960M has GM107 codename and GTX 965M has GM204 codename, both don't have support for VP9 HW decoding.
Reporter | ||
Comment 10•8 years ago
|
||
Ah, ok. Interesting! Either way, we've been able to show that my GPU supports hardware decoding for VP9. (Thanks for helping with that, Jean-Yves!) It is reasonable, then, to suspect that this is a regression from bug 1292374.
Updated•8 years ago
|
Updated•8 years ago
|
Keywords: regression
Assignee | ||
Comment 11•8 years ago
|
||
When you right click on the YouTube video player click on stats for nerds. You can select the text and paste it here. Be interested to see the frame rate of the video giving you issue. It's interesting to see that the decoder has dropped no frames. So it must be frames dropped by the compositor. Which at this stage aren't accounted for. Matt, any ideas what could be happening? The VP9 MFT only works with D3D11
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(matt.woodrow)
Comment 12•8 years ago
|
||
There's nothing really that stands out immediately. If someone could get me a profile (of all threads, in both processes) then that might show interesting things. Otherwise I'll need to try get hold of hardware that can do this and test it myself.
Flags: needinfo?(matt.woodrow)
Reporter | ||
Comment 13•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #11) > When you right click on the YouTube video player click on stats for nerds. > You can select the text and paste it here. Be interested to see the frame > rate of the video giving you issue. Video ID: _xgFYqH2vx4 Dimensions: 854 x 480 * 2 Resolution: 1920 x 1080@25 Volume: 100% Stream Host: r19---sn-aiglln7y Stream Type: https CPN: eWxgYSNjGSX_3kbn Mime Type: video/webm; codecs="vp9" DASH: yes (248/251) Connection Speed: 25161 Kbps Buffer Health: 34.4 s Network Activity: 0 KB Dropped Frames: 0/765
Assignee | ||
Comment 14•8 years ago
|
||
Could you leave the resolution setting on auto? selecting 1080p when the display size available is only 854x480 doesn't make much sense. But at least here was see that it's only 25fps, it's very surprising that there would be performance issue here. In the mean time, you can set media.wmf.vp9.enabled to false in about:support, and that will fix the problem, albeit a higher CPU usage.
Reporter | ||
Comment 15•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #14) > Could you leave the resolution setting on auto? > > selecting 1080p when the display size available is only 854x480 doesn't make > much sense. The resolution *is* on auto. I have a 4K monitor. :) But setting it manually to 480p produces the same stutter. > In the mean time, you can set media.wmf.vp9.enabled to false in > about:support, and that will fix the problem, albeit a higher CPU usage. That does indeed fix the problem!
Comment 16•8 years ago
|
||
[Tracking Requested - why for this release]: Jittery VP9 playback for some users
Status: UNCONFIRMED → NEW
status-firefox49:
--- → unaffected
status-firefox50:
--- → unaffected
tracking-firefox52:
--- → ?
Ever confirmed: true
Assignee | ||
Comment 18•7 years ago
|
||
https://people-mozilla.org/~jyavenard/Report20161113-1736.diagsession At 1 minute, resolution was changed to 1440p@60Hz -> no frames dropped. At 1:30, full screen was selected -> frames are dropped. Note that running in a debugging session, the skip to next keyframe logic is never entered (yet you see frames being dropped so it's something else) While in windowed mode, 30% of the CPU time is spent in D3D11DXVA2Manager::CopyToImage In full screen mode, 60% is spent in D3D11DXVA2Manager::CopyToImage
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 19•7 years ago
|
||
Are you playing the video in fullscreen mode, or it's bad also in windowed (default) mode ?
Flags: needinfo?(josh)
Assignee | ||
Comment 20•7 years ago
|
||
How is it playing in Chrome? (and is it using VP9, you can check by looking at the "Stats for Nerds" entry. Also, how is it playing in Edge if you enable vp9? instructions to enable it is available there: https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/#6hqyUqXTGjklYP5H.97 Go to about:flags search for VP9 and select "Enabled" then play back the video (you can check if VP9 is being used with the "Stats for nerds", if it shows webm there, it's VP9. Thank you
Reporter | ||
Comment 21•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #19) > Are you playing the video in fullscreen mode, or it's bad also in windowed > (default) mode ? Yes, it is in an ordinary window (In reply to Jean-Yves Avenard [:jya] from comment #20) > How is it playing in Chrome? (and is it using VP9, you can check by looking > at the "Stats for Nerds" entry. Chrome is fine and using VP9 > Also, how is it playing in Edge if you enable vp9? > instructions to enable it is available there: > https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in- > microsoft-edge/#6hqyUqXTGjklYP5H.97 > Go to about:flags search for VP9 and select "Enabled" > then play back the video (you can check if VP9 is being used with the "Stats > for nerds", if it shows webm there, it's VP9. Edge also reports using VP9 and no jitter.
Flags: needinfo?(josh)
Comment 22•7 years ago
|
||
Do we have any idea if Chrome/Edge are using VP9 DXVA for those, or if they're decoding in software? I'm not sure how best to determine that, the applications in question might have debug output somewhere? CPU usage while decoding could also be a hint.
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 23•7 years ago
|
||
Don't know if we can check that. But seeing that MS is using the VP9 MFT (same with Chrome), and the MFT is HW accelerated, it's likely it's also HW accelerated (DXVA). On my machine here, the CPU can't keep up with SW VP9, and the skip to next keyframe is triggered all the time. Which isn't the case when using HW decoder. Frames are dropped, but not because the MFR skipped them, they have been dropped by the MDSM/Compositor
Comment 24•7 years ago
|
||
Josh, would you be able to try bisecting the cause of this failure with mozregression? Might shed a bit more light on what's going on. http://mozilla.github.io/mozregression/ Thanks!
Assignee | ||
Comment 25•7 years ago
|
||
We've already identified what is causing the problem: VP9 hardware acceleration via D3D11
Flags: needinfo?(josh)
Comment 26•7 years ago
|
||
Is this planned to get fixed for FF 51 if VP9 hardware acceleration via D3D11 gets implemented for it?
Updated•7 years ago
|
Whiteboard: platform-rel
Assignee | ||
Comment 28•7 years ago
|
||
(In reply to walmartguy from comment #26) > Is this planned to get fixed for FF 51 if VP9 hardware acceleration via > D3D11 gets implemented for it? The feature will be available in FF 52, provided this problem can be resolved in time.
Comment 29•7 years ago
|
||
Thx for the information. I strongly suggest to keep VP9 hardware decoding disabled until the stuttery playback issue is fully resolved.
How far did we get in deciding what to do? Do we know if VP9/D3D11 is or will be in 52?
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 31•7 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #30) > How far did we get in deciding what to do? Do we know if VP9/D3D11 is or > will be in 52? The issue isn't HW VP9 per say. I can reproduce the problem with h264 too. The issue is the use of D3D11. It happened that YouTube with VP9 was working nicely before, because it was a software decoder outputting software YUV buffer. I'm still investigating where the bottleneck is. The profiler had shown that the most amount of time (>60%) was spent in the YUV->RGB conversion out of the HW decoder. However, after removing this conversion (and the sync copy) we still drop frames like crazy.
Flags: needinfo?(jyavenard)
Comment 32•7 years ago
|
||
I have this same issue with Firefox 52 and above 64bit on Windows 10 with GTX 950.
Updated•7 years ago
|
platform-rel: --- → +
Whiteboard: platform-rel → [platform-rel-Youtube]
Comment 33•7 years ago
|
||
Just wanted to confirm I have the same issue on Firefox Developer Edition 52.0a2 (2017-01-08) (64-bit), running on Windows 10 Anniversary Edition. I recently upgraded from a GTX 660 Ti to a GTX 1070 and suddenly all YouTube videos appeared to run at very noticeably reduced framerate, even though the "Stats for nerds" dialog didn't show any dropped frames. Other browsers (Chrome, Edge) did not appear to have this issue. Refreshing the profile or creating a new one seemed to resolve the problem at first, but that lasted only until a restart of Firefox - my guess is that FF runs without hardware acceleration on the first run. I can also confirm that disabling either of these settings can be used as a workaround (so the problem does indeed seem to be D3D11 related): media.wmf.vp9.enabled media.windows-media-foundation.allow-d3d11-dxva
Anything we can do to get this moving?
Flags: needinfo?(ajones)
Assignee | ||
Comment 35•7 years ago
|
||
The issue isn't vp9 per say. It's D3D11. I can reproduce the problem with h264 decoding. I think it just happen when enabling vp9 hardware we switched all those people from software decoding/render to d3d11 render. For now we should be disable vp9 hardware decoder
(In reply to Milan Sreckovic [:milan] from comment #34) > Anything we can do to get this moving? I'm hoping you're offering to help. See the email.
Flags: needinfo?(ajones)
Bas is attempting some investigation, but can't reproduce so far.
Comment 39•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #35) > The issue isn't vp9 per say. It's D3D11. > For now we should be disable vp9 hardware decoder Do we have any data on how much we can benefit from enabling VP9 HW decoding ? What percentage of users may be running into this jittery issue ? Since FF52 is right on beta channel now, it seems to a chance to let us make a decision whether it's worth enabling on FF52 or later?
Updated•7 years ago
|
status-firefox54:
--- → affected
Keywords: perf
Comment 40•7 years ago
|
||
Anthony, per comment 35 and comment 39, could it be an option once we can't fix it in beta cycle ?
Flags: needinfo?(ajones)
(In reply to Astley Chen [:astley] (UTC+8) from comment #40) > Anthony, per comment 35 and comment 39, could it be an option once we can't > fix it in beta cycle ? My thinking is to not change anything until Bas has finished his investigation.
Flags: needinfo?(ajones)
Comment 42•7 years ago
|
||
> My thinking is to not change anything until Bas has finished his
> investigation.
That makes sense. Thanks.
Comment 44•7 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #43) > Bas, any updates here? It's complicated, I don't own this particular card, and with my NVidia card from the same generation I can't reproduce the issue. Having said that I've been able to reproduce a bunch of badness in our video code. When it comes to actual limitations on integrated GPUs our problems seem to be likely related to memory bandwidth issues, but I don't see that explaining this particular case. I'm in the process of rewriting a bunch of our DXVA media code to hopefully be a little better.
Flags: needinfo?(bas)
While Bas is looking at video performance in general, this is not something that we'd uplift to 52 (especially in view of it being ESR.) At this point, if this is a problem, we should block VP9 decoding as discussed in some of the previous comments. Anthony, leaving this to you to decide what to do for 52 and 53. For 54, if we get to a performance improvement on video, we could have it ride the trains.
Flags: needinfo?(ajones)
Jean-Yves - can you write a patch to block VP9 hardware decode everywhere except nightly for now?
Flags: needinfo?(ajones) → needinfo?(jyavenard)
Bas, which bug has your D3D11 video/integrated card investigations and conclusions?
Flags: needinfo?(bas)
Comment 48•7 years ago
|
||
It's worth giving the build here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2bcc92fecba8aa3401941c086b169d009834fcb8 a shot
Flags: needinfo?(bas)
Comment 49•7 years ago
|
||
If someone could could provide me with a compiled build, I'd give it a try.
Comment 50•7 years ago
|
||
Win32: https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-2bcc92fecba8aa3401941c086b169d009834fcb8/try-win32/firefox-54.0a1.en-US.win32.zip Win64: https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-2bcc92fecba8aa3401941c086b169d009834fcb8/try-win64/firefox-54.0a1.en-US.win64.zip Thanks!
Flags: needinfo?(tempel.julian)
Comment 51•7 years ago
|
||
Anthony, if you know someone having issues, have them try that build.
Flags: needinfo?(ajones)
Comment 52•7 years ago
|
||
Hi, I'm affected by this bug and I've just tried out this build. In my case, not only the jittering problem still occur with media.wmf.vp9.enabled set to true, videos also get a pinkish tone. Compare the pref set to off (http://puu.sh/ufygO/e494946ae6.png) with it set to on (http://puu.sh/ufyhJ/7ee21d2d93.png). The video is https://www.youtube.com/watch?v=dodnbYkbiZE. In current Nightly builds, the color problem does not happen with the preference set to either value. I'd post my about:support in case it's useful to someone, but I'm not very used to bug reporting here. Should I just paste the whole text in my comment?
Comment 53•7 years ago
|
||
(In reply to Gustavo Silva from comment #52) > I'd post my about:support in case it's useful to someone, but I'm not very > used to bug reporting here. Should I just paste the whole text in my comment? You can refer to comment 5 and install a helper add-on, after that you can copy the text presented in the new tap with URL about:media and paste here.
Assignee | ||
Comment 54•7 years ago
|
||
(In reply to Astley Chen [:astley] (UTC+8) from comment #53) > (In reply to Gustavo Silva from comment #52) > > I'd post my about:support in case it's useful to someone, but I'm not very > > used to bug reporting here. Should I just paste the whole text in my comment? > > You can refer to comment 5 and install a helper add-on, after that you can > copy the text presented in the new tap with URL about:media and paste here. Reporting the content of about:media isn't very helpful here, it's not about the data content but what hardware is being used. So copy/paste of the about:support is preferred. Gerald, could you test with the Dell desktop with the nvidia 1060 installed how it goes? Thank you
Flags: needinfo?(jyavenard) → needinfo?(gsquelart)
Comment 55•7 years ago
|
||
Thanks, Ryan. The performance issue still exists, it looks like the video is played with half of the fps. Additionally, the colors look wrong with the test build.
Comment 56•7 years ago
|
||
Could you have a look at the colors with this build? https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-3d59b897cd3cdfde550134b4f04710efb682ddb7/try-win64/ https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-3d59b897cd3cdfde550134b4f04710efb682ddb7/try-win32/
Comment 57•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #56) > Could you have a look at the colors with this build? > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > 3d59b897cd3cdfde550134b4f04710efb682ddb7/try-win64/ > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > 3d59b897cd3cdfde550134b4f04710efb682ddb7/try-win32/ Colors are still broken with that build (still fine with current Nightly). However, I just made a few more tests and discovered something interesting. The stuttering problem can be fixed in both builds by resetting the media.benchmark.vp9.fps preference, restarting the browser, then playing a video, forcing the preference to be recreated. After this first restart, videos will play correctly, but after another restart two things can happen. If the preference had ended up with a value less than media.benchmark.vp9.threshold (150), videos will still play as normal. If it has a value greater than or equal to that, videos will show stuttering starting from that second restart. Here's my about:support, taken from a new profile I created to test this bug (my main profile seems to have become bugged and its about:support shows every field blank for some reason): Application Basics ------------------ Name: Firefox Version: 54.0a1 Build ID: 20170223030204 Update Channel: nightly User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 OS: Windows_NT 10.0 Multiprocess Windows: 1/1 (Enabled by default) Safe Mode: false Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Extensions ---------- Name: Application Update Service Helper Version: 2.0 Enabled: true ID: aushelper@mozilla.org Name: FlyWeb Version: 1.0.0 Enabled: true ID: flyweb@mozilla.org Name: Form Autofill Version: 1.0 Enabled: true ID: formautofill@mozilla.org Name: Multi-process staged rollout Version: 1.9 Enabled: true ID: e10srollout@mozilla.org Name: Pocket Version: 1.0.5 Enabled: true ID: firefox@getpocket.com Name: Presentation Version: 1.0.0 Enabled: true ID: presentation@mozilla.org Name: SHA-1 deprecation staged rollout Version: 1.0 Enabled: true ID: disableSHA1rollout@mozilla.org Name: Shield Recipe Client Version: 1.0.0 Enabled: true ID: shield-recipe-client@mozilla.org Name: Web Compat Version: 1.1 Enabled: true ID: webcompat@mozilla.org Name: WebCompat Reporter Version: 1.0.0 Enabled: true ID: webcompat-reporter@mozilla.org Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: wheel input enabled; touch input enabled; scrollbar drag enabled WebGL 1 Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0) WebGL 1 GL Version: OpenGL ES 2.0 (ANGLE 2.1.0.2a250c8a0e15) WebGL 1 GL Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 1 WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000a195) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses WebGL2 Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0) WebGL 2 GL Version: OpenGL ES 3.0 (ANGLE 2.1.0.2a250c8a0e15) WebGL 2 GL Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 2 WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000a195) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses Audio Backend: wasapi Direct2D: true DirectWrite: true (10.0.14393.351) GPU #1 Active: Yes Description: NVIDIA GeForce GTX 1060 6GB Vendor ID: 0x10de Device ID: 0x1c03 Driver Version: 21.21.13.7849 Driver Date: 1-20-2017 Drivers: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2umx C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvd3dum,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvwgf2um Subsys ID: 37391458 RAM: 6144 Diagnostics AzureCanvasAccelerated: 0 AzureCanvasBackend: Direct2D 1.1 AzureCanvasBackend (UI Process): skia AzureContentBackend: Direct2D 1.1 AzureContentBackend (UI Process): skia AzureFallbackCanvasBackend (UI Process): cairo GPUProcessPid: 11868 GPUProcess: Terminate GPU Process Decision Log D3D9_COMPOSITING: disabled by default: Disabled by default WEBRENDER: unavailable by runtime: Build doesn't include WebRender Important Modified Preferences ------------------------------ accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 2 browser.download.importedFromSqlite: true browser.places.smartBookmarksVersion: 8 browser.sessionstore.upgradeBackup.latestBuildID: 20170223030204 browser.startup.homepage_override.buildID: 20170223030204 browser.startup.homepage_override.mstone: 54.0a1 browser.urlbar.daysBeforeHidingSuggestionsPrompt: 3 browser.urlbar.lastSuggestionsPromptDate: 20170223 browser.urlbar.userMadeSearchSuggestionsChoice: true dom.gamepad.extensions.enabled: true extensions.lastAppVersion: 54.0a1 general.useragent.locale: en-GB media.benchmark.vp9.fps: 137 media.benchmark.vp9.versioncheck: 2 media.gmp-gmpopenh264.abi: x86_64-msvc-x64 media.gmp-gmpopenh264.lastUpdate: 1487886726 media.gmp-gmpopenh264.version: 1.6 media.gmp-manager.buildID: 20170223030204 media.gmp-manager.lastCheck: 1487890409 media.gmp-widevinecdm.abi: x86_64-msvc-x64 media.gmp-widevinecdm.lastUpdate: 1487886727 media.gmp-widevinecdm.version: 1.4.8.903 media.gmp.storage.version.observed: 1 media.hardware-video-decoding.failed: false network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.history.expiration.transient_current_max_pages: 122334 plugin.disable_full_page_plugin_for_types: application/pdf security.sandbox.content.tempDirSuffix: {f56c1bc0-f6eb-4a8a-9e33-1413bdc394c8} services.sync.declinedEngines: ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found. Important Locked Preferences ---------------------------- Places Database --------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.13.1 Version in use: 4.13.1 NSS Expected minimum version: 3.30 Beta Version in use: 3.30 Beta NSSSMIME Expected minimum version: 3.30 Beta Version in use: 3.30 Beta NSSSSL Expected minimum version: 3.30 Beta Version in use: 3.30 Beta NSSUTIL Expected minimum version: 3.30 Beta Version in use: 3.30 Beta Experimental Features --------------------- Sandbox ------- Content Process Sandbox Level: 2
> Gerald, could you test with the Dell desktop with the nvidia 1060 installed > how it goes? Thank you Yes, I can reproduce what Gustavo and walmartguy talked about: Stutters on nightly and the provided binaries, and wrong colours with the provided binaries. media.benchmark.vp9.fps=229 > threshold=150 Same about:support as in comment 57, except the video driver is at version 21.21.13.7849 (I updated it today). And Subsys ID=37181458. (I've got a GTX 1060 6MB by Gigabyte, "OC ed.") Please contact me if you'd like me to try things...
Flags: needinfo?(gsquelart)
Assignee | ||
Comment 59•7 years ago
|
||
(In reply to Gustavo Silva from comment #57) > video, forcing the preference to be recreated. After this first restart, > videos will play correctly, but after another restart two things can happen. > If the preference had ended up with a value less than > media.benchmark.vp9.threshold (150), videos will still play as normal. If it > has a value greater than or equal to that, videos will show stuttering > starting from that second restart. if the fps value is > 150 you'll be using VP9 in YouTube otherwise you'll use H264... So something is amiss with the VP9 Hardware decoder with nvidia pascal chipset. For now, just disable it with media.wmf.vp9.enabled set to false.
Comment hidden (mozreview-request) |
Comment 61•7 years ago
|
||
Are we sure this is a Nvidia issue? I don't think we have any feedback regarding Intel Kabylake and AMD Polaris yet. It could be well broken on these platforms too if it is a general problem of the video renderer in FF. VP9 decoding is fine with other programs on Nvidia, e.g. Edge.
Assignee | ||
Comment 62•7 years ago
|
||
(In reply to walmartguy from comment #61) > Are we sure this is a Nvidia issue? I don't think we have any feedback > regarding Intel Kabylake and AMD Polaris yet. It could be well broken on > these platforms too if it is a general problem of the video renderer in FF. > VP9 decoding is fine with other programs on Nvidia, e.g. Edge. AMD has disabled for now their VP9 decoder when used with the Microsoft MFT. Only their own MFT is supported and we have a bug open for that to support it. So for now, the common factor of people with issues, all have nvidia adapters.
Comment 63•7 years ago
|
||
Hrm, this suggests that VP9 hardware decoding is giving us an NV12 frame with a different color space than BT601 or BT709. I'll have to figure out a way to get DXVA to tell me about this. That's another thing I'll have to take into account with my NV12 patch then.
Comment 64•7 years ago
|
||
Could someone try the colors in: https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-ec0d420827e9a3cf6167c993326260ff24fd0735/try-win32/ https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-ec0d420827e9a3cf6167c993326260ff24fd0735/try-win64/
Comment 65•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #64) > Could someone try the colors in: > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win32/ > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win64/ Colors are correct in this build.
Comment 66•7 years ago
|
||
mozreview-review |
Comment on attachment 8840782 [details] Bug 1314458: Only enable VP9 hardware decoding on nightly channel. https://reviewboard.mozilla.org/r/115214/#review117250
Attachment #8840782 -
Flags: review?(ajones) → review+
Comment 67•7 years ago
|
||
Pushed by ajones@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b3dd5dafe84d Only enable VP9 hardware decoding on nightly channel. r=kentuckyfriedtakahe
Comment 68•7 years ago
|
||
(In reply to Gustavo Silva from comment #65) > Colors are correct in this build. For me too, but that's not surprising since there is no hardware video decoding with that build. ;) Instead, it uses software decoding. Config is set to use hardware decoding and it's doing this with FF 52 beta.
Comment 69•7 years ago
|
||
(In reply to walmartguy from comment #68) > (In reply to Gustavo Silva from comment #65) > > Colors are correct in this build. > For me too, but that's not surprising since there is no hardware video > decoding with that build. ;) > Instead, it uses software decoding. Config is set to use hardware decoding > and it's doing this with FF 52 beta. I didn't change anything with relation to that in this build, are you sure you didn't somehow trigger hardware video decoding to be disabled? Could you try again with a clean profile? I double checked and this build definitely uses hardware accelerated video decoding for me. (Not with VP9, but that's because my hardware doesn't support VP9 video decoding in general)
Comment 70•7 years ago
|
||
(In reply to Gustavo Silva from comment #65) > (In reply to Bas Schouten (:bas.schouten) from comment #64) > > Could someone try the colors in: > > > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win32/ > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win64/ > > Colors are correct in this build. Did you doublecheck whether colors were correct? I just want to make sure I actually have color conversion right here.
Comment 71•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #70) > (In reply to Gustavo Silva from comment #65) > > (In reply to Bas Schouten (:bas.schouten) from comment #64) > > > Could someone try the colors in: > > > > > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > > > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win32/ > > > https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com- > > > ec0d420827e9a3cf6167c993326260ff24fd0735/try-win64/ > > > > Colors are correct in this build. > > Did you doublecheck whether colors were correct? I just want to make sure I > actually have color conversion right here. Yes, media.wmf.vp9.enabled is set to true, videos still stutter, but colors are definitely correct. I can also check if it's using hardware acceleration, but I don't know what to look for.
Comment on attachment 8840782 [details] Bug 1314458: Only enable VP9 hardware decoding on nightly channel. Approval Request Comment [Feature/Bug causing the regression]: bug 1292374 [User impact if declined]: video playback problems on some hardware, especially for 60fps video [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: not yet [Needs manual test from QE? If yes, steps to reproduce]: I do not have the appropriate hardware to repro, so I can't state the STR better than the bug description [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: we're just reverting the behaviour by flipping a pref [String changes made/needed]: none
Flags: needinfo?(ajones)
Attachment #8840782 -
Flags: approval-mozilla-beta?
Comment 73•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b3dd5dafe84d
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Comment 74•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #69) > I didn't change anything with relation to that in this build, are you sure > you didn't somehow trigger hardware video decoding to be disabled? Could you > try again with a clean profile? I double checked and this build definitely > uses hardware accelerated video decoding for me. (Not with VP9, but that's > because my hardware doesn't support VP9 video decoding in general) Yes, it also fails with a fresh profile. In about:support it says "CP+[GFX1-]: Failed to create a D3D11 content device: 0x887a002d" ,if that makes any difference. (In reply to Gustavo Silva from comment #71) > I can also check if it's using hardware > acceleration, but I don't know what to look for. You can easily check this with the tool Nvidia Inspector: http://www.techspot.com/downloads/5077-nvidia-inspector.html If there is VPU usage, it's using hardware decoding. If there's none, it's software decoding (also CPU usage will be higher).
Comment 75•7 years ago
|
||
Btw: VP9 hardware decoding still is enabled by default with a fresh profile and 52 candidate 1, even though performance is terrible. Is this intended for the final build? If it is, it's a bad idea since lots of people will complain about bad YT performance.
Comment 76•7 years ago
|
||
I'm running Firefox 52.0b6/win64-EME-free and I don't notice any acceleration under Windows 7 64 with GTX 1060 6GB and the latest NVIDIA drivers (378.66). Is hardware acceleration of VP9 only supported under Windows 10? While watching 4K youtube videos hundreds of frames get dropped and CPU usage is close to 100% (i.e. all four cores of my Intel Core i5 2500 are busy). Also is it too much to ask to show VP9 hardware acceleration status in about:support? Currently it only shows "Supports Hardware H264 Decoding: YES/NO". And I'm interested in all other supported codecs as well, not just AVC/H.264 and VP9.
Comment 77•7 years ago
|
||
(In reply to Artem S. Tashkinov from comment #76) > Is hardware acceleration of VP9 only supported under Windows 10? Yes, only Windows 10 Redstone.
Comment 78•7 years ago
|
||
Is there any chance of getting HW acceleration of VP9 under Windows 7/Linux? Under Linux no video codec is HW accelerated at all :(
Comment 79•7 years ago
|
||
I don't think so, maybe Jean-Yves Avenard will tell us more about this. If you want to play VP9 hardware accelerated on Windows 7/Linux, give mpv with CUDA a try. It can also stream YT videos.
Comment 80•7 years ago
|
||
(In reply to walmartguy from comment #74) > (In reply to Bas Schouten (:bas.schouten) from comment #69) > > I didn't change anything with relation to that in this build, are you sure > > you didn't somehow trigger hardware video decoding to be disabled? Could you > > try again with a clean profile? I double checked and this build definitely > > uses hardware accelerated video decoding for me. (Not with VP9, but that's > > because my hardware doesn't support VP9 video decoding in general) > Yes, it also fails with a fresh profile. In about:support it says > "CP+[GFX1-]: Failed to create a D3D11 content device: 0x887a002d" > ,if that makes any difference. > > (In reply to Gustavo Silva from comment #71) > > I can also check if it's using hardware > > acceleration, but I don't know what to look for. > You can easily check this with the tool Nvidia Inspector: > http://www.techspot.com/downloads/5077-nvidia-inspector.html > If there is VPU usage, it's using hardware decoding. If there's none, it's > software decoding (also CPU usage will be higher). Hrm, not sure what the issue is there. That probably doesn't have anything to do with my particular build and might be something that landed on central. No idea. Good to know the colors are right though.
Comment 81•7 years ago
|
||
Comment on attachment 8840782 [details] Bug 1314458: Only enable VP9 hardware decoding on nightly channel. turn off vp9 hardware decoding in 52 and 53 Should be in 52 rc2.
Attachment #8840782 -
Flags: approval-mozilla-release+
Attachment #8840782 -
Flags: approval-mozilla-beta?
Attachment #8840782 -
Flags: approval-mozilla-beta+
Attachment #8840782 -
Flags: approval-mozilla-aurora+
Comment 82•7 years ago
|
||
We shouldn't have closed this out yet since the patch that landed is only a workaround. Regarding questions about which release that workaround will be in, it did indeed miss the RC1 release but should be in the next RC build later this week.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla54 → ---
Comment 83•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #70) > Did you doublecheck whether colors were correct? I just want to make sure I > actually have color conversion right here. I'm sorry, but there might be some problem with colors after all. First of all, I used NVIDIA Inspector (as recommended in comment #74) and I *can* see VPU usage in that build when media.wmf.vp9.enabled = true, so it seems to be using hardware acceleration. Second, I want to add that unlike what I've read here, I don't seem to be affected by this bug in 60fps videos. Take these sample videos: 24fps: https://www.youtube.com/watch?v=H29eJBC87mE 30fps: https://www.youtube.com/watch?v=FF2IrlqwXLI 60fps: https://www.youtube.com/watch?v=wZEgv9PNm2Q I can only see stuttering in the first two. Finally, I compared the same frame on the 30fps video with media.wmf.vp9.enabled = true (http://puu.sh/unZ15/e7d7435975.png) and media.wmf.vp9.enabled = false (http://puu.sh/unZ2k/5ebc6f80e7.png), and although the difference in color isn't as noticeable as in the first test build I tried, there is still something off. However, do note that this also happens in regular Nightly.
Comment 84•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/ff266510b1c9
Comment 85•7 years ago
|
||
There can be some difference in color by video driver's processing with DXVA enabled, especially with skin tones. I gave the latest testbuild another try and it is indeed not using hardware decoding here with VP9. However, hardware decoding for H.264 still works (and colors seemed to be normal).
Comment 86•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/34bd9ed6b265
Comment 87•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-release/rev/34bd9ed6b265
Comment 88•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-esr52/rev/34bd9ed6b265
status-firefox-esr52:
--- → fixed
Updated•7 years ago
|
Flags: needinfo?(tempel.julian)
Comment 89•7 years ago
|
||
(In reply to Gustavo Silva from comment #83) > (In reply to Bas Schouten (:bas.schouten) from comment #70) > > Did you doublecheck whether colors were correct? I just want to make sure I > > actually have color conversion right here. > > I'm sorry, but there might be some problem with colors after all. First of > all, I used NVIDIA Inspector (as recommended in comment #74) and I *can* see > VPU usage in that build when media.wmf.vp9.enabled = true, so it seems to be > using hardware acceleration. > > Second, I want to add that unlike what I've read here, I don't seem to be > affected by this bug in 60fps videos. Take these sample videos: > > 24fps: https://www.youtube.com/watch?v=H29eJBC87mE > 30fps: https://www.youtube.com/watch?v=FF2IrlqwXLI > 60fps: https://www.youtube.com/watch?v=wZEgv9PNm2Q > > I can only see stuttering in the first two. Finally, I compared the same > frame on the 30fps video with media.wmf.vp9.enabled = true > (http://puu.sh/unZ15/e7d7435975.png) and media.wmf.vp9.enabled = false > (http://puu.sh/unZ2k/5ebc6f80e7.png), and although the difference in color > isn't as noticeable as in the first test build I tried, there is still > something off. However, do note that this also happens in regular Nightly. The last one may be using BT709, which we're currently not supporting correctly, there's a bug on that.
Comment 90•7 years ago
|
||
So far It looks like NVIDIA GTX 950, 960, 970, 1060, and 1070 have this problem.
Comment 91•7 years ago
|
||
Do you have any issues playing the video at https://base-n.de/webm/VP9 Sample.html ? YouTube seems to refuse to give me the VP9 versions for the videos linked here.
Comment 92•7 years ago
|
||
Plays with horribly low framerate here on Nightly.
Comment 93•7 years ago
|
||
Same for me. It plays just like the affected YouTube videos.
Comment 94•7 years ago
|
||
Hrm. So this seems to play fine on Intel Kaby Lake hardware with VP9 decoding. So it does indeed seem to be an NVidia GP102 specific issue.
Comment 95•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #3) > Not all GTX 960 cards have VP9 decoding. All GTX 960 cards DO have vp9 decoding. cards are based on gm206. do not mistake a 960m with a 960.
Comment 96•7 years ago
|
||
(In reply to Artem S. Tashkinov from comment #78) > Is there any chance of getting HW acceleration of VP9 under Windows 7/Linux? > > Under Linux no video codec is HW accelerated at all :( There is a chance, but not from mozilla, the developers have turned neglectful towards customers using decent operating systems. DXVA2 on windows 7 handles VP9 hardware acceleration just fine, its simply a matter of making use of it.
Assignee | ||
Comment 97•7 years ago
|
||
(In reply to Danial Horton from comment #95) > (In reply to Jean-Yves Avenard [:jya] from comment #3) > > Not all GTX 960 cards have VP9 decoding. > > All GTX 960 cards DO have vp9 decoding. cards are based on gm206. > > do not mistake a 960m with a 960. please, read the history before commenting, this has been addressed before. Comment 9. Also https://en.m.wikipedia.org/wiki/GeForce_900_series#GeForce_900_.289xx.29_series
Comment 98•7 years ago
|
||
The GM204 version 960 is NOT a card. it is embedded on the motherboard. Your post stated 960 CARDS. there is no such thing as a GM204 960 "card". Have a nice day.
Comment 99•7 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #82) > We shouldn't have closed this out yet since the patch that landed is only a > workaround. Regarding questions about which release that workaround will be > in, it did indeed miss the RC1 release but should be in the next RC build > later this week. Tagging 54 as affected, when 52 and 53 are tagged as "affected" and the patch has been uplifted to all those branches, doesn't make sense to me. Should we tag 54 as "fixed" and 55 as "affected?
Flags: needinfo?(ryanvm)
Comment 100•7 years ago
|
||
Yes we should. Tracking status for things that involve NIGHTLY_BUILD ifdefs gets tricky :(
Comment 101•7 years ago
|
||
Just wanted to add that 1080 GTX is affected too. Also, any chance the patch forced high 3d clocks on youtube playback as I addressed here? https://bugzilla.mozilla.org/show_bug.cgi?id=1351507 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170323090023 Steps to reproduce: Any 720p HD video uses 1708/2502 core/mem clocks using an nvidia GTX 1080 (low gpu usage ~5%) IE and edge use 620/202 and higher gpu usage (~15%). Its a shame because high clocks use ~40W more power. Firefox version is 53.0b6 (64-bit), nvidia drivers are 378.92 Also, at https://www.youtube.com/html5, WebM VP8 and MSE & WebM VP9 are disabled. Thanks
Assignee | ||
Comment 102•7 years ago
|
||
(In reply to chekkm8 from comment #101) > Just wanted to add that 1080 GTX is affected too. Also, any chance the patch > forced high 3d clocks on youtube playback as I addressed here? > https://bugzilla.mozilla.org/show_bug.cgi?id=1351507 > > User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) > Gecko/20100101 Firefox/53.0 > Build ID: 20170323090023 > > Steps to reproduce: > > Any 720p HD video uses 1708/2502 core/mem clocks using an nvidia GTX 1080 > (low gpu usage ~5%) > > IE and edge use 620/202 and higher gpu usage (~15%). > > Its a shame because high clocks use ~40W more power. > > Firefox version is 53.0b6 (64-bit), nvidia drivers are 378.92 > VP9 hardware acceleration is disabled in current release. It is only enabled by default in Nightly (version 55). you can enable it with setting the preference media.wmf.vp9.enabled to true. Current Nightly will give you much better perforrmance. Playing a 4K 60fps YouTube only uses about 5% CPU on my machine (Dell XPS 15 with nvidia 1050)
Comment 103•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #102) > (In reply to chekkm8 from comment #101) > > Just wanted to add that 1080 GTX is affected too. Also, any chance the patch > > forced high 3d clocks on youtube playback as I addressed here? > > https://bugzilla.mozilla.org/show_bug.cgi?id=1351507 > > > > User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) > > Gecko/20100101 Firefox/53.0 > > Build ID: 20170323090023 > > > > Steps to reproduce: > > > > Any 720p HD video uses 1708/2502 core/mem clocks using an nvidia GTX 1080 > > (low gpu usage ~5%) > > > > IE and edge use 620/202 and higher gpu usage (~15%). > > > > Its a shame because high clocks use ~40W more power. > > > > Firefox version is 53.0b6 (64-bit), nvidia drivers are 378.92 > > > > VP9 hardware acceleration is disabled in current release. > > It is only enabled by default in Nightly (version 55). > you can enable it with setting the preference media.wmf.vp9.enabled to true. > > Current Nightly will give you much better perforrmance. > Playing a 4K 60fps YouTube only uses about 5% CPU on my machine (Dell XPS 15 > with nvidia 1050) Same thing with 55.0a1 64bit
Assignee | ||
Comment 104•7 years ago
|
||
What is youtube.com/html5 showing? can you please go to about:support and attach the output here. When you play the video, right click on the video and select stats for nerds. You can copy/paste the content. Please paste the content here. Also something that would be helpful. Install the about:media extension available at: https://addons.mozilla.org/en-US/firefox/addon/about-media/ Open a new window, open the YouTube video giving you problem. Now open a new tab and go to about:media copy/paste the entirety of what this page is showing here. Thanks
Comment 105•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #104) > What is youtube.com/html5 showing? > > can you please go to about:support and attach the output here. > > When you play the video, right click on the video and select stats for > nerds. You can copy/paste the content. Please paste the content here. > > Also something that would be helpful. > Install the about:media extension available at: > https://addons.mozilla.org/en-US/firefox/addon/about-media/ > > Open a new window, open the YouTube video giving you problem. > Now open a new tab and go to about:media > > copy/paste the entirety of what this page is showing here. > > Thanks WebM VP8 & MSE & WebM VP9 enabled. Tried h264ify and they get disabled. But both with and without h264ify has high clocks. Without h264ify I get the low performance bug. HTMLMediaElement debug data https://www.youtube.com/watch?v=9wcjpBO154Q&feature=youtu.be blob:https://www.youtube.com/f988b4fc-d5ee-4c34-a445-bc81239d7396 currentTime: 4763.558458 readyState: 3 Quality: 100% (total:13783 dropped:9 corrupted:0) Buffered ranges: [(4299.955, 4784.951)] SourceBuffer[0]: (4299.955, 4784.968333) SourceBuffer[1]: (4299.954, 4784.951) Internal Data: Audio Decoder: wmf audio decoder Audio Frames Decoded: 21639 Audio State: ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=30 out=29 qs=1 pending=0 wfd=0 wfk=0 sid=188 Video Decoder: blank media data decoder Hardware Video Decoding: disabled Video Frames Decoded: 14316 (skipped=0) Video State: ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=44 out=44 qs=0 pending:0 wfd=0 wfk=0 sid=185 Dumping Data for Demuxer: 1939a842400 Dumping Audio Track Buffer(audio/mp4a-latm): mLastAudioTime=4765.597666 Audio Track Buffer Details: NumSamples=22735 Size=13921467 Evictable=13364703 NextGetSampleIndex=21827 NextInsertionIndex=22735 Audio Track Buffered: ranges=[(4299.955000, 4784.968333)] Dumping Video Track Buffer(video/webm; codecs=vp9): mLastVideoTime=4763.919000 Video Track Buffer Details: NumSamples=14550 Size=29914643 Evictable=28218599 NextGetSampleIndex=13919 NextInsertionIndex=14550 Video Track Buffered: ranges=[(4299.954000, 4784.951000)] MediaDecoder State: channels=2 rate=48000 hasAudio=1 hasVideo=1 mPlayState=PLAYING mdsm=1938bc3c800 MediaDecoderStateMachine State: GetMediaTime=4763558458 GetClock=4763571104 mMediaSink=1939957f680 state=DECODING mPlayState=3 mSentFirstFrameLoadedEvent=1 IsPlaying=1 mAudioStatus=idle mVideoStatus=idle mDecodedAudioEndTime=4765576332 mDecodedVideoEndTime=4763919000mAudioCompleted=0 mVideoCompleted=0mIsPrerolling=0 VideoSink Status: IsStarted=1 IsPlaying=1 VideoQueue(finished=0 size=11) mVideoFrameEndTime=4763585000 mHasVideo=1 mVideoSinkEndRequest.Exists()=0 mEndPromiseHolder.IsEmpty()=0 Application Basics ------------------ Name: Firefox Version: 55.0a1 Build ID: 20170330030213 Update Channel: nightly User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 OS: Windows_NT 10.0 Multiprocess Windows: 1/1 (Enabled by default) Google Key: Found Mozilla Location Service Key: Found Safe Mode: false Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Nightly Features -------------------------------------- Name: Activity Stream Version: 0.0.0 ID: activity-stream@mozilla.org Name: Application Update Service Helper Version: 2.0 ID: aushelper@mozilla.org Name: FlyWeb Version: 1.0.0 ID: flyweb@mozilla.org Name: Form Autofill Version: 1.0 ID: formautofill@mozilla.org Name: Multi-process staged rollout Version: 1.14 ID: e10srollout@mozilla.org Name: Pocket Version: 1.0.5 ID: firefox@getpocket.com Name: Presentation Version: 1.0.0 ID: presentation@mozilla.org Name: Shield Recipe Client Version: 1.0.0 ID: shield-recipe-client@mozilla.org Name: Site Deployment Checker Version: 1.0 ID: deployment-checker@mozilla.org Name: Web Compat Version: 1.1 ID: webcompat@mozilla.org Name: WebCompat Reporter Version: 1.0.0 ID: webcompat-reporter@mozilla.org Extensions ---------- Name: Classic Theme Restorer Version: 1.6.3 Enabled: true ID: ClassicThemeRestorer@ArisT2Noia4dev Name: Open With Version: 6.8.1 Enabled: true ID: openwith@darktrojan.net Name: Selected Search Version: 0.4.160328 Enabled: true ID: {a3b1e8b3-ba2c-4280-9768-198db1817b5d} Name: uBlock Origin Version: 1.11.4 Enabled: true ID: uBlock0@raymondhill.net Name: Video DownloadHelper Version: 6.2.0 Enabled: true ID: {b9db16a4-6edc-47ec-a1f4-b86292ed211d} Name: h264ify Version: 1.0.5 Enabled: false ID: jid1-TSgSxBhncsPBWQ@jetpack Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled WebGL 1 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000008257) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses WebGL 1 Driver Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1080 Direct3D11 vs_5_0 ps_5_0) WebGL 1 Driver Version: OpenGL ES 2.0 (ANGLE 2.1.0.2a250c8a0e15) WebGL 1 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture WebGL 2 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000008257) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses WebGL 2 Driver Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 1080 Direct3D11 vs_5_0 ps_5_0) WebGL 2 Driver Version: OpenGL ES 3.0 (ANGLE 2.1.0.2a250c8a0e15) WebGL 2 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc Audio Backend: wasapi Direct2D: true DirectWrite: true (10.0.14393.953) GPU #1 Active: Yes Description: NVIDIA GeForce GTX 1080 Vendor ID: 0x10de Device ID: 0x1b80 Driver Version: 21.21.13.7892 Driver Date: 3-16-2017 Drivers: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvd3dum,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2um Subsys ID: 61833842 RAM: 8192 Diagnostics ClearType Parameters: Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 400 AzureCanvasAccelerated: 0 AzureCanvasBackend: Direct2D 1.1 AzureCanvasBackend (UI Process): skia AzureContentBackend: Direct2D 1.1 AzureContentBackend (UI Process): skia AzureFallbackCanvasBackend (UI Process): cairo GPUProcessPid: 6964 GPUProcess: Terminate GPU Process ClearType Parameters: Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 400 Decision Log WEBRENDER: opt-in by default: WebRender is an opt-in feature Important Modified Preferences ------------------------------ accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.parent_directory: E:\Downloads\3 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 3 browser.display.background_color: #CCCCCC browser.display.use_document_fonts: 0 browser.download.folderList: 2 browser.download.importedFromSqlite: true browser.places.smartBookmarksVersion: 8 browser.search.suggest.enabled: false browser.search.useDBForOrder: true browser.sessionstore.interval: 60000 browser.sessionstore.upgradeBackup.latestBuildID: 20170330030213 browser.startup.homepage: about:preferences browser.startup.homepage_override.buildID: 20170330030213 browser.startup.homepage_override.mstone: 55.0a1 browser.tabs.animate: false browser.tabs.drawInTitlebar: false browser.tabs.warnOnClose: false browser.tabs.warnOnOpen: false browser.urlbar.autocomplete.enabled: false browser.urlbar.suggest.bookmark: false browser.urlbar.suggest.history: false browser.urlbar.suggest.openpage: false dom.apps.lastUpdate.buildID: 20160916101415 dom.apps.lastUpdate.mstone: 49.0 dom.apps.reset-permissions: true dom.gamepad.extensions.enabled: true dom.ipc.plugins.enabled.npietab2.dll: true dom.mozApps.used: true dom.push.userAgentID: 953f0173c3ca486e86ebb2da90326406 extensions.lastAppVersion: 55.0a1 font.internaluseonly.changed: true font.minimum-size.x-western: 9 font.size.variable.x-western: 13 gfx.crash-guard.d3d11layers.appVersion: 52.0 gfx.crash-guard.d3d11layers.deviceID: 0x1b80 gfx.crash-guard.d3d11layers.driverVersion: 21.21.13.7877 gfx.crash-guard.d3d11layers.feature-d2d: true gfx.crash-guard.d3d11layers.feature-d3d11: true gfx.crash-guard.status.: 2 gfx.crash-guard.status.d3d11layers: 2 gfx.crash-guard.status.d3d11video: 2 gfx.crash-guard.status.d3d9video: 2 media.benchmark.vp9.fps: 234 media.benchmark.vp9.versioncheck: 2 media.gmp-eme-adobe.abi: x86-msvc-x64 media.gmp-eme-adobe.lastUpdate: 1469565959 media.gmp-eme-adobe.version: 17 media.gmp-gmpopenh264.abi: x86_64-msvc-x64 media.gmp-gmpopenh264.enabled: true media.gmp-gmpopenh264.lastUpdate: 1485825343 media.gmp-gmpopenh264.version: 1.6 media.gmp-manager.buildID: 20170330030213 media.gmp-manager.lastCheck: 1490887774 media.gmp-widevinecdm.abi: x86_64-msvc-x64 media.gmp-widevinecdm.lastUpdate: 1485825344 media.gmp-widevinecdm.version: 1.4.8.903 media.gmp.storage.version.observed: 1 media.hardware-video-decoding.failed: false media.peerconnection.video.h264_enabled: true media.webrtc.debug.aec_log_dir: E:\Downloads\3 media.webrtc.debug.log_file: E:\Downloads\3 network.cookie.prefsMigrated: true network.dns.disablePrefetch: true network.http.speculative-parallel-limit: 0 network.predictor.cleaned-up: true network.prefetch-next: false places.database.lastMaintenance: 1490490409 places.history.enabled: false places.history.expiration.transient_current_max_pages: 122334 plugin.disable_full_page_plugin_for_types: application/pdf plugin.importedState: true plugin.load_in_parent_process.application/ietab2: true plugin.state.flash: 1 plugin.state.npbattlelog: 0 print.printer_Microsoft_Print_to_PDF.print_bgcolor: false print.printer_Microsoft_Print_to_PDF.print_bgimages: false print.printer_Microsoft_Print_to_PDF.print_duplex: -437918235 print.printer_Microsoft_Print_to_PDF.print_edge_bottom: 0 print.printer_Microsoft_Print_to_PDF.print_edge_left: 0 print.printer_Microsoft_Print_to_PDF.print_edge_right: 0 print.printer_Microsoft_Print_to_PDF.print_edge_top: 0 print.printer_Microsoft_Print_to_PDF.print_evenpages: true print.printer_Microsoft_Print_to_PDF.print_footercenter: print.printer_Microsoft_Print_to_PDF.print_footerleft: &PT print.printer_Microsoft_Print_to_PDF.print_footerright: &D print.printer_Microsoft_Print_to_PDF.print_headercenter: print.printer_Microsoft_Print_to_PDF.print_headerleft: &T print.printer_Microsoft_Print_to_PDF.print_headerright: &U print.printer_Microsoft_Print_to_PDF.print_in_color: true print.printer_Microsoft_Print_to_PDF.print_margin_bottom: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_left: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_right: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_top: 0.5 print.printer_Microsoft_Print_to_PDF.print_oddpages: true print.printer_Microsoft_Print_to_PDF.print_orientation: 0 print.printer_Microsoft_Print_to_PDF.print_page_delay: 50 print.printer_Microsoft_Print_to_PDF.print_paper_data: 1 print.printer_Microsoft_Print_to_PDF.print_paper_height: -1.00 print.printer_Microsoft_Print_to_PDF.print_paper_name: print.printer_Microsoft_Print_to_PDF.print_paper_size_unit: 0 print.printer_Microsoft_Print_to_PDF.print_paper_width: -1.00 print.printer_Microsoft_Print_to_PDF.print_resolution: 600 print.printer_Microsoft_Print_to_PDF.print_reversed: false print.printer_Microsoft_Print_to_PDF.print_scaling: 1.00 print.printer_Microsoft_Print_to_PDF.print_shrink_to_fit: true print.printer_Microsoft_Print_to_PDF.print_to_file: false print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_bottom: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_left: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_right: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_top: 0 privacy.clearOnShutdown.cookies: false privacy.clearOnShutdown.offlineApps: true privacy.clearOnShutdown.sessions: false privacy.cpd.offlineApps: true privacy.sanitize.sanitizeOnShutdown: true security.sandbox.content.tempDirSuffix: {1ea8b4d9-9ba4-4bc3-ae28-a0d28567b907} services.sync.declinedEngines: forms,history,tabs,passwords services.sync.engine.adblockplus: true services.sync.engine.bookmarks.validation.lastTime: 1490887571 services.sync.engine.history: false services.sync.engine.passwords: false services.sync.engine.prefs.modified: false services.sync.engine.tabs: false services.sync.lastPing: 1490880379 services.sync.lastSync: Thu Mar 30 2017 22:11:35 GMT+0300 (GTB Standard Time) services.sync.numClients: 2 storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1490490409 ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found. Important Locked Preferences ---------------------------- Places Database --------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.15 Beta Version in use: 4.15 Beta NSS Expected minimum version: 3.31 Beta Version in use: 3.31 Beta NSSSMIME Expected minimum version: 3.31 Beta Version in use: 3.31 Beta NSSSSL Expected minimum version: 3.31 Beta Version in use: 3.31 Beta NSSUTIL Expected minimum version: 3.31 Beta Version in use: 3.31 Beta Experimental Features --------------------- Sandbox ------- Content Process Sandbox Level: 2
Comment 106•7 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #12) > There's nothing really that stands out immediately. > > If someone could get me a profile (of all threads, in both processes) then > that might show interesting things. Gerald brought a GTX 1060 to the office in Auckland, and with that card in my desktop I can repro frame dropping on this video: https://www.youtube.com/watch?v=dodnbYkbiZE Here's a profile I captured playing about 30 seconds of the above "Nintendo Switch Unboxing" video: https://perfht.ml/2oG515J However, this DOOM 4k video plays fine (on my 4K screen): https://www.youtube.com/watch?v=737Gl1sm0rE Even if I tweak the playbackRate to play it at 4X playback speed that DOOM video plays fine. Yes, they're both VP9. So it seems only some VP9 content is affected, not all. Bas or Mattwoodrow: Can either of you gleam anything from the profile above?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bas)
Comment 107•7 years ago
|
||
Unfortunately the profile only shows the main threads and the compositor thread. The main thread is almost entirely idle (as expected with async video), and the compositor thread (on the GPU process) spends less than 2% of it's time compositing and is idle the rest. I assume the slowness is within the media threads, but unfortunately those are not recorded. Markus, is there an easy way to get other threads (like the media thread pool) included here? Or do we need to use an external profiling tool?
Flags: needinfo?(mstange)
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bas)
Comment 108•7 years ago
|
||
If you change the value of the "Threads" textbox in the Settings section of the profiler panel to "GeckoMain,Compositor,Media", then you'll also get MediaPlayback and MediaPDecoder threads.
Flags: needinfo?(mstange)
Comment 109•7 years ago
|
||
(In reply to Chris Pearce (:cpearce) from comment #106) > Gerald brought a GTX 1060 to the office in Auckland, and with that card in > my desktop I can repro frame dropping on this video: > https://www.youtube.com/watch?v=dodnbYkbiZE > > Here's a profile I captured playing about 30 seconds of the above "Nintendo > Switch Unboxing" video: > https://perfht.ml/2oG515J > > However, this DOOM 4k video plays fine (on my 4K screen): > https://www.youtube.com/watch?v=737Gl1sm0rE > > Even if I tweak the playbackRate to play it at 4X playback speed that DOOM > video plays fine. > > Yes, they're both VP9. > > So it seems only some VP9 content is affected, not all. It's worth noting here that the first video is 24fps, while the second is 60fps. I've been experiencing this bug for about two weeks on my Windows desktop, since upgrading to a Geforce GTX 1080 Ti[0], and while I haven't exactly been religious about checking frame rates, as far as I can recall every stuttering video I've checked has been something below 60fps. In the videos posted in comment 83, I see noticeable stuttering only on the 24fps video, but not the 30fps or 60fps videos; is it possible this is somehow related to frame interpolation (or lack thereof)? Without any sort of interpolation, 30fps would more or less look fine on a 60hz display, while 24fps would have a noticeable stutter. [0] - Oddly I did not experience this bug on my previous GPU, a Geforce GTX 970 -- as far as I understand, hardware vp9 decoding should have been enabled on that as well...
Assignee | ||
Comment 110•7 years ago
|
||
this has been my experience as well, this isn't related to the framerate... And I can also reproduce it with h264 too. I don't believe it's related to VP9 decoding per say. The difference is YUV software buffer vs DXVA
Comment 111•7 years ago
|
||
I can repro this bug on GTX 1080 on a desktop and GTX 1070 on laptop(Razer) by checking [1] to compare how smooth it is with media.wmf.vp9.enabled setting false and true. Based on the information I got in this bug. 1. It could happen on h624 and vp9. 2. No dropped frames reported on "Stats for nerds" when playback is not smooth. 3. It doesn't only happen on high framerate video(60fps). If the information above are all true, It seems like not a bug in video decoding pipeline. Perhaps it is a bug in rendering pipeline. As Anthony mentioned in our meeting, if this only happens on NVIDIA cards, maybe we should enable vp9 HW decoder on Intel's first instead of disabling it on all graphics cards. It sounds a good idea. [1]https://www.youtube.com/watch?v=TEdsQmjLMKs#t=42s
Comment 112•7 years ago
|
||
Bas, After talking with jya, he highly recommends you.:-) Would you be available to check it?
Flags: needinfo?(bas)
Comment 113•7 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #112) > Bas, > After talking with jya, he highly recommends you.:-) Would you be available > to check it? I've tried extensively on Kaby Lake and VP9 decoding seems to be fine there. This bug seems to only affect NVidia 10xx series cards, which is a small portion of our userbase so I'm not certain how important this really is right now, especially with the current focus on Quantum Flow. Having said that, this might be easy to fix, I'll happily order a 1080Ti and fix this bug when I have it anyway, but I'm not sure within the QF timeframe that expenditure (of money and time) would be justified. Anthony, you'll have a better idea of the effect this has.
Flags: needinfo?(bas) → needinfo?(ajones)
Reporter | ||
Comment 114•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #113) > This bug seems to only affect NVidia 10xx series cards, which is a small > portion of our userbase so I'm not certain how important this really is > right now, especially with the current focus on Quantum Flow. It's also happening on at least some 9xx (I have a 960), so you won't have to go through the expense of getting a 10xx card.
Comment 115•7 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #113) > (In reply to Blake Wu [:bwu][:blakewu] from comment #112) > > Bas, > > After talking with jya, he highly recommends you.:-) Would you be available > > to check it? > > I've tried extensively on Kaby Lake and VP9 decoding seems to be fine there. > This bug seems to only affect NVidia 10xx series cards, which is a small > portion of our userbase so I'm not certain how important this really is > right now, especially with the current focus on Quantum Flow. Having said > that, this might be easy to fix, I'll happily order a 1080Ti and fix this > bug when I have it anyway, but I'm not sure within the QF timeframe that > expenditure (of money and time) would be justified. > > Anthony, you'll have a better idea of the effect this has. (In reply to Josh Tumath from comment #114) > (In reply to Bas Schouten (:bas.schouten) from comment #113) > > This bug seems to only affect NVidia 10xx series cards, which is a small > > portion of our userbase so I'm not certain how important this really is > > right now, especially with the current focus on Quantum Flow. > > It's also happening on at least some 9xx (I have a 960), so you won't have > to go through the expense of getting a 10xx card. Yeah I have a 950 and I'm getting this too. It's not that restricted of a userbase
Comment 116•7 years ago
|
||
Just wanted to chime in as there seems to be a lot of h/w related misinformation happening here. H/w VP9 decoding on NV GPUs is a feature added in VDPAU Feature Set F which is what is supported by NVidia VP7+ h/w block. This means that the issue with h/w decoding on NV cards will happen on all GPUs with VP7+ video decoder. Such GPUs, at the moment of writing this, include: GM206 (used in GeForce GTX 950 and 960 cards - excluding some OEM 960 models based on GM204 chip) and all consumer Pascal GPUs (GP10x; used in all GTX 10x0 cards - 1050/Ti, 1060, 1070, 1080/Ti, Titan X/p). GeForce GTX 970 cards DO NOT support h/w decoding of VP9 and thus they shouldn't be affected by this bug. It should be perfectly possible to debug the issue on a GTX 1050 card which cost ~$100. All VDPAU Feature Set F (GM206) and Feature Set H (GP10x) cards should have the same behavior in VP9 h/w decoding. Some links: https://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_GPUs_containing_a_PureVideo_SIP_block https://developer.nvidia.com/nvidia-video-codec-sdk https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
Assignee | ||
Comment 117•7 years ago
|
||
(In reply to dgrdsv from comment #116) > Just wanted to chime in as there seems to be a lot of h/w related > misinformation happening here. > > H/w VP9 decoding on NV GPUs is a feature added in VDPAU Feature Set F which > is what is supported by NVidia VP7+ h/w block. The thing is, and I wrote this earlier before: I don't believe it's limited to those cards nor is it restricted to using VP9. It's any DXVA/D3D11 nvidia ones. You didn't see the problem before we enabled HW VP9 because prior this you would have got VP9 software decoding, which uses plain YUV software buffer.. If YouTube had served you H264, and hardware decoding was used, you would have seen the same problem: judder, stuttering playback. The reason for this is that typically, people with a discrete nvidia GPU (desktop) already have a processor moderately fast. Fast enough the we've determined it could do VP9 decoding fast enough, and so VP9 is enabled. If your browser states that it supports VP9, this is what YouTube will give us and they favour this codec.
Comment 118•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #117) > The thing is, and I wrote this earlier before: I don't believe it's limited > to those cards nor is it restricted to using VP9. > > It's any DXVA/D3D11 nvidia ones. > > You didn't see the problem before we enabled HW VP9 because prior this you > would have got VP9 software decoding, which uses plain YUV software buffer.. > > If YouTube had served you H264, and hardware decoding was used, you would > have seen the same problem: judder, stuttering playback. > > The reason for this is that typically, people with a discrete nvidia GPU > (desktop) already have a processor moderately fast. Fast enough the we've > determined it could do VP9 decoding fast enough, and so VP9 is enabled. > If your browser states that it supports VP9, this is what YouTube will give > us and they favour this codec. I don't think that this is the case as there are no issues with H.264 playback in FF52+ with h/w VP9 decoding being enabled on my GTX 1080 (using Windows 10 1607 and 1704 now). To me this looks like a purely VP9 codec h/w decoding related issue. With FF52 beta default settings VP9 videos were clearly playing with approximately half of their actual framerate here (which is probably why some people say that 50/60 fps VP9 videos aren't affected as they seems to be playing at 25/30 fps which looks "normal" unless you check the framerate). H.264 videos were always fine, no matter what VP9 decoding option was selected. Also - isn't h/w H264 decode supported in Firefox since 2015(ish)? I thought that the change was only for VP9 decode - making it h/w instead of s/w. This shouldn't affect H.264 content.
Assignee | ||
Comment 119•7 years ago
|
||
(In reply to dgrdsv from comment #118) > Also - isn't h/w H264 decode supported in Firefox since 2015(ish)? I thought > that the change was only for VP9 decode - making it h/w instead of s/w. This > shouldn't affect H.264 content. This is about YouTube... You will likely find that you never used h264 when watching youtube before (even if you thought you did). And that's my point... It was working well, because you never exercised that bits of code under normal circumstances. I can reproduce the same stuttering here with h264 with a GTX 1060. Same with vp9. It's when using GPU based surface that the issue occurs. Simply setting media.webm.enabled to true. Will completely disable VP9 (including software), from that point on YouTube will serve h264 in mp4
Comment 120•7 years ago
|
||
I don't have stuttering with GPU decoding YouTube 60fps H.264 video on GTX 1070 Windows 10 Redstone 2, only with VP9.
Comment 121•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #119) > (In reply to dgrdsv from comment #118) > > Also - isn't h/w H264 decode supported in Firefox since 2015(ish)? I thought > > that the change was only for VP9 decode - making it h/w instead of s/w. This > > shouldn't affect H.264 content. > > This is about YouTube... You will likely find that you never used h264 when > watching youtube before (even if you thought you did). > And that's my point... > > It was working well, because you never exercised that bits of code under > normal circumstances. > > I can reproduce the same stuttering here with h264 with a GTX 1060. Same > with vp9. It's when using GPU based surface that the issue occurs. > Simply setting media.webm.enabled to true. Will completely disable VP9 > (including software), from that point on YouTube will serve h264 in mp4 Do you mean to say false here? According to youtube's "Stats for nerds" I get vp9 delivered when this is set to true (as it appears to be by default) and other codecs when I set it to false. Further, using this video: https://www.youtube.com/watch?v=VZSKN312BXw as a test case, I see easily noticeable stuttering when the codec is vp9, and no stuttering at all when the codec is avc1.640028 (which googling tells me is h264 high profile level 4.0). So no, I don't think this is something that affects all codecs -- it appears to be vp9 specific, at least in my case. I'm skeptical of the claim that it's youtube-specific, are there any other sites using vp9 that I can test against?
Comment 122•7 years ago
|
||
Follow-up: is there an easy way to determine if hardware decoding is being used? I assume it is being used for h264 in the case I mentioned in my previous post, but I can't say for certain. Nightly's cpu usage stays quite low, but I'd prefer a definitive indicator.
Comment 123•7 years ago
|
||
GPU-Z has a VPU usage indicator.
Comment 124•7 years ago
|
||
I'm getting a little confused here, I have 3 NVidia GPU's (admittedly no GM206 or Pascal based GPU), and all of them do H.264 hardware decoding on YouTube (or anywhere else), just fine, on nightly.
Comment 125•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #117) > (In reply to dgrdsv from comment #116) > > Just wanted to chime in as there seems to be a lot of h/w related > > misinformation happening here. > > > > H/w VP9 decoding on NV GPUs is a feature added in VDPAU Feature Set F which > > is what is supported by NVidia VP7+ h/w block. > > The thing is, and I wrote this earlier before: I don't believe it's limited > to those cards nor is it restricted to using VP9. > > It's any DXVA/D3D11 nvidia ones. > > You didn't see the problem before we enabled HW VP9 because prior this you > would have got VP9 software decoding, which uses plain YUV software buffer.. > > If YouTube had served you H264, and hardware decoding was used, you would > have seen the same problem: judder, stuttering playback. > > The reason for this is that typically, people with a discrete nvidia GPU > (desktop) already have a processor moderately fast. Fast enough the we've > determined it could do VP9 decoding fast enough, and so VP9 is enabled. > If your browser states that it supports VP9, this is what YouTube will give > us and they favour this codec. Do you have any actual evidence of this beyond your particular affected 1060 card? Everyone I've asked to test this has no issues with H.264 decoding on their NVidia cards, either in YouTube or just manually loading H.264 videos (and the same on the three that I own).
Flags: needinfo?(jyavenard)
Comment 126•7 years ago
|
||
no stuttering on GP104 or GP106 here with h264 i use h264ify because windows 7 won't get vp9 acceleration (atleast until video sdk 8 is out)
(In reply to Bas Schouten (:bas.schouten) from comment #124) > I'm getting a little confused here, I have 3 NVidia GPU's (admittedly no > GM206 or Pascal based GPU), and all of them do H.264 hardware decoding on > YouTube (or anywhere else), just fine, on nightly. Chris can reproduce the issue on a desktop with a discrete GPU card. IIUC it isn't reproducible on a laptop.
Flags: needinfo?(ajones)
Comment 128•7 years ago
|
||
Is a fix for 55 possible?
Assignee | ||
Comment 129•7 years ago
|
||
Good news (or maybe not) I can reproduce on the Dell 9560 (Intel HD 630 and nvidia 1050) with e10s off and forcing in the nvidia settings the use of the discrete GPU. using this video https://youtu.be/iNJdPyoqt8U?t=44 full screen and resolution set to 4K. (seek to 44s on the beach seen) With the Intel IGP it's buttery smooth, with the nvidia there's a very small (but noticeable) jitter. It's not as bad as what I saw with a desktop GTX 1060, but it's definitely not as nice as with the intel.
Flags: needinfo?(jyavenard)
Comment 130•7 years ago
|
||
It's easily reproduceable here on a GTX1080 in the latest beta (54b12) by switching the media.wmf.vp9.enabled flag in about:config. No need to do anything else really. Here, I've recorded a couple of 60 fps videos with media.wmf.vp9.enabled set to false and then to true using your YouTube link: False: https://youtu.be/m6H7HAMr98o True: https://youtu.be/A5F14sXNSlw I mean, it's not like the difference is hard to notice =)
Assignee | ||
Comment 131•7 years ago
|
||
This is about what I'm seeing with the mobile 1050. With the desktop 1060 it was far less subtle.. it was more like a stutter with dozen frames dropped at a time. With the 1050, like on your video, it's a light jitter.
Assignee | ||
Comment 132•7 years ago
|
||
ok... correction now that I've enabled the ability to filter on which GPU VP9 decoding will be available (bug 1360006) Using https://youtu.be/iNJdPyoqt8U?t=44 as it's easy to tell on that scene. Software H264: super smooth Software VP9: super smooth Hardware H264 intel, very smooth, two or three steps with jitter Hardware H264 nvidia , very smooth, two or three steps with jitter Hardware VP9 intel, very subtle jitter, definitely not as smooth as software decoding Hardware VP9 nvidia, subtle jitter, slightly more obvious than the intel..
Assignee | ||
Comment 133•7 years ago
|
||
:Bas, I wonder how come you're not seeing you with your video adapter... even the intel one.
Flags: needinfo?(bas)
Comment 134•7 years ago
|
||
Comment 135•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jyavenard
Assignee | ||
Comment 136•7 years ago
|
||
This bug was fixed by the attached commit will open a follow up
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Comment 137•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #136) > This bug was fixed by the attached commit will open a follow up To be clear: you mean it should be fixed everywhere (by disabling HW accel) but not yet on Nightly, and Nightly will be fixed (without disabling HWA) by bug 1371290.
Assignee | ||
Comment 138•7 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #137) > (In reply to Jean-Yves Avenard [:jya] from comment #136) > > This bug was fixed by the attached commit will open a follow up > > To be clear: you mean it should be fixed everywhere (by disabling HW accel) > but not yet on Nightly, and Nightly will be fixed (without disabling HWA) by > bug 1371290. yes.. please try this build https://archive.mozilla.org/pub/firefox/try-builds/jyavenard@mozilla.com-c798b01103e2f8f8c05e52fbe5f7c5d6e2d59466/try-win64/firefox-55.0a1.en-US.win64.installer.exe and see if it's any better. I do believe that there are two issues reported in this bug. The one seen with the Gigabyte 1060GT, which drops a massive amount of frames as soon as DXVA is involved (that includes H264 content). And the light jitter that can be seen in the panning shots.
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(bas)
Comment 139•7 years ago
|
||
I can confirm that there is a massive improvement with your testbuild, it's almost smooth now. Only almost, because I can also confirm the remaining occasional judder you've mentioned (I tested with true 60fps video and got display refreshrate matching it almost perfectly).
Comment 140•7 years ago
|
||
Same here on a GTX1080 - this build is a lot better with VP9 h/w acceleration but video still isn't really smooth.
Comment 141•7 years ago
|
||
Calling this wontfix for 55 to get it off the various bug queries tracking regression bugs. Obviously bug 1371290 continues the fight for fixing 55+ :)
Assignee | ||
Comment 142•7 years ago
|
||
(In reply to dgrdsv from comment #140) > Same here on a GTX1080 - this build is a lot better with VP9 h/w > acceleration but video still isn't really smooth. You'll have to define smooth to me then... do you see a difference between HW decoding on or off? The build is supposed to fix the light jitter. However, testing on the 1060 that showed awful playback in the past, is now perfect, even playing at 2X (120fps rate). So it looks that the problem were both the same. There's an occasional frames that seem to be dropped, but I feel this is more related to clock inaccuracy/jitter and any improvement there will be hard.
Comment 143•7 years ago
|
||
I tried the build on comment 138 on my Dell XPS15 laptop and it plays video smooth! I will check GTX 1080 on a desktop and GTX 1070 on laptop(Razer) as comment 111 to see if the playback is smooth.
Assignee | ||
Comment 144•7 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #143) > I tried the build on comment 138 on my Dell XPS15 laptop and it plays video > smooth! I will check GTX 1080 on a desktop and GTX 1070 on laptop(Razer) as > comment 111 to see if the playback is smooth. make sure you toggle in the nvidia settings to force using the discrete card and the intel, so that all GPU types are tested. thank you.
Comment 145•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #142) > (In reply to dgrdsv from comment #140) > > Same here on a GTX1080 - this build is a lot better with VP9 h/w > > acceleration but video still isn't really smooth. > > You'll have to define smooth to me then... do you see a difference between > HW decoding on or off? > > The build is supposed to fix the light jitter. > > However, testing on the 1060 that showed awful playback in the past, is now > perfect, even playing at 2X (120fps rate). > > So it looks that the problem were both the same. There's an occasional > frames that seem to be dropped, but I feel this is more related to clock > inaccuracy/jitter and any improvement there will be hard. There is still some light jitter (how you describe it). It's definitely a lot better than on current beta (were videos were playing at half fps basically) but it's still not as smooth as s/w decoding.
Comment 146•7 years ago
|
||
I was using this video in 4k 60fps: https://www.youtube.com/watch?v=aqz-KE-bpKQ In the beginning, the camera is moving down gradually which makes stutter easy to spot.
Comment 147•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #144) > (In reply to Blake Wu [:bwu][:blakewu] from comment #143) > > I tried the build on comment 138 on my Dell XPS15 laptop and it plays video > > smooth! I will check GTX 1080 on a desktop and GTX 1070 on laptop(Razer) as > > comment 111 to see if the playback is smooth. > > make sure you toggle in the nvidia settings to force using the discrete card > and the intel, so that all GPU types are tested. > > thank you. I have checked NV GTX 1080 and 1070 on desktops and 1060 on a Razer laptop. They all play smooth with the discrete NV card and the Intel's.
Comment 148•7 years ago
|
||
So the fix for the heavy judder made it into FF 55 beta 8 and VP9 hardware decoding is reenabled with it, ok. However, as I and someone else already wrote: Thie issue is not fully fixed. There is still judder going on, especially in the first seconds after playback has started. This ticket should be reopened. Chromium is perfectly judder-free, while Firefox still isn't.
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 149•7 years ago
|
||
open a new bug if you're still experiencing it
Flags: needinfo?(jyavenard)
You need to log in
before you can comment on or make changes to this bug.
Description
•