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)

52 Branch
x86_64
Windows 10
defect

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)

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
Is this happening with all videos?

Have you tried rebooting your machine see if that fixes anything.
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?
Not all GTX 960 cards have VP9 decoding.
(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?
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.
(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.
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.
(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)]
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.
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.
Blocks: 1292374
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
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
Flags: needinfo?(matt.woodrow)
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)
(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
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.
(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!
[Tracking Requested - why for this release]: Jittery VP9 playback for some users
Status: UNCONFIRMED → NEW
Ever confirmed: true
Tracking 52+ for the reason in Comment 16.
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)
Are you playing the video in fullscreen mode, or it's bad also in windowed (default) mode ?
Flags: needinfo?(josh)
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
(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)
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)
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
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!
Flags: needinfo?(josh)
We've already identified what is causing the problem:
VP9 hardware acceleration via D3D11
Flags: needinfo?(josh)
Is this planned to get fixed for FF 51 if VP9 hardware acceleration via D3D11 gets implemented for it?
Whiteboard: platform-rel
Tracking 53+ for this Jittery VP9 playback issue.
(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.
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)
(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)
I have this same issue with Firefox 52 and above 64bit on Windows 10 with GTX 950.
Priority: -- → P1
See Also: → 1312595
platform-rel: --- → +
Whiteboard: platform-rel → [platform-rel-Youtube]
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)
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.
(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?
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)
> My thinking is to not change anything until Bas has finished his
> investigation.

That makes sense. Thanks.
Bas, any updates here?
Flags: needinfo?(bas)
(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)
If someone could could provide me with a compiled build, I'd give it a try.
Anthony, if you know someone having issues, have them try that build.
Flags: needinfo?(ajones)
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?
(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.
(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)
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.
(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)
(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.
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.
(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.
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.
(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 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+
Pushed by ajones@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b3dd5dafe84d
Only enable VP9 hardware decoding on nightly channel. r=kentuckyfriedtakahe
(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.
(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)
(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.
(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?
https://hg.mozilla.org/mozilla-central/rev/b3dd5dafe84d
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
(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).
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.
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.
(In reply to Artem S. Tashkinov from comment #76)
> Is hardware acceleration of VP9 only supported under Windows 10?
Yes, only Windows 10 Redstone.
Is there any chance of getting HW acceleration of VP9 under Windows 7/Linux?

Under Linux no video codec is HW accelerated at all :(
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.
(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 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+
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 → ---
(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.
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).
Flags: needinfo?(tempel.julian)
(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.
So far It looks like NVIDIA GTX 950, 960, 970, 1060, and 1070 have this problem.
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.
Plays with horribly low framerate here on Nightly.
Same for me. It plays just like the affected YouTube videos.
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.
(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.
(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.
(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
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.
(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)
Yes we should. Tracking status for things that involve NIGHTLY_BUILD ifdefs gets tricky :(
Flags: needinfo?(ryanvm)
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
(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)
(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
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
(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
(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)
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)
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)
(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...
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
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
Bas, 
After talking with jya, he highly recommends you.:-) Would you be available to check it?
Flags: needinfo?(bas)
(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)
(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.
(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
See Also: → 1320279
See Also: → 1360006
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
(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.
(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.
(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
I don't have stuttering with GPU decoding YouTube 60fps H.264 video on GTX 1070 Windows 10 Redstone 2, only with VP9.
(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?
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.
GPU-Z has a VPU usage indicator.
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.
(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)
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)
Is a fix for 55 possible?
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)
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 =)
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.
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..
:Bas, I wonder how come you're not seeing you with your video adapter... even the intel one.
Flags: needinfo?(bas)
Assignee: nobody → jyavenard
This bug was fixed by the attached commit will open a follow up
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Depends on: 1371290
(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.
(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.
Flags: needinfo?(bas)
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).
Same here on a GTX1080 - this build is a lot better with VP9 h/w acceleration but video still isn't really smooth.
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+ :)
(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.
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.
(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.
(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.
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.
See Also: → 1372102
(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.
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)
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.