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. No - because the 'NTP' time (683383.099932) that's used for the RTCP SR packet is not between 683382.201906 and 683382.235273. The RTP timestamp of 101919 corresponds to the time 683383.099932. Agree It's perfectly OK for the NTP time that's used in a RTCP "SR" report to differ from the presentation time used in RTP packets that bracket it. Agree However, because the RTCP SR 'NTP' time is computed using "gettimeofday()" (i.e., 'wall clock' time), the presentation times for your media samples (that get passed to RTP) *must* also be aligned with 'wall clock' time. Agree. But this is the problem, as I said the MPEGVideoStreamFramer computes the TimeStamp from the Mpeg2 Stream. There is no mean to bypass or feed the presentation times. The Presentation computing mechanism is internal to the object and follow the Mpeg2 Video Stream. Unless I have missing something but I use the sample application as provided with the library. The timestamp generation code (for both RTP and RTCP) is correct. No it is not. Well I mean the RTP timestamp. The RTCP timestamp is correctly computed. For the following discussion it is important that I add this information. The Mpeg2 Video ES is an I frame only stream. Thus the Timestamp will always increment from frame to frame. When the Timestamp go from 21097 to 24100 then a new Mpeg2 I frame begin. Since the RTCP packet is sent near the end of the I frame with timestamp 21097 but before any packet of I frame with timestamp 24100 has been sent then the RTCP RS timestamp should have been somewhere between timestamp 21097 and 24100 if the RTP timestamp would have been correctly timestamped. Actually the RTCP is timestamped with value 101919 which is greater than 24100 and way off. This is out of the RTP specification to the best of my understanding. If you have the book of Colin Perkins : "RTP Audio and Video for the Internet" then please turn to page 109. This will make it more clear. Of course since the RTP packets are Mpeg2 formatted then the timestamp stay constant until the next I frame. The reason of the discrepancy is the delay introduced by the parsing of the Mpeg2 Video Stream and the reading of the raw data. This will create Timestamps that are offset in the past. However, for it to work correctly, you must feed it correct presentation times. I might not know the library code enough but at first glance it seems I cannot because the mechanism is internal to the MPEG1or2VideoStreamFramer/MpegVideoStreamFramer. Unless I change the source code of the library file. Guy Bonneau -- 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
