https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4119
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
--- Comment #2 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2009-10-22 13:10:56 PDT ---
Jaap's right, the problem is the RTP timestamps.
Frame 1158's timestamp is 1,268,938,892
Frame 1162's timestamp (the next in that direction) is 2,424,691,517
(the RTP sequence number also jumps up by several thousand.)
As a result of the fact that the RTP timestamps are used, Wireshark is trying
to insert about a billion silence frames.
A simple fix is to limit the number of silence frames to something more
reasonable. I don't know RTP so I don't know what would be considered
reasonable. 100?
Is there a Correct fix?
Another detail: because RTP timestamps are being used, the "exceeded jitter
buffer" check in gtk/rtp_player.c is skipped. But, inside of that check is a
"if there was a silence period of more than 2 packetization periods then
resync". In this case I suspect we /should/ be resync'ing. Should this 'if'
be moved outside the jiffer-buffer 'if'?
One last question (in case anyone knows): in this code (in decode_rtp_stream())
there are 2 places where silence frames are added but the silence audio is only
added in the 2nd case. Is that correct?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
