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

John Koleszar jkoleszar
Fri Jul 2 21:26:36 CEST 2010


On Wed, Jun 9, 2010 at 8:27 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Jun 09, 2010 at 12:08:59PM -0400, James Zern wrote:
>> On Tue, Jun 8, 2010 at 22:19, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > this looks and sounds wrong
>> > the way divx/xvid packed b frames are handled is much saner
>> >
>> I'll have to have a closer look at that. From what I remember, these
>> were flagged within the container with each frame having a new header
>> to allow the frames to be broken up by the decoder correct?
>
> the primarely relevant part is that it does not have more frames at container
> level than there are output by the decoder.
> having the number of frames input in the decoder differ from the output could
> cause some problems. Similarly for the encoder. Its likely not unsolveable
> if its neccessary but as this is not common it likely would break a few
> applications.
> besides strictly speaking, frames that are not presented to the user have no
> presentation time
>

In hopes of starting to write some code to move this discussion
forward, I think there are two basic issues we've been talking about:
packed ARFs and what to do about the timestamps.

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. If someone does have an idea on how to do so
we can go that route, but the rest of this mail is trying to find out
what an acceptable implementation of invisible frames in ffmpeg looks
like.

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.
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). Otherwise (and by
default, since the default timebase is 1/fr) ARFs are disabled.

Another option would be to reuse the timestamp, or set it to something
like AV_NOPTS_VALUE, and relax the check that forces timestamps to be
strictly increasing.

Probably both of these should be in conjunction with adding a flag to
the packet indicating that the frame is invisible. Another non-vp8 use
case for this flag would be frame-accurate splicing without
reencoding, if that helps frame the design at all. For completeness, a
flag should be added to the muxers that support this feature, and
throw an error if you get a packet you can't handle.

Is one of these a good approach to take? Have a better idea?



More information about the ffmpeg-devel mailing list