[vlc-devel] Buffering when reading live HTTP streams

[Rémi Denis-Courmont]

	Hello,

Le dimanche 13 mai 2012 00:41:46 Steinar H. Gunderson, vous avez écrit :
> It seems like on the client side, VLC does not always empty its socket
> buffer; the client thread reads a certain amount of data, then pauses even
> though there is more data in the buffer, and so on. In some cases,
> this affects the TCP behavior (eventually causing the stream to skip and
> glitch irrepairably until it's stopped and restarted), since the client has
> to advertise a zero window (“sorry, I'm full, please don't send any data
> right now”) until VLC comes and cleans up.

I do not know the intricate details of buffering within VLC stream_t but this 
seems to point at multiple possible problems:

1) The spaghetti code in the HTTP plugin could fail to dequeue the maximum 
possible amount of available data from the TCP/IP stack. This seems unlikely, 
but with all the spaghetti, I never know for sure.

2) There is a bug in the stream_t buffers. It requests only a small amount of 
data from the HTTP plugin, which has to obey.

3) The stream_t buffers are constantly almost full. The server is probably 
sending data faster than the media pipeline decodes.

4) There is a huge delay in decoding, during which the demuxer, the stream 
buffer and the HTTP plugin do not get to run. The TCP window fills up in the 
mean time.

Running HTTP in its own thread would constitute an obvious but non-trivial fix 
or work-around. Incresing network-caching might also work partially.

(...)
> I talked to Sam Hocevar on IRC, and he suggested that this might be since
> the HTTP access method is set as “can pace control”
> (ACCESS_CAN_CONTROL_PACE=true) unconditionally, so the rest of VLC doesn't
> want to read from it at any higher rate than it can play. I tried changing
> it to false, and the buffer behavior is perfect -- but the stream glitches
> and skips constantly instead, with messages such as

If you disable pace control, VLC will assume that it can read data at whatever 
rate it feels like from the stream. This might be almost true for VoD with 
over-provisioned bandwidth. And even then, many dedicated streaming servers do 
not allow clients to exceed the nominal bandwidth.

This is obviously not true for live streams, as the player cannot read data 
faster than real-time.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis