W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] More YouTube response

From: Marques Johansson <marques@displague.com>
Date: Fri, 2 Jul 2010 06:10:43 -0400
Message-ID: <AANLkTikmbiM2Vjx2HbhU893BIXOVdb2eG5EJ8LJIB9js@mail.gmail.com>
On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> 2. Robust Video Streaming
> Andy Berkheimer on our team has been putting some thought into this, so I'll
> defer to him for more specific proposals. ?For an app like YouTube, it is
> extremely useful to have fine-grained control over how the browser fetches
> media from the server. ?Whether the details belong in the HTML5 spec or not
> depends on the preferred design - something similar to Flash 10.1's
> appendBytes() mechanism would affect the <video> tag interface, for example,
> while a transport protocol could be completely separate.
> 3. Content Protection
> Some of the discussion here seems to have conflated application-controlled
> video delivery with content protection, but in an ideal world, the two are
> independent. ?The basic requirements around content protection that we get

I was muddling my recent requests related to "browser fetch" behavior
and "application-controlled video delivery: with the despised topic of
DRM and content protection.  Thanks for clearing that up, John.

If a seek on a HTMLMediaElement's exposed and passed along the XHR
Request to a fetcher method then I could set my constraints for the
impending request.  I would add HTTP Range headers if they are not
present and set a Range upper bound (since the server will return
402,403, or 416 on any "Range: bytes x-" request to retrieve the full
remaining content).

The initiating caller would need to understand that the length of data
requested may have shrunk (which would require the browser to seek
again when the content was all played up or when the buffer was
running low - things that should already be in place).  This, to me,
seems like an alternative to an addBytes method (if that does what I
think it does).

This would provide me with a strictly Javascript solution.  Other
methods I have been asking for would give me a purely HTTP solution
(with new range related 4xxs and, spec endorsed, shorter than
requested 206 responses) to achieve this or an HTML solution (using
new video+source element attributes for buffer (min request size) and
max request size).
Received on Friday, 2 July 2010 03:10:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC