[Libav-user] delayed_pic crash

[Ratin]

Can anybody tell me the answer to couple of questions regarding h.264
delayed pic buffer for non B frame case:

In non B frame case, what exactly causes a frame to be put in
delayed_pic buffer? Based on the code it seems its the out-of-order in
packet order but how is this determined? How is it corrected (the
buffer is put back for re-use once its filled)?

I see a a lot of code of this sort;

    pics = 0;
    while(h->delayed_pic[pics]) pics++;
    assert(pics <= MAX_DELAYED_PIC_COUNT);
    h->delayed_pic[pics++] = cur;

or:
for(i=out_idx; h->delayed_pic[i]; i++)
   h->delayed_pic[i] = h->delayed_pic[i+1];

But where do  h->delayed_pic[i]  becomes null again to be reused?

The only place I see that happening is in flush_dpb which is called
when seek is called.

Thanks

Ratin


On Wed, Aug 24, 2011 at 6:34 PM, Ratin <ratin3 at gmail.com> wrote:
> Found a crash bug while streaming  from a high latency camera with
> delayed_pic loop in avcodec/h264.c file, the GDB trace below:
>
> Please see below:
>
> cur frame T.S: 1314127402073417, nextFrameInfo.pts: 1314127402095435,
> Diff to next frame:  22018, last frame pts: 1314127402368732 (diff
> from last: 295315)
>
> : decode_postinit : h->delayed_pic[pics]: 9c7fd0
>
> : decode_postinit : h->delayed_pic[pics]: 9c6d70
>
> : decode_postinit : h->delayed_pic[pics]: 9c82e0
>
> : decode_postinit : h->delayed_pic[pics]: 9c6440
>
> : decode_postinit : h->delayed_pic[pics]: 9c8f20
>
> : decode_postinit : h->delayed_pic[pics]: 9c7390
>
> : decode_postinit : h->delayed_pic[pics]: 9c5e20
>
> : decode_postinit : h->delayed_pic[pics]: 9c5b10
>
> : decode_postinit : h->delayed_pic[pics]: 9c6a60
>
> : decode_postinit : h->delayed_pic[pics]: 9c79b0
>
> : decode_postinit : h->delayed_pic[pics]: 9c6750
>
> : decode_postinit : h->delayed_pic[pics]: 9c8c10
>
> : decode_postinit : h->delayed_pic[pics]: 9c7080
>
> : decode_postinit : h->delayed_pic[pics]: 9c76a0
>
> : decode_postinit : h->delayed_pic[pics]: 9c5800
>
> : decode_postinit : h->delayed_pic[pics]: 9c7cc0
>
> : decode_postinit : h->delayed_pic[pics]: 9c8900
>
> : decode_postinit : h->delayed_pic[pics]: 9c85f0
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fff7481a910 (LWP 27651)]
> 0x00007ffff0880a7d in decode_postinit (h=0x7fffb1eb3040,
> setup_finished=1) at h264.c:1422
> 1422        for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame
> && !h->delayed_pic[i]->mmco_reset; i++)
> Current language:  auto
> The current source language is "auto; currently c".
>
> (gdb)  bt
> #0  0x00007ffff0880a7d in decode_postinit (h=0x7fffb1eb3040,
> setup_finished=1) at h264.c:1422
> #1  0x00007ffff088cb0c in decode_nal_units (h=0x7fffb1eb3040,
> buf=0x7fffb32c2aab "", buf_size=29004) at h264.c:3739
> #2  0x00007ffff088d423 in decode_frame (avctx=0x7fffd807b580,
> data=0x7fffd807c280, data_size=0x7fff74819bd4, avpkt=0x7fff74819b30)
> at h264.c:3921
> #3  0x00007ffff0a2960c in avcodec_decode_video2 (avctx=0x7fffd807b580,
> picture=0x7fffd807c280, got_picture_ptr=0x7fff74819bd4,
> avpkt=0x7fff74819b30) at libavcodec/utils.c:747
> ..
> (gdb) list
> 1417        if(cur->reference == 0)
> 1418            cur->reference = DELAYED_PIC_REF;
> 1419
> 1420        out = h->delayed_pic[0];
> 1421        out_idx = 0;
> 1422        for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame
> && !h->delayed_pic[i]->mmco_reset; i++)
> 1423            if(h->delayed_pic[i]->poc < out->poc){
> 1424                out = h->delayed_pic[i];
> 1425                out_idx = i;
> 1426            }
> (gdb) p i
> $1 = 19
> (gdb) p h->delayed_pic
> $2 = {0x9c7fd0, 0x9c6d70, 0x9c82e0, 0x9c6440, 0x9c8f20, 0x9c7390,
> 0x9c5e20, 0x9c5b10, 0x9c6a60, 0x9c79b0, 0x9c6750, 0x9c8c10, 0x9c7080,
> 0x9c76a0, 0x9c5800, 0x9c7cc0, 0x9c8900, 0x9c85f0}
>
>  i is never supposed to be more than 17 ..
>
> has anybody experience this?
>