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

[Ben Barker]

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
>