Hi,
See bugs 165 and 269 on this. It's as the RFC states: "The use of the
marker bit is profile specific". Currently the RTP analysis is biased
towards audio, so video profiles may suffer.
Thanx,
Jaap
Lars Ruoff wrote:
From my memories:
packets with the marker bit set don't take part in the jitter calculation.
This is because in RTP audio streams marked packets usually mark the end
of silence periods.
The wrong jitter values probably come from the fact that there is no (or
at least not the right) sampling clock rate defined for the used payload
type.
Both issues would be worth revisiting.
Lars
------------------------------------------------------------------------
*From:* wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] *On Behalf Of *Shuaib
Siddiqui
*Sent:* vendredi 6 juillet 2007 16:27
*To:* wireshark-users@xxxxxxxxxxxxx
*Subject:* [Wireshark-users] RTP Stream Analyses [Marker Bit]
Hi,
I streaming videos using VLC on the client side and Darwin Streaming
Server on server side. When I analyse the rtp stream on the client side
using Wireshark, I see some RTP with marker bit set and immediately
after such RTP packet the jitter value is very high as compared to the
previous one, plus it also displays Incorrect Timestamp. I looked up the
marker bit in the RFC 1889 but they just state it as profile specific.
Kindly, can anyone provide any further explanation? Plus does the
abnormality in the jitter value means the jitter values further on are
not credible ?
Thank you for yout time!
Shuaib
--
