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

[Pásztor Szilárd]

 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 tried to find some correlation but here is where I gave 
 up
 because I found a lot of different initializations for many contexts in
 ffplay that does not exist in mplayer. I think some initialization is
 different.