- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 15 Jul 2015 15:59:57 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt <philipj@opera.com> > wrote: >> >> Basically a "I trust the browser to decide and promise not to assume >> anything state"? The "auto" state is already suitable named and >> defined for that, so if implementing "auto" as anything other than >> "try to reach HAVE_ENOUGH_DATA" is in fact web compatible, a new state >> for that might make sense. >> >> Practically speaking, though, what would be the policy for "auto" that >> differs between platforms, in the case of a single video element in a >> page? > > > Our current policy, which is basically HAVE_ENOUGH_DATA on desktop and > HAVE_METADATA on mobile. Does this mean that you don't decode the first frame on mobile? Do all formats really have reliable data about the video size without attempting to decode a frame? >> If the different policies could be made explicit, it might be >> nice to have explicit preload states for them and a way for scripts to >> know the effective preload state. > > > Maybe that's overengineering. > > I propose we leave 'auto' as-is for now until we have more data, and first > do the other work I mentioned. > > Then a possible next step would be to determine how much preloading > preload="auto" must do for Web compatibility (i.e., which readyState it must > reach), and define preload="auto" to have that as the goal readyState, *but* > we could also say that it preloads as much data as possible given > browser-specific policy (while not actually advancing the readyState beyond > the goal readyState until the autoplaying flag is false). OK, I take it the most important bit for you is in the title of this thread: preload="metadata" elements don't necessarily fire "canplay". I'd be quite happy to see preload="metadata" spec'd with a requirement to never go beyond readyState HAVE_CURRENT_DATA, except when the effective preload state is changed by the autoplay attribute, play() or setting currentTime. Spec'ing that concept of effective preload would also be great, I assume it's been implemented in multiple engines. I've added some telemetry to Blink to see how common an explicit preload="metadata" is compared to no explicit preload, to get some kind of idea about the risk. Next steps? Philip
Received on Wednesday, 15 July 2015 14:00:32 UTC