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

Martin Storsjö martin
Thu Dec 16 09:18:45 CET 2010


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.

// Martin



More information about the ffmpeg-devel mailing list