summaryrefslogtreecommitdiffstats
path: root/libmpv
Commit message (Collapse)AuthorAgeFilesLines
* various: make mentions of macOS consistentder richter2024-02-212-4/+4
| | | | | change all mentions and variations of OSX, OS X, MacOSX, MacOS X, etc consistent. use the official naming macOS.
* vo: make libmpv last in the auto-probing order for cocoa-cb onlyder richter2024-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | this partially reverts commit 7b5a258. back then the only properly working vo on macOS was cocoa-cb (libmpv). it would always use the deprecated opengl cocoa backend or no vo at all. because of that libmpv was moved to the top of the auto-probing order, so the preferred vo was used on macOS only. we now have a working vulkan gpu/gpu-next backend on macOS which should be the new default vo. though disabling the auto-probing again for libmpv would probably cause the undesired behaviour on macOS that cocoa-cb would never be auto selected again. especially if not build with vulkan support or without vulkan driver on macOS, this would lead to no video output at all. so instead of completely reverting the mentioned commit, we instead move libmpv to the bottom of the auto-probing order but only auto select it when mpv was built with cocoa-cb support. this restores the previous behaviour on all other platforms besides macOS, but also lets us auto select cocoa-cb if supported.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-1/+1
|
* libmpv: add mpv_time_ns()Dudemanguy2023-10-101-2/+9
| | | | | | 9606c3fca9d568dc43711017dcb35a408c0d2883 added mp_time_ns(). Since we apparently expose the mp_time_us() to clients already, there's no reason to not also expose the new nanosecond one.
* cplugin: allow loading mpv_* symbols dynamicallyKacper Michajłow2023-09-203-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Defining MPV_CPLUGIN_DYNAMIC_SYM during plugin compilation will replace mpv_* functions with function pointers. Those pointer will be initialized when loading the plugin. It is recommended to use this symbol table when targeting Windows. The loader does not have notion of global symbols. Loading cplugin into mpv process will not allow this plugin to call any of the symbols that may be available in other modules. Instead cplugin has to link explicitly to specific PE binary, libmpv-2.dll/mpv.exe or any other binary that may have linked mpv statically. This limits portability of cplugin as it would need to be compiled separately for each of target PE binary that includes mpv's symbols. Which in practice is unrealictis, as we want one cplugin to be loaded without those restrictions. Instead of linking to any PE binary, we create function pointer for all mpv's exported symbols. For convinience names of entrypoints are redefined to those pointer so no changes are required in cplugin source code, except defining MPV_CPLUGIN_DYNAMIC_SYM. Those function pointer are exported to make them available for mpv to init with correct values during runtime, before calling `mpv_open_cplugin`. Note that those pointer are decorated with `selectany` attribute, so no need to worry about multiple definitions, linker will keep only single instance. This fixes cplugin usability on Windows. Without any API changes, only recompilation with -DMPV_CPLUGIN_DYNAMIC_SYM is needed.
* libmpv: remove not used mpv.pc.inKacper Michajłow2023-09-201-12/+0
| | | | waf leftover
* DOCS: update LGPL building instructionslights01232023-08-101-1/+1
| | | | previous build system used --enable-lgpl
* waf: remove waf as a build systemLaserEyess2023-07-232-53/+0
| | | | | | Remove waf entirely in favor of meson as the only supported build system. Waf was officially deprecated in 0.36.0, and has not been preferred over meson since 0.35.0.
* libmpv: fix file name in documentationSam Van Den Berge2023-04-111-1/+1
| | | | render_cb.h doesn't exist but render.h does.
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* test: integrate unittests with mesonDudemanguy2023-03-021-29/+0
| | | | | | | | | | | | This reworks all of mpv's unit tests so they are compiled as separate executables (optional) and run via meson test. Because most of the tests are dependant on mpv's internals, existing compiled objects are leveraged to create static libs and used when necessary. As an aside, a function was moved into video/out/gpu/utils for sanity's sake (otherwise most of vo would have been needed). As a plus, meson multithreads running tests automatically and also the output no longer pollutes the source directory. There are tests that can break due to ffmpeg changes, so they require a specific minimum libavutil version to be built.
* libmpv: add mpv_del_property() convenience functionrcombs2023-01-281-1/+11
|
* meson: add simple test executable for libmpvThomas Weißschuh2023-01-191-0/+29
| | | | This can be used to make sure that the built libmpv is functional.
* misc/random: add xoshiro random number implementationLeo Izen2022-08-171-2/+0
| | | | | | | Add xoshiro as a PRNG implementation instead of relying on srand() and rand() from the C standard library. This, in particular, lets us avoid platform-defined behavior with respect to threading.
* client API: always export symbols on windowsDudemanguy2022-05-111-3/+3
| | | | | | | | Windows is weird and symbols weren't actually being exported. This is because __GNUC__ is defined and picked up in the conditional, but __attribute__((visibility("default"))) doesn't actually export anything to the dll. Instead, just check if we have win32 defined first and then always set __declspec(dllexport). Fixes #10171.
* client API: also export mpv_stream_cb_add_roDudemanguy2022-03-111-2/+2
| | | | | | | 20c4036daa680ebf9d379c9a7566bcf3ae12d405 switched to hiding all symbols by default and exporting the ones we want with MPV_EXPORT. However, the mpv_stream_cb_add_ro function was missed and it is part of the client API. Export it too. Fixes #9971.
* player: make deprecated track/chapter/metadata events internalsfan52021-12-151-40/+0
| | | | | We still need these to track or notify of modifications to certain properties, but they're now gone from the libmpv ABI.
* libmpv: remove opengl_cb API and other deprecated symbolssfan52021-12-154-508/+7
| | | | | | Not all deprecated symbols were removed. Only three events were removed for now since these are not used internally. This bumps the library version to 2.0.
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-151-2/+1
|
* client API: also export mpv_client_api_versionDudemanguy2021-11-271-1/+1
| | | | | | | 20c4036daa680ebf9d379c9a7566bcf3ae12d405 switched to using symbol visibility attributes for mpv client api functions (for the meson build at least). Unfortunately mpv_client_api_version was mistakenly missed. We need to export this function as well. Fixes #9531.
* client API: use symbol visibility attributesDudemanguy2021-11-192-68/+77
| | | | | | | | In mpv, the only symbols we want to export are the functions from the client API. This is accomplised using a specific .def whitelist, but the main compilers people use (gcc or clang) like these attributes since it allows for further optimizations. MSVC also allegedly supports this as well (untested of course), so use __declspec for tht case.
* client API: update alignment requirements for software renderingwm42020-09-171-9/+12
| | | | | | | Previous commit fixes it for libswscale. The libzimg path has extra code to copy by slice, but it still may access pixel groups using normal memory accesses (for example, reading rgba pixel data via uint32_t), so document a minimum alignment requirement per pixel format.
* client API: note about libswscale corrupting memorywm42020-08-201-1/+10
| | | | | | The software rendering API makes libswscale directly write into supplied user memory. As such, weird memory corruption bugs on non-optimal buffer configurations are exposed to the user.
* command: extend subprocess command stdin, change behaviorwm42020-08-161-1/+2
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* client API: fix misleading remarkAlcaro2020-08-131-2/+1
|
* client API: fix incorrect documentation in sw rendererwm42020-08-121-4/+4
| | | | | | This was incorrect, and grossly misleading. It created the impression that the buffer is passed to mpv_render_context_create(), instead of mpv_render_context__render().
* client API: comment about signal handlerswm42020-07-201-0/+2
| | | | | | | | | | | | Sharing a process sure is hard in POSIX. The rationale is that you'd have to handle EINTR on every single blocking syscall. stream_file.c does not seem to handle it on read() calls. It appears that on most modern systems, this can happen only if you call sigaction(), and incompetently forget to add SA_RESTART. signal() usually adds it.
* client API: add software rendering APIwm42020-07-082-1/+101
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* client API: correct an outdated commentwm42020-05-061-2/+1
|
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-271-0/+21
| | | | | | 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.
* client API: add a per client unique IDwm42020-03-262-0/+19
| | | | | | 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.
* client API, lua, ipc: unify event struct returnwm42020-03-212-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-211-0/+17
| | | | | | This should make dealing with some async. things easier. It's intentionally not a globally unique ID.
* player: fix subtle idle mode differences on early program startwm42020-03-211-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user manages to run a "loadfile x append" command before the loop in mp_play_files() is entered, then the player could start playing these. This isn't expected, because appending files to the playlist in idle mode does not normally start playback. It could happen because there is a short time window where commands are processed before the loop is entered (such as running the command when a script is loaded). The idle mode semantics are pretty weird: if files were provided in advance (on the command line), then these should be played immediately. But if idle mode was already entered, and something is appended to the playlist using "append", i.e. without explicitly triggering playback, then it should remain in idle mode. Try to follow this by redefining PT_STOP to strictly mean idle mode. Remove the playlist->current check from idle_loop(), since only the stop_play field counts now (cf. what mp_set_playlist_entry() does). This actually introduces the possibility that playlist->current, and with it playlist-pos, are set to something, even though playback is not active or being started. Previously, this was only possible during state transitions, such as when changing playlist entries. Very annoyingly, this means the current way MPV_EVENT_IDLE was sent doesn't work anymore. Logically, idle mode can be "active" even if idle_loop() was not entered yet (between the time after mp_initialize() and before the loop in mp_play_files()). Instead of worrying about this, redo the "idle-active" property, and deprecate the event. See: #7543
* client API: remove deprecated qthelper.hpp headerwm42020-03-061-386/+0
| | | | | | | | | | | | No replacement. Qt or C++ code has no business in this repository, and new code (even if it uses Qt) should not use it. Get rid of it. We consider the libmpv API itself as stable. Symbols can be deprecated, but not be removed. However, qthelper.hpp was never considered part of the libmpv API. There no ABI implications either, since it's a header- only implementation that uses C API symbols only. It's just a header provided for convenience for Qt/C++ programs (i.e. extremely limited usefulness).
* client API: minor clarification when asynchronous commands send eventswm42020-02-241-0/+5
|
* client API: document requirement about PID managementwm42020-02-191-0/+3
| | | | Basically, UNIX sucks. (Not as much as the other POS of course.)
* client API: document srand() usewm42020-01-211-0/+2
|
* client API: deprecate tick eventwm42019-12-221-3/+4
| | | | | This is conceptually outdated and should not exist. This affects Lua scripting and JSON IPC too.
* client API: remove comment about error statuswm42019-12-191-1/+0
| | | | | | mpv_event_property (for property observation) actually never sets an error status. You cannot distinguish between unavailable properties and properties which returned an error. Not sure if it ever did.
* DOCS: explicitly mention that property observing has an initial eventwm42019-10-081-1/+4
| | | | | This is definitely intended from the start, and it's generally useful, but for some reason it wasn't actually documented.
* DOCS/compatibility.rst: add this filewm42019-10-051-0/+2
| | | | | | | | | | | Another thing nobody will read. I'm attempting to document the rules by which incompatible changes can be made. These rules have always been present in this project, but I don't think they were written down. Or maybe they were, but I forgot where. I think due to the time of the day it became increasingly incoherent (not necessarily near the end of the text). Hopefully no logical or freudian lapses in there.
* manpage: clarify some details about async. commands and "subprocess"wm42019-10-041-0/+2
| | | | | | | | | There's potential confusion about how long a process started with the "subprocess" command is allowed to live. Add some more explanations regarding "subprocess" specifics (such as the playback_only field), and things that apply to asynchronous commands in general. Partially for #7025.
* stream_cb: add cancel_fn callbackAman Gupta2019-09-272-1/+18
| | | | | | | | This allows stream_cb backends to implement blocking behavior inside read_fn, and still get notified when the user wants to cancel and stop playback. Signed-off-by: Aman Gupta <aman@tmm1.net>
* stream_cb: fix a typo in a commentwm42019-09-271-1/+1
|
* client API: be explicit about usage rules and deadlocks some morewm42019-09-261-0/+7
| | | | | | | I think a popular libmpv application did exactly this: enabling advanced control, and then receiving deadlocks. I didn't confirm it, though. In any case, the API docs should avoid tricking users into making this easy mistake.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-262-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* client API: add mpv_command_retDark2019-09-212-0/+17
| | | | | | | | | | This change adds a version of `mpv_command` that also returns a result. The main rationale behind this is `mpv_command_node` requires defining multiple structs before you can even use it, which results in a pretty painful to use interface just to get the result from a command. There isn't really a good name for this function, so I'm open to suggestions on a better name for it.
* client API, vo_libmpv: document random deadlock problemswm42019-09-201-0/+4
| | | | | | | I guess trying to make DR work on libmpv was a mistake. I never observed such a deadlock, but it's looks like it's theoretically possible.
* client API: document unfortunate render API threading requirementwm42019-09-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is because dr_helper.c calls pthread_self(). It's used to avoid deadlocks. This was not a problem internal to mpv (dr_helper.c was first created for vo_gpu.c), but it accidentally leaked as an unintended consequence of an implementation detail to libmpv. This problem existed for MPV_RENDER_PARAM_ADVANCED_CONTROL users, ever since it was introduced. Maybe this could be done differently, but it's certainly very tricky. the pthread_t is used to avoid deadlocks when the caller is on the same thread as the one which needs to handle the calls. The critical code is in free_dr_buffer_on_dr_thread(). It's called when a DR image is free'd. Freeing a DR image requires access to the GL context, i.e. it just has to run on the "GL" thread. In libmpv's case, this is done by calling the API user's wakeup call, and the user will eventually call mpv_render_context_update() on the "GL" thread, which in turn calls mp_dispatch_queue_process() on the dispatch queue that was passed to dr_helper_create(), which then calls av_buffer_unref(), which calls gl_video_dr_free_buffer(). (God who came up with this rube goldberg shit.) The above case will typically happen when e.g. vd_lavc.c (internal mpv thread) frees images. Allocation works similarly; deallocation is just trickier because calls to free images are everywhere. Now consider if mpv_render_context_render() releases a DR image. This function is always called on the "GL" thread. Going through the dispatch queue would obviously deadlock, because according to the render API rules, the user's wakeup callback must not mpv_render_context_update(), instead it has to signal the "GL" thread, which must wait until mpv_render_context_render() returns. To avoid this deadlock, dr_helper.c checks whether the calling thread is the "GL" thread, and if so, allows a reentrant call (basically gl_video_dr_free_buffer() is called directly). While with GL, you usually will stay on the same thread, API users were in theory allowed to e.g. move the GL context to a different thread. But this dr_helper issue means this is not possible. Moreover, other APIs will not have the same thread-locality problems as GL. FUCK THIS SHIT In theory, libmpv could provide an API to "move" the context to a separate thread, but let's not start with even more broken crap like this. I'm not sure yet whether there is an easy solution. Maybe all mpv_render() function could be guarded by entry/exit functions, which set/unset a flag that dr_helper.c should use reentrant calls. libmpv users which do not set MPV_RENDER_PARAM_ADVANCED_CONTROL were never affected.
* client API: fix some commentswm42019-09-191-4/+4
|
* drm: fix libmpv ABI breakage introduced in ↵Anton Kindestam2019-09-183-16/+33
| | | | | | | | | | | | | | | 351c083487050c88adb0e3d60f2174850f869018 Extending the client-allocated mpv_opengl_drm_params struct constituted