W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

Re: [whatwg] preload="metadata" elements don't necessarily fire "canplay"

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 16 Jul 2015 14:32:39 +1200
Message-ID: <CAOp6jLZtVSjNQxtF_8k=f3o2Pf-VEXYF3_6nXxZqi8iua1uB0A@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt <philipj@opera.com>

> 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.

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.

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
Received on Thursday, 16 July 2015 02:33:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 July 2015 02:33:11 UTC