[Libav-user] Segfault on corrupted video

[Tim Pitman]

Interesting. However, I'm using x264 with --intra-refresh and --tune
zerolatency (no b frames).

On Wed, Jun 27, 2012 at 5:13 PM, Michael Bradshaw
<mbradshaw at sorensonmedia.com> wrote:
> On Wed, Jun 27, 2012 at 5:58 PM, Tim Pitman <tapitman11 at gmail.com> wrote:
>> Alrighty,
>>
>> I was relying on the return value from avcodec_decode_video2.
>> Basically I assumed that if it was > 0 then the picture was valid.
>> However, I was curious about what got_picture was for so if changed:
>>
>> if (ret > 0)
>>
>> to
>>
>> if (ret > 0 && got_picture)
>>
>> It no longer crashes, but instead seems to freeze for a few seconds,
>> which is definitely a big step in the right direction.
>>
>> What is the difference between the return value and got_picture?
>
> Some codecs require you to decode several frames before you can start
> getting usable pictures. For example, if you look at
> http://en.wikipedia.org/wiki/Video_compression_picture_types you will
> see that in the sample picture the frame sequence goes I-P-B-I. You
> won't get a usable picture from the B-frame until you decode the last
> I-frame, so in this example that B-frame would ret > 0 (because it was
> successful) but got_picture == 0 (because it's buffering the picture
> and has to wait for the next frame before you can get a usable frame
> out).
>
> This is also why you have to flush some codecs. Look at what the docs
> say about avcodec_decode_video2 for codecs that have CODEC_CAP_DELAY
> capability set.
>
> That "freeze" for a few seconds is your app just decoding the first
> several frames until it finally has enough information decoded that
> you start getting usable frames out.
>
> --Michael
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user