Open Bug 1232652 Opened 9 years ago Updated 2 years ago

Skipping in videos with few keyframes uses a lot of CPU

Categories

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

defect

Tracking

()

People

(Reporter: sleepwalkingnarcolepticinsomniac, Unassigned)

References

Details

(Keywords: webcompat:contact-ready, Whiteboard: [contactready] [video])

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 Steps to reproduce: Examples I've come across tend to be NSFW, for example: http://www.xmoviesforyou.com/2015/12/readyornothereicum-nekane-the-kidnapping-of-nekane-12-04-2015.html The same vid is embedded from two different hosts. You can choose either. It starts playing normally (CPU-wise) but when you skip it, CPU skyrockets to maxing out or close to it. I've tested in stable and dev with clean profiles, and it happens every time. If you test the same vids in Chrome you'll notice it uses slightly higher resources than other vids from the same host, but handles them pretty well considering. Not really knowing what I'm talking about, it seems to me that this occurs when there are index issues with inferior encodes. Chrome seems to adjust on the fly, while Firefox has seizure. Actual results: Poorly encoded(?) html5 vids hemorrhage CPU once skipped Expected results: Poorly encoded(?) html5 vids should not have hemorrhaged CPU once skipped
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Can you clarify what you mean by 'skip' in the video. Skipping to a different location in the playback timeline? clicking on a link to a different page?
Could be keyframe distance as well as bad index, exacerbated by our frame-accurate seeking. I think Chrome is less precise.
Firefox uses frame accurate seeing by default and Chrome does not. This means that Firefox will decode from the keyframe to the seek target whereas Chrome will start playing form the keyframe.
Yes, skipping to a different location in the playback timeline. Picture freezes momentarily, and CPU skyrockets when it finally resumes. Keyframes are just like "chapters" in the index, right? By targeting the exact frame you're only gaining accuracy of a few frames (milliseconds I would guess), so I'm not sure how the benefits outweigh a pretty serious bug in this case.
(In reply to sleepwalkingnarcolepticinsomniac from comment #4) > Yes, skipping to a different location in the playback timeline. Picture > freezes momentarily, and CPU skyrockets when it finally resumes. Keyframes > are just like "chapters" in the index, right? By targeting the exact frame > you're only gaining accuracy of a few frames (milliseconds I would guess), > so I'm not sure how the benefits outweigh a pretty serious bug in this case. The video has 115308 frames and only 201 keyframes. 115308/201=573 which means we're getting one keyframe every 20 seconds of video. You can see slowly and accurately in Firefox and quickly and inaccurately in Chrome. Seeking on Firefox is faster if hardware decoding works but that depends on your GPU.
Thanks for clarifying. I thought keyframes were much closer together. That arguably would justify a slight delay, but that isn't the issue here. The problem is with videos that have index issues (the assumption) which play fine in other browsers, cause Firefox to start massively overusing CPU when skipping to a different location in the playback timeline.
The video is poorly encoded so browsers are forced to make a no-win trade off. It is worse on slower systems. The commands I used to diagnose the issue is: $ ffprobe -show_packets -select_streams v video.mp4 2>/dev/null |grep flags|grep K|wc 201 201 1608 $ ffprobe -show_packets -select_streams v video.mp4 2>/dev/null |grep flags|wc 115308 115308 922464 There is an API for fastSeek() which seeks to the nearest keyframe and developers can use custom controls that use fastSeek() instead of currentTime= Hallvord - can you talk to the site about keyframe spacing, fast vs accurate seek and the message they show when you play the video on Firefox?
Flags: needinfo?(hsteen)
I guess we can - however just to check: have we considered switching to Chrome's way of doing things? Also, the original reporter mentions this NSFW site as "an example" - presumable means s/he knows other sites that need contacting if we're going to do outreach?
Flags: needinfo?(ajones)
Summary: Poorly encoded(?) html5 vids hemorrhage CPU once skipped → Skipping in videos with few keyframes uses a lot of CPU
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's more to do with how inferior encodes are handled than a particular host. The example url I provided has the same video embedded from two different hosts, and they both have the same problem. The first one is the host that shows a message saying "for a better experience use Chrome instead of Firefox" or something to that effect. This is probably because the way Firefox skips is slightly slower and choppier as far as buffering for an extra beat when skipping around, coupled with the fact that it doesn't handle inferior encodes well. The way that these types of shadier sites operate doesn't allow a lot of quality control in terms of content being uploaded and they know their audience is going to be people skipping around quite a bit, so they're not wrong acknowledging that the performance will suffer in Firefox currently. If this video's keyframes are 20 seconds apart, which I gather from the title change is abnormally low, it would still put the degree of accuracy at 10 seconds in either direction. That's the worst case scenario and the average would be much lower. I know that it was said that the delay caused by "accurate seek" varies depending on hardware. My computer is nothing to brag about, but it's a quad core with 1G dedicated gpu, and a slight delay/extra second of buffering afterwards is almost always noticeable when skipping around frequently in videos in Firefox.
(In reply to Hallvord R. M. Steen [:hallvors] from comment #8) > I guess we can - however just to check: have we considered switching to > Chrome's way of doing things? Both inaccurate seek and fast seek are considered buggy by different populations. The way we do it is generally better but it does suffer the degenerate case where a poorly muxed video is slow on a slow machine. That is why we give developers the choice between fast vs accurate seek. Given that the site uses custom controls it may be very simple for them to use fastSeek() instead of currentTime=
Flags: needinfo?(ajones)
I'm not sure how effective outreach will be here (since reporter says "examples I've come across" - note plural, seems like it is sort of common and happens on several sites). Especially hard to get anyone to change things when the brokenness is subtle like this (just some sluggishness and CPU waste) and when the problem can easily be blamed on the UA (it can). Does anyone have contact information for xmoviesforyou.com? If I understand this correctly, there are two different fixes for the website. Either re-encode the video with more keyframes, or use the method video.fastSeek() when skipping.
Flags: needinfo?(hsteen)
Whiteboard: [needscontact] [video]
(In reply to Hallvord R. M. Steen [:hallvors] from comment #11) > I'm not sure how effective outreach will be here (since reporter says > "examples I've come across" - note plural, seems like it is sort of common > and happens on several sites). Especially hard to get anyone to change > things when the brokenness is subtle like this (just some sluggishness and > CPU waste) and when the problem can easily be blamed on the UA (it can). > > Does anyone have contact information for xmoviesforyou.com? > > If I understand this correctly, there are two different fixes for the > website. Either re-encode the video with more keyframes, or use the method > video.fastSeek() when skipping. The same video is embedded from two different hosts on that page. They both have the same issue. Their contact info is: https://openload.co/contact contact@videomega.tv (this is the site that flashes a warning that Firefox has inferior playback)
Whiteboard: [needscontact] [video] → [contactready] [video]
(In reply to sleepwalkingnarcolepticinsomniac from comment #12) > https://openload.co/contact Do you have a link for the video on the openload site?
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #13) > (In reply to sleepwalkingnarcolepticinsomniac from comment #12) > > https://openload.co/contact > > Do you have a link for the video on the openload site? They don't provide an easy option to watch on their site, but you can open up the video url in the browser's default player and it'll have the same issue: https://pgli2s.oloadcdn.net/dl/l/t9rcO1QfvkI/5N7LCwGSh8s/ReadyOrNotHereICum.15.12.04.The.Kidnapping.Of.Nekane.XXX.1080p.MP4-KTR.mp4?mime=true Not sure if that pokes a hole in the theory that the site is to blame. Maybe they're still setting the seek value. No idea how that works.
(In reply to sleepwalkingnarcolepticinsomniac from comment #14) > Not sure if that pokes a hole in the theory that the site is to blame. Maybe > they're still setting the seek value. No idea how that works. The underlying problem is the keyframe spacing. You can work around it by using inaccurate seeking but that isn't really the issue. Bug 1257107 should make seeking a bit faster.
Depends on: 1257107
Mass change P2 -> P3
Priority: P2 → P3
The bug regarding the huge CPU suck may or may not be fixed by now, but the underlying issue that html5 playback is inferior in Firefox is still a sentiment I see frequently, and one that I agree with from personal experience. I really want to like Firefox. Every once in a while, I try really hard to use it as my default browser. One of the most important aspects of a browser is for html5 playback to not only be fast and smooth, but to do so while using the minimum resources possible. Skipping around rapidly in a video timeline should usually take fractions of a second, and very rarely a second or two. These intervals while searching should have a brief spike in CPU. Firefox occasionally skips quickly, but even then the CPU spike lasts twice as long. More often though, skipping rapidly eventually causes 5-10 second buffering delays leading to CPU spikes that take even longer to normalize. Even people who don't have a monitoring tool for resources can feel the performance hit. It's slower and clumsier. If using fast seek over accurate seek would resolve these issues and the only drawback would be a marginal loss of accuracy in favor of optimizing speed and performance, that seems like a no-brainer. You have sites actually warning users that Firefox has an inferior html5 experience, and they're not wrong. I think that this one small issue affects the user experience and people's opinion of Firefox in general in a far more negative way than you realize. I still hope it gets sorted out. I really want to like Firefox.

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.