[Wireshark-bugs] [Bug 7935] Wrong Timestamps in RTP Player-Decode
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7935 Christopher Maynard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Christopher Maynard --- (In reply to Christopher Maynard from comment #3) > Can someone confirm whether this bug still exists with the latest supported > version of Wireshark and the Qt UI? Because Wireshark 1.8.2 is no longer > supported and neither is the GTK+ UI. With no confirmation, I can only assume that the bug still exists with the GTK+ UI but since that UI is no longer supported, I'm closing the bug as "WONTFIX". If the bug can be reproduced with the latest stable version of Wireshark and the Qt UI, then feel free to reopen the bug and update the relevant information. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 7935] Wrong Timestamps in RTP Player-Decode
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7935 --- Comment #3 from Christopher Maynard --- (In reply to Bertrand from comment #2) > 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? Can someone confirm whether this bug still exists with the latest supported version of Wireshark and the Qt UI? Because Wireshark 1.8.2 is no longer supported and neither is the GTK+ UI. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 7935] Wrong Timestamps in RTP Player-Decode
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7935 Michal Labedzki michal.labed...@tieto.com changed: What|Removed |Added CC||michal.labed...@tieto.com --- Comment #1 from Michal Labedzki michal.labed...@tieto.com 2012-10-29 23:45:14 PDT --- 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 -- Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Sent via:Wireshark-bugs mailing list wireshark-bugs@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 7935] Wrong Timestamps in RTP Player-Decode
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7935 --- Comment #2 from Bertrand bfa...@eircom.net 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. ___ Sent via:Wireshark-bugs mailing list wireshark-bugs@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
