[Live-devel] Problem with NTP timestamps in SR packets with Flir A320 camera source

[Matt Schuckmannn]

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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel