- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 6 Jul 2015 13:17:28 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > In Gecko, <video preload="metadata"> doesn't fire "canplay". This is > allowed (encouraged, even) by the spec, since we can efficiently satisfy > preload="metadata" by stopping decoding after one frame, and if we only > decode one frame then readyState will not advance beyond HAVE_CURRENT_DATA. > However, this may be counterintuitive for Web developers. Also, Chrome > fires "canplay" in this situation (although that's probably part of the > "Chrome fires canplay and canplaythrough willy-nilly" bug). Anyone else > have an opinion on this? Are you having site compat problems related to this? Since Chrome's default preload 'auto', I wouldn't expect a whole lot of dependency on the precise amount of buffering for 'metadata', but would quite expect some sites to assume that by default one will HAVE_FUTURE_DATA so that the canplay event is fired. As for preload 'metadata' itself, it looks like in Chrome it's driven by the read requests that come out of the media framework, not so much an explicit policy to decode only one frame: https://code.google.com/p/chromium/codesearch#chromium/src/media/blink/buffered_resource_loader.h&l=35 I would be unsurprised if there are other issues hidden here, though, CC Andrew Scherkus who knows the Chromium-side code of this. Philip
Received on Monday, 6 July 2015 11:17:54 UTC