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

[Bug 8731] New: Consider expanding buffering control for media elements

From: <bugzilla@wiggum.w3.org>
Date: Wed, 13 Jan 2010 07:35:06 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-8731-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8731

           Summary: Consider expanding buffering control for media elements
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: mjs@apple.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


Currently, the <audio> and <video> elements allow some limited hints of the
authors intent on preloading the resource via the "autobuffer" attribute. The
presence of the autobuffer attribute hints that the video is very likely to be
played and the UA should consider buffering aggressively. Absence of the
autobuffer attribute indicates either a hint *not* to buffer aggressively, or
no hint at all. Per discussion on public-html, there are plausible use cases
not addressed by this setup:

1) It seems valuable to distinguish no hint from explicit hint not to buffer,
so that browsers can apply heuristics in the prior case without interfering
with explicit author intent.

2) In some cases (very many videos with separate thumbnails provided via poster
attirbute), it may be beneficial to request no preloading whatsoever, not even
the metadata needed to get size and duration.

3) It may be useful to distinguish a hint to buffer truly as much as possible,
from buffering just enough that playthrough is likely to succeed without
further blocking.

Of the proposals made on the list, it seems the most thorough and best liked
is:

* preload attribute with the following values:
  * preload=none - request to preload nothing, not even metadata
  * preload=metadata - request to preload only enough to get to the
HAVE_METADATA state, and then stop
  * preload=all (or preload=full?) - request to buffer as much as possible -
same as current autobuffer attribute
  * preload=playthrough - preload metadata plus however much of the media item
seems enough to play through

Not all agree that the fourth value is worthwhile.

Other proposals involved a similar attribute named "buffering", with possibly
fewer values, but on reflection playthrough seems like a better name.

Still other proposals suggested changing "autobuffer" to not be a strictly
boolean attribute, such that "autobuffer=off" would reverse the meaning, but
that seems to add unnecessary compatibility issues and is not particularly
elegant syntax.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 13 January 2010 07:35:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC