Closed Bug 1031121 Opened 7 years ago Closed 6 years ago
Gecko cannot display 60fps You
Tube videos with HTML <video>
YouTube is officially going 60 Frames Per Second on its videos. The problem is that Gecko does not display those extra frames. At all. I'm using the latest version of Flash player and Nightly. But I have also confirmed that Fx30 behaves the same. Users trying to view this are confused at the issue. Internet Explorer 11 and Chrome Dev Channel displays correctly. However Opera Dev Channel does not. I'm filing this under Plugins, but this may also be a Graphics/Layers issue.
Note: To test this, the video HAS to be set at 720p or higher.
I've done a bit more poking. According to the stats on the YouTube player, when 720p is chosen the frames are dropped to maintain 30fps. The NPAPI version of the plugin is also used in Opera Dev which shows similar behavior. I cannot get the beta PPAPI plugin to work for Opera Dev so there's no way for me to test there. BUT the PPAPI plugin in Chrome Dev shows the video properly. The HTML5 version of the video also drops frames in Firefox/Nightly compared to Opera Dev. Internet Explorer 11 on YouTube uses the HTML5 player by default and also displays the frames correctly. After all this, I believe that this should go into Graphics.
This bug is confusing. We have three video platforms that we could be talking about here: * Youtube Flash * plain <video> without MSE * <video> with MSE It's unlikely that we'll be spending any effort on improving Flash-based video, especially since we have such little control. So I'm going to scope this bug specifically to the <video> implementation. What is the exact hardware you're testing on, and what is our actual frame rate in the <video> case? And do you have MSE enabled?
Component: Graphics → Video/Audio
Summary: Gecko cannot display 60fps YouTube videos → Gecko cannot display 60fps YouTube videos with HTML <video>
The flash quip is unfortunate. Many Firefox users are confused about not seeing the extra frames and noticing that other browsers don't have a problem. 1. Its a fairly recent system: Intel Core i5 3570k 3.40GHz 8GB Ram AMD HD7970 3GB, Catalyst 14.6 beta drivers. 2. The current frame information display is not terribly informative about consistent framerate. If there's another way to determine that information, I'll gladly check it out. 3. I did not have MSE enabled at the time. But after testing with MSE: Nightly displays more frames. Its nowhere near as smooth as other platforms and is served VP9, not h264. Also, sometimes Nightly won't shutdown properly after enabling MSE. Bonus! A crash. https://crash-stats.mozilla.com/report/index/4053477d-79b0-4acd-9d56-c063e2140627
Note about the frame information: framesdisplayed and framespresented are in sync. So I supposed there's no dropped frames.
Thanks. I filed bug 1031532 for the crash so that we can track it separately from the framerate issues discussed here.
Any ideas on the stall at shutdown? On another note. YouTube's HTML5 player page does not detect MSE h.264 which is why I got the VP9 version. (I just now realize that its serving VP9 and not VP8! doh!)
(In reply to Leman Bennett [Omega] from comment #7) > On another note. YouTube's HTML5 player page does not detect MSE h.264 which > is why I got the VP9 version. That's bug 1027875.
FWIW I see smooth 60fps in flash mode at the target link in linux/x64, it might be worth trying to figure out what configurations hit the 30fps problem (vsync gone wrong?). I filed bug 1033045 for that > Also, sometimes Nightly won't shutdown properly > after enabling MSE. This is probably bug 931388
I also can no longer get youtube to serve me HTML5 video at that link with or without MSE :(
(In reply to John Schoenick [:johns] from comment #10) > I also can no longer get youtube to serve me HTML5 video at that link with > or without MSE :( Works for me. It won't serve you the 60fps video without MSE enabled. Also the video has to be set to either 720p or 1080p. It won't work on lower resolutions.
Using youtube-dl to list the available formats for the Titanfall video and then downloading a sample, I find: 720p WebM (DASH/MSE) and 720p MP4 (DASH/MSE) are served as 60fps, regular 720p MP4 is served as 30fps. Fetching one of the 60fps videos and playing it locally in Firefox works fine. So for native video, this bug reduces to needing MSE to be offered 60fps video, and enough of MSE working that we can switch to the 720p/1080p stream (which is currently broken, being fixed in bug 1024858 and bug 1025768).
(In reply to Matthew Gregan [:kinetik] from comment #12) > Using youtube-dl to list the available formats for the Titanfall video and > then downloading a sample, I find: 720p WebM (DASH/MSE) and 720p MP4 > (DASH/MSE) are served as 60fps, regular 720p MP4 is served as 30fps. > > Fetching one of the 60fps videos and playing it locally in Firefox works > fine. > > So for native video, this bug reduces to needing MSE to be offered 60fps > video, and enough of MSE working that we can switch to the 720p/1080p stream > (which is currently broken, being fixed in bug 1024858 and bug 1025768). Good to know. I look forward to those patches.
This is still an issue. Switching from 480p to 720p is seamless. Switching to 1080p from 720p will cause the video to stop painting. Audio will continue for a time until the video stops completely.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > This bug is confusing. No kidding. Bug 1091407 - is this a duplicate? Bug 1091653 - this is about Flash Player playback, which is what this report was originally about. When tested, I had the same issue in Opera, so it looks like either a Flash Player NPAPI problem, or maybe a YouTube problem. Bug 1033045 - this is about Flash Player playback being capped at 30 FPS, so it's definitely distinct from the above, right? Thanks in advance to anyone who can provide some clarity.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
6 years ago
See Also: → 1091653
6 years ago
See Also: 1091653 →
You need to log in before you can comment on or make changes to this bug.