Closed Bug 1318404 Opened 4 years ago Closed 2 years ago
Video playback broken (loop)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce: Playing a HTML5 video on YouTube. Actual results: Video playback keeps looping (usually the first few frames), audio is however working fine. Expected results: Video stream should not loop, hardware-acceleration broken, codec issues?
Did it use to work in FF49? If yes, could you install the tool mozregression to narrow down a regression range. See http://mozilla.github.io/mozregression/ for details. You need to install python 2.7 to rn Mozreg, then run the command "moeregression --good=49" and copy here the final pushlog from repository mozilla-inbound.
@Loic: Yes, it did work fine in FF49. Going to install and run mozreg. Thanks.
Same issue here on Fedora 24, intel graphics card (integrated) on a skylake laptop. Firefox 49 worked just fine, it's only version 50 having the problem. My desktop with an nvidia card (binary drivers) does not have the issue.
I'm sorry for spamming, but I wanted to add that the problem applies to gifs as well. Also it's something that happens randomly after a while. Apparently restarting the browser sometimes helps (for a little bit).
Same with Arch Linux on a Haswell desktop with intel graphic. Working with FF49 broken with FF50 and newer betas
We need a regression range. Could you run Mozregression and copy the pushlog, please.
Have the same problem under Debian Jessie, but can't reproduce it with "mozregression --good=49". Should i/we test it with default settings or with actually settings(of our "own" firefox)? Because there are settings, which are not yet set in the final one(Version 50), like settings for e10s. Is there maybe an other way to test it?
Yes, you can disable e10s when using the command --pref "browser.tabs.remote.autostart:false". Or you can create a new testing profile with all the prefs you want to set and use it with Mozregression with the command --profile=PATH --profile-persistence=reuse
Gentoo on a 4.4.26 kernel with Firefox 50.0 on a NVidia GeForce GTX 960 using the binary drivers (proc shows version 361.28). I never experienced it on FF 49, but on 50 I see it exactly as described in the original post. If I get time this week I'll download mozregression, but it sounds like that may only be so useful. This issue happens intermittently for me; I can only conclude the bug is present after using each FF instance for a while, and if the bug hasn't shown up I can't conclude that it never will. Interesting note: Once the issue began happening in my current Firefox instance I wanted to confirm it doesn't happen with Flash videos. I went to a Twitch.tv stream, where the issue remained in the HTML5 player. I switched to the Flash player (click the gear icon in the video overlay) and saw no issue, but when I switched back to the HTML5 player, the issue was gone.
I'm having the exact same effect. In my case i'm using Mesa 13.0.1 with a Radeon X280 with the RadeonSI driver. It looks like almost any kind of GFX driver can show this bug.
For some reason this 'bug' doesn't seem to happen anymore. Is there any possible (relevant/profile) information that may help (like e10 is force-enabled)? Packages installed: mesa 13.0.1-1 mesa-demos 8.3.0-2 mesa-libgl 13.0.1-1 mesa-vdpau 13.0.1-1 opencl-mesa 13.0.1-1 ffmpeg 1:3.2-2 xf86-video-ati 1:7.8.0-1 I would like to close this issue, but it seems other affected by this bug.
Workarounds for this bug include: 1. Enabling e10s, or 2. Setting the config option 'layers.acceleration.force-enabled' to false.
There is a bug filed for this in Gentoo's bugzilla as well: https://bugs.gentoo.org/show_bug.cgi?id=600344 The discussion there is mostly copied from here, but some folks who also experience this issue shared config and environment information there.
Simply enabling e10s fixed the problem for me completely (it's been over 24 hours now since I've been testing it extensively).
(In reply to dheddicke from comment #7) > Have the same problem under Debian Jessie, but can't reproduce it with > "mozregression --good=49". > > Should i/we test it with default settings or with actually settings(of our > "own" firefox)? > Because there are settings, which are not yet set in the final one(Version > 50), like settings for e10s. Is there maybe an other way to test it? Could you test with e10s disabled and layers.acceleration.force-enabled=true?
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 OS Linux 4.4.0-47-generic Multiprocess Windows 0/2 (Disabled by add-ons) Same issue here. Videos can be playing fine and then without restart or change of settings the looping starts. Setting the config option 'layers.acceleration.force-enabled' to false, as Soren121 said, did fix the issue.
Setting layers.acceleration.force-enabled to false fixed this for me as well.
I made some test (Fedora 24 4.8.8-200, Firefox 50): e10s enabled + layers.acceleration.force-enabled=true -> run normally e10s disabled + layers.acceleration.force-enabled=true -> bug e10s disabled + layers.acceleration.force-enabled=false -> run normally If I quite remember, setting layers.acceleration.force-enabled to true was an old workaround for a bug affecting youtube videos on my computer.
Matt, any idea about this issue?
I've tried multiple configurations (also tweaking e10, HWAccel, etc.), a new profile, some tweaking on the main configuration, but I couldn't reproduce the bug anymore. Could this be a bug in a library dep for media playback instead of a FF issue? The good news is that this bug doesn't happen for me anymore, but could you guys that still have this issue please use the mozregression tools as requested by Loic? Thanks.
(In reply to Nigiord from comment #18) > I made some test (Fedora 24 4.8.8-200, Firefox 50): > > e10s enabled + layers.acceleration.force-enabled=true -> run normally > e10s disabled + layers.acceleration.force-enabled=true -> bug > e10s disabled + layers.acceleration.force-enabled=false -> run normally > > If I quite remember, setting layers.acceleration.force-enabled to true was > an old workaround for a bug affecting youtube videos on my computer. Confirmed here, with Slackware current, kernel 4.4.32, firefox 50.1.0 and intel i915. e10s disabled + layers.acceleration.force-enabled=true -> bug e10s enabled + layers.acceleration.force-enabled=true -> run normally
This sounds like the Linux graphics issue (that I thought had been fixed) so I'll pass it on to graphics.
Component: Audio/Video: Playback → Graphics
I get this exact problem on FreeBSD 11 running the latest NVidia driver on a GeForce GTX 950. Firefox 50.1.0. The Nigiord in comment 18 (https://bugzilla.mozilla.org/show_bug.cgi?id=1318404#c18) explained the same scenario that worked for me as well. If I disable the offending plugin(s) that are forcing e10s to be off it works fine with layer acceleration forced on. Otherwise both must be off.
I've found a reliable way to repro this on Arch Linux, with Firefox 50 and 50.1.0, on three different systems (with different GPUs/etc). Videos play correctly for a while after Firefox starts, and then after a certain point all videos start looping the first few frames. The issue is resolved after restarting Firefox. After a bit of experimentation, the cause seems to be watching any video which is set to automatically loop. For example: https://gfycat.com/AdorableReflectingAmberpenshell The (11 second) video in the above link is set to loop automatically. After it's played once, it returns to the beginning, and the issue starts to occur (for that video, and for all future videos opened until Firefox is restarted). I've got layers.acceleration.force-enabled enabled (due to tearing issues), and electrolysis is off (due to plugins). I downloaded and ran mozregression, and tried revisions between release 47 and the present day, but was unable to repro the issue at all. Note that the issue is reproducible every time with the above 11-second steak video, when using the copy of Firefox which comes with Arch.
Same problem with Nvidia gtx1060 Firefox 50.1.0 Debian testing running latest Nvidia Stable driver. I had e10 blocked by an addon, installed Add-on Compatibility Reporter disable offending addon but after reboot e10 was disabled again, so i set extensions.e10sBlockedByAddons to false and have e10 enabled according to comment 18 https://bugzilla.mozilla.org/show_bug.cgi?id=1318404#c18. Now work fine butI can not say with certainty to have fixed the problem has followed randomly, look a few days
Same problem on the following system configurations. - Firefox 50.1.0 Nvidia gtx 970 with nvidia drivers, Gentoo Linux - Firefox 50.1.0 Intel Iris Graphics 6100, Gentoo Linux Sometimes the reported behavior occurs, sometimes it doesn't.
Same problem with gentoo linux (USE flags are in "bug supported" state, no customization of CFLAGS or any dependency debundling) X11 session (qtile) firefox 50.1.0 AMD RX480, opensource drivers Happens regardless hwaccel. Regardless the website, but every time with html5 videos. Youtube, coub, vk, twitch streams. Bug seem to be random. I can watch bunch of videos without a problem, then suddenly get this looping in next video. Experiencing this bug (now it is a twitch stream) while writing this report. I could open new tab and launch youtube video, it works without problems. I could open second tab with SAME stream, and it works fine. Affected player instance doesn't exactly play a loop of first frames. Every time I switch tabs it gets couple of new frames from stream into the loop. Now, after some minutes it almost self-healed, it can partially progress through the video steam. I have a black frame, some old frame (may be the first one) and some fresh frames played, then again black frame, old frame, etc. Finally, it showed downloading rotator for some time, and video stream came back to normal. This happens quite often though, I've got a habit to open another browser to watch broken video. No idea how today's case could self-heal, usually nothing can help, including refreshing/ctrl+f5 the page. Next time I will try to open same page in new tab.
Same problem on Gentoo linux with radeon drivers.
(In reply to Nigiord from comment #18) > > e10s enabled + layers.acceleration.force-enabled=true -> run normally > e10s disabled + layers.acceleration.force-enabled=true -> bug > e10s disabled + layers.acceleration.force-enabled=false -> run normally > I use Gentoo Linux on an Intel i7-2600 and Nvidia GTX-560. Nvidia driver version 375.26-r1. Firefox was compiled with none of the fancy stuff turned on. Had the looping too with e10s disabled + layers.acceleration.force-enabled=true. Then tried out both other settings and can confirm that the loops went away. Next I checked firefox-bin to exclude anything fishy going on with my build. Same result. Even built FF with custom-cflags and custom-optimization turned on. Still same behaviour. Your config trick seems to be the workaround for me until this gets proper fix.
Is this bug fixed in firefox-51 ?
I cannot recreate this bug in Firefox 51.0. Running FreeBSD 11 GeForce GTX 950 NVidia driver 375.26. I've confirmed e10s is enabled. I'll run this for a few days and confirm whether it's fixed or not. Can anyone else confirm that 51.0 fixes the issue?
The issue presented itself again...this time when e10s is disabled! When I have layers.acceleration.force-enabled=true and e10s gets disabled by an addons I get the looping. If I go back in and set 'disabled by addons' to false everything works as expected. Unfortunately this seems to reset itself after a time, annoying. Is anyone else seeing this?
The only reliable way to overcome this bug is opening browser command line (Shift + F2) and type "restart". This will preserve your opened tabs and enabled addons. Opened video usually starts to work.
Setting media.navigator.video.default_fps to 0 worked for me. The issue seems fixed in yesterday's (yesternight's) Nightly.
P.S. Actually setting media.navigator.video.default_fps to 48 should be better.
What finally has this working for me is layers.acceleration.force-enabled;false I don't know if any of these matter, but here is what I have: extensions.e10s.rollout.hasAddon;false extensions.e10sBlockedByAddons;true extensions.e10sBlocksEnabling;true
(In reply to Gene Mosher from comment #36) <snip> What version of Firefox?
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #22) > This sounds like the Linux graphics issue (that I thought had been fixed) so > I'll pass it on to graphics. What Linux graphics issue is this? Where can I read more about it? On my box (Debian Stretch + KDE + nouveau driver) the desktop freezes alongside the Firefox video glitch. Restarting plasmashell fixes both the freezing and the looping.
Bug is not fixed in firefox-51.0, tested with hwaccel. When hwaccel is disabled there are no problems.
"no problems" except poor video performance...
Bug still is there with Firefox 51.0.1 (64Bit, Linux, nvidia proprietary driver).
Why this bug is 'UNCONFIRMED' ???
I can confirm this with Firefox 50.1.0 and 51.0.1 on Linux, x86-64. Different hardware and desktop environments tested. This occurs with some other videos too, not only Youtube. Hardware acceleration is force-enabled. If not force-enabled (=disabled), the problem doesn't occur. Hardware video decoding is enabled but not force-enabled, I think this is the default.
Same issue here running Firefox 51.0.1 64-bit on Ubuntu 16.04 with Oibaf PPA ( https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers ) on an Intel Core i7-6700K and layers.acceleration.force-enabled=true. Could you please fix this ASAP? If this bug makes it into Firefox 52, it will mean that it will make it into an ESR, which would be very bad.
I have 51.0.1-1.3.x86_64 from the openSUSE "mozilla" repository on oS Leap 42.2, and have tried going back to the main OSS repo, but I have the video loop problem with both versions. Before, I had the same version on openSUSE 13.2, and video worked flawlessly, both on my main machine (intel GPU, Sandy Bridge i5 2500K) and on an older laptop (intel GPU). I can, unfortunately, not go back to oS 13.2, because the 42.2 installation replaces that. On my laptop with Debian Jessie video works.
setting "layers.acceleration.force-enabled" to false repaired it for me. This afternoon, even a completely new profile didn't work. Later, when I tried another new profile, video worked in that profile, and - strangely enough - the first video after that also worked in my standard profile which is unchanged from ffx 51.0.1-1.3 on openSUSE 13.2. Now I've turned off HW acceleration - which worked on openSUSE 13.2 - video is OK again.
(In reply to N. W. from comment #44) > Same issue here running Firefox 51.0.1 64-bit on Ubuntu 16.04 with Oibaf PPA > ( https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers ) on an > Intel Core i7-6700K and layers.acceleration.force-enabled=true. > > Could you please fix this ASAP? > > If this bug makes it into Firefox 52, it will mean that it will make it into > an ESR, which would be very bad. Just enable e10s, that will fix it for you. In fact not enabling it is a waste of core i7 power and capabilities. Bug already made it into FF 52 I think, the late 53 Nightlies were the first versions I couldn't see it.
(In reply to K from comment #47) > Just enable e10s, that will fix it for you. Thank you, that fixed it indeed. Turns out I had some add-ons installed which auto-disabled e10s. Needed to force enable it as outlined on the Wiki: https://wiki.mozilla.org/Electrolysis#Force_Enable ;)
Bug affects even gif images.
Does anybody even work on this bug ?
(In reply to neumond from comment #49) > Bug affects even gif images. I doesn't (these are not gifs but videos). (In reply to Branko from comment #50) > Does anybody even work on this bug ? Try latest Nightly, I couldn't see the bug there. I haven't seen it in 52 as well by the way, not yet at least. Glorious Firefox devs have fixed it without even confirming it.
This bug has been fixed a long time ago.
Based on Comment 50 and Comment 52, will close this issue as Resolved - WFM. If anyone can still reproduce the issue, please provide the needed information.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.