[Live-devel] B-Frame

Ross Finlayson finlayson at live.com
Tue Mar 15 11:26:09 PST 2005


>1-When I set the fPresentationTime variable is better to use the
>timestamp of the frame or the actual time?

"fPresentationTime" should be the 'presentation time' of the frame (i.e., 
representing the (relative) time that the frame should be displayed on the 
screen of the receiver).

>2-If I encode the stream as simple profile (in particular with no
>B-Frame) it works but if I try to use an advanced simple profile (using
>B-frame) the result, when I try to play it, is a video with a strange
>behaviour: like if it receives the frames in the wrong order.

I suspect that this is related to the "fPresentationTime" issue.

When you are generating B-frames, the the sequence of "fPresentationTime"s 
- for each frame - that are passed to the "RTPSink" object (for streaming) 
should *not* be monotonically increasing.  This is because frames are 
generated by the encoder in 'decoding order', which - for B-frames - is not 
the same as display order.

There are two possible ways to do this:
1/ Make sure that your encoder uses actual presentation timestamps when 
setting "fPresentationTime" (so that the resulting sequence of 
"fPresentationTime"s - when B-Frames are used - will *not* be monotonically 
increasing).
*or*
2/ Have the "fPresentationTime" generated by your encoder be the wall-clock 
time (i.e., generated by calling "gettimeofday()") at the time that the 
frame entered the encoder.  But then, before passing the frame to a 
"RTPSink" (for streaming), pass it through a 
"MPEG1or2VideoStreamDiscreteFramer" object (or, for MPEG-4, a 
"MPEG4VideoStreamDiscreteFramer" object).  This will cause the 
"fPresentationTime" of B-frames to be adjusted properly (so that the 
sequence of "fPresentationTimes" is no longer monotonically increasing when 
they reach the "RTPSink").


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>



More information about the live-devel mailing list