[MPlayer-users] Bug: av sync, bframes, dwStart issues

[Corey Hickey]

John Stebbins wrote:
> Nico Sabbi wrote:
>> Corey Hickey wrote:
>>> I agree, though, it's not at all ideal. I'm open to suggestions. At the
>>> moment, I don't see how to make mencoder recognize how many frames
>>> decoder output has been delayed (I'm not implying it can't be done--just
>>> that I haven't figured out how).
>>>  
>> the delay may be variable (depending on the number of bframes present),
>> so it should be updated for every frame in the encoding loop

The encoder delay is variable, and is indeed dependent on the number of 
B-frames. mencoder does compensate for encoder delay on-the-fly. Decoder 
delay, however, is what's in question (see below).

> I'm not sure this is true. Somebody please correct me if I'm not getting
> this correct.
> 
> For any number of b-frames, you need one I and one P before you can
> decode and display the first B. The I can be presented right away, but
> the B (which is the next frame to be presented) must wait for the P to
> be decoded.  Each subsequent B no longer waits because the P it depends
> on is already present.

As I understand, you're partially correct, but bear in mind that I'm no 
expert here. If I am wrong in what I write below, someone will point it out.

You're right that the decoder delay depends on the reference "depth", 
not the number of B-frames; however, when a stream has B-frames, the 
presentation of I-frames is delayed as well, so there don't end up being 
gaps in display. When the B-frame "depth" is 1 (e.g. MPEG-4 ASP or h.264 
without b_pyramid), the I-frame is stored and then displayed after the 
following P-frame is decoded, and so on. Loren made some nice diagrams. 
Note how the "decode pts" of the stream is shifted.

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-January/040033.html

> If you enable b-pyramids, you add another frame delay because a B may
> depend on an I, a B, and through transitive operation a P.

Indeed, though I don't know for sure if this works out the same way as 
what I wrote above. Also, as far as I know, b_pyramid can have a "depth" 
greater than 2, though that isn't currently implemented in x264.

-Corey