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

[JULIAN GARDNER]

--- On Wed, 15/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: Wednesday, 15 December, 2010, 0:31
> On 12/14/2010 10:50 PM, JULIAN
> GARDNER wrote:
> 
> > 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 problem.
> 
> FFmpeg is driven by the decoding loop, so either your
> system buffer the
> network packet for you or you'll read them longer past
> their arrival
> depending on what ffmpeg is doing (e.g. it got enough data
> to decode
> while probing so it won't check for it for a while).
> 
> > 
> > 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
> 
> Are you 100% sure it is working as should? try to write a
> small program
> that fetches from udp and feeds to a file and then inspect
> the resulting
> dump and then feed it to ffmpeg from a pipe
> 
> lu

what i am going to do as the stream is a TS over UDP is add in a CC checker to make sure i am receiving all the TS packets.

Will let you know as soon as i have this done

I do also have a buffer overrun message which i only see if i set the system to encode 4 streams at one go as the fisrt part where ffmpeg tries to workout what the stream is does take quite a long time, is there a way of shortening this delay

joolz