Opened 3 years ago

Closed 2 years ago

#5156 closed defect (fixed)

Multiple instances of ffplay to stream different rtp streams on same port fail

Reported by: jeroenz Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: udp sdp multicast rtp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
There are multiple rtp video streams in the system, each multicasted on different addresses but same port number. For each stream, there is a sdp file (a.sdp, b.sdp). When I start 'ffplay a.sdp', 'stream a' is shown. Then, when I start a second instance (ffplay b.sdp), both instances show 'stream b' and start to generate a lot of errors like these:

[h264 @ 0x7f049c008c00] RTP: missed -44310 packetssq= 0B f=0/0
[h264 @ 0x7f049c008c00] RTP: PT=60: bad cseq 1476 expected=c18c
[h264 @ 0x7f049c008c00] RTP: missed -44310 packetssq= 0B f=0/0
[h264 @ 0x7f049c008c00] RTP: dropping old packet received too late
[h264 @ 0x7f049c008c00] RTP: dropping old packet received too late

It turned out that both instances receive 'all streams' to that port number, because the binding is not/incorrectly done.
See libavformat/udp.c (function udp_open, line 734 in 2.8.4):

if (s->is_multicast && !(h->flags & AVIO_FLAG_WRITE)) {

bind_ret = bind(udp_fd,(struct sockaddr *)&s->dest_addr, len);

}

The bind is only done when the socket is opened in read-only mode, and apparently that is not the case with ffplay. When I remove the check for the AVIO_FLAG_WRITE and rebuild ffplay, all is working fine!

Also see http://ffmpeg.gusari.org/viewtopic.php?f=14&t=2587

Attachments (5)

ffplay-20160112-192301.log (90.5 KB) - added by jeroenz 3 years ago.
console output of first ffplay instance
ffplay-20160112-192340.log (16.7 KB) - added by jeroenz 3 years ago.
console output of second ffplay instance
sdp-files.zip (979 bytes) - added by jeroenz 3 years ago.
Used sdp-files…
ffplay-20160113-205144.log (60.5 KB) - added by jeroenz 3 years ago.
console output of first ffplay instance using head of ffmpeg
ffplay-20160113-205154.log (25.2 KB) - added by jeroenz 3 years ago.
console output of second ffplay instance using head of ffmpeg

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 years ago by cehoyos

  • Priority changed from important to normal

If you know how to fix this, please send your patch (made with git format-patch) to the development mailing list.
If you cannot fix the issue, please test current FFmpeg git head and please provide your command line together with the complete, uncut console output to make this a valid ticket.

Changed 3 years ago by jeroenz

console output of first ffplay instance

Changed 3 years ago by jeroenz

console output of second ffplay instance

Changed 3 years ago by jeroenz

Used sdp-files...

comment:2 Changed 3 years ago by jeroenz

Unfortunately I am absolutely no network specialist nor familiar with the ffmpeg code structure, so I don't know if my 'fix' will break other functionality on one or more platforms. Anyway, I did check the head version and noticed no changes in the piece of code I patched compared with the 2.8.4 release. Here's the offending piece (udp.c):

    /* If multicast, try binding the multicast address first, to avoid
     * receiving UDP packets from other sources aimed at the same UDP
     * port. This fails on windows. This makes sending to the same address
     * using sendto() fail, so only do it if we're opened in read-only mode. */
    if (s->is_multicast && !(h->flags & AVIO_FLAG_WRITE)) {
        bind_ret = bind(udp_fd,(struct sockaddr *)&s->dest_addr, len);
    }

I replaced this with the following code to make it work:

    if (s->is_multicast) {
        bind_ret = bind(udp_fd,(struct sockaddr *)&s->dest_addr, len);
    }

But again, I'm not sure if this is the proper solution. I really wonder why ffplay would open the socket in read/write mode, because I think read-only would be sufficient in this case.

To be complete, I'll add the console output for both instances of ffplay as attachments. Note that this is the output from the unpatched (hence failing) 2.8.4 version. The first instance(ffplay-20160112-192301.log) starts off just fine, but as soon as I start the second instance (ffplay-20160112-192340.log), things go wrong on the first instance too.
I'll also add the sdp-files I used, although that doesn't seem very relevant to me...
I hope this is enough info to make this a valid ticket...

comment:3 Changed 3 years ago by cehoyos

Is this issue reproducible with current FFmpeg git head?

Changed 3 years ago by jeroenz

console output of first ffplay instance using head of ffmpeg

Changed 3 years ago by jeroenz

console output of second ffplay instance using head of ffmpeg

comment:4 Changed 3 years ago by jeroenz

Yes, it also reproduces with the head version. I just built the head and the result is the same as with 2.8.4. See new attachments ffplay-20160113-205144.log and ffplay-20160113-205154.log for the console output for 1st and 2nd instance of ffplay.

comment:5 Changed 2 years ago by coyotenq

Same issue here.
ffmpeg "mix" udp streams coming from same port (but from different multicast ip addresses)

using
ffmpeg version 2.8.8-0ubuntu0.16.04.1 Copyright (c) 2000-2016 the FFmpeg developers

gonna check trunk version.

comment:6 Changed 2 years ago by coyotenq

solved at trunk, please close this ticket

Thanks!

comment:7 Changed 2 years ago by cehoyos

  • Keywords rtp added
  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from 2.8.3 to git-master
Note: See TracTickets for help on using tickets.