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

[Reimar Döffinger]

On 17 Aug 2012, at 00:17, Pásztor Szilárd <don at tricon.hu> wrote:
> Reimar Döffinger:
>> I don't know what gave you that idea. The container does have PTS, but
>> H264-ES has timestamps just as much as MPEG-2
> 
> It has vop_time_increment in theory but I found no way in mplayer so far
> to get this info out of the stream. Do you maybe have a hint?

Well, the problem is that with e.g. mp4 container it is the container time stamp that counts, not the one in the frames.
However you could try having the PTS values reordered by the FFmpeg decoder (I think nowadays that works by putting the timestamp in in the AVPacket and getting it out in the AVFrame).
I would kind of like the general code to handle mixed up timestamps anyway though if reasonably possible....

>> Actually with the default it should be at most 10% of the frame time, so
>> around 4 ms.
>> I wonder if something that takes c_total into account wouldn't detect
>> and eliminate this "jerking back and forth with not real overall effect"
>> better.
> 
> It still seems to me that we misunderstand each other. Or my message just
> doesn't get through.
> I'm not talking about A-V sync. It doesn't have a problem worth working on.
> I'm talking about the fact that differing PTS values are improperly assigned
> to frames. And this results in a very jerky video, even without sound.

No, no misunderstanding. It's just that IMO the A-V sync code does something similar, trying to eliminate this kind of jerks (maybe not similar enough though).
I don't think it runs when there is no sound at all though.