[Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer

[Guy Bonneau]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/7b450fd0/attachment.html