summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
Commit message (Collapse)AuthorAgeFilesLines
* player: don't try to use duration 0wm42014-11-101-1/+1
|
* video/out: minor simplification to event query functionwm42014-11-091-1/+1
| | | | The "clear" parameter is confusing and useless.
* command: add window-minimized property (X11 only)wm42014-11-021-0/+2
| | | | | | More or less requested by #1237. Should be simple to extend this to other backends.
* command: make window-scale property observablewm42014-11-021-0/+10
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* player: always use demux_chapterwm42014-11-021-2/+2
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* player: don't display zero duration for files with unknown durationwm42014-10-291-7/+7
| | | | | | On OSD/terminal, just don't display the duration if unavailable. Make the "length" property unavailable if duration is unavailable.
* player: don't spam video-reconfig eventwm42014-10-271-1/+1
| | | | | | | | Without --force-window, this is called on every iteration or so, and calling uninit_video_out() sends the video-reconfig event. Avoid sending redundant events. Fixes #1225 (using an alternative patch).
* player: disable --force-window if VO failswm42014-10-241-1/+5
| | | | Otherwise, it'd retry creating the window all the time.
* player: fix --frameswm42014-10-141-1/+1
| | | | | | | | | This could produce an extra frame, because reaching the maximum merely signals the playloop to exit, without strictly enforcing the limit. Fixes #1181. CC: @mpv-player/stable
* player: don't mess up cursor visibility statewm42014-10-101-1/+1
| | | | | | | | | | | | Manually setting can break things forever, because it puts the VO cursor state out of sync with the remembered state by handle_cursor_autohide(). Use the normal autohide code during idle mode too instead. (Originally the idea was to make the cursor always visible in idle mode, but not so important.) Regression since e1e8b07c. Fixes #1166. CC: @mpv-player/stable
* player: signal EOF when using --frameswm42014-10-101-1/+1
|
* player: don't reset buffering pausing state on seekswm42014-10-091-1/+0
| | | | | | | | This was added with commit 3cbd79b3, but it turns out this unintentionally enables "real" pausing when seeking while buffering. It was done for ensuring correct state of the "cache-buffering-state" property, but it also turns out that this was unneeded (another variable that is reset when seeking happens to take care of this).
* player: minor cosmetic changewm42014-10-081-1/+1
|
* command: add cache-buffering-state propertywm42014-10-071-1/+19
|
* player: open stream and demuxer asynchronouslywm42014-10-061-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
* player: properly wakeup when delaying OSDwm42014-10-031-1/+3
| | | | | | | Not sure in which situations this could make a difference; probably none in practice, but it's more correct. CC: @mpv-player/stable
* video: return responsibility of video redraw back to playloopwm42014-10-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When the VO was moved it its own thread, responsibility for redrawing was given to the VO thread itself. So if there was a condition that indicated that redrawing was required, like expose events or certain VOCTRLs, the VO thread was redrawing itself. This worked fine, but there are some corner cases where this works rather badly. E.g. if I fullscreen the player and hit panscan controls with mpv's default autorepeat rate, playback stops. This happens because the VO redraws itself after every panscan change command. Running each (repeated) command takes so long due to redrawing and (involuntary) waiting on vsync, that it never leaves the input processing loop while the key is held down. I suspect that in my case, redrawing in fullscreen mode just gets slow enough that it takes 2 vsyncs instead of 1 on average, and the processing time gets larger than the autorepeat delay. Fix this by taking redraw control from the VO, and instead let the playloop issue a "real" redraw command to the VO if needed. This basically reverts redraw handling to what it was before moving the VO to a thread. CC: @mpv-player/stable
* player: remove central uninit_player() function and flags messwm42014-10-031-8/+6
| | | | | | | | | | | | | | Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
* player: move code to make playloop smallerwm42014-09-251-6/+0
| | | | | This is basically a cosmetic change, although it weirdly also affects the percent position in encoding mode.
* player: rate-limit OSD text updatewm42014-09-251-0/+2
| | | | | | | | | | | | | | | There's no need to update OSD messages and the terminal status if nobody is going to see it. Since the player doesn't block on video display anymore, this update happens to often and probably burns slightly more CPU than necessary. (OSD redrawing is handled separately, so it's just mostly useless text processing and such.) Change it so that it's updated only on every video frame or all 50ms (whatever comes first). For VO OSD, we could in theory try to lock to the OSD redraw heuristic or the display refresh rate, but that's more complicated and doesn't work for the terminal status.
* player: fix OSD redraw heuristic with audio-only modewm42014-09-251-1/+1
| | | | | | When using --force-window (and no video or cover art), this heuristic prevents any redrawing during seeking. It should be applied only if there is any form of video.
* player: change --keep-open semanticswm42014-09-241-1/+3
| | | | By popular request.
* player: show correct playback time with --keep-open --no-videowm42014-09-241-1/+2
| | | | Whatever.
* player: --loop-file takes precedence before --keep-openwm42014-09-241-2/+2
|
* player: allow passing number of loops to --loop-filewm42014-09-221-0/+2
| | | | | | | | | | E.g. --loop-file=2 will play the file 3 times (one time normally, and 2 repeats). Minor syntax issue: "--loop-file 5" won't work, you have to use "--loop-file=5". This is because "--loop-file" still has to work for compatibility, so the "old" syntax with a space between option name and value can't work.
* player: make code more obviouswm42014-09-201-2/+2
| | | | Or at least I think so.
* player: use backwards flag for seeking external trackswm42014-09-201-1/+1
| | | | | Otherwise, the external track could end up at a position that's too late.
* player: fix idle mode event handlingwm42014-09-131-8/+9
| | | | | | | | | | | Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing, until the next event happened. This was because it directly went to sleep after processing commands. What we should do instead is rechecking all state after processing commands, redraw OSD, and then go to sleep. This also fixes some strange OSD-related behavior. Also move some other code around to separate idle mode initialization from the normal run loop.
* terminal-unix: move to threadwm42014-09-101-5/+0
| | | | | | | Do terminal input with a thread, instead of using the central select() loop. This also changes some details how SIGTERM is handled. Part of my crusade against mp_input_add_fd().
* player: reset some VO state when video is terminatedwm42014-09-091-0/+3
| | | | | Useful for idle mode or if video is switched off during playback, and --force-window is used.
* player: some more input refactoringwm42014-09-071-21/+9
| | | | | | | | | | | | | | | | | Continues commit 348dfd93. Replace other places where input was manually fetched with common code. demux_was_interrupted() was a weird function; I'm not entirely sure about its original purpose, but now we can just replace it with simpler code as well. One difference is that we always look at the command queue, rather than just when cache initialization failed. Also, instead of discarding all but quit/playlist commands (aka abort command), run all commands. This could possibly lead to unwanted side-effects, like just ignoring commands that have no effect (consider pressing 'f' for fullscreen right on start: since the window is not created yet, it would get discarded). But playlist navigation still works as intended, and some if not all these problems already existed before that in some forms, so it should be ok.
* player: minor refactoringwm42014-09-061-22/+29
| | | | | | | Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
* player: add --osd-playing-msg optionwm42014-09-021-5/+13
|
* player: fix quit handling when seeking past EOF while pausedwm42014-08-291-6/+5
| | | | | | | | | | The player didn't quit when seeking past EOF in audio-only mode while paused. The only case when we don't want to quit is when the last video frame is displayed while paused. This logic was probably broken a while ago, but I'm not exactly sure. CC: @mpv-player/stable
* player: update cache state only if requestedwm42014-08-281-1/+6
| | | | | | | | | Add a mechanism to the client API code, which allows the player core to query whether a client API event is needed at all. Use it for the cache update. In this case, this is probably a pure microoptimization; but the mechanism will be useful for other things too.
* player: simplify chapter display name codeBen Boeckel2014-08-281-3/+2
| | | | | The display name is always recomputed, so we can always toss the input name.
* player: dynamically change cache wait timeswm42014-08-271-1/+12
| | | | | | | | | | | Remove the hardcoded wait time of 2 seconds. Instead, adjust the wait time each time we unpause: if downloading the data took longer than its estimated playback time, increase the amount of data we wait for. If it's shorter, decrease it. The +/- is supposed to avoid oscillating between two values if the elapsed time and the wait time are similar. It's not sure if this actually helps with anything, but it can't harm.
* player: slightly better cache underrun detectionwm42014-08-271-5/+2
| | | | | | | | | | | | | | | | | | Use the "native" underrun detection, instead of guessing by a low cache duration. The new underrun detection (which was added with the original commit) might have the problem that it's easy for the playloop to miss the underrun event. The underrun is actually not stored as state, so if the demuxer thread adds a new packet before the playloop happens to see the state, it's as if it never happened. On the other hand, this means that network was fast enough, so it should be just fine. Also, should it happen that we don't know the cached range (the ts_duration < 0 case), just wait until the demuxer goes idle (i.e. read_packet() decides to stop). This pretty much should affect broken or unusual files only, and there might be various things that could go wrong. But it's more robust in the normal case: this situation also happens when no packets have been read yet, and we don't want to consider this as reason to resume playback.
* player: better cache status on status linewm42014-08-271-9/+5
| | | | | | | | | | | | | | The cache percentage was useless. It showed how much of the total stream cache was in use, but since the cache size is something huge and unrelated to the bitrate or network speed, the information content of the percentage was rather low. Replace this with printing the duration of the demuxer-cached data, and the size of the stream cache in KB. I'm not completely sure about the formatting; suggestions are welcome. Note that it's not easy to know how much playback time the stream cache covers, so it's always in bytes.
* player: fix basic playbackwm42014-08-271-6/+6
| | | | | | | | | | | | | The "buffering" logic was active even if the stream cache was disabled. This is contrary to what the manpage says. It also breaks playback because of another bug: the demuxer cache is smaller than 2 seconds, and thus the resume condition never becomes true. Explicitly run this code only if the stream cache is enabled. Also, fix the underlying problem of the breakage, and resume when the demuxer thread stops reading in any case, not just on EOF. Broken by previous commit. Unbreaks playback of local files.
* player: redo how stream caching and pausing on low cache workswm42014-08-271-21/+33
| | | | | | | | | | | | | | | | | | | Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
* player: fix weird behavior when framestepping over format changeswm42014-08-261-1/+1
| | | | | | | | | | When video format changes, the frame before the frame with the new format sets video_status briefly to STATUS_DRAINING. This caused the code to handle the EOF case to kick in, which just pauses the player when trying to step past the last frame. As a result, trying to framestep over format changes resulted in pausing the player. Fix by testing against the correct status.
* audio: minor improvements to timeline switchingwm42014-08-231-4/+4
| | | | | | | | In theory, timestamps can be negative, so we shouldn't just return -1 as special value. Remove the separate code for clearing decode buffers; use the same code that is used for normal seek reset.
* player: some more debugging outputwm42014-08-221-0/+2
|
* player: don't clobber playback position on video endwm42014-08-221-5/+3
| | | | | | | | If video reaches EOF, and audio is also EOF (or is otherwise not meaningful, like audio disabled), then the playback position was briefly set to 0. Fix this by not trying to use a bogus audio PTS. CC: @mpv-player/stable (maybe)
* video: get rid of video_next_pts fieldwm42014-08-221-3/+1
| | | | | | Not really needed anymore. Code should be mostly equivalent. Also get rid of some other now-unused or outdated things.
* video: don't assume query_format is thread-safewm42014-08-201-1/+1
| | | | Although it's probably safe for most VOs, there's no guarantee.
* player: never print status messages before playback beginswm42014-08-181-1/+1
| | | | | | | | | | | | | | | | | | After a new file is loaded, playback never starts instantly. Rather, it takes some playloop iterations until initial audio and video have been decoded, and the outputs have been (lazily) initialized. This means you will get status line updates between the messages that inform of the initialized outputs. This is a bit annoying and clutters the terminal output needlessly. Fix this by never printing the status line before playback isn't fully initialized. Do this by reusing the --term-playing-msg code (which prints a message once playback is initialized). This also makes sure the status line _is_ shown during playback restart when doing seeks. It's possible that the change will make the output more confusing if for some reason is stuck forever initializing playback, but that seems like an obscure corner case that never happens, so forget about it.
* player: remove unneeded callwm42014-08-181-4/+0
| | | | | | | | print_status() is called at a later point anyway (and before sleeping), so this code has little effect. This code was added in commit a4f7a3df5, and I can't observe any problems with idle mode anymore. Now print_status() is called from a single place only, within osd.c.
* player: cosmetics: make code more compactwm42014-08-161-5/+2
|
* video: add VO framedropping modewm42014-08-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
* player: use virtual time for --audio-file with ordered chapterswm42014-08-151-1/+2
| | | | | | | | | Apparently users prefer this behavior. It was used for subtitles too, so move the code to calculate the video offset into a separate function. Seeking also needs to be fixed. Fixes #1018.
* player: don't quit with --loop-filewm42014-08-131-0/+1
| | | | | | Fixes #1009. CC: @mpv-player/stable
* video: fix and simplify video format changes and last frame displaywm42014-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit broke these things, and fixing them is separate in this commit in order to reduce the volume of changes. Move the image queue from the VO to the playback core. The image queue is a remnant of the old way how vdpau was implemented, and increasingly became more and more an artifact. In the end, it did only one thing: computing the duration of the current frame. This was done by taking the PTS difference between the current and the future frame. We keep this, but by moving it out of the VO, we don't have to special-case format changes anymore. This simplifies the code a lot. Since we need the queue to compute the duration only, a queue size larger than 2 makes no sense, and we can hardcode that. Also change how the last frame is handled. The last frame is a bit of a problem, because video timing works by showing one frame after another, which makes it a special case. Make the VO provide a function to notify us when the frame is done, instead. The frame duration is used for that. This is not perfect. For example, changing playback speed during the last frame doesn't update the end time. Pausing will not stop the clock that times the last frame. But I don't think this matters for such a corner case.
* video: move display and timing to a separate threadwm42014-08-121-25/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also