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

Ed Wildgoose lists at wildgooses.com
Thu Aug 26 08:41:13 CEST 2004


>Actually, isn't this pretty much what happens in current mplayer, if you have,
>say, 1 fps video? Then the current code in mplayer will do exactly that,
>run the entire thing again and listen for keyevents and so forth?
>
>Not that your patch makes it any worse really. It just changes one currently
>existing broken behaviour to break in a different way, which one is worse
>is purely subjective of course. Only noticeable on low fps video, too.
>  
>

Hmm, that's true.  I guess one could bodge this kind of behaviour 
further and try to skip up to the top of the loop for a while, and then 
to the keypress stuff once we waited too long...

Another idea is that after frame adjustment that the frame becomes 
immediately due to be shown - this is a slightly tricky change though 
because all the code appears to be geared towards expecting a seek to be 
a seek to (effectively) the end of the frame before the one we want to 
show, ie we always have to wait the frame time before we show it.  On 1 
frame a sec video I would expect this to appear as: seek, wait 1 sec, 
show frame?  I haven't tested mind (don't have any 1 frame/sec video).

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. 

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?

Ed W




More information about the MPlayer-dev-eng mailing list