[whatwg] More YouTube response

[Marques Johansson]

If the seek method was further hookable it should be possible to add decrypt
or  transcode methods to interpret the fetched content, possibly requesting
more data to the filter stream bucket, before apending the bytes of media.

On Jul 2, 2010 6:10 AM, "Marques Johansson" <marques at displague.com> wrote:

On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> 2. Robust Video Streamin...
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/df4ae321/attachment-0002.htm>