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

[Guy Bonneau]

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/d2fb3d6a/attachment-0001.html