[MPlayer-dev-eng] [PATCH] mencoder, B-frames, and video/audio delay

[Corey Hickey]

Loren Merritt wrote:
>>But first, let me digress to x264. My tentative understanding of the way
>>x264 handles decoding delay is to put it into a header*. Loren pointed
>>me to x264/encoder/set.c:187
>>
>>sps->vui.i_num_reorder_frames = param->b_bframe_pyramid ? 2 :
>>param->i_bframe ? 1 : 0;
>>
>>So, it looks like I don't have to worry about the decoder delay for
>>x264. Like I said, though, that's only a tentative understanding on my
>>part. This is the first time I've ever looked at x264 source.
>>
>>Anyway, does MPEG-4 have any kind of similar facility for putting
>>anticipated decoding delay into a header? If not, then adjusting the
>>muxer stream timer seems like the only reasonable recourse.
> 
> 
> It's always eithyer 0 or 1, specified by s->low_delay

Ah, but of course.

So, if it's supposed to be up to the player to compensate for the
one-frame delay when s->low_delay isn't set, does that mean that it's
incorrect for libavcodec to be adding the one-frame delay? Should this
line (and others like it) in mpegvideo.c:

  avctx->delay= s->low_delay ? 0 : (s->max_b_frames + 1);

...be changed to:

  avctx->delay= s->max_b_frames;

...?

>>* I can see that it's an SPS, but despite lots of googling I can't find
>>what an SPS is. Can someone give me a quick definition?
> 
> 
> SPS is "the header containing stream-global settings".
> As opposed to PPS, which is "the other header containing more 
> stream-global settings" :)

Hah. :)

> The difference is supposed to be that SPS contains info about the decoded 
> stream (resolution, colorspace, interlacing, delay, etc), whereas PPS 
> contains info that only the codec needs to know (quant matrices, cabac, 
> weighted prediction, etc). But the segregation isn't perfect.

Thank you.

-Corey