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)
Core
Audio/Video: Playback
Tracking
()
NEW
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
Comment 1•9 years ago
|
||
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?
Comment 2•9 years ago
|
||
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.
Reporter | ||
Comment 4•9 years ago
|
||
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.
Reporter | ||
Comment 6•9 years ago
|
||
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)
Comment 8•9 years ago
|
||
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
Updated•9 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 9•9 years ago
|
||
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)
Comment 11•9 years ago
|
||
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]
Reporter | ||
Comment 12•9 years ago
|
||
(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)
Updated•9 years ago
|
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?
Reporter | ||
Comment 14•9 years ago
|
||
(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
Updated•9 years ago
|
Priority: -- → P2
Mass change P2 -> P3
Priority: P2 → P3
Reporter | ||
Comment 17•8 years ago
|
||
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.
Comment 18•6 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to keywords.
Keywords: webcompat:contact-ready
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•