[vlc-devel] Buffering when reading live HTTP streams

[Steinar H. Gunderson]

Hi,

I'm streaming with VLC and x264 on the server side, and VLC and Flash on the
client, over HTTP. (UDP is, unfortunately, out of the question for us, due to
NAT issues--RTSP does not work satisfactory for most of our clients.)

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.

You can see an example of this pathological behavior here; the x axis is
seconds (since midnight); note how the window consistently and often goes to
0, and then goes back up again once VLC reads from the buffer (although that
message takes ~150 ms to reach the client due to network delay -- not shown
on the graph)

  http://home.samfundet.no/~sesse/window.png

Here's a more typical, but still not ideal run -- things mostly go okay,
until it starts getting behind:

  http://home.samfundet.no/~sesse/window2.png

For comparison, this is Flash (jwPlayer) on the same stream, showing much
more reasonable behavior even though it glitches once:

  http://home.samfundet.no/~sesse/window-flash.png

This behavior is consistent between all VLC versions I've seen, including
1.1.3 and 2.0.1. However, exact behavior depends on network conditions;
for instance, I cannot reliably reproduce the behavior in the first graph
myself, although I have several real-world TCP traces.

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

  [0xb4b115b4] main audio output warning: buffer is 88882 late, triggering upsampling
  [0xb4b115b4] main audio output warning: audio drift is too big (-249914), clearing out
  [0xb4b115b4] main audio output warning: timing screwed, stopping resampling
  [0xb4b115b4] main audio output warning: mixer start isn't output start (-103919)
  [0xb4b115b4] main audio output debug: audio output is starving (344116), playing silence
  [0xb4b115b4] alsa audio output debug: recovered from buffer underrun
  [0xb4b115b4] main audio output warning: buffer is 97538 late, triggering upsampling
  [0xb4b115b4] main audio output warning: audio drift is too big (260473), dropping buffer
  [0xb4b115b4] main audio output warning: audio drift is too big (239139), dropping buffer
  [0xb4b115b4] main audio output warning: audio drift is too big (217806), dropping buffer 

Does anybody know if there's a way to keep these buffers emptied reliably?
It seemingly is one of the last hurdles for me in stable intercontinental
HD streaming (the other pieces of the puzzle involve packet pacing and some
hacks on the server side, but that's a different story).

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