On 2012-11-21 09:13:27 -0800, Ronald S. Bultje wrote: > On Wed, Nov 21, 2012 at 5:37 AM, Janne Grunau <[email protected]>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. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
