Why am I getting lost packets in ffmpeg doing local RTP streaming?

Question

I am trying to test ffmpeg streaming with RTP via local SDP file. So to start the stream I run

ffmpeg -re -thread_queue_size 4 -i .\bbb_streamable.flv -strict -2 -vcodec copy -an -f rtp rtp://127.0.0.1:6005 -acodec copy -vn -f rtp rtp://127.0.0.1:7005

That gives me the following SDP

v=0
o=- 0 0 IN IP4 127.0.0.1
s=Big Buck Bunny, Sunflower version
t=0 0
a=tool:libavformat 58.10.100
m=video 6005 RTP/AVP 96
c=IN IP4 127.0.0.1
b=AS:3500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAKKzZQHgCJ+XARAAAAwAEAAADAPA8YMZY,aOrssiw=; profile-level-id=640028
m=audio 7005 RTP/AVP 97
c=IN IP4 127.0.0.1
b=AS:96
a=rtpmap:97 MPEG4-GENERIC/44100/2
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=121056E500

So to record the RTP stream in another window I execute:

ffmpeg -protocol_whitelist "file,rtp,udp" -i .\test.sdp -strict -2 test.flv

While this is occurring I"m constantly getting messages in ffmpeg about missed packets

[sdp @ 0000020b70f2aa80] max delay reached. need to consume packete=2149.1kbits/s dup=0 drop=1 speed= 1.2x
[sdp @ 0000020b70f2aa80] RTP: missed 230 packets
[h264 @ 0000020b71456ec0] error while decoding MB 20 11, bytestream -45
[h264 @ 0000020b71456ec0] concealing 6869 DC, 6869 AC, 6869 MV errors in I frame
[sdp @ 0000020b70f2aa80] max delay reached. need to consume packete=2119.4kbits/s dup=0 drop=1 speed=1.17x
[sdp @ 0000020b70f2aa80] RTP: missed 208 packets
[h264 @ 0000020b70ff5f80] error while decoding MB 116 12, bytestream -13
[h264 @ 0000020b70ff5f80] concealing 6653 DC, 6653 AC, 6653 MV errors in I frame
[sdp @ 0000020b70f2aa80] max delay reached. need to consume packete=2107.8kbits/s dup=0 drop=1 speed=1.15x
[sdp @ 0000020b70f2aa80] RTP: missed 17 packets
[h264 @ 0000020b70ff5f80] error while decoding MB 22 48, bytestream -7
[h264 @ 0000020b70ff5f80] concealing 2427 DC, 2427 AC, 2427 MV errors in P frames dup=0 drop=1 speed=1.14x
[sdp @ 0000020b70f2aa80] max delay reached. need to consume packet
[sdp @ 0000020b70f2aa80] RTP: missed 210 packets

When viewing the generated flv file it has a ton of artifacts and issues. The source file is 100% clean.

Why is this performing so badly, even over 127.0.0.1?

Solution

Try to remove flag '-re'!

-re (input)

Read input at native frame rate. Mainly used to simulate a grab device, or live input stream (e.g. when reading from a file). Should not be used with actual grab devices or live input streams (where it can cause packet loss).

http://ffmpeg.org/ffmpeg.html#Advanced-options

Comments

[davidbaumann]

Is any core on 100%?

[KallDrexx]

Nope, no core is over 30%

[Matt Wolfe]

I am seeing something similar but the data is coming from a Wi-Fi source on the network. I logged sequence numbers of the incoming RTP packets and none of them were dropped and they were coming in plenty fast enough to be decoded in time yet when having ffmpeg ingest the stream I had these same errors...

[hemu]

Thanks @Elektordi

[j1elo]

I came here searching for the same issue, although in my case the RTP sender is some other software. The RTP receiver in this question was not using -re to begin with, so why would it make any difference? Is there anything to add in the receiver command, that might help reduce the "max delay reached" and "RTP: missed n packets" messages?

[Elektordi]

@j1elo take a look at udp buffers (both in ffmpeg itself, and sometimes in operating system). You can also try to increment probesize.

[Admin]

@Elektordi the current documentation is a bit different: "-readrate speed (input) [...] Value 1 represents real-time speed and is equivalent to -re. [...] Should not be used with a low value when input is an actual capture device or live stream as it may cause packet loss. [...]". To me, a low value should be less than 1, something like 0.4. Since -readrate 1 = -re, the -re option shouldn't cause problems with live sources.