[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