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.
