[vlc-devel] Buffering when reading live HTTP streams

[Steinar H. Gunderson]

On Sun, May 13, 2012 at 11:10:41AM +0300, Rémi Denis-Courmont wrote:
> I do not know the intricate details of buffering within VLC stream_t but this 
> seems to point at multiple possible problems:

Yes, I noticed it is quite complex :-)

> 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.

Well, even if so, ideally the buffer should be emptied when VLC catches up.
My problem is not really that it fills, more that it seems to get into a
steady state where it's not emptied.

I can easily provoke the «half-full» behavior (the one you see in the
right-hand side of window2.png) simply by pausing a bit and then continuing
to play; it never really catches up. (I understand of course that the data
needs to live somewhere; it just shouldn't be in the socket's buffer.)

> 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've tried increasing network-caching (and http-caching in 1.1.3), and it has
no effect on this behavior.

> If you disable pace control, VLC will assume that it can read data at whatever 
> rate it feels like from the stream.

Don't you mean the opposite? I thought the problem was that since the HTTP
access says “yes, I can ask the source to back off [or even pause]”, VLC only
reads at exactly the speed it feels like.

Certainly e.g. the UDP access has pace_control=false? There's also logic in
http.c to set pace_control=false if a live stream is detected (e.g., the
server is Icecast), but it's disabled.

/* Steinar */
-- 
Homepage: http://www.sesse.net/