[FFmpeg-user] Query about dealing with duplicate multicast packets

Ben Barker ben at bbarker.co.uk
Sat Apr 2 01:22:22 CEST 2016


I have a multicast network that occasionally has config problems, and when
it does it is fairly common that instances of ffmpeg joining UDP multicast
video streams will receive duplicate packets. Looking at the streams in
wireshark the duplicates can clearly be seen - with identical sequence
numbers, timestamps, etc

Obviously the "correct" solution is to fix the network, but this can take
some time whilst the problem is identified.
Whilst it is happening, any streams joined have a tendency to "smear" when
played back

An ideal solution, from my point of view, would be to be able to drop a
packet if it is received from a source with an already seen sequence number
within a certain period. To that end, I've been trying to get my head
around how ffmpeg deals with such duplicates.

Please bear with me, as I am not very familiar with any of this, but so far
as I can see the logic is dealt with here:

http://ffmpeg.org/doxygen/3.0/rtpdec_8c_source.html
In particular on line 246

It seemed that setting the return value on this line to -1 might accomplish
what I was aiming for - but whilst it compiled, the effect was not obvious,
so I must be missing something.

However I noticed that when I was receiving duplicate packets, the "RTP
missed packet" warnings went through the roof
The code for this warning seems to be (in the same file as above)

         av_log(s->st ? s->st->codec : NULL, AV_LOG_WARNING,
                "RTP: missed %d packets\n", s->queue->seq - s->seq - 1);

Is it correct to say that if the sequence numbers are identical,
"s->queue->seq - s->seq - 1" will be negative, which for an unsigned int
displays as a high number - hence the very high displayed values?

Can anyone offer any advice on whether my understanding of why duplicates
cause the missed RTP figures to be so high is correct - and also if there
is a way to simply skip duplicates when they occur - so far my attempts
haven't worked!


More information about the ffmpeg-user mailing list