W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Public feedback on HTML5 video

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 3 Jan 2010 14:26:26 +1100
Message-ID: <2c0e02831001021926s4bd68306o7253e5906feecc70@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Philip Jägenstedt <philipj@opera.com>, "Edward O'Connor" <hober0@gmail.com>, Jeremy Keith <jeremy@adactio.com>, HTMLwg <public-html@w3.org>
On Sun, Jan 3, 2010 at 1:46 PM, Maciej Stachowiak <mjs@apple.com> 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
undertaking.]

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".

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC