[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