[vlc-devel] byte ranges in vlc HTTP requests
Rainer Joswig
joswig at lisp.de
Wed Jul 15 11:14:00 CEST 2009
Am 15.07.2009 um 10:34 schrieb Anthony Loiseau:
Hi,
I have tested VLC 1.0.0 against an HTTP 1.1 server written in Lisp .
The server itself is available since 1994.
Applications like Apple's Quicktime player, Apple's iPhone, Adobe
Acrobat Reader Plugin,
and also VLC 0.9.9 and VLC 0.9.8 currently don't have any problems
with the server
- using the GET with byte ranges.
VLC 1.0.0 has. So probably it is not related to the byte range feature,
but something else introduced with the new version?
If I turn on the HTTP continuous stream option, then it works fine
with VLC 1.0.0.
The video is an h.264 video.
> Hi,
>
> 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[1] 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 [1]? Have you
> tested
> to keep a socket opened for a long time on your server?
I see a lot of requests from VLC 1.0.0, but the playing stops after four
seconds.
The VLC log contains things like:
access_http debug: trying to seek to 211744
main debug: net: connecting to 10.0.1.4 port 8000
main debug: connection: Operation now in progress
main debug: connection succeeded (socket = 11)
access_http debug: protocol 'HTTP' answer code 206
access_http debug: Server: CL-HTTP/70.216 (LispWorks Personal Edition;
2.1.7)
access_http debug: Content-Type: video/quicktime
access_http debug: this frame size=35462401
access_http debug: stream size=35674145,pos=211744,remaining=35462401
main debug: Buffering 90%
main debug: Buffering 100%
main debug: Stream buffering done (1100 ms in 983 ms)
main debug: Decoder buffering done in 0 ms
main warning: PTS is out of range (-32848), dropping buffer
main warning: output date isn't PTS date, requesting resampling (-43305)
main warning: buffer is 43307 in advance, triggering downsampling
VLC 1.0.0 sends many more requests but does not play anything.
The server log looks like this:
[2009-07-15 11:05:34] {0.01 1} 10.0.1.4 408 HTTP/1.1 8000 {0}
49152 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye - (c)
1996-2009 the VideoLAN team" -
[2009-07-15 11:05:34] {0.06 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
221184 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:34] {0.01 1} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:34] {0.0 1} 10.0.1.4 408 HTTP/1.1 8000 {0} 16384
- "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye - (c)
1996-2009 the VideoLAN team" -
[2009-07-15 11:05:34] {0.01 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:35] {0.01 1} 10.0.1.4 408 HTTP/1.1 8000 {0}
16384 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye - (c)
1996-2009 the VideoLAN team" -
[2009-07-15 11:05:35] {0.01 1} 10.0.1.4 408 HTTP/1.1 8000 {0}
147456 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:35] {0.01 1} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:35] {0.01 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:36] {0.89 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:37] {1.0 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:38] {0.5 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:38] {0.5 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
221184 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
[2009-07-15 11:05:39] {0.5 2} 10.0.1.4 408 HTTP/1.1 8000 {0}
212992 - "GET /h.mov" "VLC media player - version 1.0.0 Goldeneye -
(c) 1996-2009 the VideoLAN team" -
Regards,
Rainer Joswig
>
>
> To understand better the HTTP access process, you can read its code
> [2].
> 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.
>
>
> Regards,
> Anthony
>
> 1:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1
> 2:
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/access/http.c;h=fdcee422c41aaa4b5c3be971ad906af5d91efeb4;hb=HEAD
>
>
> On Sun, 2009-07-12 at 20:26 +0200, Rainer Joswig wrote:
>> Hi,
>>
>> 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?
>>
>> Regards,
>>
>> Rainer Joswig
More information about the vlc-devel
mailing list