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 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). I believe it is using this
because the camera is on a closed network with no SNTP time server to
correct it. This is kind of sad because the camera does have it's own
clock that stays correct between power cycles that would be much better
to use in the absence of a SNTP time server.
I don't know if this points to a bug in the SR handling code in
LiveMedia. In RTPReceptionStats::noteIncomingSR() 0x83AA7E80 is always
subtracted from theNTP seconds value and this caused the reported
presentation time value to wrap around and report something way out in
the future (around 2038).
I really don't know if there is anything better that you could do here,
probably not.
Thanks for listening,
Matt S.
Matt Schuckmannn wrote:
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.
In tracking this down I believe that the Flir camera is at fault here
and I've contacted there tech support. What I think is happening is
the Flir camera is reverseing the seconds and microseconds values in
the NTP time stamp field of the SR packet (i.e. it is placing the
seconds value in the LSW and the microseconds in the MSW. Below is a
SR packet from the camera (as reported by the LiveMedia library)
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.
Here is the first RTCP packet I see from the Flir camera, after
LiveMedia receives this packet the presentation times become very very
wrong.
80c806 18b8cc55 018f60 0000 1b4e8250 00190 03e80 81ca09 18b8cc55
1e6361 6d657261 40302e30 2e302e30 2067 52545020 312e300 0000
Assuming that I'm correct and that Flir is unwilling to correct their
code can you make any suggestions on how I could work around this in
my code?
Thank you,
Matt Schuckmann
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
