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

[Rudolf Polzer]

On Sat, Jul 24, 2010 at 06:32:35PM +0200, Dan Oscarsson wrote:
> 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).

I'd be interested in trying this on some of the video files I have here that
cause nasty mencoder AV sync failures (all in mkv format, though). However,
neither -mc 0 nor my change "fix" them.

Best regards,

Rudolf Polzer