- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 14 Jul 2015 13:13:49 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Tue, Jul 14, 2015 at 1:08 PM, Robert O'Callahan <robert@ocallahan.org> wrote: > On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt <philipj@opera.com> > wrote: >> >> I see, is this a policy that's applied even with a single <video> in a >> page, or is it something like a limit on the total number of players >> that can be created, or limits on how much stuff (decoders) they set >> up internally? Presto actually had a limit on the number of players on >> 32-bit systems, as one might otherwise run out of virtual memory with >> just a few hundred <video> elements... > > > There are various kinds of resource limits. The problem with those is that > they're fragile and make behavior unpredictable. Yeah, this is tricky, obviously no browser could successfully load a million <video> elements up to readyState HAVE_ENOUGH_DATA simultaneously, but making that fail in the same way cross-browser seems like a big task. If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload="auto", to rule out artificial limits if any browser has them. Philip
Received on Tuesday, 14 July 2015 11:14:20 UTC