From https://www.reddit.com/r/firefox/comments/ob35no/severe_frame_drop_while_playing_yt_4k60/

Getting severe frame drops (~15%, sometimes more) while playing 4K@60 YouTube videos (VP9 codec) since almost a year I think. No issues on Chromium based browsers (Chrome, Edge, Brave, etc.)

Hardware: Asus Laptop i7-7500U HD620, 8 GB RAM, SSD

Frames dropped 1128 / 3589 (It's usually around 15-20% idk why it was higher this time)

https://share.firefox.dev/2UbqPXO

Video played back: https://www.youtube.com/watch?v=oj4fIW7cH3Q

We've recently landed some changes to improve performance with higher resolution videos (see bug 1692881). It would be useful to know if folks see any improvement in nightly.

(In reply to Bryce Seager van Dyk (:bryce) from comment #2)

We've recently landed some changes to improve performance with higher resolution videos (see bug 1692881). It would be useful to know if folks see any improvement in nightly.

Hello, I am the OP from reddit post. I am see seeing worse performance in Nightly for some reason.
https://imgur.com/a/ZUHiE8R

Hi, I read your post on Reddit, and it seems you have been encountering this issue for a while. I wonder if the performance on Nightly is worse than on Beta or on Release? or they are nearly the same?

I also noticed that you already tried to enable HW acceleration, but it seems not working?

Could you help me to test wathcing that video again but (following actions are all indepedent)
(1) disable media.rdd-process.enabled
(2) disable media.wmf.enabled and make sure media.ffvpx.enabled is enabled
to see what will happen on your side?

Thank you.

Hey, thanks for the help.

(In reply to Alastor Wu [:alwu] from comment #4)

Hi, I read your post on Reddit, and it seems you have been encountering this issue for a while. I wonder if the performance on Nightly is worse than on Beta or on Release? or they are nearly the same?

Yes, performance is worse on Nightly compared to Release. See last link

(In reply to Alastor Wu [:alwu] from comment #4)

I also noticed that you already tried to enable HW acceleration, but it seems not working?

I tried "media.hardware-video-decoding.force-enabled", performance is no different than without enabling it on Release with default settings. I checked with GPU usage in Task manager, GPU is being used but Firefox uses GPU differently than Edge https://imgur.com/gallery/w2YZcnL

(In reply to Alastor Wu [:alwu] from comment #4)

Could you help me to test wathcing that video again but (following actions are all indepedent)
(1) disable media.rdd-process.enabled
(2) disable media.wmf.enabled and make sure media.ffvpx.enabled is enabled
to see what will happen on your side?

Test done with 1 only, with 2 only and then both 1 & 2. https://imgur.com/a/14XtCJV

Thank you for help!
Would you mind to help me capture the debug on Nightly by using MOZ_LOG=MediaDecoder:5,MediaFormatReader:5,PlatformDecoderModule:5?
Thank you.

I have never "captured the debug" so I hope I did it right. These are the files generated in temp folder after running Nightly with those cmds.
https://drive.google.com/file/d/1BzKNrc_acT-kmn6L0LOKf5b0ZbqISTNq/view?usp=sharing

Interesting, the log shows that your situation is exactly what I've seen in bug 1692881, where video decoding is too slow so we want to (1) seek to next key frame earlier and (2) to store as much as possible frames as we can. However, in your log, none of these mechanism kicked in and bug 1692881 is actually used to mitigate that situation.

(2) will start taking effect when (1) start successfully. The reason of (1) failed on your side may be that we can't find the keyframe in your buffered range, so Firefox kept decoding data which were already late and would be discarded later. When you test that video, did you start video immediately after it starts loading? Could you help me to try to start video later until you see there are some data have already been buffered (via checking the progess bar on Youtube) and see if the result would be improved?

As both (1) and (2) didn't take effect on your case, I suspect that there might be other factors which slow down your decoding speed. Would you mind to help me use mozregression to bisect different versions of Firefox and see which one starts showing this issue?

Thank you so much.

In addition, probably worth to mention, on Ubuntu, my Nightly actually has better performace on that video. On Release 89 I have usually ~15% dropped frames, but on Nightly 91 I have <1% dropped frames.

(In reply to Alastor Wu [:alwu] from comment #8)

When you test that video, did you start video immediately after it starts loading? Could you help me to try to start video later until you see there are some data have already been buffered (via checking the progess bar on Youtube) and see if the result would be improved?

In all of the tests above I had video buffered to like 14-15 sec (seen as buffer health in stat for nerds) and then I played it.

(In reply to Alastor Wu [:alwu] from comment #8)

As both (1) and (2) didn't take effect on your case, I suspect that there might be other factors which slow down your decoding speed. Would you mind to help me use mozregression to bisect different versions of Firefox and see which one starts showing this issue?

Actually now that I think about it I only started watching 4K@60 (no issues on 4K@30 videos) YT videos since this YTber started uploading in April 2020 (this is like the only YTber that I watch who uploads 4K@60 footage). So now I am not sure if this issue was not present before 2020, as I only started noticing it since last year. Should I still run mozregression?

(In reply to Alastor Wu [:alwu] from comment #9)

In addition, probably worth to mention, on Ubuntu, my Nightly actually has better performace on that video. On Release 89 I have usually ~15% dropped frames, but on Nightly 91 I have <1% dropped frames.

For me performance on Nightly is significantly worse than Release.

Yes, as the performance is getting really bad for you on Nightly, it would be helpful if you could use mozregression to check that what version of Firefox starts getting such bad performance.
Thank you.

(In reply to Alastor Wu [:alwu] from comment #11)

Yes, as the performance is getting really bad for you on Nightly, it would be helpful if you could use mozregression to check that what version of Firefox starts getting such bad performance.
Thank you.

Wow, mozregression is an amazing tool, after 3 hours (1 hour just figure out the app & watching tutorial) I finally found the last release version which had no performance issues. v81 has no issues (sometimes no frame drops, other times ~0.5% frame drops, which is barely noticeable) but v82 do have performance issues. On more closer look problem originated b/w 2020-08-02 & 2020-08-04. Final result https://imgur.com/a/KSJVge6

Log--https://bin.snopyta.org/?9f86757f5d3be379#2uBgpabsYub461jbCkujdDf2KhgHdbx5rx8P2NnBFUE5
Let's hope this helps, again thank you so much for helping.

mozregression points to bug 1653409 from the log above.

Interesting, so bug 1653409 causes an almost fixed amount of dropped frames on 4k+60fps videos for you (~15%). But there is still a unknown factor which causes frame dropping becoming more serious on your computer, would you mind to use mozregression again to help me find out which version of Fireox starts dropping frame so serious?
Thank you so much.

Hmm, wait. Bug 1653409 would only affect rendering on MacOS, you are on Windows so it's not possible. Bug 1653166 looks more possible, but I can't make sure because it's about supporting scaling.

Sorry for late reply, had some issues back home. Again thanks for helping me.
Please disregard mozregression bisecting done in previous post. I mistook v81.0a1 as same as v81 release. I also clean installed Win 10 just to get a more clean environment for testing (% frames dropped have reduced to 11% for current release v90, for current nightly v92 still getting more than 50% frames dropped).

(In reply to Alastor Wu [:alwu] from comment #14)

Interesting, so bug 1653409 causes an almost fixed amount of dropped frames on 4k+60fps videos for you (~15%).

I logged % Frame dropped from v72 to v91 release. https://imgur.com/a/gTFpfMS

Did a bisection with mozregression b/w v80 & v81 release.
https://bin.snopyta.org/?3039d28a4fe61e3b#DVx6s9ZsKvAvw8tH64NNyiubozXN7Cpcx56KYLD9b2sk
https://imgur.com/a/JaNalTF

Another bisection b/w v90 & v91. (for severe frame drops)
https://bin.snopyta.org/?fb6033f58fb95f79#FginzHFfb4T71xfX14xGZjuuaiyXZoLcdqLLGoAGWJzk
https://imgur.com/a/nQEpaw9

Thank you so much. I will focus on your 90&91 bisection result first. I found this the affected push range from your result, which pointed out the bug 1717909 being a root cause. But I'm not so convinced by that because that bug seems affect crash reporting only.

And I noticed that there is a push which actually contains 40 merges at the same time, and I suspect the real root cause is among them. I know it's annoying, but if you don't mind, could you help me again to check those changeset and see which one causes the issue for you?

So you can go to this page and search a1125ca12e8090bf6e8b0752f40984bc3398e0e3. Then enter the changesets, which are included in that changeset, directly into the mozregression, which would directly open Firefox that was built based on that specific version. You could probably start testing from d23b5390345dac48f1c6fc66482edbe85d1ea3ad, which is from bug1718309. But that bug is used to prevent decoding too aggresively and related with bug1692881. As the mechanism I landed in bug1692881 didn't jump in when I checked your previous debug log, I guess that might not be the root cause for you. But still worth to try from that (maybe I'm wrong and that is the root cause?)

Thank you so much.

(In reply to Alastor Wu [:alwu] from comment #17)

And I noticed that there is a push which actually contains 40 merges at the same time, and I suspect the real root cause is among them. I know it's annoying, but if you don't mind, could you help me again to check those changeset and see which one causes the issue for you?

I just finished testing all those changesets, phew. All of them have severe frame drops ~50% result

Sorry for my late reply. So probably the result in the first bisection was incorrect, because you already tried all those changesets and all of them all have same sympton. I'm going to apply another change in bug 1717171, and I think that might (I hope so) help you and mitigate the severe frame drops.

(In reply to Alastor Wu [:alwu] from comment #19)

So probably the result in the first bisection was incorrect
If you mean 'comment 12' then, Yes. I mistook v81.0a1 same as v81 release. Bisection done in 'comment 16' should be accurate, I could do it again if you want.

If you mean 'comment 12' then, Yes. I mistook v81.0a1 same as v81 release. Bisection done in 'comment 16' should be accurate, I could do it again if you want.

Oh sorry I meant comment16 that pointed the root cause is bug 1717909, which is wrong, because in comment 18 you tested other changesets which are all eariler than that bug and still have serious drop frames. I think we can see if bug 1717171 helps first, if everything goes well, it should be on Nightly tomorrow or the day after tomorrow.

Would you mind to try today's Nightly to see if it improves the frame dropping issue or not?
Thank you.

Tested Stable release and Nightly. Can confirm situation has improved a lot in Nightly (still dropping twice as many frames compared to Release though), from 40-50% frame drops to now 20% frame drops (on release it's ~10%).
https://imgur.com/a/Cjb2w7Z

This is what video playback feels on current nightly, video basically freezes every few seconds. heavy frame drops come in batches.
https://www.youtube.com/watch?v=Rn1DKN7ZM20

'gfx.webrender.all' is already set to 'false' by default (in a completely new profile) but 'about:support' shows composting done by webrender.

Completely disabling Webrender (changes composting to 'Direct3D 11') by enabling these two preferences solve the issue completely.
gfx.webrender.compositor false
gfx.webrender.force-disable true

No more frame drops, unfortunately FF v93 will remove the option to disable it.
https://imgur.com/a/jHkky3f

It would be good to know if you encounter the same problem with "WebRender (Software D3D11)":
gfx.webrender.all=false
gfx.webrender.force-disable=false
gfx.webrender.software=true <---------
(restart Firefox to apply pref change)

With above settings
https://imgur.com/a/jOMllzH

Tested 95.0a1 (2021-10-11) and Yup some work has been, now GPU actually shows using "video decode" in task manager. Still getting around 6-8% frame drops, which is not that bad but video playback is still stuttery.

Would you mind to get a profiled result with media preset again? we added some new profiler labels and markers related with performance which would help us better analyze the data. Thank you!

https://share.firefox.dev/3DBD6Ge

From the profiled result in comment30, it seems the decoding was still too slow. For 60fps video, one frame's duration is around 16.6ms, and I can see decoding time easily exceeded that, some of them even took 30+ ms for a single frame. (See RequestDecode:V: markers in MediaSupervior thread)

Then I found that the decoder in GPU process spent a lot of time (26%) on NtGdiDdDDIWaitForSynchronizationObjectFromCpu. It seems to me that after decoder finished decoding the video, it couldn't give them back to up because of that blocking. And I found a post which might be related with this, and it seems related with swap chain?

Jeff, would you have any idea about those long blocking calls?

Thank you.

So NtGdiDdDDIWaitForSynchronizationObjectFromCpu is a pretty generic "wait for the GPU to be done with something" call. Time spent in there could be bad or it could be expected it's pretty hard to know, especially given how opaque MFT is. Alastor, do you have similar hardware to this? Are you able to reproduce the same time spent in NtGdiDdDDIWaitForSynchronizationObjectFromCpu?

Per comment1, the GPU which the reporter uses is Intel(R) HD Graphics 620. On my Dell Xp15 machine, my GPU is Intel(R) UHD Graphics 630 which is very similar with 620, based on this comparison. However, I didn't encounter any dropped frame on the same video where the reporter saw around 6~8% dropped frames. Here is my profiled result, the decoding took very short time and NtGdiDdDDIWaitForSynchronizationObjectFromCpu only took less than 1% time on the GPU process.

Based on this comment, MS people said the problem was caused by ANGLE, and the reporter uses ANGLE 2.1.14225 and mine is ANGLE 2.1.15727. And the lastest comment (2019 Sep) showed that the problem was still in the ANGLE master at that time, but it probably got fixed in the some version already. As I don't know much about ANGLE, is that something we can control? Or we need to ask users to update their ANGLE version?

Thank you.

(In reply to Alastor Wu [:alwu] from comment #33)

Per comment1, the GPU which the reporter uses is Intel(R) HD Graphics 620. On my Dell Xp15 machine, my GPU is Intel(R) UHD Graphics 630 which is very similar with 620, based on this comparison.

The link compared 'UHD Graphics 620' instead of 'HD Graphics 620'. 'UHD Graphics 630' is 15-60% (depending upon benchmark used) faster than 'HD Graphics 620' based on this comparison, also the architecture is different.

(In reply to Alastor Wu [:alwu] from comment #33)

the reporter uses ANGLE 2.1.14225 and mine is ANGLE 2.1.15727. And the [lastest comment].

About:Support
Current angle version as I can see in 'About:support' is 'ANGLE 2.1.15727', same as yours. That may have changed since starting of this bug report due to me updating graphics driver versions.

After updating the Nightly today and creating another new profile I am seeing ~3% frame drops as seen here. Don't know if it is the update or the new profile doing this (don't use Firefox as daily driver so haven't changed any settings or installed any extensions).
Here is the profiled result

kuldeep, can you compare and report GPU usage (both "3D" and "Video Decode") in Task Manager with Firefox vs Chrome?

Here you go https://imgur.com/a/9m7WrU1

It looks like Chrome is using the YUV swapchain support on your machine.

bug 1735694 is another report using Intel(R) HD Graphics 620 and has a lot of waiting time in NtGdiDdDDIWaitForSynchronizationObjectFromCpu.

Still reporduced with the latest Intel driver 30.0.101.1960?

(In reply to Takanori MATSUURA from comment #42)

Still reporduced with the latest Intel driver 30.0.101.1960?

Sorry for late reply. I don't really use that laptop anymore now after getting a new one, but I can confirm the bug is resolved now. I clean installed Firefox with only Adguard extension, here's a screenshot.

https://imgur.com/a/ClRsubO

Device is on slightly older Intel graphics driver version : 30.0.101.1340
Windows version 21H2 build 19044.1706

https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html
https://www.intel.com/content/www/us/en/support/articles/000091662/graphics.html

In case anyone else comes here in the future, make sure to update your Intel graphics driver to the latest version 31.0.101.2111 or later version for Gen9/Gen9.5/Gen11 integrated GPUs.