[whatwg] More YouTube response

On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson <marques at displague.com>
> wrote:
> > For my purposes I am interested in application-controlled video delivery.
>  I
> > want to be able to deliver unprotected mp4, webm, or ogv content in a
> > metered way.  If the user has payed to watch the entire video once and
> has
> > managed to work around HTTP no-cache and the other constraints that a
> normal
> > browser viewed experience would have, then they will have succeeding in
> > downloading a copy of the video - a task which they could have
> accomplished
> > with a VM session or through other means regardless of DRM.
>
> There's no way to stop this at the markup level, since the user could
> just configure a user-agent to ignore the attributes, or manually
> remove them with a tool like Firebug.  More to the point, since this
> feature doesn't provide significant benefit to many users or authors,
> no user agent would bother implementing it in the first place.
>
> You should instead look into to writing server-side scripts that meet
> your needs.  When the user requests a video, have the script check how
> much video the user is authorized to view, and just truncate it after
> that point.  Or have it insert an extra clip at the end of what
> they're allowed to view saying "you have to pay more to keep viewing",
> then truncate it.  Or whatever.  This is pretty easy to do, and not
> possible for the user to circumvent.


If the UA didn't follow the prescribed size constraints they would get a 403
response (or a better 4xx range too large if it existed).

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

> These requests can be seen as generally allowing servers to reduce load
> for
> > video or large file downloads.  Since a client may be able to download 5
> > minutes of video in under a minute I would like to see the client
> disconnect
> > from the server and reconnect in 5 minutes to get the additional content.
>  I
> > would like to see the server have the ability to enforce this (through
> HTTP
> > errors) or at least suggest it (through HTML5 attributes or additional
> HTTP
> > headers).
>
> Well-written clients should already buffer only as much as they need
> to ensure the video will play smoothly.  The preload="" attribute is
> already provided to allow authors to control this behavior.  When the
> client has read enough for now, it will just stop reading new content
> from the server until it needs more.  If the server thinks that the
> client is reading too fast, on the other hand, it can just send fewer
> packets.  Again, I don't think anything needs to be changed in HTML
> here.
>

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.

If the <video> tag included a minbuffer and a maxbuffer (at least the
latter) then the client would always have an upper bound on video ranges
requested.  If the UA failed to include this the server can give them a 403,
416, or some 4xx that does not yet exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/75e5e419/attachment.htm>

Received on Tuesday, 6 July 2010 07:24:45 UTC