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

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