[FFmpeg-devel] [RFC] unix socket protocol and our proto situation

[Luca Barbato]

On 12/16/2010 03:21 AM, Michael Niedermayer wrote:
> On Wed, Dec 15, 2010 at 05:59:55PM +0100, Luca Barbato wrote:
>> On 12/15/2010 05:37 PM, aviad rozenhek wrote:
>>> On Wed, Dec 15, 2010 at 17:46, JULIAN GARDNER <joolzg at btinternet.com> wrote:
>>> I believe it is best to put a have a good default in place, so that
>>> applications using the API or commandline users dont have to jump through
>>> hoops to get udp input to work
>>
>> requesting larger system buffer just hides the problem IMHO.
> 
> I disagree :)
> IMHO if one can portably make the system buffer big enough this is the correct
> fix, not trying to implement realtime data buffer emptier in userspace because
> this is cerftainly not portable your code can be paged out to disk and the
> disk could be saturated with other accesses so only the system buffer that
> is handled by a driver from locked memory can provide a gurantee to not
> loose data.

I'd rather have both sides covered, if we can indulge in asking more
buffer from the kernel, so be it, if we cannot but we still can process
the data in time because we have enough cpu (think about the multi-core
little arms being around) we might want to try that as well

That said, let's start with the quickest of the two: who's against
changing the default to an higher value (as in my previous patch) ?

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero