[MPlayer-dev-eng] Reverted patch of time-based PTS locking
Pásztor Szilárd
don at tricon.hu
Mon Aug 20 23:17:51 CEST 2012
Reimar Döffinger:
> I don't think that can be quite the cause, if the AVFrames were in
> the
> wrong order, the displayed video frames would be in the wrong order
> as
> well.
> I have nothing to support that theory so far, but are you sure it is
> not
> something the sh->pts values being delayed by e.g. one frame and thus
> coming out no better than they got in?
I don't know if they were in the same (wrong) order or in another wrong
order, but it's easy to try by inserting:
pkt.pts = (int64_t)(sh->pts * 90000 + 0.5);
just before the avcodec_decode_video2() call in vd_ffmpeg.c, then using
printf after call to see the results. Unless I was on a very wrong
track
all the time, considerable effort is needed to figure out the reason.
BTW I tried your suggestion of the mpi || drop_frame thing and it
didn't
work as causes a wrong overwrite of sh_video->pts and a possible bogus
limitation of the pts buffer (resulting in pts drop) by the delay var.
More information about the MPlayer-dev-eng
mailing list