[FFmpeg-devel] [RFC] unix socket protocol and our proto situation
Thu Dec 16 14:31:43 CET 2010
--- On Thu, 16/12/10, Martin Storsj? <martin at martin.st> wrote:
> From: Martin Storsj? <martin at martin.st>
> Subject: Re: [FFmpeg-devel] [RFC] unix socket protocol and our proto situation
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu>
> Date: Thursday, 16 December, 2010, 8:44
> On Thu, 16 Dec 2010, JULIAN GARDNER
> > > > > > 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
> > This helps, was my first modifications. But i still
> got lots of errors
> > on high rate channels hence the addition of a 2Mb
> circular buffer.
> > As ive said before when ffmpeg is probing the circular
> buffer can use
> > upto and over 800k whilst its doing the probing and
> before it starts
> > encoding, and the frame rate usually starts over
> 100fps as it eats the
> > circular data, after a while if drops down to the
> correct frame rate.
> Yes, av_find_stream_info is problematic with streams over
> lossy channels
> such as UDP, since depending on the stream, it can buffer
> up quite a bit
> of data, and won't read any more until the buffered data is
> For realtime streams, I tend to prefer not to use
> av_find_stream_info at
> all, but I think modifying ffmpeg/ffplay to work that way
> might be a bit
> of work.
> // Martin
So what do you recommend, is there some software that would work better at taking in realtime streams and encoding to h.264/aac.
Or would writing a program be the better way to do this, and add the circular buffer as a major part of it.
More information about the ffmpeg-devel