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! _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
