[FFmpeg-trac] #5399(undetermined:new): Dealing with duplicated multicast RTP packets

[FFmpeg]

#5399: Dealing with duplicated multicast RTP packets
-------------------------------------+-------------------------------------
             Reporter:  dbrb2        |                     Type:
               Status:  new          |  enhancement
            Component:               |                 Priority:  normal
  undetermined                       |                  Version:
             Keywords:  duplicate    |  unspecified
  RTP                                |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 I have been discussing a bug / feature (depending on your point of view)
 identified with ffmpeg.

 It affects the latest version from git (and previous versions)
 and is independent of the precise command used to launch ffmpeg. However
 it is reproduceable:

 Problem:

 * Join a UDP multicast stream
 * Provide duplicate multicast packets, so sequence numbers are repeated -
 this should never actually happen, but often can in a multicast network if
 the config on a switch somewhere is wrong, and it would be very good if
 this was handled
 * These duplicate packets are not dropped, but processed causing the image
 to become unusable

 Expetcted (hoped for?) outcome
 * RTP packets with duplicated sequence numbers dropped

 I have discussed this on the ffmpef users mailing list, with the thread
 providing some of the steps already taken, and culminating in the
 suggestion I try to raise the issue here:

 https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-April/031538.html

 The logic for what to do with "unexpected" sequence numbers seems to
 reside in rtpdec.c

 I have tried to change some of this logic to drop duplicated sequence
 numbers without any success - though the code still compiles, the
 behaviour I am expecting does not..hence now asking the real developers...

 As an aside, I have noticed that VLC does handle this situation - as I
 understand it VLC is build using ffmpeg libraries, so I am also trying to
 work out what it does dfferently...but as yet have not found an answer
 there either.








 https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-
 April/031538.html

 Summary of the bug:
 How to reproduce:
 {{{
 % ffmpeg -i input ... output
 ffmpeg version
 built on ...
 }}}
 Patches should be submitted to the ffmpeg-devel mailing list and not this
 bug tracker.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5399>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker