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

[aviad rozenhek]

On Wed, Dec 15, 2010 at 17:46, JULIAN GARDNER <joolzg at btinternet.com> wrote:

>
>
> --- On Wed, 15/12/10, aviad rozenhek <aviadr1 at gmail.com> wrote:
>
> > From: aviad rozenhek <aviadr1 at gmail.com>
> > Subject: Re: [FFmpeg-devel] [RFC] unix socket protocol and our proto
> situation
> > To: "FFmpeg development discussions and patches" <
> ffmpeg-devel at mplayerhq.hu>
> > Date: Wednesday, 15 December, 2010, 15:03
> > On Wed, Dec 15, 2010 at 16:35, Ronald
> > S. Bultje <rsbultje at gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Dec 15, 2010 at 6:31 AM, aviad rozenhek <aviadr1 at gmail.com>
> > wrote:
> > > > The 64k socket buffer asked for by ffmpeg is too
> > small, especially when
> > > > using higher bitrate streams like 10mbps and up.
> > > > using 250k is much more reasonable IMHO and works
> > much better.
> > > > using a tight loop to read from the socket
> > improves on the current
> > > > situation, but does not fix it.
> > > > increasing the buffer size solves it completely,
> > and requires no code.
> > >
> > > I think this is fine, but if you change default,
> > please document that
> > > properly in changelog and try making it settable, if
> > possible, with a
> > > AVOption in the RTSPDemuxer. That way apps that want
> > smaller buffers
> > > don't have to waste memory.
> > >
> > > Ronald
> > >
> > >
> > I don't have commit access,
> > I was hoping that someone with commit access would be able
> > to change the
> > default buffer size in udp.c
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at mplayerhq.hu
> > https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> >
>
> you can change the buffer size on the command line already
>
> append ?buffer_size=xxxxxx at the end of your udp line
>
> udp://224.10.0.3:1234?packet_size=131072
>
> joolz
>
>
>
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