[vlc-devel] [PATCH] network: export SO_RCVBUF & SR_SNDBUF as config options

[Tzu-Jung Lee]

On Thu, Aug 15, 2013 at 11:54 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le jeudi 15 août 2013 23:41:09 Tzu-Jung Lee a écrit :
>> Hi Rémi,
>>
>> On Thu, Aug 15, 2013 at 11:21 PM, Rémi Denis-Courmont <remi at remlab.net>
> wrote:
>> > Le mardi 13 août 2013 01:31:00 Tzu-Jung Lee a écrit :
>> >> This patch allows user to overrite default values set by VLC on our
>> >> Linux system, though I haven't managed to build a Windows version
>> >> and give it a try.
>> >
>> > This won't really fix the problem. Users will not know that they need to
>> > change the VLC settings. And those who do know will complain that it does
>> > not work, because they will omit to raise the limits in /proc or the
>> > registry or whatever...
>> >
>> > If the limits are wrong for some input or some output, I think that
>> > specific input or output should select a better default value.
>> > Increasing the buffer
>> > sizes for all sockets does not look like such a great idea to me.
>>
>> I certainly agree your points but that doesn't conflict what the patch
>> proposed at all.
>
> I think it does conflict. If you have a configuration option, there is no way to
> provision per-plugin defaults later, without breaking the option. And then,
> taking the option in the code base reduces the incentive to really fix the
> problem.
>
> It seems to me the problem is mainly with receiving TS over UDP (and/or maybe
> TS over RTP over UDP). Then those specific input plugins should have larger
> default receive buffers.

Unlike UDP access_out, which use a blockfifo as buffer, UDP access does not
buffer the input, but provides the wrapper functions for the consumers to pull
the data from the socket buffer directly.

So you prefer to have a patch, which rework the UDP access module instead?

 1. Create a block fifo.

 2. Create a thread, so the received data can be asynchronously pull from socket
     buffer to the access module's fifo as soon as possible.

> Better yet figure out why VLC sucks so badly with high bandwidth TS streams.
> Something is probably wrong in the input thread or the stream cache.


>> The values under /proc or registry are system-wise default and max values.
>> The setsocketopt() in VLC overwrites the 'MAX' one, which means if the
>> 512KB is not enough for specific input/output, users can't do anything even
>> they know the buffer size is the key here.
> Then put larger values by default in the affected plugin(s). Values above the
> system limits will be capped anyway.
>> So we can keep the current default 512 KB in VLC, and allow user to
>> overwrite this value when they know what values work for them.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>