[FFmpeg-trac] #5156(avformat:new): Multiple instances of ffplay to stream different rtp streams on same port fail

[FFmpeg]

#5156: Multiple instances of ffplay to stream different rtp streams on same port
fail
-------------------------------------+-------------------------------------
             Reporter:  jeroenz      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  2.8.3        |               Resolution:
             Keywords:  udp sdp      |               Blocked By:
  multicast                          |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (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...

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5156#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker