[Libav-user] avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet) why most of the time frameFinished is zero ?
jkordani at lsa2.com
Tue May 27 23:29:58 CEST 2014
On 5/27/14 11:28 AM, wm4 wrote:
>> Probably. Especially if you use threads, the delay (in number of
>> frames) will rise. Also have a look at AVCodecContex.has_b_frames and
>> max_b_frames. This _should_ be the inherent delay used by the
>> decoder. In this context, it might also be important to explain why
>> this happens: the use of B-frames means that decoding of frames can
>> depend on the decoding of _future_ frames, so a future frame is
>> decoded first, and only then an "earlier" frame is decoded. This
>> means that even if the decoder decodes this future frame, it can't
>> return it to the user yet - because the user expects frames in
>> display order. So the frame is buffered internally, and no output is
>> returned yet.
Thank you for your response. It makes sense that this behavior would be
the case since the encoder has to handle b frames coming in, I was
wondering if the encoder returned a frame as soon as it knew that the
frame it has is supposed to be the next frame in display order,
especially if I know I am not sending b frames in the first place.
I'll investigate the class members you mentioned.
> I'm not really sure. "packet" corresponds to libavcodec's understand of
> a packet. I'm pretty sure you must not pass more than 1 frame worth of
> data to the decoder, though. The API can't handle that. (Imagine you'd
> feed 2 frames on each avcodec_decode_video2 call - the decoder can
> return only 1 frame, so frames would accumulate internally. Obviously
> this can't happen, and I assume the call will either return how much
> data was decoded, similar to audio decoding - or just drop the data.)
This is also good to keep in mind, thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user