Open Bug 1606162 Opened 4 years ago Updated 1 year ago

Playing video on Videobin.co results in high CPU - in ntoskrnl.exe, Windows 7

Categories

(Core :: Graphics, defect, P3)

73 Branch
x86_64
Windows 7
defect

Tracking

()

REOPENED
Tracking Status
firefox73 --- affected

People

(Reporter: therubex, Unassigned)

Details

(Keywords: perf)

Attachments

(2 files)

(Potentially NSFW website including popups & other "stuff" so proceed, cautiously.)

URL: https://videobin.co/pfltkg6ue425

Click to play the video.
(Might take a second or third or forth click... due to aforementioned, "stuff".)

Note the "stars" falling... (which I don't believe is the issue).

Eventually the video should start to play - perhaps (but in any case, so long as it attempts to start to load, you should see the issue).

Results:

On Win7 x64, in Mozilla browsers, the (Windows) process "NT Kernel & System" (aka "System" aka ntoskrnl.exe) starts to eat 50% CPU (on a 4 core processor), greatly affecting overall computer system performance.

Other browser:

On Google Chrome, resultant CPU usage remains in chrome.exe, leaving ntoskrnl.exe unaffected.

Other:

Perhaps it is not even the actual video playback that is the issue, but the web page itself? Not sure? In any case, visiting the site greatly affects one's computer system - and it does this outside of "firefox.exe" itself (which may only actually use < 10% CPU during this time).

dxgmms1.sys 6.1.7601.24513

It's possible that this is being caused by differences in performance between the video decoders used between Firefox and Chrome. In the case of Firefox we use a windows decoder, which could explain the CPU usage you're seeing, while Chrome uses a different decoder.

Could you capture a profile run using the Firefox Profiler? If you could set the threads being captured to '*' by putting that value in the 'Add custom threads by name:' text box that will capture all threads. Then could you link the profile on this bug? That will help give us a better idea on if anything else on the page is eating resources.

Flags: needinfo?(therubex)

Note the "stars" falling... (which I don't believe is the issue).

Perhaps it is not even the actual video playback that is the issue, but the web page itself? Not sure?

Well, at this point, I'm no longer able to duplicate the issue.
Currently, FF (74) is using ~15% CPU, all contained within "firefox.exe", ntoskrnl.exe unaffected.

Perhaps it was the "stars" falling?
(Somewhere, more recently, I've seen stars...)

Or perhaps it was an issue on their site, that they've since rectified?

In any case, I find it rather disturbing, that the issue occurred, that the issue manifested itself "outside" of FF, & that it was so intrusive to the computer at large.

Flags: needinfo?(therubex)

Aha, got it!

From Google Cache, with stars & high CPU.
Simply did a search, site:videobin.co, & luckily, quickly found a cached link that displayed the issue.

No telling how long it will last...

https://webcache.googleusercontent.com/search?q=cache:miH6DisgDicJ:https://videobin.co/cca4mjy7lych+&cd=3&hl=en&ct=clnk&gl=us&client=firefox-b-1-d

Is this what you need?

https://profiler.firefox.com/from-addon/marker-table/?globalTrackOrder=0-1-2-3-4-5-6-7-8-9-10-11&hiddenGlobalTracks=1-2-4-5-7-8-9-10-11&hiddenLocalTracksByPid=4812-2-4-6-7-8-9-10-11-12-13-15-16-17-18-19-20-24-25-26-27-28-29-30-31-32-33-34-35-36-37-38-39-40-41-42-43-44-45-46-48-49-50-51-54-55-56-57~9024-1-3-4-5~8364-1-3-4~5224-1-5-6-7-8-10-11-12-13-14-15-16-17-18-19-23-24-25~6136-1-2-4-5-7-8-10-11-12-13-14-15-16-17-18-19-23-24~1324-1-2-4-5-6-8-10-11-12-13-14-15-16-17-18-19-23-24-25-26-27-28-29-30~10004-2-4-6-7~9416-1-3-5-6-7-8-10-11-12-13-14-15-16-17-18-19-23-24-25~6192-1-3-5-6-7-8-10-11-12-13-14-15-16-17-18-19-23-24-25~9284-1-3-5-6-7-8-10-11-12-13-14-15-16-17-18-22~3308-1-3-5-6-7-8-10-11-12-13-14-15-16-17-18-19-23-24-25~8772-1-3-4-6-7-8-10-11-12-13-14-15-16-17-18-19-23-24-25&localTrackOrderByPid=4812-58-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-31-32-33-34-35-36-37-38-39-40-41-42-43-44-45-46-47-48-49-50-51-52-53-54-55-56-57~9024-7-0-1-2-3-4-5-6~8364-5-0-1-2-3-4~5224-26-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25~6136-25-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24~1324-31-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30~10004-8-0-1-2-3-4-5-6-7~9416-26-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25~6192-26-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25~9284-23-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22~3308-26-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25~8772-26-0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25~&thread=73&v=4

(In reply to therube from comment #5)

Is this what you need?

snip

There should be a share button that should upload the profile and give a smaller link. Would that happen to be a profile link from the page on the google cache with the worse performance?

Yes.
New Profile.
Open (orig) videobin.co link.
Issue not present.

Find "bad" (Google cached) videobin.co link.
Issue present.

https://perfht.ml/2NfoGnM

The profile you linked does show a lot of time being used to do painting. Based on the information you've provided it seems possible that the snow being painted by the page is done in a way that is degrading performance.

With regards to seeing the high CPU usage in non-Firefox process, this can be a product of that Firefox needs to interact with the operating system to perform certain operations (like decoding a video, or asking it to render something). If the operating systems itself is performing calculations that use a lot of CPU, this can result in behaviour like you see here.

I suspect this is actually an issue more closely related to graphics. However, since the page has removed the snow/stars, and since we don't know how long the cache will stay up, I'm going to resolve this. If they return the effect to the page, please reopen this and we can see if graphics are able to diagnose what's going on.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE

The point is not that the site is not causing particular issues - now.
The point is not that the cached page may go away at some point.

The point is that there is an issue - with FF, that at the least may hang FF - totally, that negatively impacts one's entire computer system - greatly.

If not "this" website, there will be another, that ends up likewise affecting FF, to the detriment of it's users.

The OS performing calculations is not the issue.
There is a direct relationship between that page (now the cached page with the stars - which is still live) & FF.
Close FF, & the issue subsides. Open FF to an affected page, & the issue returns.

Other (non-Mozilla) browsers were not affected.
Other Mozilla browsers, other then "FF Nightly" (including "legacy" browsers) are affected.

Have you even visited the cached page, yourself, to see what it may or may not do on your end?

Instead of AV/Playback (which may not even be the issue), I'm thinking I probably should have just posted this is "FF General" & let them ferret it out to where they believe it should have gone.

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

The priority flag is not set for this bug.
:bryce, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bvandyk)

(In reply to therube from comment #10)

snip

My explanation as to why you are seeing the CPU usage where it is was in response to comment 3 given that you seemed concerned as to why it was happening there.

I have visited the cached page and did not reproduce the issue on my machine. However, as I indicated above, I believe the issue is graphics related. To expand on that, based on the profile, I think it's a combination of the page's code drawing a lot of separate elements and how Firefox is drawing. I'm going to move this to the graphics component.

Component: Audio/Video: Playback → Graphics
Flags: needinfo?(bvandyk)
Blocks: wr-perf
Keywords: perf
Priority: -- → P3
No longer blocks: wr-perf
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: