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

[jeroenz]

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

[cehoyos]

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.

[jeroenz]

console output of first ffplay instance

[jeroenz]

console output of second ffplay instance

[jeroenz]

Used sdp-files...

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

[cehoyos]

Is this issue reproducible with current FFmpeg git head?

[jeroenz]

console output of first ffplay instance using head of ffmpeg

[jeroenz]

console output of second ffplay instance using head of ffmpeg

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

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

[coyotenq]

solved at trunk, please close this ticket

Thanks!

[cehoyos]

My guess is 6f5048f4a0f702d92794dda7752c20ed6033233b