Hi, On Wed, Nov 21, 2012 at 12:29 PM, Janne Grunau <janne-li...@jannau.net>wrote:
> On 2012-11-21 09:13:27 -0800, Ronald S. Bultje wrote: > > 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?) > > The current patch seems to work fine and fate-h264 still passes so this > approach is easier for me. I also think that not dropping frames is > less surprising option. Expecting tests of sender and receiver in > situations where low delay is important is not unreasonable. I can add a > warning when low_delay gets enabled with delayed frames. Well, what I meant is that we probably shouldn't reset s->avctx->has_b_frames and s->low_delay, since that may give the (incorrect) assumption to the application that there is no delay... A warning would be good, yes. Ronald
_______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
