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

Reimar Döffinger Reimar.Doeffinger
Fri Jul 2 22:20:18 CEST 2010


On Fri, Jul 02, 2010 at 03:26:36PM -0400, John Koleszar wrote:
> Regarding packed vs non-packed ARFs, I don't think there's any way to
> introduce a packed format at the codec level without breaking
> backwards compatibility.

Breaking compatibility to what, in which way?
Support for packed format can be added by just trying to decode once
again if after decoding there's still data left and it was an ARF.
This can be handled completely in libvpx, so no change for anyone using
that.
For any hardware decoder, it should still be a trivial software change
to do the same thing, at least if e.g. the size of the ARF is appended to the
end of the frame.
Also, given that e.g. ARF in AVI does not exist currently, it's hardly
possible to break backward compatibility with it.

> For the question about what to do with the pts, the closest thing to
> the current implementation would be to create a pts between frames if
> the user's time base supports it, and disable the feature otherwise.

And how would a transcoding application figure out the real frame-rate
from this mess when e.g. transcoding to DivX (MPEG-4 in AVI)?
But more importantly, how would the _encoder_ know which time base the
_muxer_ will use?

> So if the user passes in a timebase on the command line, the time is
> calculated in that base either based on a frame rate from the command
> line or the time in the originating container, and ARFs are enabled
> (presuming the user's time base is precise enough).

So with each transcoding from VP8 to VP8 you end up doubling the frame
rate?

> Have a better idea?

Use a packed format for all formats that VP8 with ARF has not been
used with so far, disable ARF for all others.
Perfect backward-compatibility and none of the other strange issues.
Obvious disadvantages I won't have to mention I guess.



More information about the ffmpeg-devel mailing list