summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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-118/+41
| | | | | | | 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-245-0/+108
| | | | | | | 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.
* input: add glue code for named argumentswm42018-05-244-47/+248
| | | | | | | | | | Named arguments should make it easier to have long time compatibility, even if command arguments get added or removed. They're also much nicer for commands with a large number of arguments, especially if many arguments are optional. As of this commit, this can not be used, because there is no command yet which supports them. See the following commit.
* node: move a mpv_node helper from ipc.c to shared codewm42018-05-243-14/+17
| | | | This particular one is needed in a following commit.
* thread_pool: set thread namewm42018-05-241-0/+3
|
* 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-243-1/+7
| | | | (Why the fuck are there up to 20 mouse buttons?)
* TOOLS: add a stupid test program for Lua async commandswm42018-05-241-0/+53
|
* lua: expose async commandswm42018-05-243-0/+49
| | | | 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-243-12/+33
| | | | This was not done sooner out of laziness.
* client API: clarify asynchronous call ordering non-guaranteeswm42018-05-241-6/+3
| | | | | | | | | | | | | | Both asynchronous and synchronous calls used to be put into the core's dispatch queue. Also, asynchronous calls were actually synchronous, just without forcing a wait on the client's thread. This meant that both kinds of calls were always strictly ordered. A longer time ago, synchronous calls were changed to simply lock the core. This could possibly lead to reordering. Recently, some commands were changed to run on worker threads, which made the order even looser. Also remove another now incorrect doxygen comment regarding async commands.
* input: remove unused fieldwm42018-05-241-1/+0
| | | | This was forgotten in commit fb9bbf2a0d7f8.
* screenshot: change async behavior to be in line with new semanticswm42018-05-245-130/+86
| | | | | | | | | | | | | | | | | | | | | | 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.)
* manpage: mention that --no-correct-pts can break seeking toowm42018-05-241-2/+2
|
* player: make all external file loading actions asyncwm42018-05-244-23/+93
| | | | | 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-244-7/+24
| | | | | | | | | | 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-2410-47/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-243-43/+142
| | | | | | | | | | | | 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).
* misc: add a synchronization helperwm42018-05-243-0/+102
| | | | | | | | | | | | | | | | | This is almost like rendezvous(), except it allows async wakeup, and does not require global state. It will be used by a later commit. struct mp_waiter is intended to be allocated on the stack, and uses an initializer including PTHREAD_MUTEX_INITIALIZER. This is the first case in mpv that it uses PTHREAD_MUTEX_INITIALIZER for stack-allocated mutexes. It seems POSIX still does not allow this formally, but since POSIX is worth less than used toilet paper, I don't really care. Modern OSes use futexes, which means you can make _every_ memory location a lock, and this code tries to make use of it, without using OS specific code. The name of the source file is rather generic, because I intend to dump further small helpers there (or maybe move mp_rendezvous() to it).
* input: move an enum back to its correct placewm42018-05-242-13/+13
| | | | This was accidentally moved together with the cmd stuff.
* command: handle list commands like normal commandswm42018-05-242-11/+11
| | | | Pretty annoying.
* dispatch: add an assert()wm42018-05-241-0/+1
|
* client API: some doxygen fixes/additionswm42018-05-243-6/+28
|
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-246-5/+36
| | | | | | | | | | | | | | | 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: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_lavf: co-locate disposition checksAman Gupta2018-05-241-2/+2
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* waf: require wayland-protocols >= 1.14Rostislav Pehlivanov2018-05-201-1/+1
| | | | Needed for the new xdg-wm tiling enums.
* wayland_common: require wl_compositor of version 3Rostislav Pehlivanov2018-05-201-3/+2
| | | | | We already did require it, in order to call set_buffer_scale. This just makes it error out more gracefully.
* wayland_common: fix maximized stateRostislav Pehlivanov2018-05-202-13/+22
| | | | Window size should not change if the window has been maximized or tiled.
* vo_gpu: allow higher icc-contrast and improve loggingNiklas Haas2018-05-172-3/+4
| | | | | | | | | | With the advent of actual HDR devices, my real measured ICC profile has an "infinite" contrast, since the display is completely off on pure black inputs. 100k:1 might not be enough, so let's just bump it up to 1m:1 to be safe. Also, improve the logging in the case that the detected contrast is too high by default.
* stats: show sample format of audio tracksfan52018-05-171-0/+1
|
* waftools: update clang_compilation_databaseBin Jin2018-05-171-13/+33
| | | | | The old copy is broken with waf-1.9.8, update to the latest commit (waf-project/waf@5e4b86b81df3b9819738d757eb8d2c8646ef0ede) instead.
* manpage: fix typoNiklas Haas2018-05-171-1/+1
|
* manpage: clarify target-prim/trc=auto behaviorNiklas Haas2018-05-171-2/+6
| | | | | | | This logic has been changed throughout the years, notably in 38ac5d5 and 3bdbf6. Update the documentation to reflect the current state. Closes #5834.
* m_option: fix duplicate flag valuePhilip Sequeira2018-05-131-2/+2
|
* wscript: Remove code check for cuda hwaccelPhilip Langdale2018-05-102-17/+1
| | | | | | This was there originally to detect too-old versions of ffmpeg. We now only support >= 4.0, so it's not relevant. We just need the dependencies to be present.
* drm_atomic: Fix memory leaks in drm_atomic_createAnton Kindestam2018-05-081-34/+33
|