[Live-devel] Presentation time when streaming video recordingfrom surveillance cameras

[Michael S. Juul]

Hi Ross

 

I have attached a screen dump from WireShark showing you the RTSP protocol exchange between our client and the server (camera).

The "DESCRIBE", "SETUP" and "PLAY" commands are packet no. 153, 173 and 186.

 

Venlig hilsen / Best regards

Michael S. Juul

B.SC.E.E

mj at unitek.dk <mailto:mj at unitek.dk> 

 

Unitek A/S

Vævervej 5

8800 Viborg

Tlf.: +45 86 61 44 22

mail at unitek.dk <mailto:mail at unitek.dk> 

www.unitek.dk <http://www.unitek.dk/> 

 

 

 

 

Fra: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] På vegne af Ross Finlayson
Sendt: 11. september 2013 10:54
Til: LIVE555 Streaming Media - development & use
Emne: Re: [Live-devel] Presentation time when streaming video recordingfrom surveillance cameras

 

	We use the RTSPClient from Live555 to access live video and video recordings from surveillance cameras, utilizing the cameras built-in RTSP server and recording storage (An SD card).

	We have a problem regarding the presentation time when streaming video recordings.

	Let's say we have a video recording from "last week" which we would like to stream. We start the stream; we can even start the stream from a specific time in the video recording, so that's swell.

	BUT, the presentation time we receive is "now", not "last week".

 

You're misunderstanding the purpose of "presentation time".  The "presentation time" is a timestamp - generated by the server and conveyed to the client for each RTP packet - that tells the client the relative spacing of successive frames of the same media type, and also - if both audio and video substreams are present - allows the client to synchronize the audio and video (i.e., 'lip sync').  The absolute value of the presentation times is undefined and irrelevant.  (It is often the 'current' time, but doesn't have to be.  E.g., if the server's clock happens to be set to 1990, then the presentation times will be from then.)

 

What you want is something like the "normal play time" (NPT), but (as you discovered) we don't compute that when the client is seeking by absolute time, which I think is what you're doing.

 

But I think some sort of solution should be possible.  To be sure, please give us an example of a RTSP protocol exchange between your client and the server, when you're asking to stream from some time in the past - i.e., the "DESCRIBE", "SETUP", and "PLAY" commands, and their responses.

 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130912/059c649e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WireSharp_dump.png
Type: image/png
Size: 196249 bytes
Desc: WireSharp_dump.png
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130912/059c649e/attachment-0001.png>