[whatwg] More YouTube response

On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson  
<marques at displague.com> wrote:

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

The first request is tricky for the browser too. Having no idea of how big  
the resource is or what the bitrate is, there is no bounded request that  
makes sense, in my opinion. The downside is that for a conservative  
approach, the only solution is to abort the connection half way through,  
with the server having no idea when this will happen. I haven't seen any  
negative effects of this in practice yet, but this thread has me thinking  
that it could be better. Handling a short reply gracefully would be a good  
start.

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

Let's wait until preload="" is actually implemented to see if more  
fine-grained control is actually needed.

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Tuesday, 6 July 2010 07:59:04 UTC