summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player: don't print status line again when quittingwm42018-08-111-2/+5
| | | | | | | | Quitting is slightly asynchronous, so the status line can be updated again. Normally, that's fine, but if quitting comes with a message (such as with quit_watch_later), it will print the status line again after the message, which looks annoying. So flush and clear the status message if it's updated during quitting.
* HACK: prefetch subtitles on track switch a bit morewm42018-06-301-1/+4
| | | | To get overlapping shit etc.
* player: don't cache subtitles across deselectionwm42018-06-302-6/+6
| | | | | This means reselection triggers full reinit. This is better if you have options that "edit" subtitles or whatever.
* player: fix coding stylewm42018-05-241-3/+3
| | | | | I'm also not sure whether this condition doesn't subtly break a lot of things.
* command: avoid some direct MPOpts write accesseswm42018-05-241-7/+7
| | | | | | | | | | | This is working towards a change intended in the future: nothing should write to the option struct directly, but use functions that raise proper notifications. Until this is complete it will take a while, and this commit does not change all cases of direct access, just some simple ones. In all of these 3 changes, the actual write access is done by the generic property-option bridge.
* player: get rid of mpv_global.optswm42018-05-244-21/+23
| | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
* vd_lavc: move hwdec opts to local config, don't use global MPOptswm42018-05-241-6/+8
| | | | | | | The --hwdec* options are a good fit for the vd_lavc local option struct. This annoyingly requires manual prefixing of most of these options with --vd-lavc (could be avoided by using more sub-struct craziness, but let's not).
* path: don't access global option structwm42018-05-241-0/+1
| | | | | | | The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
* ao: use a local option structwm42018-05-242-2/+11
| | | | Instead of accessing MPOpts.
* player: remove deprecated vo/ao auto profileswm42018-05-241-9/+0
| | | | | These were deprecated almost 2 years ago. Now they happen to be in the way.
* m_config: remove extra default_data fieldwm42018-05-241-3/+4
| | | | Just wastes memory (a few KB, because there are so many options).
* input: remove now unused "abort command" and cancel infrastructurewm42018-05-241-5/+5
| | | | The previous commit removed all uses.
* player: make playback termination asynchronouswm42018-05-244-32/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
* player: change the role of the "stop_play" and "playing" variablewm42018-05-245-18/+23
| | | | | | | | | | | | | | | | | Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
* player: move a function (no functional changes)wm42018-05-241-7/+7
|
* player: some further cleanup of the mp_cancel crapwm42018-05-241-46/+14
| | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
* demux: get rid of free_demuxer[_and_stream]()wm42018-05-241-1/+1
| | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
* player: simplify edition switchingwm42018-05-243-13/+2
| | | | | | | | | | | | | | The player fully restarts playback when the edition or disk title is changed. Before this, the player tried to reinitialized playback partially. For example, it did not print a new "Playing: <file>" message, and did not send playback end to libmpv users (scripts or applications). This playback restart code was a bit messy and could have unforeseen interactions with various state. There have been bugs before. Since it's a mostly cosmetic thing for an obscure feature, just change it to a full restart. This works well, though since it may have consequences for scripts or client API users, mention it in interface-changes.rst.
* command: whitelist some blocking accesses for certain demuxers/streamswm42018-05-241-8/+10
| | | | | | | | | | | | | | | | | | | | | The properties/commands touched in this commit are all for obscure special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream layer. For network streams, this blocking is very unwelcome. They will affect playback and probably introduce pauses and frame drops. The player can even freeze fully, and the logic that tries to make playback abortable even if frozen complicates the player. Since the mentioned accesses are not needed for network streams, but they will block on network streams even though they're going to fail, add a flag that coarsely enables/disables these accesses. Essentially it establishes a whitelist of demuxers/streams which support them. In theory you could to access BD/DVD images over network (or add such support, I don't think it's a thing in mpv). In these cases these controls still can block and could even "freeze" the player completely. Writing to the "program" and "cache-size" properties still can block even for network streams. Just don't use them if you don't want freezes.
* command: make loadlist command async and abortablewm42018-05-241-2/+6
| | | | | | | | | | Don't allow it to freeze everything when loading a playlist from network (although you definitely shouldn't do that, but whatever). This also affects the really obscure --ordered-chapters-files option. The --playlist option on the other hand has no choice but to freeze the shit, because there's no concept of aborting the player during command line parsing.
* player: make various commands for managing external tracks abortablewm42018-05-243-54/+81
| | | | | | | | | | | | | | | | | | | | | Until now, they could be aborted only by ending playback, and calling mpv_abort_async_command didn't do anything. This requires furthering the mess how playback abort is done. The main reason why mp_cancel exists at all is to avoid that a "frozen" demuxer (blocked on network I/O or whatever) cannot freeze the core. The core should always get its way. Previously, there was a single mp_cancel handle, that could be signaled, and all demuxers would unfreeze. With external files, we might want to abort loading of a certain external file, which automatically means they need a separate mp_cancel. So give every demuxer its own mp_cancel, and "slave" it to whatever parent mp_cancel handles aborting. Since the mpv demuxer API conflates creating the demuxer and reading the file headers, mp_cancel strictly need to be created before the demuxer is created (or we couldn't abort loading). Although we give every demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer), it's still rather messy to create/destroy it along with the demuxer.
* misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-241-1/+1
| | | | | | | | | | | | It seems a bit inappropriate to have dumped this into stream.c, even if it's roughly speaking its main user. At least it made its way somewhat unfortunately to other components not related to the stream or demuxer layer at all. I'm too greedy to give this weird helper its own file, so dump it into thread_tools.c. Probably a somewhat pointless change.
* command: give named arguments to almost all commandswm42018-05-241-170/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, only 1 command or so had named arguments. There is no reason why other commands can't have them, except that it's a bit of work to add them. Commands with variable number of arguments are inherently incompatible to named arguments, such as the "run" command. They still have dummy names, but obviously you can't assign multiple values to a single named argument (unless the argument has an array type, which would be something different). For now, disallow using named argument APIs with these commands. This might change later. 2 commands are adjusted to not need a separate default value by changing flag constants. (The numeric values are C only and can't be set by users.) Make the command syntax in the manpage more consistent. Now none of the allowed choice/flag names are in the command header, and all arguments are shown with their proper name and quoted with <...>. Some places in the manpage and the client.h doxygen are updated to reflect that most commands support named arguments. In addition, try to improve the documentation of the syntax and need for escaping etc. as well. (Or actually most uses of the word "argument" should be "parameter".)
* misc: move some helper code from client.cwm42018-05-241-49/+2
| | | | | (Slightly oddly function names, because I want to avoid starting them with mpv_*, which is reserved for public API.)
* player: use canonical playback time for video refresheswm42018-05-241-4/+1
| | | | | | | | | | | | | | | | When changing video filters during initialization, there was a small time window where video was initialized, but playback restart was not complete yet. In this time window, playback_pts is not set. But since issue_refresh_seek() was using this, it could lead to no refresh being done _if_ the "video" had only 1 frame (such as cover art). Fix this by using get_current_time() instead, which is the current time with corner cases such as ongoing loading or seeks taken into account. See also the previous commit. Without that, get_current_time() could return NOPTS during init. Fixes #5831.
* player: don't reset last_seek_pts on playback state resetwm42018-05-242-4/+2
| | | | | | | | | | | This is nonsense. Didn't matter in most situations, because seeking itself set this after it was cleared. But some callers don't do this, see e.g. commit ed73ba89644fc6. There is no need to clear it at all, and it causes issues with the next commit. It only needs to be reset on loading. Also move the initialization on loading up, which doesn't change behavior, but makes the intention clearer.
* client API: kill async commands on terminationwm42018-05-243-14/+46
| | | | | | | | | | | This affects async commands started by client API, commands with async capability run in a sync way by client API (think mpv_command_node() with "subprocess"), and detached async work. Since scripts might want to do some cleanup work (that might involve launching processes, don't ask), we don't unconditionally kill everything on exit, but apply an arbitrary timeout of 2 seconds until async commands are aborted.
* lua: expose mpv_abort_async_command()wm42018-05-242-3/+26
| | | | Also somewhat cleans up mp.command_native_async() error handling.
* command: make "subprocess" explicitly abortablewm42018-05-241-5/+7
| | | | Now mpv_abort_async_command() can be used to stop the process.
* command: add a way to abort asynchronous commandswm42018-05-248-9/+131
| | | | | | | | | | | | Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
* player: rename "lock" to "abort_lock"wm42018-05-243-12/+12
| | | | | | If a struct as large as MPContext contains a field named "lock", it creates the impression that it is the primary lock for MPContext. This is wrong, the lock just protects a single field.
* lua: reimplement mp.subprocess_detached() by invoking the "run" commandwm42018-05-242-30/+4
| | | | | | | | The "run" command is old. I'm not sure why the separate Lua implementation was added. But maybe it as because the "run" command used to be limited to a small number of arguments. This limit has been removed a while ago. In any case, the old implementation is not needed anymore.
* lua: reimplement mp.subprocess() by invoking the new subprocess commandwm42018-05-243-79/+24
| | | | | | | We keep mp.subprocess() with roughly the same semantics for compatibility with scripts (including the internal ytdl script). Seems to work with rhe ytdl wrapper. Not tested further.
* command: add a subprocess commandwm42018-05-241-0/+96
| | | | | | | This supports named arguments. It benefits from the infrastructure of async commands. The plan is to reimplement Lua's utils.subprocess() on top of it.
* video: trust container FPS early on if possiblewm42018-05-241-1/+2
| | | | | If the container FPS is correct, this can help getting ideal mix factors for vo_gpu interpolation mode. Otherwise, it doesn't matter.
* input: add a define for the number of mouse buttons and use itwm42018-05-241-1/+1
| | | | (Why the fuck are there up to 20 mouse buttons?)
* lua: expose async commandswm42018-05-242-0/+40
| | | | Might be useful for some.
* screenshot: report success to callerwm42018-05-241-3/+7
| | | | Matters only to API callers, but still nice to have.
* client API: merge status_reply() helper with only remaining callerwm42018-05-241-12/+5
| | | | | All other callers had to be changed, so there's no point in keeping this helper function around. It's just another unnecessary indirection.
* client API: add returning of data from async commandswm42018-05-241-5/+10
| | | | This was not done sooner out of laziness.
* screenshot: change async behavior to be in line with new semanticswm42018-05-243-115/+75
| | | | | | | | | | | | | | | | | | | | | | Basically reimplement the async behavior on top of the async command code. With this, all screenshot commands are async, and the "async" prefix basically does nothing. The prefix now behaves exactly like with other commands that use spawn_thread. This also means using the prefix in the preset input.conf is pointless (without effect) and misleading, so remove that. The each_frame mode was actually particularly painful in making this change, since the player wants to block for it when writing a screenshot, and generally doesn't fit into the new infrastructure. It was still relatively easy to reimplement by copying the original command and then repeating it on each frame. The waiting is reentrant now, so move the call in video.c to a "safer" spot. One way to observe how the new semantics interact with everything is using the mpv repl script and sending a screenshot command through it. Without async flag, the script will freeze while writing the screenshot (while playback continues), while with async flag it continues.
* command: move screenshot command stubs to screenshot.cwm42018-05-243-67/+66
| | | | | | | | | | Commands are not a monolithic giant switch() statement anymore, but individual functions. There's no reason to have the command handlers themselves in command.c, with a weird under-defined API in between. (In the future, I'd like to split up command.c further, and when I do that, scrrenshot.c will probably gets its own mp_cmd_def[] array, and define the commands locally instead of exporting the raw handlers.)
* player: make all external file loading actions asyncwm42018-05-243-22/+91
| | | | | Still missing: not freezing when removing a track (i.e. closing demuxer) with the sub-remove/audio-remove/rescan-external-files commands.
* player: make abort during loading faster if ytdl_hook is usedwm42018-05-241-0/+7
| | | | | | | | | | | | | | | | Basically, the ytdl_hook script will not terminate the script, even if you change to a new playlist entry. This happens because ytdl_hook keeps the player core in an early loading stage, and the forceful playback abort is done only in the ermination code. This does not handle the "stop" and "quit" commands, which can still take longer than expected, but on the other hand have some weird special handling (see below). I'm not doing this out of laziness. Playback stopping will have to be somewhat redone anyway. Basically we want to give everything a chance to terminate, and if it doesn't work, we want to stop loading or playback forcefully after a small timeout. We also want to remove the mess with input.c's special handling of "quit" and some other commands (see abort_playback_cb stuff).
* player: don't even start loading external tracks when aborting loadingwm42018-05-241-1/+1
| | | | | | It seems the ytdl script like to continue loading external tracks even if loading was aborted. Trying to do so will still quickly fail, but not without a load of log noise. So check and error out early.
* command: make sub-add and audio-add commands asyncwm42018-05-243-7/+21
| | | | | | | | | | Pretty trivial, since commands can be async now, and the common code even provides convenience like running commands on a worker thread. The only ugly thing is that mp_add_external_file() needs an extra flag for locking. This is because there's still some code which calls this synchronously from the main thread, and unlocking the core makes no sense there.
* command: add infrastructure for async commandswm42018-05-247-44/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
* thread_pool: make it slightly less dumbwm42018-05-241-1/+1
| | | | | | | | | | | | The existing thread pool code is the most primitive thread pool possible. That's fine, but one annoying thing was that it used a static number of threads. Make it dynamic, so we don't need to "waste" idle threads. This tries to add threads as needed. If threads are idle for some time, destroy them again until a minimum number of threads is reached. Also change the license to ISC.
* client: merge can_terminate() functionwm42018-05-241-15/+12
| | | | | | | | | | | This has some tricky interactions. In particular, it requires the core to be locked due to reading outstanding_async, which is documented on the only caller only. It's probably better to merge it with its only caller. The new code should be strictly equivalent, other than the fact that it doesn't temporarily unlock+lock when entering the loop for the first time (which doesn't matter here).
* command: handle list commands like normal commandswm42018-05-241-7/+11
| | | | Pretty annoying.
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-243-3/+26
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include