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

[Reimar Döffinger]

On Thu, Jun 17, 2010 at 07:18:42AM +0200, Reimar D?ffinger wrote:
> On Thu, Jun 17, 2010 at 07:04:24AM +0200, Michael Niedermayer wrote:
> > 
> > On Thu, Jun 17, 2010 at 06:24:12AM +0200, Reimar D?ffinger wrote:
> > > On Wed, Jun 16, 2010 at 10:30:50PM -0400, John Koleszar wrote:
> > > > I still think this multiple packet approach is very much KISS, and
> > > > it's not just libvpx that it's simple for. The other part of that rule
> > > > is "make it as simple as possible, but no simpler."
> > > 
> > > No it really isn't. It introduces data packets that produce no data.
> > > The fact that no other format has this means this needs extensive
> > > testing and honestly won't work for quite a few applications
> > > (won't work with MEncoder, won't work with MPlayer if you try to
> > > override -fps to some fixed value, probably won't work with ffmpeg
> > > if you try to use -fps, I doubt it will work with any Video for Windows
> > > application, for which VirtualDub is an example, and I think that
> > > is not possible to fix).
> > 
> > i realize now that -skip_frame is capable of skiping b frames, non ref frames
> > and non key frames.
> > This could create a similar effect, so you could test mplayer & mencoder
> > besides that this is a usefull feature
> 
> Not sure what you intend to say here, but yes, the skip_frame flag works
> for e.g. H.264 in MPlayer, even with -fps (as said in the other mail,
> I confused how it handles things).

Hm... better don't believe anything I say today.
However I think that ARF will actually break MPlayer timing using the simple
timing mode (which is e.g. used for AVI, but also if you want to override
fps etc. and for mencoder in general, use -nocorrect-pts to active this mode).
The general code:
This reads a single video packet, however the demuxer splits things (parsing for
MPEG-ES included though):
        in_size = video_read_frame(sh_video, &sh_video->next_frame_time,
                                   &start, force_fps);
[...]
Then it unconditionally increases the video time stamp
        sh_video->timer += frame_time;
[...]
Then it tries to decode it
        decoded_frame = decode_video(sh_video, start, in_size, drop_frame,
                                     sh_video->pts);
[...]
If that worked it will display the frame, if not it won't be displayed
but the video time stays increased anyway, which is why the skip_frame feature
works even in this mode:
        *blit_frame = (decoded_frame && filter_video(sh_video, decoded_frame,
                                                    sh_video->pts));

Note while the pts is passed around, it is not actually used for timing in
this mode.
So my conclusion for now is: For anything using a simple constant-frame-rate
timing code (i.e. ignoring pts/dts) with the current API one of either
skip_frames or ARF will break timing.