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

[Jan Knutar]

On Thursday 26 August 2004 09:41, Ed Wildgoose wrote:

> 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...

I was vaguely thinking of adding a flag of some sort, so that events to
which we can respond in realtime (such as quit, for example), we do it
within 1/fps or 1/audiobufsize time, and for seeks, reaction remains the
same, 2/fps (?), since as you say, seek doesnt work really well if the
event loop runs faster than fps.

Changing seeks to be immediate, and not have to wait for next frame,
would probably lead to total collapse of A/V sync code.

> 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).

Yes, and attempting to fix this is probably a few magnitudes more challenging
task than you'd think. 

> 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.

It sort of does this already, yes? The frequency is just determined by either
audio or video fps, with both upper and lower limits defined, (except on 
-nosound case, where it's always controlled by video fps).

> 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. 

Setting the frequency in stone would probably be a bad idea. You don't want
to sleep 0.25 secs, do key events, sleep 0.01 sec remaining to display frame.
The audio and video requirements can be considered hard real time, but the
event loop isn't really as important. Having the sleep time controlled by audio
and video, as it is now, still seems like a good idea to me. What we want, though,
is to limit to maximum sleep time (already does this?), and, possibly, ability to skip,
some of the code blocks in the main loop from being executed too often, although,
it's probably only the event code which suffers any damage from this.

> 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. 

Splitting main into several logical subunits is probably a long standing
wishlist item, too :-) The reason nobody has done it yet is because of
its complexity. Heck, just look at the subtle behavioural changes your
patch would do, which first looks like a "No brainer harmless" :-)
The real question is of course, now that atleast some of those effects
have been brought up, whether it would be acceptable, or whether you/we
have to try fix it too first. :-)


> 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?

Audio sync probably.

It's not as easy as playing audio stream at 44100 hz, and playing video at 25fps,
the sound board, graphics board, motherboard, OS, all have different opinions
about how long a second is :)


Disclaimer: It's late in the morning after nightshift. Contents above likely to have
teh brainworms.