Hi, On Wed, Nov 21, 2012 at 5:37 AM, Janne Grunau <janne-li...@jannau.net>wrote:
> On 2012-11-21 13:14:34 +0000, Loren Merritt wrote: > > On Wed, 21 Nov 2012, Janne Grunau wrote: > > > On 2012-11-16 18:14:29 -0800, Ronald S. Bultje wrote: > > > > > > > > So I'm going to have to wonder what happens to the delayed frames > already > > > > cached in h->delayed_pics[]? Are they still output? > > > > > > yes, delayed pictures are returned as long as h->delayed_pics[0] is not > > > NULL. > > > > And when you return something from delayed_pics[] instead of the new > > frame that just got decoded, the new frame gets delayed, so that you > > don't ever actually switch to low delay mode? > > Since we can't return multiple frames at once we can't switch to low > delay mode once we have delayed pictures. If low delay after switching > from a stream with delayed pictures to a low_delay stream is important > and dropping frames is an option requiring a decoder flush from sounds > reasonable to me. > That's one option. We could also simply say that low_delay can't be re-enabled once disabled, so even though the SPS says we're low-delay, just ignore it. I don't really have a preference either way, whichever is easier implementation-wise or whichever you feel is a better representation of what the end user of a non-fuzzed bitstream likely wanted to happen. (In practice, this probably never happens anyway?) Ronald
_______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
