<p>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.</p>

<p><blockquote type="cite">On Jul 2, 2010 6:10 AM, "Marques Johansson" <<a href="mailto:marques@displague.com">marques@displague.com</a>> wrote:<br><br><p><font color="#500050">On Thu, Jul 1, 2010 at 6:59 PM, John Harding <<a href="mailto:jharding@google.com">jharding@google.com</a>> wrote:<br>
> 2. Robust Video Streamin...</font></p>I was muddling my recent requests related to "browser fetch" behavior<br>
and "application-controlled video delivery: with the despised topic of<br>
DRM and content protection.  Thanks for clearing that up, John.<br>
<br>
If a seek on a HTMLMediaElement's exposed and passed along the XHR<br>
Request to a fetcher method then I could set my constraints for the<br>
impending request.  I would add HTTP Range headers if they are not<br>
present and set a Range upper bound (since the server will return<br>
402,403, or 416 on any "Range: bytes x-" request to retrieve the full<br>
remaining content).<br>
<br>
The initiating caller would need to understand that the length of data<br>
requested may have shrunk (which would require the browser to seek<br>
again when the content was all played up or when the buffer was<br>
running low - things that should already be in place).  This, to me,<br>
seems like an alternative to an addBytes method (if that does what I<br>
think it does).<br>
<br>
This would provide me with a strictly Javascript solution.  Other<br>
methods I have been asking for would give me a purely HTTP solution<br>
(with new range related 4xxs and, spec endorsed, shorter than<br>
requested 206 responses) to achieve this or an HTML solution (using<br>
new video+source element attributes for buffer (min request size) and<br>
max request size).<br>
</blockquote></p>