Re: Public feedback on HTML5 video

On Sun, Jan 3, 2010 at 1:46 PM, Maciej Stachowiak <> wrote:
> On Dec 31, 2009, at 3:15 AM, Silvia Pfeiffer wrote:
>> I believe so. Every web page that has more than maybe 3 videos
>> "embedded" - and that is video search results pages, video archive
>> listings and similar things - will need to stop their videos from
>> taking up unwanted bandwidth. This is a really common use - and also
>> one that John Gruber's blog post mentioned.
> How much network traffic does it take to grab enough of the video to get
> dimensions, duration, and possibly the first frame (if there's no separate
> poster frame)? If it's similar to or less than the cost of loading an image,
> than doing it 3 or even 50 times for a single page load does not seem so
> bad. After all, you need to load that number of images anyway to show any
> form of thumbnail whatsoever

It's probably on a similar scale to loading images - maybe a little
more. Since the poster frame will always be loaded, it would roughly
double or triple the amount of data loaded on a busy video page. I
guess for a normal desktop browser, it shouldn't be so bad. It'd be
more of an issue for mobile browsers - but they may decide to never
autobuffer anyway.

I guess it brings another dimension into buffering, that could be
relevant to be expressed by the page author:

* the page author could have four choices - don't care, buffer
nothing, buffer bare essentials, buffer full resource.

* the browser has three choices to react to these suggestions - buffer
nothing, buffer bare essentials, buffer full resource (the decision
being influenced by the suggestion of the page author and other
information it has available at the time).

* further, the user could have four choices (to be expressed in
browser preferences) - let browser decide, never autobuffer anything,
always autobuffer bare essentials, always autobuffer full resource.
[And if we wanted to bring in accessibility here, it could even be:
autobuffer only video track or autobuffer only audio track - but that
is taking it a bit too far at the moment, since these require
splitting the resource into tracks which is generally not a simple

OTOH, we could wait with this feature for a future HTML6 or something,
when we will have more experience with how often Web authors had to
create javascript to avoid the pre-buffering activity of the browsers.
I obviously don't currently have any stats to support the need for
expressing "don't buffering anything".


Received on Sunday, 3 January 2010 03:27:18 UTC