[Live-devel] Question about FileSink and presentation time

[Ross Finlayson]

>I'm trying to implement sort of video recorder by receiving a MP4 
>RTP stream (tanks to MPEG4ESVideoRTPSource class) and feeding a 
>FileSink with the corresponding frames. I'm not using openRTSP to do 
>that (basically because my RTP stream comes from a sip phone). When 
>I try to replay the recorded stream with testOnDemandRTSPServer 
>program, the clip I get run faster than what I recorded. So, If I 
>record 30 seconds, the 30 seconds are played within 10 seconds 
>approximatively.
>I suspect a timestamp problem in the RTP packets sent by 
>testOnDemandRTSPServer (via MPEG4ESVideoRTPSink).

No, I doubt that this is a RTP timestamp related problem.  More 
likely, the problem is that there is a problem with the MPEG 
timestamp information embedded within your MPEG-4 video data. 
("MPEG4VideoStreamFramer" - via "MPEG4VideoStreamParser" - parses 
this information in order to figure out the fPresentationTime, and 
fDurationInMicroseconds, for each MPEG-4 video frame.  See 
"MPEGVideoStreamFramer.cpp".)

>The frame rate is supposed to be 10fps but I think there is some 
>variable frame rate that might be the problem. For example, I see 
>that the first VOP received from my SIP phone (during recording 
>phase) is fragmented in several packets and is followed 1 second 
>later by the second VOP with a timestamp difference equivalent to 1 
>second. This would correspond to 10 frames in a constant frame rate. 
>When I play the file back, the second VOP is sent with a timestamp 
>difference corresponding to 1OO ms (as with a normal frame rate of 
>10), which IMO is the problem.
>Do you think MPEG4VideoStreamFramer object is able to compute 
>presentation times and frame durations correctly from the 
>ByteStreamFileSource in this case ?

I don't know.  I suggest reviewing the code for 
"MPEG4VideoStreamParser::parseVideoObjectPlane()" (in 
"MPEG4VideoStreamFramer.cpp").  Note that this code already contains 
some special cases to handle some kinds of buggy MPEG-4 video 
streams.  Perhaps your stream is yet another type of buggy MPEG-4 
video stream, or perhaps there's something else in your stream that's 
tripping up this code?
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/