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 <[email protected]> wrote: > On Wed, Jun 27, 2012 at 5:58 PM, Tim Pitman <[email protected]> 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
