[Libav-user] avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet) why most of the time frameFinished is zero ?

[Joshua Kordani]

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!

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140527/140f5d1c/attachment.html>