[MPlayer-dev-eng] [PATCH] 64-bit get time 2nd try

[Reimar Döffinger]

On Mon, Oct 11, 2010 at 08:11:59AM +0200, Dan Oscarsson wrote:
> sön 2010-10-10 klockan 22:55 +0200 skrev Reimar Döffinger:
> > I don't believe that using av_gettime will require any less thought.
> > Unless of course you're happy with an implementation that breaks whenever
> > something unexpect happens.
> 
> As the code currently is written to use non-wrapping timestamps changubg
> to GetTimer which wraps needsthought to avoid making misstakes due to
> wrapping time.

Using av_gettime needs thought that clock jumps do not break it too badly,
all cases need thought to handle suspend/resume, I don't think there's
a way to avoid think carefully about the time handling a few times...

> > > One I can think of, is that in my code vo
> > > reports the time of last vsync it has seen. After a pause, which could
> > > take many hours, some vo do not update the last vsync time so after the
> > > pause a 32-bit value may have wrapped several times.This case I can fix
> > > - the vo have to, when requested to resume after a pause, wait for a
> > > vsync so it can report a current vsync timstamp.
> > 
> > Why do you think this needs any different handling than just starting playback?
> 
> At start, vsync interval length is calculated, this is not needed after
> pause (unless you want to handle that people pause and then change
> display refresh speed - that is not implemented yet).

If possible I prefer code that figures out on its own that something is
fishy and compensates (where "possible" for me implies that the result
of this "intelligence" will never be significantly worse than not having it),
which ideally would handle startup, vsync changes during both playback and
pause and whatever else might go wrong with timing.