[MPlayer-dev-eng] Adding threaded functionality to mplayer NODAEMON
lists at wildgooses.com
Tue Sep 21 12:13:53 CEST 2004
>>So "the requirement is 10ms", which I estimated from 40ms frame durations
>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.
More information about the MPlayer-dev-eng