[MPlayer-dev-eng] Adding threaded functionality to mplayer NODAEMON

[Ed Wildgoose]

>>So "the requirement is 10ms", which I estimated from 40ms frame durations
>>at 25fps.
>>    
>>
>
>10ms is the minimum to get a smooth pic. Note that MPlayer uses some
>tricks to get around the 100Hz timer limit. Also try older kernels which
>had a very coarse sleep() resolution which could sleep easily 20ms
>instead of 10ms and thus on these kernels the video looked a bit "shaggy".
>  
>

As I suggested in an earlier message, I still have a hunch that there 
are some other interrupts available on certain hardware which might be 
useful in order to make the video timing smoother.  For example there is 
the vertical retrace availalble either from certain nvidia drivers, or 
the opengl driver on certain cards.  Although frame rate does not equal 
refresh rate in many cases, its still a slightly moot point because you 
can only view the video at that rate.  So for example if you have 25Hz 
video and 60Hz refresh rate, then the best you can do is really show the 
frame at the point that creates least jitter.

So the problem now reduces to finding the closest retrace interval and 
sleeping until that - we then work out which is the next best retrace to 
minimise jitter and also not to let the audio drift to far apart and 
sync with that, etc...

If there is sympathy for this as a process then I will consider adding 
that to my Todo list.

Ed W