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

[Ronald S. Bultje]

Hi,

On Wed, Dec 15, 2010 at 9:46 PM, Luca Barbato <lu_zero at gentoo.org> wrote:
> 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) ?

Fine with me.

As said, please consider implementing an AVOptions property also at some point.

Ronald