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

[Ben Barker]

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:

av_log(s->ic, AV_LOG_WARNING,
               "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
handle.

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
> behaves.
>
> 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
>> take
>> > 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):
>>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=libavformat/rtpdec.c;h=037260596abbfc955f9a919e8be73d20f2d38f1d;hb=HEAD#l246
>>
>> > 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.
>>
>> 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:
>>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=libavformat/rtpdec.c;h=037260596abbfc955f9a919e8be73d20f2d38f1d;hb=HEAD#l625
>>
>> 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
>> 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!
>>
>> 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
>> helps.
>>
>> Cheers,
>> Moritz
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>
>