Unfortunately it's not something you can define or
fix.
It has to be fixed by the developers.
Lars
Hi,
Looks like i didnt get the messages ... sorry about that.
@ Lars:
"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." I didnt understand what you
mean, who and where we have to define the
sampling clock rate or how can we fix this ?
thanks!
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
On 7/12/07, Lars
Ruoff <lars.ruoff@xxxxxxxxxxxxxxxxx>
wrote:
There were
some responses to your mail!
Lars
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
PS: I have asked this question before but didnt get any explanation,
so I would kindly request all the users and the Wireshark Gurus to give
some insight into this problem, thank
you!
--
MSc in Communication Systems
I&C
Faculty
EPFL
Switzerland
Home page:
http://shuaibe.googlepages.com/