On Tue, 06 Jul 2010 17:42:22 +0200, Marques Johansson
<marq...@displague.com> wrote:
On Tue, Jul 6, 2010 at 10:59 AM, Philip Jägenstedt
<phil...@opera.com>wrote:
On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson <
marq...@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
