Last modified: 2012-12-17 14:49:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43909, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41909 - Playing a large Theora file causes Firefox to lock up with 100% CPU
Playing a large Theora file causes Firefox to lock up with 100% CPU
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
TimedMediaHandler (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Michael Dale
http://commons.wikimedia.org/wiki/Fil...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-09 04:29 UTC by Tim Starling
Modified: 2012-12-17 14:49 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Tim Starling 2012-11-09 04:29:20 UTC
Today, a 26MB video file was featured on the English Wikipedia main page, see URL field above. Clicking the "play" button in Firefox causes the browser to become unresponsive, using 100% of one core. The browser does respond to clicks after a delay of 10s or so, but never appears to repaint. Closing the tab is possible and causes the CPU usage to stop.

Observed with the current version of Firefox on Ubuntu 12.04, with a default profile and in safe mode.

Playing the same file using Firefox's video capabilities but without TMH involved does work. Once the file is loaded into the browser's cache, the bug stops happening and the video will play correctly. The bug can be reproduced again by clearing the cache with the "clear your recent history" feature.

I tried enabling EmbedPlayer.NativeControls but it didn't help.
Comment 1 Michael Dale 2012-11-09 06:05:16 UTC
Played without issue on first load, no cache mode & cleared cache. ( Ubuntu 12.04, Firefox 15.0.1, pulse audio )

What version of Firefox are you using and what audio back-end ? 

Does it do it for webm files: 
http://commons.wikimedia.org/wiki/File:2012-07-18_Market_Street_-_San_Francisco.webm

Does it do it when you disable javacript ( and just play the asset inline ) ?
Comment 2 Tim Starling 2012-11-09 06:30:45 UTC
(In reply to comment #1)
> Played without issue on first load, no cache mode & cleared cache. ( Ubuntu
> 12.04, Firefox 15.0.1, pulse audio )
> 
> What version of Firefox are you using and what audio back-end ? 

$ dpkg-query -W firefox
firefox	16.0.2+build1-0ubuntu0.12.04.1

PulseAudio is installed, but the file has no sound and pavucontrol shows no open streams while it is playing.

> Does it do it for webm files: 
> http://commons.wikimedia.org/wiki/File:2012-07-18_Market_Street_-_San_Francisco.webm

No.

> Does it do it when you disable javacript ( and just play the asset inline ) ?

Yes. With JavaScript disabled, the video has no controls, but there is a "play" item in the context menu. Clicking it causes the issue, and it even persists after the tab is closed. After closing the tab, it takes about 45 seconds for the browser to become responsive again.

If I play the video by navigating directly to 

<http://upload.wikimedia.org/wikipedia/commons/d/d0/Webcam_CT_transmissions.OGG>

it works, so I guess it just affects <video>.
Comment 3 Andre Klapper 2012-11-09 10:00:10 UTC
Fedora 16, Firefox 16.0.2:
URL  "about:memory"  shows that allocated memory slowly increases, but I don't see any such lag. Memory is freed again after video has finished playing.
Comment 4 Jan Gerber 2012-11-09 13:35:44 UTC
from http://news.ycombinator.com/item?id=4762181 it looks like this is a Firefox bug that was fixed and might be backported to 16
Comment 5 Michael Dale 2012-11-09 14:28:24 UTC
On the bright side by default we prefer WebM so once all the transcoding is completed the error should be less common ( unless you select the ogg source )

Jan do we have a bug for prioritizing a particular file transcode?  We should be able to do that for blog posts, fundraiser, featured videos etc. This way prominent videos have all their derivatives. This may be less-necessary once the backlog is proccessed. But still useful for say; if we enable h.264 and want to do a blog post showing the video working on iPhones.
Comment 6 Jan Gerber 2012-12-17 14:49:26 UTC
Firefox 17 is the stable version now and fixes this issue, in addition we have webm transcodes now. closing this bug.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links