[FFmpeg-devel] [PATCH] libvpx: alt reference frame / lag

[Reimar Döffinger]

On Wed, Jun 16, 2010 at 11:06:27AM -0400, John Koleszar wrote:
> Consider a packing that required you put a b-frame into the same
> packet as a p-frame. Every disadvantage I can think of for such a
> system applies to putting ARFs into the same packet as another frame.
> You'd need non-trivial queuing on the encoder, which introduces
> latency. You'd need asynchronous or partial decoding on the decoder,
> which may or may not have an unusual API, or have to accept additional
> latency/jitter. Applications that did want to get at the frames
> individually would need to duplicate the sort of parsing that's
> usually done by a demuxer.

What are you talking about? A P-frame is always displayed,
a ARF is never displayed (there is no reason to even call it a frame),
thus _not a single_ of the problems of packed B-frame applies.
Yes, having the ARF separate means you have a chance of cannibalizing
from the decoding time of the previous frame, however for the worst
case the existence of ARF means your decoder must be able to handle
twice the frame rate and twice the bitrate of a stream without.
No amount of regrouping the data is going to change that (as said,
for the worst case).

> A packet stream is a clean abstraction that everybody
> understands, the only twist here is that not all packets are
> displayed.

That argument works just as well for claiming that e.g. for JPEG
the SOI, EOI etc. should each be in a separate packet.
Or that for H.264 each slice should go into its own packet, after
all someone might want to decode only the middle slice for some
reason.