[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