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

[Michael Niedermayer]

On Thu, Jun 10, 2010 at 09:49:21AM -0400, John Koleszar wrote:
> 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.

the problem isnt mkv the problem are many other containers. If you
dont want to support them, it might be a matter of disabling the
strict monotonicity check and making tripple sure that every single
frame has a timestamp, that is the player doesnt end up producing
timestamps based on last+1/fps or other formulars that dont expect
2 frames with the same timestamp.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100610/a36f1b29/attachment.pgp>