I was looking at the RR reports sent by quick time player (version 7, 6 & 5) and noticed that the DLSR (Delay since last Sender Report) values that are getting reported to HelixServer by the player were very very huge. According to RFC 1889, DLSR (delay since last SR report) should be in the units
of 1/65536 seconds. But the value sent by quick time player is unusually high
which definitely doesn not seem to be the expected value.
Here is a sample debug output that I printed on my Helix Server:
"Now" is the middle 32 bits of RR report
arrival time (NTP) at the server.
"LSR" is the middle 32 bits of the NTP time that server sent in the last SR
report and that is reported back by client in RR.
"diff" is the difference between "Now" and "LSR".
"DLSR" is the value sent by client in RR in DLSR field.
As you can see, DLSR is a very huge value and ideally it should never be more than
"diff" above.
Can you please let me know if this is a know problem or a bug. Also, if you can let me know the algorithm that is being used at the player to arrive at this value, it would help us adding a work around to properly interpret this value.
If this is not the correct mailing list that I should be sending this query to, please let me now the appropriate alias.
Thanks In Advance.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Streaming-server-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/streaming-server-dev/email@hidden
This email sent to email@hidden
