[html5] Autoplay and preload insufficient for proper video playback.

[Kevin Carle]

On Wed, Aug 25, 2010 at 9:58 PM, Eric Carlson <eric.carlson at apple.com>wrote:

>
> On Aug 25, 2010, at 6:06 PM, 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.
> >
> > 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.
> >
> > I can also imagine scenarios where autoplay is set to "on" but the end
> user has low bandwidth, or scenarios where preload is set to "auto" but the
> end user clicks the play button too fast for the file to load. (yes, some of
> our end users are ninja's!)
> > We had the same issue with the experience of progressively downloaded
> media years ago, when I first started our early experiments with flash video
> (before every user had broadband), that was until we set the buffer
> attribute in flash, which fixed the whole issue.
> >
>   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.
>
>
Well, in some cases (like a dedicated video site) you can have additional
data on the user's bandwidth that the UA doesn't have. Historical playback
data, for example, that shows the user's last N playbacks and the achieved
bitrate.

At the very least it would be nice to be told how much had been loaded
before playback began (maybe as part of an event). I suppose polling
buffered would work, if buffered actually worked properly...

Theoretical scenario:

Listen for canplay -- this _should_ fire when just a couple frames are
ready, yes?
Poll buffered state until desired buffer amount
Call play()

I don't think this actually works today though, largely due to bad
implementations of buffered.

-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100826/00504f30/attachment-0003.htm>