[whatwg] More YouTube response

On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson
<marques at displague.com> wrote:
> The benefit to the user is that they could have less open network
> connections while streaming video from server controlled sites and those
> sites will have the ability to meter their usage more accurately.
> Inserting an extra clip at the end is more of a playlist or scripting
> answer. ?Or perhaps a a live re-encoding answer. ? I'm looking for a way to
> give the user the raw video file in a metered way.

It sounds like your use-case is very special, and best handled by
script.  I suggested server-side script -- you could do that today.
Just cut off the HTTP connection when the user has used up their
allotted time.  Alternatively, it might be reasonable to have
client-side scripting for video that's flexible enough to do what you
want.  But a dedicated declarative feature is just not reasonable for
such a specific purpose.

>?A 200 response or
> partial 206 responses that returns less than the full requested range is not
> handled by browsers in a consistent or usable way (for this purpose). ?Only
> Chrome will continue to fetch where the previous short 206 response left off
> (request 1-10, server replies 1-5, request 6-10, server replies 6-10). ?The
> HTTP spec isn't clear about whether UAs should take this behavior - and so
> they don't.
> Some UAs request video without sending "Range: bytes 0-". ?The server has no
> way to negotiate that the UA (a) must use ranges to complete the request or
> that (b) the range requested is too large, retry will a smaller range.

You don't need to return less than the browser requests, until it
actually uses up the bandwidth the user has paid for.  Let the browser
fetch as much of the video as the user wants to view, using
preload=metadata when that's supported by all browsers.  Every time
the server sends a new chunk of video to the user, it should deduct
that much from the user's current balance.  When the user has received
as much video as he's paid for, just have the script exit without
sending more output.

You don't have to return a proper Range header and expect the browser
to issue new requests.  Just pretend you're serving the whole
resource, then cut it off unexpectedly before you've actually returned
all the content.  The browser will handle this fine, it will just
treat it as a network error.  A client-side script can then detect the
error and present nice UI.

> All of the current video clients make requests like "Range: 0-" or (when you
> seek) "Range: 0-end_of_file". ?I don't want to give them the whole 2gb file
> right now, they may seek to the end of the video at any moment while the
> server is paying to send that data and the transfer will have been wasted.
> ?I don't want to throttle the connection because that is also a waste of
> resources. ?I want the UA to request X many bytes (which equates to some
> fragment of time), disconnect if they will be busy beyond the keep-alive
> time, and come back when they need more video data. ?A 200 response and an
> unbounded 206 response do not permit this.

This part is handled by the preload attribute already.  You just have
to wait for browsers to actually support it.

Received on Tuesday, 6 July 2010 13:37:09 UTC