[FFmpeg-devel] drop entire frame when RTP packets are lost

Reimar Döffinger Reimar.Doeffinger at gmx.de
Thu Jul 5 20:24:34 CEST 2012


On Wed, Jul 04, 2012 at 09:27:02PM +0200, Michael Niedermayer wrote:
> On Wed, Jul 04, 2012 at 02:19:29AM +0200, Michael Niedermayer wrote:
> > On Tue, Jul 03, 2012 at 04:01:49PM -0400, Martin Carroll wrote:
> > > 
> > > > the problem is caused by the OS UDP buffer overflowing this is because
> > > rtpproto.c
> > > > disabled our ring buffer without the ring buffer the code depends on
> > > the OS having
> > > > large enough buffers which it plain doesnt ... 
> > > 
> > > Yes, I had already spotted that, and to "fix" it I did a side-experiment
> > > in which I
> > > hard-coded a very large receive buffer (in the setsockopt() call in
> > > udp.c).  Even
> > > with a very large buffer, I still eventually start losing packets.  I
> > > did not bother
> > > to mention that side experiment, because I was under the impression that
> > > the
> > > *existing* code allegedly worked.
> > 
> > I tried the same before writing the mail and my results where
> > different.
> > are you sure you updated net.core.rmem_max and net.core.rmem_default ?
> > because these limit the buffer size on linux?
> > 
> > 
> > > 
> > > Given your statements re how to fix it, I conclude that ffplay, as
> > > written, does not
> > > support the playing of RTP streams that are longer than under, say, a
> > > minute or so.
> > > Please correct me if I'm wrong...
> > 
> > Iam not aware of such a limitation.
> > the way stream probing works is libavformat causes a irregularity in
> > the calling of the rtp code which then causes the OS buffers to
> > overflow as the UDP ring buffer is not useable with RTP ATM.
> > This has nothing to do with ffplay, ffplay reads data as it needs it
> > ffmpeg reads all data it can get as quick as it can. You can achive
> > the same with ffplay by increasing MIN_FRAMES but this has other
> > disadvantages ...
> 
> you can now use ffplay -infbuf instead of changing MIN_FRAMES
> to enable this hack, thanks to martin.
> but still this is not a proper solution, some applications cannot
> gurantee that they would call the rtp code frequently enough to avoid
> buffer overflows. Single threaded players like mplayer come to mind ...

Well, the cache code in MPlayer could handle it just fine. But I think
rtp is one of the formats that bypasses the stream layer and thus
MPlayer can't use the cache...


More information about the ffmpeg-devel mailing list