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

Michael Niedermayer michaelni at gmx.at
Wed Jul 4 21:27:02 CEST 2012

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 ...


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120704/c95908ca/attachment.asc>

More information about the ffmpeg-devel mailing list