mirror of
https://github.com/mpv-player/mpv
synced 2024-12-27 09:32:40 +00:00
17ec073a15
The code removed from handle_input_and_seek_coalesce() did two things: 1. If there's a queued seek, stop accepting non-seek commands, and delay them to the next playloop iteration. 2. If a seek is executing (i.e. the seek was unqueued, and now it's trying to decode and display the first video frame), stop accepting seek commands (and in fact all commands that were queued after the first seek command). This logic is disabled if seeking started longer than 300ms ago. (To avoid starvation.) I'm not sure why 1. would be needed. It's still possible that a command immediately executed after a seek command sees a "seeking in progress" state, because it affects queued seeks only, and not seeks in progress. Drop this code, since it can easily lead to input starvation, and I'm not aware of any disadvantages. The logic in 2. is good to make seeking behave much better, as it guarantees that the video display is updated frequently. Keep the core idea, but implement it differently. Now this logic is applied to seeks only. Commands after the seek can execute freely, and like with 1., I don't see a reason why they couldn't. However, in some cases, seeks are supposed to be executed instantly, so queue_seek() needs an additional parameter to signal the need for immediate update. One nice thing is that commands like sub_seek automatically profit from the seek delay logic. On the other hand, hitting chapter seek multiple times still does not update the video on chapter boundaries (as it should be). Note that the main goal of this commit is actually simplification of the input processing logic and to allow all commands to be executed immediately. |
||
---|---|---|
.. | ||
lua | ||
timeline | ||
audio.c | ||
command.c | ||
command.h | ||
configfiles.c | ||
core.h | ||
dvdnav.c | ||
loadfile.c | ||
lua.c | ||
lua.h | ||
main.c | ||
misc.c | ||
osd.c | ||
playloop.c | ||
screenshot.c | ||
screenshot.h | ||
sub.c | ||
video.c |