[MPlayer-dev-eng] [PATCH] -vf fixpts=use_timer

[Dan Oscarsson]

ons 2010-07-21 klockan 19:59 +0200 skrev Reimar Döffinger:
> On Wed, Jul 21, 2010 at 06:11:11PM +0200, Dan Oscarsson wrote:
> > As I would also like to have monotonous pts values very much
> > I have been testing enabling reordering for the nocorrect-pts case and
> > for several .avi files which get
> > [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) as decoder, I see that the first
> > video frame is "delayed" (i.e. mpvdec->decode returns NULL).
> > When using -demuxer lavf which sets correct_pts, the pts for first video
> > frame is 0.041708 while without it, the pts is 0.000000.
> > 
> > Now I wonder, what is the correct pts of the first frame? Is it 0.000
> > which is what I could expect from a .avi file, or is the first frame in
> > the file is discarded so the first frame has pts 0.041708?
> > 
> > Not every .avi (mpeg-4) file "delays" first frame. Is the above because
> > of a B-frame so no frame is discarded, just delayed?
> 
> The frame is only "delayed" in the sense that you need to put multiple
> packets in the decoder before you get one out.
> This (is not supposed to) have any effect on the pts values themselves,
> only their order. And since minimum and maximum do not change with order,
> the start time should not change.
> I suspect that MPlayer simply always starts with 0 when decoding with
> -nocorrect-pts, but I don't know for sure.

I have tested some more with .avi files with mepg-4 video. From what I
can see, often demux_avi.c returns a different pts for first video frame
than the lavf demuxer. The second frame from demux_avi returns the pts
the lavf demuxer returns for first frame. The code for .avi demuxing is
so different between lavf and demux_avi so I have not found out why.

I have tested by changing in decode_video so that it always reorders pts
values and from what I can see it works fine on all my files. While the
above tests show that the pts values are one frame off between lavf and
demux_avi, I cannot hear and see which is most correct. Both sounds like
a-v is in sync. But a sound difference in about 40 ms is difficult, at
least for me, to detect.

So should we go for always having the pts reorder code in decode_video
enabled? Or just add an option for it?

That would make my h264 streams in mpeg-ts get monotonously increasing
pts values. And I expect also for other types where it is needed (as
long as the decoder gives correct response).

  Dan