[x264-devel] Re: Influence delay B-Frames on playout
Loren Merritt
lorenm at u.washington.edu
Wed Jan 4 20:26:26 CET 2006
On Wed, 4 Jan 2006, Davy De Winter wrote:
> we've written a streamer using the x264-codec as encoder and ffmpeg as
> decoder. We wanted to test the influence on the playout-delay of the
> different parameters on encoder-side. We measured delay by continuously
> synchronizing the encoder & decoder (so the drift from our local NTP-server
> is below 1 ms). We took 2 timestamps: before grabbing the input-frame (from a
> framegrabber) and just after displaying the frame at the client. By
> subtracting these 2 values, we got in a 4 minute-sample (6000 frames) the
> following average values:
> 0-bframes: 86.6 ms
> 1-bframe: 136 ms
> 2-bframe: 181 ms
> As can be seen, the average delay is always augmented by more or less the
> time of capturing one extra frame. However, 1 expected when using b-frames,
> the delay would augment by num_of_bframes * frame_readtime. Thus in the
> case of 1 b-frame: 80 ms extra delay instead of only 40 ms.
You saw (num_of_bframes * frame_readtime), I would expect
((num_of_bframes+1) * frame_readtime). Which, yes, is +80ms for the 1st
B-frame.
> As the encoder sends
> out the frames in playout-order and not (as I expected) in encoding-order
> when using b-frames, I wonder how the decoder "knows" how to decode a B-frame
> if het didn't receive the (future) P-or I-frame the B-frame encoder depends
> on. Or is this information included in the parameter-sets?
x264 returns frames in encoding order, and ffmpeg requires that the frames
be recieved in encoding order.
--Loren Merritt
--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html
More information about the x264-devel
mailing list