I believe I might have ran into a design issue for the TimeStamp creation when MPEG1or2VideoStreamFramer is used. Here what I have found. I have checked the RTCP SR packets that are sent when I play a video Mpeg2 ES. I have used the sample application testMPEG1or2VideoStreamer. I have followed the RTP/RTCP packets that are sent when no client has synchronized through a RTSP session. The TimeStamp values computed in the RTCP SR packet have a gap that mismatch the Mpeg2 ES RTP timestamp packet. Here are the value computed by the library fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 sending REPORT fTimestampBase: 0xae0daf0d, tv: 683383.099932, RTP timestamp: 101919 Creating RTCP SR packet, SSRC is 0x6da5, NTP is : tv: 683383.099932, TimeStamp is: 101919 sending RTCP packet 80c80006 00006da5 83b4ebf7 199524c0 00018e1f 000000db 0003c76d 81ca0005 00006da5 010a7377 6f70742d 766f6970 00000000 schedule(1.015347->683384.121916) fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100
Obviously the TimeStamp value of the RTCP SR packet should be between 21097 and 24100. After looking in the code I have found that the first TimeStamp is initialized from the creation of the MPEG1or2VideoStreamFramer object when MPEGVideoStreamFramer::reset() is called. However there is gap between the time the MPEG1or2VideoStreamFramer object is created and the time it take from videoSink->startPlaying(...) to initiate the reading of the file through the ByteStreamFileSource object. This notwithstanding the delay that can be induced between the creation of MPEG1or2VideoStreamFramer and the calling of videoSink->startPlaying(...) and also the time it take for the operating system to open and begin reading the file itself. This will introduce a delay that will offset all TimeStamp of the RTP packets to be sent with the RTCP SR computed timestamp. I believe the timestamp should be created somewhere else. May be when the MPEG1or2VideoRTPSink send the first RTP packet. I have not checked but this problem is likely to occurs in other framer object if they use the same timestamp initialization methodology. Guy Bonneau
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
