[Live-devel] wrong timestamping for MPEG-4 ES

Bernhard Feiten Bernhard at Feiten.de
Mon Oct 31 16:39:36 PST 2005


Dear Ross,

thank you for your quick answer.
I tried, what you proposed and activated the DEBUG.
I get a very rich print out. This is surely helpful, but it is very 
difficult for me to inteprete quickly.

I got aware of the mistake when I added a print out in the function:
  void MPEGVideoStreamFramer::computePresentationTime
just before the presentation time is calculated. The print out looks like.

...
tcSecs 35 pictureTime 0.600000
tcSecs 35 pictureTime 0.666667
tcSecs 35 pictureTime 0.733333
tcSecs 35 pictureTime 0.800000
tcSecs 35 pictureTime 0.866667
tcSecs 35 pictureTime 0.933333
tcSecs 35 pictureTime 0.933333
tcSecs 35 pictureTime 0.933333
tcSecs 35 pictureTime 0.933333
tcSecs 35 pictureTime 0.933333

tcSecs 36 pictureTime 1.000000
tcSecs 36 pictureTime 1.066667
tcSecs 36 pictureTime 1.133333
tcSecs 36 pictureTime 1.200000
tcSecs 36 pictureTime 1.266667
tcSecs 36 pictureTime 1.333333
tcSecs 36 pictureTime 1.400000
tcSecs 36 pictureTime 1.466667
tcSecs 36 pictureTime 1.533333
tcSecs 36 pictureTime 1.600000
tcSecs 36 pictureTime 1.666667
tcSecs 36 pictureTime 1.733333
tcSecs 36 pictureTime 1.733333
tcSecs 36 pictureTime 1.733333
tcSecs 36 pictureTime 1.733333
tcSecs 36 pictureTime 1.733333

tcSecs 36 pictureTime 0.800000
tcSecs 36 pictureTime 0.866667
tcSecs 36 pictureTime 0.933333
tcSecs 36 pictureTime 1.000000
tcSecs 36 pictureTime 1.066667
tcSecs 36 pictureTime 1.133333
tcSecs 36 pictureTime 1.200000
tcSecs 36 pictureTime 1.266667
...

I inserted two blank lines to draw your attention to one situation where 
first the presentation time jumps foward more than one second .
The line shows a part where it jumps back nearly a second.

Would that be an expected behaviour ?

You wrote:
> Note that - if the video contains "B" frames, then the frames' 
> presentation times - and thus the RTP timestamps - will not be increasing 
> monotonically.  This is expected.
I thought RTP time stamps have always to increase -- per definition  ???

Best regards,
Bernhard



----- Original Message ----- 
From: "Ross Finlayson" <finlayson at live555.com>
To: "LIVE555 Streaming Media - development & use" 
<live-devel at ns.live555.com>
Sent: Monday, October 31, 2005 3:53 PM
Subject: Re: [Live-devel] wrong timestamping for MPEG-4 ES


>
>>for a MPEG-4 video stream, generated with ffmpeg,  we found out that the 
>>timestamps were not generated always correcctly. The timestamps are not 
>>increasing monoton.
>
> Note that - if the video contains "B" frames, then the frames' 
> presentation times - and thus the RTP timestamps - will not be increasing 
> monotonically.  This is expected.
>
>>Without having fully understood the parsing of the MPEG-4 stream, I found 
>>out that the problem disappeares when the variable fPrevNewTotalTicks is 
>>reseted when a new time code is parsed from the file. (see code below)
>
> The "fPrevNewTotalTicks" variable is intended to detect (and, ideally 
> correct for) certain types of buggy MPEG-4 video streams.  Perhaps your 
> stream is buggy in this way??  You can detect this by adding
>         #define DEBUG 1
> to the start of "MPEG4VideoStreamFramer.cpp", and recompiling (after 
> reverting the change that you made).
>
> If the debugging error messages don't help you, then please place a copy 
> of your MPEG-4 Elementary Stream video online, and send us the URL, so we 
> can take a look at it.
>
>
> Ross Finlayson
> Live Networks, Inc. (LIVE555.COM)
> <http://www.live555.com/>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel 



More information about the live-devel mailing list