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

[Martin Storsjö]

On Thu, 16 Dec 2010, Martin Storsj? wrote:

> On Wed, 15 Dec 2010, Ronald S. Bultje wrote:
> 
> > 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.
> 
> Fine with me, too.

The patch could btw use some small comment saying why this is larger than 
the maximum UDP packet size (when the name currently is UDP_MAX_PKT_SIZE), 
perhaps just rename the define to UDP_RX_BUF_SIZE.

// Martin