The problem is the camera is using the time since the camera was
last rebooted for the NTP time values in the SR reports (which in my
case was about 30 hours and now is about 10 min).
This is legal (although unusual). The NTP timestamps don't have to
actually be set to the 'true' time using t
Ok it's been a long day, I now get it.
For anybody else using this camera here is what is happening.
The NTP seconds and microseconds values are not reversed they are fine
and if I'd have looked at more than one SR packet in sequence I'd have
seen that from the beginning.
The problem is the ca
I just wanted to verify if I'm correct or see if anybody else has
experienced this problem or if there might have been any recent
fixes to the SR receiving code of liveMedia that I might be missing.
No. The RTCP reception/presentation-time-setting code has not
changed in months (years?), and
I'm using the livemedia library to receive a MPEG4 stream from a Flir
Thermocam A320 infrared camera.
The problem I'm seeing is the presentation times coming from the
afterGettingFrame callback start out reasonable then jump way ahead to
sometime around 2038 after the first SR packet is received
