CODEWITHSUNDEEP
ffmpegvideo-streamingrtp
Андрей_RnD
Андрей_RnD

Reputation: 41

ffmpeg rtp streaming errors: RTP: dropping old packet received too late

I start video transfer by means of ffmpeg like this:

ffmpeg -f video4linux2 -i /dev/video0 -vcodec libx264 -preset ultrafast -crf 20 -tune zerolatency -s 800x600 -r 25 -b:v 0.9M -sdp_file video.sdp -f rtp rtp://192.168.10.24:5010

I reproduce this way:

ffplay -protocol_whitelist file,udp,rtp video.sdp

Everything works just fine. Then I interrupt transmission and after a couple of seconds I resume. ffplay does not immediately start to reproduce but errors occur:

....
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 14 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 33 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 41 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 49 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 33 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 27 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 14 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 48 times
[sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
    Last message repeated 34 times
......

After a some time, playback is restored, but it is too long. Is there a way to eliminate or minimize the occurrence of errors of this nature when the incoming stream is suspended, can options or something else? Read the manual ffmpeg nothing worthwhile about this did not naryl .... ((((

Upvotes: 4

Views: 5827

Answers (1)

MatteoBee
MatteoBee

Reputation: 81

Ok so I was having the same issue and spent a good hour on it. digged into the ffmpeg code; in libavformat/rtpdec.c

    if ((s->seq == 0 && !s->queue) || s->queue_size <= 1) {
    /* First packet, or no reordering */
    return rtp_parse_packet_internal(s, pkt, buf, len);
} else {
    uint16_t seq = AV_RB16(buf + 2);
    int16_t diff = seq - s->seq;
    if (diff < 0) {
        /* Packet older than the previously emitted one, drop */
        av_log(s->ic, AV_LOG_WARNING,
               "RTP: dropping old packet received too late\n");
        return -1;
    } else if (diff <= 1) {

it speaks of no reordering. So I followed up the queue_size and in libavformat/rtsp.c speaks of reordering_queue_size and in the doc https://ffmpeg.org/ffmpeg-protocols.html#rtsp shows

-reorder_queue_size

    Set number of packets to buffer for handling of reordered packets.

It's not explicit but if you add -reorder_queue_size 0 it solves the issue because it stops ordering the packets. I verified and solved my issue. I can interrupt the source... and after 2 minutes restart and it just works

mainly because being udp and realtime I have no need for any order, it should just play what comes through

Hope this solves your issue as well

Upvotes: 8

Related Questions