summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
Commit message (Collapse)AuthorAgeFilesLines
* player: put --term-playing-msg in a separate log categorywm42015-07-131-1/+3
| | | | Fixes #1983.
* player: refactor chapter seek codewm42015-07-101-22/+1
| | | | | | | mp_seek_chapter() had only 1 caller. Also the code was rather roundabout; the entire function can be compressed to 5 lines of code. (The new code is functionally the same - "mpctx->last_chapter_seek = -2;" was effectively a dead assingment.)
* player: never overwrite stop_play fieldwm42015-07-081-2/+3
| | | | | | | This is a real pain: if a quit command is received, it's set to PT_QUIT. And then other code could overwrite it, making it not quit. The annoying bit is that stop_play is written and read in many places. Just not overwriting it unconditionally seems to be the best course of action.
* player: increase tick event update frequencywm42015-06-231-1/+1
| | | | | | | | | | | | | | | 500ms is a bit too high. Change it to 50ms. This improves client API (and Lua) playback state update frequency. Updating absolutely every time the audio PTS changes would be possible, but is not helpful. Audio samplerates are high to trigger a wakeup feedback loop, so the process would waste CPU time on updating the playback position all the time. (If a client application wants to ensure smooth update of the playback position, it should update the position manually using a timer and by reading the property - the application can make a much better decision at how often the playback has to happen.)
* player: add some debug output for seekingwm42015-06-181-0/+4
|
* command: do not exit playback if the B point of A-B loop is past EOFwm42015-06-161-0/+2
| | | | | | | | | | | | | | The previous behavior is confusing if the B point is near EOF (consider B being the duration of the file, which is strictly speaking past the last video timestamp). The new behavior is fine as well for B being far past EOF. Achieve this by checking the EOF state in addition to whether playback has reached the B point. Also, move the A-B loop code out of command_event(). It just isn't useful anymore, and obfuscates the code more than it makes it loop simple. Fixes #2046.
* player: do not exit when a seek gets queuedwm42015-06-161-0/+4
| | | | | | | | | Seems logical. Note that if playback otherwise ends while playback is active and a seek is still queued, we still exit. Otherwise you couldn't end playback by seeking past the end of the file (which is classic MPlayer and mpv behavior).
* player: add function to compute past frame durationswm42015-05-241-0/+21
| | | | | And use it for the estimated-vf-fps property (it should be doing the same as before).
* player: handle hotplug events in idle mode toowm42015-05-021-0/+1
|
* player: clamp display time to known time range on seekingwm42015-04-281-0/+7
| | | | | | | | | | | | | | | During seeking, and there is momemtarily no new data available yet, the player will display the seek target as current time. Clamp this time to the known time range as implied by the start time and the duration of the file. This improves behavior especially when seeking in audio files, for which this for some reason triggers rather often. There were some users complaining about this. This makes behavior worse for files with timestamp resets, or incorrectly reported duration. (The latter is relatively common, e.g. libavformat shortcomings, or incomplete files.)
* demux_mkv: move global options to the demuxerwm42015-04-231-2/+0
| | | | | | | The options don't change, but they're now declared and used privately by demux_mkv.c. This also brings with it a minor refactor of the subpreroll seek handling - merge the code from playloop.c into demux_mkv.c. The change in demux.c is pretty much equivalent as well.
* client API: add glue for making full use of mpv_command_node()wm42015-04-201-1/+1
| | | | | Until now, the return value was always MPV_FORMAT_NONE. Now a command can actually set it. This will be used in one of the following commits.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: use symbolic constant for seek precisionwm42015-03-041-11/+13
| | | | Meh.
* player: allow unsetting --term/osd-playing-msgwm42015-02-181-2/+2
| | | | | | Treat an empty string as unset. The fact that the option values can be NULL is merely weirdness due to how the option parser works (it unfortunately doesn't initialize string fields to non-NULL).
* player: fix audio-device-list updateswm42015-02-141-0/+1
| | | | | | | The way the AO wakes up the playloop has nothing to do with events; instead we must query the events on the AO once the playloop was woken up. Querying the events in every playloop iteration is thus the correct way to do this.
* player: add a --loop=force modewm42015-02-121-1/+1
| | | | | | | Requested. See manpage additions. This also makes the magical loop_times constants slightly saner, but shouldn't change the semantics of any existing --loop option values.
* player: move more code out of central playloop functionwm42015-01-291-58/+73
| | | | | | | | | | ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
* player: fix framestep over timeline segment boundarieswm42015-01-261-0/+2
| | | | | | | | | | | This was subtly broken by commit a937ba20. Instead of framestepping over the timeline segment boundary, it would just unpause playback, because seeking now resets mpctx->step_frames. This was especially apparent when doing something like "mpv *.jpg --merge-files". Fix by restoring the step_frames field specifically if the seek is done for switching segment boundaries. Hopefully the number fields which need such an exception on seeking won't grow and turn this code into a mess.
* player: some fixes for property notificationxylosper2015-01-231-1/+1
| | | | | | | | | | `core-idle` depends on seeking state `mpctx->restart_complete`, so make `core-idle` notified whenever `seeking` is notified, too. `paused-for-cache` can be changed on MPV_EVENT_CACHE_UPDATE obviously. Finally, `MPV_EVENT_PLAYBACK_RESTART` should be notified after `mpctx->restart_complete` changed.
* demux_disc: pass seek flags to stream layerwm42015-01-191-3/+6
| | | | | | | | | | | | | | | | Pass through the seek flags to the stream layer. The STREAM_CTRL semantics become a bit awkward, but that's still the least awkward part about optical disc media. Make demux_disc.c request relative seeks. Now the player will use relative seeks if the user sends relative seek commands, and the demuxer announces it wants these by setting rel_seeks to true. This change probably changes seek behavior for dvd, dvdnav, bluray, cdda, and possibly makes seeking useless if the demuxer-cache is set to a high value. Will be used in the next commit. (Split to make reverting the next commit easier.)
* player: fallback to seek time for percent-pos propertywm42015-01-141-2/+2
| | | | | | | | | | | | | The percent-pos property normally goes by time, except for file formats like .ts or .ogg, where you can't trust the timestamps and duration info to compute the position in the overall files. These use the byte position and size instead. When the file position was unavailable (e.g. due to an ongoing seek), the percent-pos was unknown. Change it to use the time position instead. In most cases, it's actually accurate enough, and the temporary unavailability of the property can be annoying, e.g. on the terminal status line.
* video: batch query_format callswm42015-01-031-1/+3
| | | | | | | There are currently 568 pixel formats (actually fewer, but the namespace is this big), and for each format elaborate synchronization was done to call it synchronously on the VO. This is completely unnecessary, and we can do with just a single call.
* player: hack against --keep-open misbehaving with broken fileswm42014-12-241-0/+2
| | | | | | | | | | | | | | | | If a file (or a demuxer) is broken, seeking close to the end of the file doesn't work, and seek_to_last_frame() will be called over and over again, burning CPU for no reason. Observed with incomplete mp4 files. That this can happen was already mentioned in commit 090f6cfc, but I guess now I'll do something against it. hrseek_lastframe is cleared by reset_playback_state(), so it's only set if seek_to_last_frame() was called, and no other seek happened since then. If finding the last frame succeeds, no EOF will happen (unless the user unpauses, but then it will simply remain at the last frame). If it fails, then it will return immediately, without retrying.
* player: don't show "0%" percentage in infinite streamswm42014-12-201-2/+3
|
* player: cosmetics: remove ancient commentwm42014-12-171-3/+0
| | | | | The DVD horror was confined to specific parts of the player, instead of having it spread everywhere.
* player: add a --keep-open=always modewm42014-12-121-1/+2
| | | | | | | | The --keep-open behavior was recently changed to act only on the last file due to user requests (see commit 735a9c39). But the old behavior was useful too, so bring it back as an additional mode. Fixes #1332 (or rather, should help with it).
* player: make chapter seek to end jump to last frame with --keep-openwm42014-12-081-1/+1
| | | | | | | | There were complaints that a chapter seek past the last chapter was quitting the player. Change the behavior to what is expected: the last frame. If no chapters are available, this still does nothing.
* player: when seeking past EOF with --keep-open, seek to last framewm42014-12-071-1/+27
| | | | | | | | | | | | | | | | | | | | | It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
* player: don't ignore relative seeks by 0 secondswm42014-11-291-4/+0
| | | | | | | I don't know why this done; most likely it had no real reason. Remove it because it breaks "refresh seeks" to the same position. (Although the refresh seeks mpv sometimes does were fine.)
* player: reset frame step counter on seekswm42014-11-291-0/+1
| | | | | I suppose this wasn't done in order to keep the frame step counter active even in the next file, but actually it was reset anyway.
* player: simplify and fix ordered chapter EOF handlingwm42014-11-281-12/+3
| | | | | | | | | | | | | | Ordered chapter EOF was handled as special-case of ending the last segment. This broke --kee-open, because it set AT_END_OF_FILE in an "inconvenient" place (after checking for --keep-open, and before the code that exits playback if EOF is reached). We don't actually need to handle the last segment specially. Instead, we remain in the same segment if it ends. The normal playback logic will recognize EOF, because the end of the segment "cuts off" the file. Now timeline_set_from_time() never "fails", and we can remove the old segment EOF handling code in mp_seek().
* 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
| | | | | | |