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

[Dan Oscarsson]

On 2010-07-25 at 14:23 +0200 Rudolf Polzer wrote:
> 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.

The attached patch just enables so reordering is always done.
It is just my quick test code - not the way it should be done if we
decide to always have reordering active.

   Dan 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reord.diff
Type: text/x-patch
Size: 780 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100725/41536d91/attachment.bin>