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:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of *Shuaib > Siddiqui > *Sent:* vendredi 6 juillet 2007 16:27 > *To:* wireshark-users@wireshark.org > *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 > -- _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
