[vlc-devel] byte ranges in vlc HTTP requests
thannoy at actech-innovation.com
Wed Jul 15 10:34:48 CEST 2009
I never look at HTTP access on VLC 1.0.0, but it should be close to 0.9.
VLC ask for 0- range for some reasons:
- if the HTTP server handle ranges, a 206 ret code must be given. VLC
know by this code that the stream is seekable (because range are
accepted by the server).
- HTTP specifications says the entire file must be returned in case
of "0-" range requests, so "0-" is interesting. TCP stream remains open
as for a download request and VLC read this socket at the time it needs
to render the playback.
Have you tested your server against this statement ? Have you tested
to keep a socket opened for a long time on your server?
To understand better the HTTP access process, you can read its code .
It is easy to read.
For what I remember, it only request for another range if the socket
have been closed (not always and maybe only for Icecast) or if the user
use seek feature. To see if it is a seek, look at your server logs to
see if the first chunk was 198511 bytes long or not.
On Sun, 2009-07-12 at 20:26 +0200, Rainer Joswig wrote:
> I'm trying to support the use of VLC with a web server (CL-HTTP) that
> handles byte ranges.
> Currently I have some trouble when I want to display a movie that
> comes from that webserver.
> The transport is going over HTTP 1.1.
> VLC requests a byte range of 0- and for the next request of
> 198512- .
> Why doesn't it request byte ranges of 0-198511 and 198512-397023 ?
> Why not ask the web server for a specific byte range like above?
> How is VLC's current transfer method supposed to work? Is there a
> description of what is implemented?
> VLC requests bytes from 0 to the end of the data source, but then ends
> the transfer some point (?) and requests a new range from some number
> to the end?
> Is that a good idea?
> Rainer Joswig
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel