Wrong Presentation time at H264 streams [Live555 O

Question

I modify the OpenRtspClient so that

• Now instead of writing frames to file I collect them in a queue with incoming presenttaion times

• Then give the h264 frames to MP4 muxer [ Geraint Davies MP4 mux filter]

• Finally write muxed data to file...

So I can able to save h264 stream into MP4 container...

But the problem is that, some of the recorded data [NOT all of them] has wrong values for time duration:

Suppose that a 10 minute record seems that it was 12 h stream... VLC play the 10 minute that play last frame for the remaing time.

It seems that i set sample times wrong into the Muxer... Then i debug and see that there is positive and negative dramatic jumps at time stamps...

Here is how i set time stamps:

• Firts i take presentationTime from H264VideoFileSink::afterGettingFrame1 function
• Then calculate the firstPresentaionTime [ at the beginning]
• Then collect other timestamps

And I see that frameTimeStamp values show dramatic jumps to negative or positive values...[ i keeep those values as int64 ]

#define TIMEVAL_TO_REFERENCE_TIME(x) 
      ((__int64)(x.tv_sec * 1000000) + x.tv_usec) * 10

void  H264VideoFileSink::
 afterGettingFrame1(unsigned frameSize, struct timeval presentationTime) 
{

    // At the beginning [ just for once calculate firstPresentaionTime ]

    firstPresentaionTime = TIMEVAL_TO_REFERENCE_TIME(presentationTime);

    // for the other frames collect frames timestamps

    frameTimeStamp = TIMEVAL_TO_REFERENCE_TIME(presentationTime) - 
firstPresentationTime

    }

What my cause this?

• Or is it agood idea to use this "presentationTime" for a MP4 Muxer?
• Where the "presentationTime" is calculated at library?
• Is it possible that H264VideoFileSink::afterGettingFrame1 method "presentationTime" values may be wrong?
• Anybody record h264 stream in a mp4 contianer and wanted to share his/her experience?

Answer 1

In partial answer to your question:

• Where the "presentationTime" is calculated at library?
• Is it possible that H264VideoFileSink::afterGettingFrame1 method "presentationTime" values may be wrong?

• the presentation time is based on the RTP timestamp of the sample.
• Unlikely, we have been using live555 for a fairly long period without any timestamp issues. If the timestamps are incorrect, I would suspect that the timestamp is wrong at the RTP source i.e. the RTSP server or camera. It may or may not be helpful to sniff the RTP packets with wireshark to look at the RTP timestamps and then convert back into NTP time from there to see what the difference is between consecutive frames.

Answer 2

If you follow MPEG class of compression - in video, The Presentation time stamp WILL come up and down. This is because if you have I and P frames are encoded prior to their B frame neighbors which depend on forward as well as backward.

For example, frame number 0, 1, 2, 3 - can be I, B, B, P - but when actually they are transmitted it becomes 0, 3, 1, 2 - (I, P, B, B). Obviously the PTS (presentation time stamp) of frame 3 > PTS of frame 1 hence you receive PTS of 1 - it is negative according to your logic.