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

[JULIAN GARDNER]

--- On Tue, 14/12/10, Luca Barbato <lu_zero at gentoo.org> wrote:

> From: Luca Barbato <lu_zero at gentoo.org>
> Subject: Re: [FFmpeg-devel] [RFC] unix socket protocol and our proto situation
> To: ffmpeg-devel at mplayerhq.hu
> Date: Tuesday, 14 December, 2010, 21:21
> On 12/14/2010 07:29 PM, JULIAN
> GARDNER wrote:
> > 
> > 
> > --- On Tue, 14/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: Tuesday, 14 December, 2010, 16:43
> >> On Sun, Sep 19, 2010 at 15:40, Luca
> >> Barbato <lu_zero at gentoo.org>
> >> wrote:
> >>
> >>> On 09/18/2010 11:39 AM, Howard Chu wrote:
> >>>> Lowering the send buffer size sounds like
> a
> >> reasonable solution for
> >>>> local sockets. That really should be all
> that's
> >> necessary to deal with
> >>>> unix domain sockets.
> >>>
> >>> Changing the defaults to be the same as udp
> fixed the
> >> issue indeed.
> >>> I exposed both buffer_size and pkt_size, now.
> >>>
> >>> Comments and test welcome as usual =)
> >>>
> >>> lu
> >>>
> >>>
> >> I still have a lot of loss on windows when
> streaming from
> >> ffmpeg to ffplay.
> >> I found out that all this problems go away when
> the receive
> >> buffer is
> >> bigger.
> >> I don't know how big the buffer can be set on
> other
> >> platforms, but on
> >> windows, a buffer size of 0x3FFFF [262143 bytes]
> works like
> >> a charm without
> >> any losses.
> >>
> >> would it be possible to increase the default
> receive buffer
> >> size for udp to
> >> 0x3FFFF, at least on windows systems?
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel at mplayerhq.hu
> >> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> >>
> > 
> > I am having the same problem, i receive a multicast
> stream from a hardware encoder
> > in MPEG2 and using ffmpeg i then encode the stream in
> x264.
> > 
> > Now my problem was/is that ffplay works fine, no
> errors, but ffmpeg gives lots of errors.
> 
> > I added a circular buffer into the udp.c file which
> allocates a 2Mb buffer and this is
> > controlled by a seperate task.
> 
> May we see that code? for now a too long time I'm drafting
> ideas to
> provide ffmpeg with a poll+enqueue infrastructure for
> network protocols...
> 
> > I have validated that the buffer is working and
> sometime i see a max level of 800k
> > but it is normally around 450k.
> > 
> > But i am still getting decode errors on the input, so
> if i am receiving the data and not
> > losing any why do i get decode errors?
> 
> udp isn't reliable at all. Our implementation of network
> protocols
> relies too much on the OS buffers and exacerbates the
> situation.
> 
> lu
> 
> -- 
> 
> Luca Barbato
> Gentoo/linux
> http://dev.gentoo.org/~lu_zero
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 

Ok but can you explain why ffmpeg is so bad when other programs receiving UDP data dont seem to have a problem, the machine is a core i7 950 and from my work on other bits of software i dont lose UDP data, but ffmpeg seems to have a probelm.

Now with my circular buffer i dont seem to lose any data from the UDP but ffmpeg still fails on decoding, which is mpeg2, and this causes a few problems

joolz