Last Comment Bug 774901 - Lots of video elements on a page will eventually prevent videos from loading
: Lots of video elements on a page will eventually prevent videos from loading
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla17
Assigned To: Matthew Gregan [:kinetik]
:
:
Mentors:
http://robothaus.org/mozilla/bugs/too...
Depends on:
Blocks: 766712 1192708
  Show dependency treegraph
 
Reported: 2012-07-17 15:10 PDT by Bobby Richter [:secretrobotron]
Modified: 2015-08-09 23:47 PDT (History)
6 users (show)
kinetik: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch v0 (944 bytes, patch)
2012-07-24 22:58 PDT, Matthew Gregan [:kinetik]
roc: review+
Details | Diff | Splinter Review

Description Bobby Richter [:secretrobotron] 2012-07-17 15:10:24 PDT
http://robothaus.org/mozilla/bugs/too-much-video/

The above link will show a page with 150 videos with unique urls. On my OSX machine, it appears to load about 200 of the videos and then stop completely. So, opening more than one tab will attempt to load 300 videos.

Closing the first tab (with 150 properly loaded videos) will *eventually* let the second tab load, but only after something like gc runs (hard to tell exactly what happens).

On Firefox 14, this is a lot more evident, because it will completely disallow new connections to the server, regardless of the file requested. In Nightly, this problem appears to eventually clear up.
Comment 1 cajbir (:cajbir) 2012-07-17 17:08:26 PDT
There's a hard limit on the number of active decoding threads that can be going at any time. This is currently set to 25. See bug 691096 for why this limit was added.
Comment 2 Matthew Gregan [:kinetik] 2012-07-17 22:57:02 PDT
I was chatting to Bobby about this bug, so I'll grab it.  We discussed the decode thread limit; what seems to be going on is that elements that should've released their decode thread after decoding and going idle don't seem to be doing so after completing (pre-)load.  This only starts to happen after 100-150 have loaded--the number depends on how fast they load.
Comment 3 Matthew Gregan [:kinetik] 2012-07-18 12:25:24 PDT
(In reply to Bobby Richter [:bobby] from comment #0)
> The above link will show a page with 150 videos with unique urls.

Unrelated to the rest of this bug, but the URIs aren't guaranteed to be unique because Date.now()'s resolution is 1ms, and it's possible to create multiple elements in less than a millisecond--for instance, in my (slow) debug build I'm seeing 20-30 elements end up with the same URI.
Comment 4 Bobby Richter [:secretrobotron] 2012-07-18 15:22:39 PDT
(In reply to Matthew Gregan [:kinetik] from comment #3)
> Unrelated to the rest of this bug, but the URIs aren't guaranteed to be
> unique because Date.now()'s resolution is 1ms, and it's possible to create
> multiple elements in less than a millisecond--for instance, in my (slow)
> debug build I'm seeing 20-30 elements end up with the same URI.

Good catch. I've fixed it up here: http://robothaus.org/mozilla/bugs/too-much-video/index2.html
Comment 5 Matthew Gregan [:kinetik] 2012-07-24 22:51:16 PDT
As the testcase pages load, the media loads are being suspended by the element (from FirstFrameLoaded) and by the media cache (for throttling, as the cache runs out of space).  Normally, a load suspended by both the element and the cache would need to be resumed the same way (i.e. via calls to Resume() from the element and cache), but if the cache resumes a load via CacheClientSeek (e.g. due to resuming at a different offset due to evicted blocks), it will recreate the channel even when mSuspendCount > 0, which results in the channel being suspended from its OnStartRequest if mSuspendCount is still > 0.

Once enough of these loads are resurrected by the cache, the per-server HTTP connection limit is reached and no further loads from that server will ever complete.

I think the right thing to do is to avoid recreating the channel in CacheClientSeek if mSuspendCount > 0, and set the MediaResource up so that a subsequent resume will recreate the channel as necessary.
Comment 6 Matthew Gregan [:kinetik] 2012-07-24 22:58:20 PDT
Created attachment 645656 [details] [diff] [review]
patch v0

This patch allows me to open 10 copies of the testcase (1000 elements) and have no pending HTTP connections after each tab's load event has fired.  I could create more, but each new tab takes longer to load due to scalability issues in the media cache's block management code when dealing with thousands of elements.

Mochitests pass locally, let's see how it goes on Try: https://tbpl.mozilla.org/?tree=Try&rev=c12fbcfeb529
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-07-25 14:25:03 PDT
Comment on attachment 645656 [details] [diff] [review]
patch v0

Review of attachment 645656 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch!
Comment 8 Matthew Gregan [:kinetik] 2012-07-25 17:12:32 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/f887e55f0594
Comment 9 Ed Morley [:emorley] 2012-07-26 05:08:47 PDT
https://hg.mozilla.org/mozilla-central/rev/f887e55f0594

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