summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* options: make imgfmt options always accept "no"wm42020-04-092-6/+3
| | | | | | | | This was optional, with the intention that normally such options require a valid format. But there is no reason for this (at least not anymore), and it's actually more logical to accept "no" in all situations this option type is used. This also gets rid of the weird min field special use.
* options: fix ab-loop-* propertieswm42020-04-093-4/+7
| | | | | | | | | | | These used ".min = MP_NOPTS_VALUE" to indicate certain exceptions. This broke with the recent change to how min/max are handled, which made setting min or max mean that a value range is used, thus setting max=0. Fix this by not using magic a value in .min; replace it with a proper flag. Fixes: #7596
* lua: wrap existing allocator instead of reimplementing itNiklas Haas2020-04-091-16/+12
| | | | | | | | This is the proper fix for 1e7802. Turns out the solution is dead simple: we can still set the allocator with lua_getallocf / lua_setalloc. This commit makes memory accounting work on luajit as well.
* lua: disable memory accounting for luajitNiklas Haas2020-04-091-0/+7
| | | | | | | | This is a stopgap measure. In theory we could maybe poll the memory usage on luajit, but for now, simply reverting this part of fd3caa26 makes Lua work again. (And we can still collect cpu usage metrics) Proper solution pending (tm)
* manpage: finish a sentencewm42020-04-091-1/+2
|
* ipc: add --input-ipc-client optionwm42020-04-096-7/+57
| | | | | | | | | While --input-file was removed for justified reasons, wanting to pass down socket FDs this way is legitimate, useful, and easy to implement. One odd thing is that Fixes: #7592
* stats: some more performance graphswm42020-04-0915-11/+519
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* input: add binding to quit on ctrl+wsfan52020-04-041-0/+1
| | | | Other GUI applications typically handle this as "close document" or "close window".
* stats: fix previous commitwm42020-04-031-2/+2
| | | | | The previous commit included a rendering error of the "Speed:" line, caused by incorrect copy&paste.
* stats: move input speed to cache page, make it a graphwm42020-04-031-13/+12
| | | | | | | I think that makes more sense. And also remove the graph from the total cache usage, since that wasn't very interesting. So there's still a total of 2 graphs.
* command: make input speed available as part of cache statge propertywm42020-04-032-0/+9
| | | | | | That's where it comes from after all. The other property does not have much of a reason to exist anymore, but there's no real reason to remove it either.
* umpv: convert to python 3wm42020-04-031-2/+2
| | | | Sigh.
* player: make a function staticwm42020-04-032-2/+1
|
* build: only check for EGL pc in one build optionNicolas F2020-04-021-7/+5
| | | | | | | | | | | | | | | | | Previously, EGL as provided by a pkg-config was checked for independently in several places. The effect this had is that --disable-egl would not actually disable EGL from the build, as this only affected the "egl" option relied upon by egl-x11. wayland-gl and egl-drm did their own EGL checks. By making wayland-gl and drm-egl depend on egl instead, we fix this behaviour and can simplify egl-helpers a bit, as we can now simply check whether egl or one of the other features providing some non-pc egl is enabled, instead of checking every single thing that might be pulling in egl. Future work could make the "egl" option just be a catchall for any EGL implementation, so that brcmegl and angle and Android can piggyback on the egl option as well.
* ytdl_hook: enable runtime changes of script optionssfan52020-03-291-1/+4
|
* ao_oss: remove this audio outputwm42020-03-285-681/+1
| | | | | | | | | | Ancient Linux audio output. Apparently it survived until now, because some BSDs (but not all) had use of this. But these should work with ao_sdl or ao_openal too (that's why these AOs exist after all). ao_oss itself has the problem that it's virtually unmaintainable from my point of view due to all the subtle (or non-subtle) difference. Look at the ifdef mess and the multiple code paths (that shouldn't exist) in the removed source code.
* ao_rsound: remove this audio outputwm42020-03-285-170/+0
| | | | | | I wonder what this even is. I've never heard of anyone using it, and can't find a corresponding library that actually builds with it. Good enough to remove.
* ao_sndio: remove this audio outputwm42020-03-285-338/+0
| | | | | | It was always marked as "experimental", and had inherent problems that were never fixed. It was disabled by default, and I don't think anyone is using it.
* manpage: clarify some event/hook detailswm42020-03-281-4/+18
|
* input: remove deprecated --input-file optionwm42020-03-2811-192/+2
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* umpv: change from legacy FIFO to socketwm42020-03-281-23/+14
| | | | --input-file is deprecated, and the JSON IPC is saner anyway.
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-277-15/+70
| | | | | | May or may not help when dealing with playlist loading in scripts. It's supposed to help with the mean fact that loading a recursive playlist will essentially edit the playlist behind the API user's back.
* client API: another minor clarification for conveniencewm42020-03-271-1/+3
| | | | The previous commit actually makes use of this.
* ipc: fix recently added memory leakwm42020-03-271-1/+3
| | | | Sucks.
* scripting: remove race condition when toggling internal scriptswm42020-03-266-31/+31
| | | | | | | | | | Scripts such as the OSC can be loaded and unloaded at runtime by toggling the option that enables them. (It even works, although normally it's only used to control initial loading.) Unloading was racy because it used the client name; fix this. The load-script change is an accidental feature. And probably useless.
* command: use client IDs for hookswm42020-03-264-12/+24
| | | | | Removes weird potential race conditions when a client is removed and a new one with the same name is created.
* client API: add a per client unique IDwm42020-03-264-0/+47
| | | | | | I mostly intend this for internal purposes. Probably pretty useless for external API users, but on the other hand trivial to expose. While it makes a lot of sense internally, I'll probably regret exposing it.
* client API: update MPV_EVENT_PLAYBACK_RESTART docswm42020-03-261-3/+3
| | | | Ordered chapters haven't used user-visible seeks for over 4 years.
* command: make revert seek command use time from end of seekwm42020-03-261-0/+3
| | | | | | | | | This time is set on every seek (but when initiating it). A new seek longer than 2 seconds after this is counted as separate seek for the sake of the revert seek command. If a seek takes a bit longer, this removes time from these 2 seconds. This commits resets it on the end of the seek. (Doing anything special for seeks that take longer than 2 seconds is out of scope of this commit.)
* video: report negative subtitle/OSD margins if necessarywm42020-03-261-4/+4
| | | | | | | | | | | | | | Until now, it used only coordinates clipped to the screen for this, which meant no negative margins were ever reported to libass. This broke proper rendering of explicitly positioned ASS events (libass simply could not know the real video size in this case.) Fix this by reporting margins even if they're negative. This makes it apparently work correctly with vo_gpu at least. Note that I'm not really sure if anything in the rendering chain required non-negative margins. If so, and that code implicitly assumed it, I suppose crashes and such are possible.
* travis: reactivate notifications on failureder richter2020-03-251-1/+1
|
* travis: fix config validation warningsder richter2020-03-251-3/+1
| | | | | private keys should be prefixed with an underscore (_). the sudo key is deprecated and doesn't influence anything anymore.
* vd_lavc: make hwdec fallback message more consistentwm42020-03-241-4/+1
| | | | | | | | | | | The "rule" is that a fallback warning message should be shown only shown if software decoding was used before, or in other words when either hwdec was enabled before, but the stream suddenly falls back, or it was attempted to enable it at runtime, and it didn't work. The message wasn't printed the first time in the latter case, because hwdec_notified was not set in forced software decoding mode. Fix it with this commit. Fortunately, the logic becomes simpler.
* lua: mp.get_property[_osd] don't need special handling anymoreAvi Halachmi (:avih)2020-03-231-11/+2
| | | | Because they recently became normal autofree functions.
* lua: readdir: fix double closedir, use one more autofreeAvi Halachmi (:avih)2020-03-221-3/+1
| | | | | The double closedir is a regression from the previous commit, which also forgot to use the autofree context with the fullpath string.
* lua: autofree: use in few more places where it could leakAvi Halachmi (:avih)2020-03-221-14/+49
| | | | | | | This also uses talloc destructors- like the JS autofree does. The lua autofree is now used at the same places where the JS autofree is used.
* lua: autofree: the ctx is now an argumentAvi Halachmi (:avih)2020-03-221-40/+41
| | | | | | | | | | | There's no more need to call mp_lua_PITA to get the ctx, and the autofree prototype is now enforced at the C level at compile time. Also remove the redundant talloc_free_children at these functions since it's now freed right after the function completes. Also, rename auto_free_node to steal_node_allocations to be more explicit and to avoid confusion with the autofree terminology.
* lua: use an autofree wrapper instead of mp_lua_PITAAvi Halachmi (:avih)2020-03-221-38/+51
| | | | | | | | | | | | | | | | | | | Advantages of this approach: - All the resources are released right after the function ends regardless if it threw an error or not, without having to wait for GC. - Simpler code. - Simpler lua setup which most likely uses less memory allocation and as a result should be quicker, though it wasn't measured. This commit adds the autofree wrapper and uses it where mp_lua_PITA was used. It's not yet enforced at the C level, there are still redundant talloc_free_children leftovers, and there are few more places which could also use autofree. The next commits will address those.
* encode: fix occasional init crash due to initialization order issueswm42020-03-222-9/+7
| | | | | | | | Looks like the recent change to this actually made it crash whenever audio happened to be initialized first, due to not setting the mux_stream field before the on_ready callback. Mess a way around this. Also remove a stray unused variable from ao_lavc.c.
* lua: restore recent end-file event, and deprecate itwm42020-03-224-6/+18
| | | | | | | | | | | | Lua changed behavior for this specific event. I considered the change minor enough that it would not need to go through deprecation, but someone hit it immediately and ask on the -dev channel. It's probably better to restore the behavior. But mark it as deprecated, since it's problematic (mismatch with the C API). Unfortunately, no automatic warning is possible. (Or maybe it is, by playing sophisticated Lua tricks such as setting a metatable and overriding indexing, but let's not.)
* ci: remove missed remnants of libass from the macOS script as wellJan Ekström2020-03-221-1/+1
|
* ci: remove libass enablementJan Ekström2020-03-222-2/+0
| | | | This is no longer a configurable option.
* travis: shut the fuck upwm42020-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Travis is currently having "problems" and is spamming IRC all the time with pointless failure notifications. Make it so that it hopefully sends a message only when it goes from success to failure, which should exclude these cases. While I'm at it, I'd like to complain how idiotic it is to store CI configuration in a project's source repository. Such a repository should only contain things that are inherently part of the code's function, not part of the organization. You don't store bug reports, build results, the website, developer access controls, etc. in this repository either. But for CI it's supposed to be OK? I'm all for this "configuration as code" thing, but what it should mean is that you store configuration files in some git managed repository, NOT necessarily that you dump them into the main source code repo. There are many arguments why it should not be there, such as this very commit. I have a feeling this is mostly just because all these idiotic web services just want to advertise their shit and bind customers by not giving easy ways to treat source code and CI service configuration orthogonal. And so, the source code repo gets clobbered with stupid shit (both in the set of files and the commit history). It's fairly idiotic and my tolerance for it is waning. (Oh, of course you could probably jump through hoops to make it a separate repo, but I bet that is complicated and has all kinds of downsides because it won't be the way "it's meant to be used".)
* encode: deprecate encoding modewm42020-03-222-1/+3
| | | | | While I'd like to keep it, I'm apparently the maintainer now, and I have no idea what the heck some of this code does, so it's deprecated.
* encode: add some shit that does some shitwm42020-03-221-3/+6
| | | | | | | | ????????????? Makes no sense, can endless loop, but whatever. Part of #7524.
* encode: restore audio muxer timebase usewm42020-03-223-0/+12
| | | | | | Seems to crash hard if an error happens somewhere at init. Who cares. Part of #7524.
* encode: fix whitespacewm42020-03-221-1/+1
|
* js: make wait_event autofreeAvi Halachmi (:avih)2020-03-221-6/+5
| | | | | | | | | | | | The VM could throw at pushnode and before mpv_free_node_contents, which would have resulted in leaked content. Now this case is handled without leaks. Note: the lua code still leaks on such case, but mp_lua_PITA doesn't have destructors like the JS autofree has, which, specifically here, can do mpv_free_node_contents. So TODO: enhance the lua PITA code to behave more similar to the JS autofree.
* js: use unified events (match 218d6643, 8a58a699)Avi Halachmi (:avih)2020-03-211-98/+4
|
* lua: simplify furtherwm42020-03-211-8/+1
| | | | As suggested by avih. Obviously this was unnecessarily convoluted.
* client API, lua: unify event code furtherwm42020-03-213-54/+38
| | | | | | | | | Move some parts that can be generic to the client API code. It turns out lua.c doesn't need anything special. This adds the "id" field. I think this was actually missing from the JSON IPC code (i.e. it's a very recent regression that is fixed with this commit).
* command: fix accidental stack dumpingwm42020-03-211-1/+1
|
* client API, lua, ipc: unify event struct returnwm42020-03-219-259/+294
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both Lua and the JSON IPC code need to convert the mpv_event struct (and everything it points to) to Lua tables or JSON. I was getting sick of having to make the same changes to Lua and IPC. Do what has been done everywhere else, and let the core handle this by going through mpv_node (which is supposed to serve both Lua tables and JSON, and potentially other scripting language backends). Expose it as new libmpv API function. The new API is still a bit "rough" and support for other event types might be added in the future. This silently adds support for the playlist_entry_id fields to both Lua and JSON IPC. There is a small API change for Lua; I don't think this matters, so I didn't care about compatibility. The new code in client.c is mashed up from the Lua and the IPC code. The manpage additions are moved from the Lua docs, and made slightly more "general". Some danger for unintended regressions both in Lua and IPC. Also damn these node functions suck, expect crashes due to UB. Not sure why this became more code instead of less compared to before (according to the diff stat), even though some code duplication across Lua and IPC was removed. Software development sucks.
* client API: add a playlist entry unique IDwm42020-03-217-2/+53
| | | | | | This should make dealing with some async. things easier. It's intentionally not a globally unique ID.
* player: add potentially forgotten property change triggerwm42020-03-211-0/+1
| | | | | | Unfortunately, merely changing the playlist current position affects the flags returned by the "playlist" property, so the entirely thing needs to be marked as changed. Seems to be a design mistake.
* player: add a number of new playlist contol commands/propertieswm42020-03-215-19/+156
| | | | | | | | | | | | | | | | | | | | | | | Should give a good deal more explicit control and insight over the player state. Some feel a bit pointless, and/or expose internal weirdness. However, it's not like the existing weirdness didn't exist before, or can be made go away. (In part, the weirdness is because certain in-between states are visible. Hiding them would make things simpler, but less flexible.) Maybe this actually gives users a better idea how the API _should_ look like, too. On a side note, this tries to really guarantee that mpctx->playing is set between playback start/end. For that, the loadfile.c changes assume that mpctx->playing is set (guaranteed by code above the change), and that playing->filename is set (probably could never be false; was broken before and actually would have crashed if that could ever happen; in any case, also add an assert to playlist.c for this). playlist_entry_to_index() now tolerates playlist_entrys that are not part of the playlist. This is also needed for mpctx->playing.
* player: playlist-pos now use -1 for "no entry selected"wm42020-03-214-11/+17
| | | | | | | | | | | | | | | | | | | | | It's odd that this state is observable, but is made implicit by making the property unavailable. It's also odd that an API user cannot directly put the player into such a state. Just allow reading/writing -1 (or in fact, any out of bounds index) for this case. I'm also refraining from using OPT_CHOICE for the "no selection" case, because although that would be cleaner in theory, it would cause only problems to API users due to the more complex property type (worse is better). One reason for not restricting the integer range on the input property anymore is that if there are no playlist elements, the range would contain only 1 integer, which cannot be represented anymore since the recent m_option change. This was actually broken with 1 element playlists before (and still is, with the constricted type for OSD and the add/cycle commands). Doesn't matter too much.
* demux: average reported download speed some morewm42020-03-211-1/+5
| | | | | | Currently, this reported the number of received bytes per second. Improve this slightly by averaging over 2 seconds (but still updating every second).
* manpage: improve loadfile descriptionwm42020-03-211-3/+9
|
* osc: avoid using a deprecated eventwm42020-03-211-1/+1
| | | | The new code is pretty much equivalent.
* client API: actually warn against enabling any deprecated eventswm42020-03-211-2/+18
| | | | | | Like it was done for the "tick" event, but for all deprecated events. Not entirely effective, since the C API enables all events by default.