The crux of my question concerns the *delta* that a reference implementation (Helix USM) applies to one of the rtptime=X values that is reported in the RTP-Info header. All of our testing (with ~30 different brand/model combinations) has shown that this is critical for many mobile phones to correctly apply A/V sync. The live555 code (the 2008.07.25 release) does not adjust (calculate a delta) the RTP-Info header in this way. It simply reports the seqNum & rtptime of the first packet on each stream. And while you may think that RTSP/RTP/RTCP clients should not use the RTP timestamps, these phones are doing just that. Wouldn't it be nice if we could play nicely with them too? Cheers & thanks for all your hard work and excellent code. ChrisB
Chris Burns M: +64 21 391 286 [EMAIL PROTECTED] <http://www.abdeus.com/> ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Finlayson Sent: Friday, 08 August 2008 12:02 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Calculating rtptime for RTSP/PLAY-Response "RTP-Info" header I'm specifically trying to work out how to create the "RTP-Info" header in a RTSP/PLAY-Response. Our server implementation does this automatically (see "RTSPServer.cpp", and search for "rtpInfo"). You shouldn't have to do anything yourself to generate this. Similarly, at the client end, the information is filled in automatically - if you wish, you can just access the "MediaSubsession::rtpInfo" structure. Most clients, however, will not need to access this structure directly. Instead, if they wish to get the current 'normal play time' (NPT) for the stream, they can just call "MediaSubsession::getNormalPlayTime()", which uses the "rtpInfo" structure. Also (as I have explained several times before), RTSP/RTP/RTCP clients (receivers) should rarely, if ever, need to look at RTP timestamps, sequence numbers, or RTCP packet data. Our receiving code automatically uses this information itself, to give you a properly-synchronized presentation time for each incoming frame of data. -- 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
