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