summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* m_config: remove an old temporary hackwm42018-05-242-308/+336
| | | | | | | | | | | | | | | | Actually rewrite most of the option management code. This affects how options are allocated, and how thread-safe access to them is done. One thing that is nicer is that creating m_config_cache does not need to ridiculously recreate and store the entire option list again. Instead, option metadata and option storage are now separated. m_config contains the metadata, and m_config_data all or parts of the actual option values. (m_config_cache simply uses the metadata part of m_config, which is immutable after creation.) The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the global state around g_group_mutex. Although it was "benign" global state, it's good that it's finally removed.
* osdep: add portable C11-like alignof() macrowm42018-05-241-0/+5
|
* m_config: remove outdated commentwm42018-05-241-1/+0
|
* m_config: check for int16_t offset overflowwm42018-05-241-1/+3
| | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
* m_config: remove an unused functionwm42018-05-242-15/+0
|
* m_option: remove an unused fieldwm42018-05-242-13/+0
|
* m_config: cosmetics: fix 2 typoswm42018-05-241-2/+2
|
* input: remove now unused "abort command" and cancel infrastructurewm42018-05-245-75/+7
| | | | The previous commit removed all uses.
* player: make playback termination asynchronouswm42018-05-248-32/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux: add a way to destroy the demuxer asynchronouslywm42018-05-242-8/+93
| | | | | | | | | | | | | | This will enable the player core to terminate the demuxers in a "nicer" way without having to block on network. If it just used demux_free(), it would either have to block on network, or like currently, essentially kill all I/O forcefully. The API is slightly awkward, because demuxer lifetime is bound to its allocation. On the other hand, changing that would also be awkward, and introduce weird in-between states that would have to be handled in tons of places. Currently unused, to be user later.
* player: move a function (no functional changes)wm42018-05-241-7/+7
|
* manpage: update --demuxer-thread optionwm42018-05-241-3/+6
| | | | Be a bit more detailed, and discourage disabling it.
* player: some further cleanup of the mp_cancel crapwm42018-05-246-79/+62
| | | | | | | | | | 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-248-27/+31
| | | | | | | 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-244-13/+4
| | | | | | | | | | | | | | 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-247-8/+18
| | | | | | | | | | | | | | | | | | | | | 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.
* timer: remove an unused helper functionwm42018-05-242-16/+0
| | | | It's also dumb.
* thread_pool: add a helper functionwm42018-05-242-10/+30
| | | | | The behavior of mp_thread_pool_queue() doesn't or shouldn't change, but the new helper function requires touching its logic.
* thread_pool: move comments to .h filewm42018-05-242-17/+17
|
* command: make loadlist command async and abortablewm42018-05-245-7/+15
| | | | | | | | | | 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-245-54/+96
| | | | | | | | | | | | | | | | | | | | | 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.
* demux: add a "cancel" fieldwm42018-05-245-5/+8
| | | | | Instead of relying on demuxer->stream->cancel. This is better because the stream is potentially closed and replaced.
* stream_file: use a separate mp_cancel thingwm42018-05-241-2/+8
| | | | | | | | | | | | | The intention is to avoid that the parent mp_cancel retains the internally allocated wakeup pipe. File FDs are a relatively scarce resource, so try to avoid having too many. This might matter for subtitle files, for which it is relatively likely that they are loaded in large quantities. demux_lavf.c will close the underlying stream for most subtitle files, and now it will free the wakeup pipe too. Actually, there are currently only 1 or 2 mp_cancel objects per mpv core, but this could change if every external subtitle track gets its own mp_cancel in later commits.
* thread_tools: unify mp_cancel POSIX/win32 paths, add featureswm42018-05-242-52/+153
| | | | | | | | | | | | | | | The OS specifics are merged because the resulting ifdeffery is not much worse than the old ifdeffery, but the logic that is now shared is becoming more complex. Create all objects lazily. The intention is to make mp_cancel instances cheaper. POSIX pipes and win32 Events are pretty heavy weight, and are only needed in special situations. Add a mechanism to "chain" mp_cancel instances. Needed by the later commits for whatever reasons. Untested on win32.
* misc: add linked list helperswm42018-05-242-0/+269
| | | | | | | | | | | | | | | | This provides macros for managing intrusive doubly linked lists. There are many ways how to do those in a "generic" way in C. For example Solaris style lists are pretty nice: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/list.h https://github.com/illumos/illumos-gate/blob/master/usr/src/common/list/list.c I even have an independent implementation of this, which could be ISC licensed. But I think it's easier to vomit ~100 lines of preprocessor garbage, which has a lower footprint, and I think it wins slightly on the side of type safety, simplicity, and ease of use, even if it doesn't look as magically nice.
* thread_tools: minor simplificationwm42018-05-241-3/+1
|
* misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-2415-145/+171
| | | | | | | | | | | | 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.
* cmd: do not use a random value for MP_CMD_OPT_ARGwm42018-05-241-1/+1
| | | | | | | | | | | This flag is used only by the command parser. Its value overlapped with some of the existing m_option flags, but only flags that did not matter for the command parser (i.e. the flag bits used had mostly private uses in each component). It's still a bit unclean and dangerous to use an essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it. Since M_OPT_OPTIONAL_PARAM has a slightly longer name than MP_CMD_OPT_ARG, I'm going to keep the old name.
* input: slightly improve --input-cmdlist outputwm42018-05-242-6/+7
| | | | | Output argument names, whether varargs are used, and indicate optional arguments correctly (instead of only half of them).
* command: give named arguments to almost all commandswm42018-05-245-249/+409
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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".)
* json: add some non-standard extensionswm42018-05-243-7/+77
| | | | | Also clarify this and previously existing differences to standard JSON in ipc.rst.
* json: format slightly nicer escape sequenceswm42018-05-242-6/+20
| | | | | | Make use the escape sequences allowed by JSON. Also update the linked RFC to the newest one.
* test: add tests for json parser/formatterwm42018-05-241-0/+86
| | | | This should have been done sooner.
* misc: move some helper code from client.cwm42018-05-243-49/+56
| | | | | (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.
* manpage: mention that fd:// file descriptors may be modifiedwm42018-05-241-0/+2
| | | | | For example, we call setmode() to switch a FD from text to binary mode on garbage OSes.
* stream_file: properly detect stdin as pipewm42018-05-241-17/+16
| | | | | | | | | | | | There is some code that checks a FD for whether it is a regular file or not. If it's not a regular file, it e.g. enables use of poll() to avoid blocking forever. But this was done only for FDs that were open()ed by us, not from stdin special handling or fd://. Consequently, " | mpv -" could block the player. Fix this by moving the code and running for it on all FDs. Also, set p->regular_file even on mingw.
* vd_lavc: minor simplification for get_format fallbackwm42018-05-241-7/+1
| | | | | | | | | | | The default get_format does exactly do this, so we don't need to duplicate it. The only potential problem with this is that the logic doesn't entirely prevent that the avcodec_default_get_format hw_device_ctx path is triggered, which would probably work, but has unknown consequences and interactions. But the way the logic currently works it can't happen, provided the hwaccel metadata libavcodec provides is correct.
* manpage: remove a reference to a removed optionwm42018-05-241-2/+1
|
* demux: late streams on start shouldn't restrict the seek rangewm42018-05-241-1/+9
| | | | | | If a stream starts later than the others at the start of the file, it shouldn't restrict the seek range to the time stamp where it begins. This is similar to the previous commit, just for the other end.
* demux: streams that reached EOF shouldn't restrict the seek rangewm42018-05-241-6/+20
| | | | | | | | | | | | | | | | | | | Normally, the seek range is the minimum overlap of the cached ranges of each stream. But if one of the streams ends earlier, this leads to the seek range getting cut off, even if you could seek there. Change it so that EOF streams cannot restrict the end of the seek range. They can only extend it. This is the opposite from not-EOF streams, so they need to be handled separately. In particular, they get exluded from normal end range calculation, but when full EOF is reached, all streams are EOF, and the maximum end time can be used to set the seek end time. (In theory we could also take the max with the demuxer signaled total file duration, but let's not for now.) Also, if a stream is completely empty, essentially skip it, instead of considering the range unseekable. (Also, we don't need to mess with seek_start in this case, because it will be NOPTS and is skipped anyway.)
* demux: fix/improve aspects of EOF signalingwm42018-05-241-9/+14
| | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
* client API: kill async commands on terminationwm42018-05-245-14/+65
| | | | | | | | | | | 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.
* demux_lavf: remove ffm blacklist entrywm42018-05-241-2/+0
| | | | ffm (ffserver) was removed from ffmpeg.
* ipc: some user-visible changes to prepare for making all commands asyncwm42018-05-243-1/+18
| | | | | | | | | | | | | | | I wanted to put all commands through mpv_command_node_async() instead of mpv_command_node(). Using synchronous commands over a synchronous transport doesn't make sense anyway. This would have used the request_id field in IPC requests as reply ID for the async commands. But the latter need to be [u]int64, while the former can be any type. To avoid that we need an extra lookup table for mapping reply IDs to request_id values, we now require that request_id fields are integers. Since this would be an incompatible change, just deprecate non-integers for now, and plan the change for a later time.
* ipc: cosmetic: switch a negated if/elsewm42018-05-241-3/+3
|
* ipc: alias set_property_string to set_propertywm42018-05-242-28/+4
| | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
* lua: expose mpv_abort_async_command()wm42018-05-244-3/+47
| | | | Also somewhat cleans up mp.command_native_async() error handling.
* command: make "subprocess" explicitly abortablewm42018-05-242-5/+9
| | | | Now mpv_abort_async_command() can be used to stop the process.
* command: add a way to abort asynchronous commandswm42018-05-2412-9/+169
| | | | | | | | | | | | 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-243-30/+7
| | | | | | | | 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-244