Opened 5 years ago
Closed 4 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)
Change History (12)
comment:1 Changed 5 years ago by cehoyos
- Priority changed from important to normal
comment:2 Changed 5 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 5 years ago by cehoyos
Is this issue reproducible with current FFmpeg git head?
comment:4 Changed 5 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 4 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 4 years ago by coyotenq
solved at trunk, please close this ticket
Thanks!
comment:7 Changed 4 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
My guess is 6f5048f4a0f702d92794dda7752c20ed6033233b
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.