[vlc-devel] Buffering when reading live HTTP streams

[Rémi Denis-Courmont]

On Tue, 29 May 2012 14:03:27 -0400, Robert Forsman
<bob.forsman at ericsson.com> wrote:
> 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.

TCP buffering is addressed by the IETF in its protocol specification and
in the IP stack. Anyone who claims that it should be defined somewhere else
needs to learn about pragmatism and layer separation.

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

Blablabla.

TCP is designed to use buffers with byte size, because TCP transmits
bytes. The TCP/IP stacks found in most operating systems offer byte size
controls for their buffer size. For one thing, the TCP/IP stack is _not_
only about streaming.

I'm pretty sure non-free software has the exact same "bug", since it uses
the same TCP/IP implementations.

-- 
Rémi Denis-Courmont
Sent from my collocated server