Re: Public feedback on HTML5 video

On Wed, Dec 30, 2009 at 8:42 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 30 Dec 2009 03:57:33 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Wed, Dec 30, 2009 at 1:35 AM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>>
>>> On Tue, 29 Dec 2009 15:21:43 +0100, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>
>>>> On Wed, Dec 30, 2009 at 1:13 AM, Philip Jägenstedt <philipj@opera.com>
>>>> wrote:
>>>>>
>>>>> On Tue, 29 Dec 2009 14:26:44 +0100, Silvia Pfeiffer
>>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>>
>>>>>> On Tue, Dec 29, 2009 at 6:52 PM, Philip Jägenstedt <philipj@opera.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, 29 Dec 2009 00:44:50 +0100, Edward O'Connor
>>>>>>> <hober0@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>> Is the absence of the autobuffer attribute an explicit request not
>>>>>>>>> to
>>>>>>>>> pre-buffer?
>>>>>>>>
>>>>>>>> I'd rather it not be.
>>>>>>>>
>>>>>>>> I think it's important for the author to be able to say "hi browser,
>>>>>>>> please do whatever is most appropriate given your platform / network
>>>>>>>> connection / memory / etc., insofar as buffering is concerned." In
>>>>>>>> fact,
>>>>>>>> I suspect this to be the most common authoring case. Most authors
>>>>>>>> would
>>>>>>>> prefer it if, say, cell phone browsers defaulted to
>>>>>>>> no-autobuffering,
>>>>>>>> whereas they might prefer desktop browsers to behave differently.
>>>>>>>> Given
>>>>>>>> that, I'd prefer the default/lazy authoring behavior (not specifying
>>>>>>>> the
>>>>>>>> attribute at all) to have this meaning.
>>>>>>>>
>>>>>>>> Essentially, we have three things we'd like authors to be able to
>>>>>>>> convey
>>>>>>>> to the browser:
>>>>>>>>
>>>>>>>>  1. Do whatever the browser thinks best.
>>>>>>>>
>>>>>>>>  2. Please autobuffer.
>>>>>>>>
>>>>>>>>  3. Please *don't* autobuffer.
>>>>>>>>
>>>>>>>> And there are a few things we'd like to be able to say about
>>>>>>>> whatever
>>>>>>>> design we settle on:
>>>>>>>>
>>>>>>>>  A. (1) above should be the default condition, so its syntax should
>>>>>>>> be
>>>>>>>>  what most authors will do anyway (not provide attributes at all).
>>>>>>>>
>>>>>>>>  B. Any new boolean attributes should behave like the other boolean
>>>>>>>>  attributes already present in HTML (presence means t and absense
>>>>>>>>  means nil).
>>>>>>>>
>>>>>>>>  C. If at all possible, we should be able to use different values
>>>>>>>> for
>>>>>>>>  the same attribute for (2) and (3). (Minting separate attributes
>>>>>>>>  for (2) and (3) means allowing authors to write nonsensical markup,
>>>>>>>>  and having to spec what HTML5 processors should do when they're
>>>>>>>>  both present. What does <video buffer nobuffer> mean?)
>>>>>>>>
>>>>>>>> There's a lot of tension between (B) and (C), so much so that I
>>>>>>>> think
>>>>>>>> autobuffer="" should probably become an enumerated attribute[1]
>>>>>>>> instead
>>>>>>>> of a boolean attribute. Something like the following:
>>>>>>>>
>>>>>>>>  1. Do whatever the browser thinks best. [no autobuffer attribute]
>>>>>>>>
>>>>>>>>  2. Please autobuffer. [autobuffer="on"]
>>>>>>>>
>>>>>>>>  3. Please *don't* autobuffer. [autobuffer="off"]
>>>>>>>>
>>>>>>>>
>>>>>>>> Ted
>>>>>>>>
>>>>>>>> 1.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#keywords-and-enumerated-attributes
>>>>>>>>
>>>>>>>
>>>>>>> I do not support making this distinction, because as an implementor I
>>>>>>> cannot
>>>>>>> act any differently in case 1 and 3. Any browser that has gone to the
>>>>>>> effort
>>>>>>> of being conservative with network resources will want that behavior
>>>>>>> even
>>>>>>> if
>>>>>>> autobuffer="off" is given. Unless there is some browser vendor who
>>>>>>> can
>>>>>>> see
>>>>>>> themselves acting differently in case 1 and 3, this just adds a bit
>>>>>>> of
>>>>>>> complexity and the illusion of control on part of the author where
>>>>>>> there
>>>>>>> is
>>>>>>> in fact none.
>>>>>>
>>>>>> I believe as a desktop browser on a web page with only one video in a
>>>>>> prominent location ("above the fold"), I would decide to autobuffer.
>>>>>> The same web page on a mobile phone browser, I would not decide to
>>>>>> autobuffer.
>>>>>>
>>>>>> With more than one video on a page, I would probably autobuffer
>>>>>> nothing.
>>>>>>
>>>>>> This is a minor distinction though. Maybe you are right and there is
>>>>>> never a need to autobuffer unless the autobuffer attribute is given.
>>>>>> In this case, though, we should change the specification and make it
>>>>>> clear that when autobuffer is given, it will autobuffer and when
>>>>>> autobuffer is *not* given it will *not* autobuffer (unless autoplay is
>>>>>> given).
>>>>>>
>>>>>> There are in fact two problems with the current specification:
>>>>>>
>>>>>> 1. it doesn't allow specification by the page author to *not*
>>>>>> autobuffer - all the page author (and user) can *hope* for is that by
>>>>>> not specifying the attribute, the user agent will not buffer.
>>>>>
>>>>> It just seems to me that any sane browser would conserve bandwidth if
>>>>> it
>>>>> knows how to, allowing the author to ask for that is a little bit like
>>>>> <script slowdown="no">.
>>>>
>>>> I would say that John Gruber's discovery has contradicted this
>>>> statement.
>>>
>>> Isn't it just that most browsers (all except Firefox?) are ignoring the
>>> autobuffer attribute? It seems that the solution is to implement
>>> conservative network usage and to let the autobuffer attribute disable
>>> this
>>> behavior. In my opinion, the difficult part is actually being
>>> conservative
>>> to begin with and I don't know if there's any point in introducing shades
>>> of
>>> conservative.
>>
>> So are you saying that most browsers have not implemented support of
>> the autobuffer attribute yet and that is the real problem? If so, then
>> it makes sense to have three states: when autobuffer is implemented
>> and supported, "on" and "off" needs to be provided, which means "my
>> browser has control over its buffering behaviour and I can give that
>> control into the hands of the web developer". And if I do not
>> implement autobuffer support, then what the video element does is
>> random - depending on what is more convenient for my browser to do,
>> i.e. the current state of when autobuffer is not in use.
>
> Yes, the real problem is that it is much more difficult to be conservative
> with network resources than to just download the whole resource and it seems
> most browsers aren't done with their implementation. I expect that there are
> only two states however: trying being conservative and not.

