[Libav-user] h264 decoding delay higher than it could be in a real-time app

[Camera Man]

On 03/11/2012 12:20 PM, Alex Cohn wrote:
> In some cases, simply ignoring B-frames on input can produce video
> frames that will not look terrible. You will see artifacts, but the
> overall visual experience will be better than simply stumbling until
> the next key frame. In some cases, the result of ignoring B-frames
> will be disastrous.
That's not an option for me then; Thanks for saving me countless hours 
of debugging ...
>> 2. Is it safe to just force low_delay=1 in my case?
> Most likely, it is: if the decoder encounters a B-frame in low_delay
> mode, decode_postinit() will fix it for you (see h264.c):
>
>      } else if (s->low_delay&&
>                 ((h->next_outputed_poc != INT_MIN&&  out->poc>
> h->next_outputed_poc + 2) ||
>                  cur->f.pict_type == AV_PICTURE_TYPE_B)) {
>          s->low_delay = 0;
>          s->avctx->has_b_frames++;
>      
Do I understand this correctly - if low_delay is set to 1, but a frame 
arrives out of order - low_delay is simply set to 0, and the delay 
buffer length is increased? (introducing a one-frame pause for each time 
that happens?)

If so, then strategically setting s->low_delay=1, has_b_frames=0, 
num_reorder_frames=0 or modifying the bitstream PPS to have 
num_reorder_frames=0 would always introduce the minimum delay possible, 
and increase that delay as needed -- which is fine for me.

Thanks again for your time and advice!