[vlc-devel] Buffering when reading live HTTP streams

[Robert Forsman]

On Tue, 29 May 2012 11:20:24 -0400
"Steinar H. Gunderson" <sgunderson at bigfoot.com> wrote:

> On Sun, May 13, 2012 at 11:04:50AM +0200, Steinar H. Gunderson wrote:
> > So, I guess my question then is: Exactly why does the timing go haywire if 
> > I turn off pace control? And is there anything to do about it?
> 
> OK, it seems I can't expect anyone to jump up and come up with a magical fix
> here, so what about a temporary hotfix? The UDP module already increases the
> receive buffers to 512 kB, so maybe we can do the same thing for the TCP
> module? That would at least hide the problem most of the time, as long as the
> user doesn't try to pause the stream.

Buffering is usually addressed by the specification for the container
format.

I'm most familiar with MPEG transport streams where buffering is
covered by ISO IEC 13818 part 1 section 2.4 "Transport Stream bitstream
requirements".  Large portions of that are still somewhat confusing to
me, but I do have a vague grip.

Unfortunately each container format is going to have slightly different
math, and multiplexers from the free software side typically ignore it
completely, or use their own algorithms that cause the stream to not
fulfill the requirements of the official spec.


Probably the most important adjustment I would recommend is "buffer
based on time, not kilobytes".  If you're pulling down an 0.5Mbit/s
stream, only buffer 0.25 Mbyte (4 seconds).  If you're pulling down a
19Mbit/s stream, buffer 9.5 Mbyte.  Feel free to pick a value other
than 4 seconds.  I think MPEG 2 has around an 0.5 second buffer, while
H.264 can go up to 10 seconds.  Unfortunately I'd have to go digging to
be certain about those numbers.