[whatwg] More YouTube response

On Tue, 06 Jul 2010 17:42:22 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Tue, Jul 6, 2010 at 10:59 AM, Philip J?genstedt  
> <philipj at opera.com>wrote:
>
>> On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson <
>> marques at displague.com> wrote:
>> 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.
>
>
> For webm files, Chrome requests 0-1024 and then some block near the end  
> of
> the file.  I assume that the meta data / time ranges are stored at these
> locations.
>
> As for bounded requests that make sense - I'm sure the server hosting the
> content could suggest something ;-)

If the index is stored in the beginning of the file, there should be no  
need to seek to the end. What we want is to get at least metadata and the  
first frame in a single request, and I can't guess any number that doesn't  
risk being larger than the file itself. Somehow involving the server just  
amounts to two network roundtrips, which was exactly what we were trying  
to avoid.

> I've tried having the server disconnect a HTTP/1.1 200 response by doing  
> a
> php exit() before having sent the "Content-Length" specified number of
> bytes.  Browsers did not attempt to pick up where the server left off.
>
> I think you are suggesting that the client disconnect but without  
> scripting
>
> I don't really have control over that and if with scripting that doesn't
> seem doable unless the video element could be feed with an appendBytes()
> type of function.

Yes, the browser disconnects, and scripts have no influence over it. With  
preload="metadata" implemented, it should disconnect as soon as possible  
after getting enough data for the first frame. For preload="auto", it will  
disconnect after buffering X seconds of data. If you need more granularity  
than that, I suggest server-side control informed by information collected  
by JavaScript. If browsers handled a short reply to a range request, it  
should work just fine, no?

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Wednesday, 7 July 2010 01:49:48 UTC