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

[Ed Wildgoose]

Jan Knutar wrote:

>On Tuesday 21 September 2004 13:13, Ed Wildgoose wrote:
>
>  
>
>>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 
>>    
>>
>
>mga_vid can be compiled to use the retrace interrupt, but last time I checked,
>it didn't really work very well...
>  
>

Why?  What happened?

I'm not quite sure how the output drivers like mga_vid actually work, 
but there is no obvious hook back to the main() loop, so my guess would 
be that this option would only affect the frame tearing in the mga 
output, and doesn't actually impact the timing code in the main loop 
(which is what I was suggesting).

We would need to get all these retrace interrupts into a standard format 
so that they can be used as part of the sleep code in the main loop (or 
at least as many as make sense for the average user - no need to make 
this an impossible project). 

For example I have a 25fps input stream here, and using the Mythtv 
player app which supports syncing to the nvidia video retrace interrupt 
I get absolutely perfect 25 fps output (in my case it's easier because I 
have a 50fps video mode).  Before, using RTC I would have a few ms 
jitter either side (which was good, but not perfect and was sometimes 
visible as a frame skip).

Myth only has basic support for the frametiming logic though and needs 
you to have an exact multiple of output frame rate for it to work.  
However, it serves to show the potential to get very accurate timing 
with low PC load.

Since this appears to be the main synchronisation point of mplayer, this 
idea appears to be worth a little mulling over?

Ed W