Re: [whatwg] Improving <video preload>?

As shown in [2], mobile browsers don't preload anything, which is OK 
because the network fee is usually high.
Loading 25 seconds is the behavior of desktop Chrome, and I don't see 
this as a big problem.

Static web pages probably don't have enough knowledge to determine how 
much data the UA should preload, because it depends on the network 
status and user's preference. So I think better solutions could be:

1) UAs allow user to specify how much data should be preloaded according 
to network status.
2) Add preloadData and preloadTime IDL properties to HTMLMediaElement to 
fine-tune the preload behavior, e.g.
        // preload at most 1000KB or 3 seconds, which comes first.
        video.preloadData = 1000;
        video.preloadTime = 3;
    In JS codes, authors are encouraged to set them after detecting the 
network status (e.g. 
https://developer.mozilla.org/en-US/docs/Web/API/Connection).

Regards,
   Duan Yao

在 2015/3/27 18:43, Mikko Rantalainen 写道:
> The <video> element currently supports only 3 possible values for 
> @preload attribute [1]. Real world user agent implementations agree on 
> keyword "none" only. Both "metadata" and "auto" have a pretty poor 
> interoperability, especially considering the amount of actual data 
> transferred if user never hits "play" [2].
>
> For example, current Chrome defaults to loading first 25 seconds of 
> video even with value "metadata". If one has high quality HD video as 
> the source, 25 seconds may be around 20 MB which is pretty much above 
> the size I would expect to contain only "metadata".
>
> Would it be possible to allow data sizes in @preload attribute in 
> addition to keywords?
>
> For example, <video preload="100KB"> would preload the first 100 KB of 
> video file if user never hits the "play". Granted, this puts some 
> additional burden on content authoring but it would allow having some 
> preloading instead of currently available "none" for many services. 
> Both "auto" and "metadata" load way too much to be usable in many user 
> agents.
>
> While streaming, the preload amount should be assumed to mean 
> additional buffering over the automatic buffering done by the UA. This 
> would allow scripts to add extra buffer margins e.g. if user has 
> previously experienced buffer underruns while viewing other videos on 
> the same site.
>
> It might even make sense to support @preload with a numeric value 
> without an unit as the count of kilobytes to preload. However, always 
> requiring the unit would allow extending @preload with e.g. <video 
> preload="5s"> in the future. I personally don't like specifying 
> preload amount as seconds because it requires first loading metadata 
> to compute the actual amount to preload. In addition, the preloaded 
> amount seldomly matches any second amount but actual available data 
> transfer bandwidth, video bitrate and audio bitrate needs to be 
> considered for skipless playback.
>
>
> [1] 
> https://html.spec.whatwg.org/multipage/embedded-content.html#attr-media-preload
>
> [2] http://www.stevesouders.com/blog/2013/04/12/html5-video-preload/
>

Received on Friday, 27 March 2015 12:21:54 UTC