That is actually only one dimension. The other is the likelihood of
playback, which is one that only the web page author knows.
But it seems that we agree and the Web browser should always be
conservative, which basically means no autobuffering.
That can only be overruled by a web page author who knows that it will
be highly likely that a video will be played back (i.e. "autobuffer),
highly unlikely that a video will be played back (i.e. no autobuffer),
or no opinion (in which case we get back to conservatism).


>> Or are you saying that really every browser should implement
>> autobuffer support and then the lack of an autobuffer attribute
>> signifies that it doesn't do autobuffering? In this case, we need to
>> rewrite what the lack of @autobuffer means: no autobuffering.
>
> I wouldn't really oppose making this explicit in the spec. However, I'm not
> sure how to make meaningful conformance requirements for "no autobuffering"
> as anything but downloading the whole resource should qualify. Not wasting
> network resources is just common sense, mandating it in the spec is really
> like asking browsers to execute scripts and decode images as fast as they
> can. However, if people are genuinely confused by the spec then I'm all for
> clarifying it.
>
>> Shades of conservative is what we currently have: every browser can do
>> what they like when no autobuffer is present. Firefox is more
>> conservative than Safari. Instead, we need to clarify what is to be
>> expected by a user.
>
> What I mean is that no browser has shades of conservative, where they
> sometimes try a little bit harder to not waste bandwidth. Such an
> implementation is possible, but hypothetical at this point.
>
>>>> Also, if we really are asking for no autobuffering when the attribute
>>>> is not present, then this has to be stated in the HTML5 standard. So,
>>>> either we introduce a autobuffer=yes/no option or we prescribe that
>>>> when autobuffer is not present it means no autobuffering. Either
>>>> requires a change to the spec.
>>>
>>> We could add a non-normative note to implementors that it's nice if they
>>> don't waste bandwidth, even though I'm sure all implementors are already
>>> very aware of this.
>>
>> Obviously not. Neither Safari nor Chrome implement conservative
>> bandwidth behaviour - that's two out of three browsers that have
>> decided (at least for now) to waste bandwidth. After this discussion,
>> I'm sure they will all change it. But what about others who implement
>> the text of the standard? They are not required or even requested to
>> behave well. It does indeed need at minimum a recommendation, if not a
>> requirement in the spec to make the browsers aware that they should
>> behave conservative with bandwidth on video.
>
> I don't believe that the reason browser are currently wasting bandwidth is
> because it never struck them, rather it's because it's actually quite
> difficult to implement conservative behavior and they haven't gotten to
> doing that yet. But enough speculation, I'm fine with any changes to the
> spec in this regard as long as they are either non-normative or have
> testable conformance requirements.
>
>> I actually think that if it's not a required feature, ppl will avoid
>> it since there are so many other features to implement. Our question
>> here is: is this a feature that is absolutely necessary to make the
>> video element usable or not. I believe that the discussions that have
>> been stirred up through John Gruber's blog post show that it is a
>> required feature - he clearly states it is "unusable" otherwise, and
>> others have agreed.
>
> I agree that it's not production-ready if browser aren't conservative with
> bandwidth. If a spec change can put pressure on browser vendors to fix this,
> sure. What concrete spec change though?

Well, there are two options: either we introduce a three-state option
on autobuffer or we make sure to describe that lack of an autobuffer
attribute means no autobuffering is done (and only the absolute
minimum is downloaded to initialise the video element, preferably
nothing. If no pre-buffering is done, all initialising of the video
decoding pipeline is done only upon a play() event).

I personally have no issues in keeping the current option for browsers
to do what they find easiest when no autobuffer attribute is
specified. I.e. I'd actually support the three-state solution. When a
browser supports the autobuffer attribute, they have to support "on"
and "off" values, which then make the wishes of the web page author
explicit. If nothing is specified, a browser is free to choose
whatever they like. BTW: I also don't think it's not much of an issue
with already rolled out code, since it seems that only Firefox is
properly supporting @autobuffer anyway.

So, basically:

1. nothing specified - the browser does whatever it thinks is best,
the web page author doesn't care; maybe the best action in this
situation is to initialise the video element, but stop downloading
after the headers have been read and the decoding pipeline set up.
This could be a recommendation, but not a requirement.

2. @autobuffer="on" (or "true" or "yes" or whatever) - the web page
author cares and believes this element has a high likelihood of being
played, so it makes sense for the browser to autobuffer, and thus the
browser autobuffers

3. @autobuffer="off" - the web page author cares and believes it would
be a nuisance to the user to autobuffer this video and waste
bandwidth, so the browser doesn't autobuffer - it this case, it may
even make sense to not even try and initialise the decoding pipeline,
but only display the poster frame, if possible (maybe the
X-Content-Duration can help to display the video duration and that's
all that's required?). I'm specifically thinking here about a Web page
that has dozens of videos on it (e.g. as search results or for
browsing a collection). It might not make sense to pre-buffer anything
at all in such a case where playback is highly unlikely.

Then, of course, we have browser preference settings, which may turn
any video element into one that does not autobuffer, or one that
always autobuffers. And mobile phones may decide to behave differently
again. But at minimum it was then possible to fully describe the
intentions of the web page author.

Cheers,
Silvia.

Received on Wednesday, 30 December 2009 13:34:42 UTC