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
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
