> I’m using Live555 to replace an old streaming stack in a video / audio > recording system. One of the requirements of this system is that any > client playing back the media should be able to display the original time > at which the video / audio was recorded. In the previous system this > was supported by storing the original NTP timestamps from when the > video was recorded and reusing them in the RTCP packets when streaming.
This was a misuse of these timestamps. They are intended only to help generate accurate presentation times (at receivers) that receivers can use to synchronize audio and video tracks (i.e., 'lip sync'). Although they are referred to as 'NTP timestamps' in the RTP/RTCP specification, there is no requirement or guarantee that they actually be generated by NTP; instead, they merely correspond to what the sender's server thinks is the presentation time of each frame, using its own clock (which could have been set to any time). So, when (the client part of) your system was recording a stream, there was never any guarantee that the 'NTP timestamps' (or the presentation times that are derived from them) were 'correct' (apart from being accurate for a/v syncing); they merely reflect what the stream's server's clock happened to have been set at. (And also, as you discovered, if (the server part of) your system wants to use our code, it cannot set its presentation times (nor the 'NTP timestamps') to arbitrary values; instead, it has to generate presentation times that are aligned with 'wall clock' time - i.e., values that you'd get by calling "gettimeofday()".) Instead, a much better way to convey 'recording time' - and other non-real-time attributes of the stream (such as title, author, etc.) is to use an appropriate mechanism for conveying these attributes. There are two possible ways to do this: 1/ Use the "i=" line in the SDP description to encode these attribute(s) (however you want). In your server, when you're creating a "ServerMediaSession" object, create a string that encodes these attribute(s), and pass it as the "info" parameter to "ServerMediaSession::createNew()". Then, this string will be set as the "i=" line that clients will see - in the SDP description - when they do a RTSP "DESCRIBE" command. (If these clients happen to be implemented using our code, then they can get this string by calling "MediaSession::sessionDescription()".) 2/ Have your server implement the RTSP "GET_PARAMETER" command - using an appropriate parameter name - to return these attribute(s). To do this, subclass both "RTSPServer" and "RTSPServer::RTSPClientSession", and reimplement "RTSPServer::RTSPClientSession::handleCmd_GET_PARAMETER()". Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
