W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] More YouTube response

From: Marques Johansson <marques@displague.com>
Date: Tue, 6 Jul 2010 11:42:22 -0400
Message-ID: <AANLkTinE3ruLIKVeVaqkufZ1RRnC1Zmzd52H1bu82EqL@mail.gmail.com>
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 ;-)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/d1f7eb4e/attachment.htm>
Received on Tuesday, 6 July 2010 08:42:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC