- From: Marques Johansson <marques@displague.com>
- Date: Fri, 2 Jul 2010 06:40:09 -0400
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.htm>
Received on Friday, 2 July 2010 03:40:09 UTC