[MPlayer-dev-eng] New Main() loop

[Attila Kinali]

On Thu, Aug 26, 2004 at 07:41:13AM +0100, Ed Wildgoose wrote:
 
> Since the suggestion for threads went down like a lead ballon, the next 
> best change to the main() loop would probably be to restructure it as an 
> event loop, so it whizes round and round and fires off those big lumps 
> of code on periodic intervals.  Perhaps the keyboard event code then 
> gets fired 1/25 sec no matter what the framerate, audio loop gets fired 
> at buffer latency, and frame output gets fired at the appropriate sync 
> interval. 
> 
> I don't have time to code up such a change right now, but it wouldn't be 
> such a big change - basically you are just reformatting the current main 
> loop into sub routines and adding some timing logic instead. 

You have to be very carefull with such requests. We are here somewhere
at the edge to real time applications. Currently we need to get called
every 1/fps, which is around 30ms. Inacurancies of the sleep resp call
time of 5-10ms start to get noticable, anything above 20ms is very bad.
10ms is already considered soft realtime.
An event naive aproach to an event loop would reduce sleep times
greately as the next event may be scheduled at any time. Thus moving
us further into the direction of hard realtime. So your i
"not such a big change" will get quite big to handle those events
in an intelligent way by not requesting too small sleep times,
not introducing "have to wait for 1ms" spin loops that waste
precious cpu time and still working in 99% of all cases.

> Any comments for or against?
> 
> I guess a useful patch would also be to adjust the logic so that 
> frameseeks caused the frame draw to become instantly due, and not have 
> to wait a frame interval to draw them.  Any reasons why this change in 
> behaviour would break something subtle?

Uhmm.. how many assumptions of the code will this break ?
Please keep in mind that playing a video file is not just
filling the audio buffer and displaying a picture once in a while.
It's a lot more complex (mplayer.c wouldnt be nearly 4k lines otherwise).


I just had a look at your patch again, and it really looks like
a no-brainer, but i somewhat feel there is more to it. The main loop
has to keep a lot of things in mind and i somewhat think that you left
out a few of those.

			Attila Kinali