[html5] Autoplay and preload insufficient for proper video playback

[Ian Hickson]

On Thu, 26 Aug 2010, Herman Hassel wrote:
>  On 24.08.2010 01:17, Ian Hickson wrote:
> > On Wed, 30 Jun 2010, Herman Hassel wrote:
> > >
> > > I keep finding the media attributes "preload" and "autoplay" 
> > > insufficient for video playback.
> >
> > Before considering proposed alternatives, could you elaborate on how 
> > "preload" is insufficient? (It's impossible for me to evaluate how the 
> > proposed alternatives are better without knowing how the existing 
> > solutions are bad!)
>
> Sure! At the moment I need to set preload to "none" or "metadata". Often 
> we do use more than one video or audio element on the same page, and we 
> do want the initial load of each page to be as low as possible. We do 
> have some visitors with low bandwidth, or people who use their phones 
> and are charged by their ISP by the MB. If we had only high bandwidth 
> users and few elements on a page, we'd just use auto. We don't limit our 
> media files to ranges or anything like that, we just want our users to 
> have the best possible experience viewing the videos provided on the 
> websites we make.

In theory, the browsers of your users with low bandwidth, when faced with 
preload=auto, should not preload. But it's early days yet and it isn't 
surprising that they don't yet discriminate.


> Whenever an end user starts a video or audio element that hasn't been 
> preloaded, and the end user doesn't have good enough bandwidth to match 
> the progressive download of the video file, we tend to get very 
> stuttered and broken video for the first seconds, until either the speed 
> of the stream picks up or the end users pause the playback themselves 
> and wait for it to buffer up a bit. Now with audio this isn't such a big 
> issue since the KB/s rate of audio files is so much smaller, but it's 
> very noticeable with video.

You can work around this with a custom interface that uses the 
oncanplaythrough event handler to decide when to start playing, and 
buffers until then.


> It's in the few starting seconds of cases like this that the end user 
> experience would be enhanced by us having a buffer attribute in our 
> toolbox. We need to make sure a few seconds of a media file always gets 
> loaded before any actual playback begins. The buffer attribute wouldn't 
> break anything already in place, it would only enhance the attributes 
> already existing. :)

The browser should be doing this for you anyway when it's showing its own 
controls; when you have your own controls, the API already provides you 
with the tools to do this.


On Thu, 26 Aug 2010, Herman Hassel wrote:
> On 26.08.2010 06:58, Eric Carlson wrote:
> > A static attribute that specifies a minimum buffer size or duration 
> > will only help users with exactly the bandwidth the for the attribute 
> > value - anyone with less bandwidth will still run out of data, and 
> > anyone with more bandwidth will have to wait longer than necessary.
>
> Yes, but this also depends on how a developer would use the buffer 
> attribute, for our use we wouldn't set it too high. (3-5 seconds or so 
> is what we would favor at this time). A low bandwidth user would run out 
> of data, but he would get at least 5 seconds of video before this would 
> happen. From my experience with how users interact with video an end 
> user will notice the loaded bar not moving as fast as the scrubber, but 
> at least we've given him a teaser of the full content before he needs to 
> wait. For a user with exact or higher bandwidth, the 3-5 second buffer 
> loads fast enough to not break the experience. :)

If you're writing your own controller, you already have the data available 
to know when five seconds have been buffered, so you can already do this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'