[MPlayer-dev-eng] Reverted patch of time-based PTS locking

[Reimar Döffinger]

On Mon, Aug 20, 2012 at 09:13:28PM +0200, Pásztor Szilárd wrote:
> Reimar Döffinger:
> >Could you give more details?
> >Getting a best_effort_timestamp I'd expect a bit complicated,
> >but naively I'd expect that a simple AVPacket->pts in,
> >AVFrame->pkt_pts is supposed to "just work" since it should be
> >reordered inside the codec in the same way the pixel data itself
> >is...
> 
> I did a lot of digging in the ffmpeg/mplayer sources and found out that
> the missing link is in
> 
> static mp_image_t *decode(sh_video_t *sh, void *data, int len, int
> flags)
> 
> in vd_ffmpeg.c where the pkt struct gets initialized but the propagated
> sh->pts coming directly from the stream is not assigned to pkt.pts. So
> after an ugly timebase conversion: (int)(sh->pts * 90000 + 0.5) I
> assigned
> naively to it and saw that after calling avframe_decode_video2,
> frame->pkt_pts is still not in order. Exactly the same call in ffplay.c
> DOES return the pts in order, but not in mplayer. I was already digging
> in h264.c to find that h->next_output_pic for the same frames is
> different
> for ffplay.c and for mplayer, and this determines which avframe the
> decoder
> is returning.

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?