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

[Robert O'Callahan]

On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com
wrote:

 On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
 rob...@ocallahan.org wrote:
  On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@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.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

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

[Philip Jägenstedt]

On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
 On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@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