Wireshark-bugs: [Wireshark-bugs] [Bug 7935] Wrong Timestamps in RTP Player-Decode
Date: Tue, 30 Oct 2012 17:28:23 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7935

--- Comment #2 from Bertrand <bfaust@xxxxxxxxxx> 2012-10-30 17:28:22 PDT ---
(In reply to comment #1)
> I see that 176ms jitter buffer is enough for Bertrand's stream. Maybe it is
> related by for example frame 49, where is about 151ms packet time difference
> from previous one (48).
> 
> I notice similar issue that is related to this one. Please see
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7893
> 
> When RTP Timestamps are equals (for example 0) then stream cannot be decoded
> correctly, but RTP specification says:
> "Several consecutive RTP packets may have equal timestamps if
>    they are (logically) generated at once, e.g., belong to the same
>    video frame." 
> 
> It's work for my phone, but I do not believe that 3 minutes music is generated
> "at once". I guess there is a need to fix jitter buffer (etc.) to support case
> like that (use packet time and sample duration for generate silent to play
> stream as it heard by user)
> 
> Link: http://tools.ietf.org/html/rfc1889#section-5.1

Looking at the RTP Player code it looks like Wrong Timestamps is incremented
when the difference between 2 successive timestamps is not consistent (in
samples) with the number of decoded bytes/2 in the former of the 2 timestamps.
I guess the decoded bytes/2 is due to the G711 decoding creating 2 bytes per
sample?
I still don't think this happens with this particular set of data?

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.