[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