<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#CCCCCC">

    On 5/27/14 11:28 AM, wm4 wrote:

    <blockquote cite="mid:20140527211627.255f66b7@debian" type="cite">

      <blockquote type="cite">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.</blockquote>

    </blockquote>

    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.<br>

    <br>

    I'll investigate the class members you mentioned.<br>

    <blockquote cite="mid:20140527211627.255f66b7@debian" type="cite">

      <blockquote type="cite">

      </blockquote>

      <pre wrap="">

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.)

</pre>

    </blockquote>

    This is also good to keep in mind, thank you!<br>

    <br>

    Josh<br>

  </body>

</html>