[FFmpeg-user] Query about dealing with duplicate multicast packets
ben at bbarker.co.uk
Sat Apr 2 17:42:52 CEST 2016
Ah - in respect to the "missed packets" when duplicate sequence numbers are
received, I am actually seeing:
RTP: missed -1 packets
That error is found in rtp_parse_queued_packet:
"RTP: missed %d packets\n", s->queue->seq - s->seq - 1);
So far as I can see, by the time this section of the code is reached, the
packets are in their final order, and the above can only equal -1 if two
packets have the same sequence number - the condition I am trying to
So maybe this would be a better place to deal with the problem...simply
don't add the packet to the queue if the two sequences are identical here...
On Sat, Apr 2, 2016 at 4:23 PM, Ben Barker <ben at bbarker.co.uk> wrote:
> Yes - that's the line I was looking at. I have recompiled with a return
> value of 0 - certainly it hasn't made matters worse, I just need to create
> some verifiable duplicate traffic to test the behaviour and check how it
> The comment for that line is "duplicate or reordered" - I've been trying
> to verify what packets would fall into that category by working out how
> that statement could be reached.
> For instance, if a packet the largest sequence number received at t=0 has
> seq=10, and then a duplicate of that packet is received (also with seq=10),
> then udelta for that new packet will presumably = 0:
> uint16_t udelta = seq - s->max_seq;
> In that case, "udelta < MAX_DROPOUT" will be true, and the packet will be
> handled - even though it is a duplicate - and the section of code I was
> looking at will be skipped...
> My missed RTP thoughts as to the large numbers seen don't quite seem to
> pan out either - as you suggest if that was what was happening you'd expect
> to see the maximum possible unsigned integer value, whereas my values vary
> On Sat, Apr 2, 2016 at 2:42 PM, Moritz Barsnick <barsnick at gmx.net> wrote:
>> Hi Ben,
>> On Sat, Apr 02, 2016 at 00:22:22 +0100, Ben Barker wrote:
>> > Obviously the "correct" solution is to fix the network, but this can
>> > some time whilst the problem is identified.
>> Indeed. :)
>> > http://ffmpeg.org/doxygen/3.0/rtpdec_8c_source.html
>> > In particular on line 246
>> You mean this line, right? (link trying to avoid quoting line numbers
>> which might change over time):
>> > It seemed that setting the return value on this line to -1 might
>> > what I was aiming for - but whilst it compiled, the effect was not
>> > so I must be missing something.
>> You misinterpreted how that function is used. The comment above it
>> hints that it is boolean, i.e. zero or one. Indeed, there is only one
>> usage in ffmpeg:
>> Returning -1 would have the same effect as returning 1: The packet
>> would be handled. Your intent would probably have been to return 0
>> instead of the "default" 1 in the code right below. Thereby you
>> probably didn't actually change the behavior.
>> > 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?
>> > av_log(s->st ? s->st->codec : NULL, AV_LOG_WARNING,
>> > "RTP: missed %d packets\n", s->queue->seq - s->seq - 1);
>> Indeed. What value was printed? UINT32_MAX = 4294967295?
>> > Can anyone offer any advice on whether my understanding of why
>> > cause the missed RTP figures to be so high is correct - and also if
>> > is a way to simply skip duplicates when they occur - so far my attempts
>> > haven't worked!
>> From what I understand in the code, your intent is correct. That empty
>> case for dupicated packets shouldn't be doing nothing (thereby
>> returning 1). Do try to fix it as I suggested, and tell us whether that
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user