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

[John Koleszar]

On Fri, Jul 2, 2010 at 4:20 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.
>

There are a number of ways to actually pack the data, that's not the
issue. It would require every decoder out there to be
rebuilt/reinstalled/etc. For this change to be invisible to users,
you'd have to coordinate all of them, which is impossible, or wait
long enough that it was reasonable to expect everyone had updated, and
then there'd still probably be issues. It's effectively a change to
the bitstream, or at least would have to be managed like one.

>> 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?
>

err... lavc encoders don't know that now, and a number of muxers use
their own, different time bases.. I don't see what you're getting at
here.

>> 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?
>

I never said anything about doubling. Users who wanted to use this
feature aren't likely to know the real frame rate, so they'd probably
end up specifying a timebase of ms/us/ns. The encoder wouldn't change
the time base given in this scheme. If you're transcoding material
that's already in a high precision timebase, you'd be able to use
ARFs, since the frame duration would be >1.

>> 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.

Maybe I'm not parsing this correctly -- you're saying disable ARF for
formats that already are being used for VP8, like webm? and use a
packed format for non-webm? I don't follow the first part, but
defining a packing for non-webm formats seems fine, though it'd have
to get a different fourcc/id, and you'd have to put smarts into a webm
muxer for unpacking the frames before muxing them which is a layering
violation, but maybe worthwhile. None of that solves the issue of what
to do with the pts and/or invisible flag after the frames are unpacked
though.