- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 16 Jul 2015 10:44:36 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Thu, Jul 16, 2015 at 4:32 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt <philipj@opera.com> > wrote: > >> 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? >> > > We do enough work to make sure that the video size is available. If that > requires decoding the first frame, we do that. Makes sense :) > 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? >> > > When I started this thread I didn't realize there was no specced way to > preload to a HAVE_ENOUGH_DATA, and I think that's just as important as the > Web compatibility questions around preload="metadata" --- after all, if we > spec preload="metadata" to limit to HAVE_CURRENT_DATA, we should also offer > an official way to preload beyond HAVE_CURRENT_DATA. So I'm enthusiastic > about doing all of the changes I suggested. OK, so perhaps file two bugs for each of those things and continue discussion there? Philip
Received on Thursday, 16 July 2015 08:45:18 UTC