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

[John Koleszar]

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:
>> > On Tue, Jun 08, 2010 at 06:44:42PM -0400, James Zern wrote:
>> >> Index: libavcodec/libvpxenc.c
>> >> ===================================================================
>> >> --- libavcodec/libvpxenc.c ? ?(revision 23540)
>> >> +++ libavcodec/libvpxenc.c ? ?(working copy)
>> >> @@ -218,11 +218,21 @@ static av_cold int vp8_init(AVCodecConte
>> >> ? ? ?}
>> >> ? ? ?dump_enc_cfg(avctx, &enccfg);
>> >>
>> >> + ? ?/* With altref set an additional frame at the same pts may be produced.
>> >> + ? ? ? Increasing the time_base gives the library a window to place these frames
>> >> + ? ? ? ensuring strictly increasing timestamps. */
>> >> + ? ?if (avctx->flags2 & CODEC_FLAG2_ALT_REF) {
>> >> + ? ? ? ?avctx->ticks_per_frame = 2;
>> >> + ? ? ? ?avctx->time_base ? ? ? = av_mul_q(avctx->time_base,
>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(AVRational){1, avctx->ticks_per_frame});
>> >> + ? ?}
>> >
>> > 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
>

There needs to be some framing applied to be able to separate the
frames, so I don't see anything wrong with using the container for
that, especially since it has a notion of invisible frames. Using a
different packing would be a topic for webm-discuss. In any case, this
time twiddling belongs in the muxer, IMO. I don't think there's
anything wrong with the encoder producing monotonically increasing
timestamps, but if the container needs them to be strictly increasing,
that's the muxer's problem IMO. I've yet to hear any real explanation
for why we can't just leave them as monotonically increasing in the
container, but I don't know anything about mkv/webm.