aboutsummaryrefslogtreecommitdiffhomepage
path: root/libmpv
Commit message (Collapse)AuthorAge
* drm: rename plane options to better, invariant, namesGravatar Anton Kindestam2018-12-01
| | | | | | | | | | | | | | | | | | | | | This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
* hwdec_vaegl: Fix VAAPI EGL interop used with gpu-context=drmGravatar Anton Kindestam2018-07-09
| | | | | | | | Add another parameter to mpv_opengl_drm_params to hold the FD to the render node, so that the fd can be passed to hwdec_vaegl. The render node is opened in context_drm_egl and inferred from the primary device fd using drmGetRenderDeviceNameFromFd.
* drm/atomic: add connector to atomic contextGravatar LongChair2018-05-01
| | | | | | | | | | This patch adds - DRM connector object to atomic context. - fd property to the drm atomic object as well as a method to read blob type properties. This allows to ensure that the proper connector is picked up, especially when specifying it from the commandline, and also allows to make sure we're using the right one when embedding with interop into an application.
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesGravatar LongChair2018-05-01
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* client API: some doxygen clarificationsGravatar wm42018-04-29
| | | | | | | Strictly speaking redundant, but probably helpful. In particular I want to push MPV_RENDER_PARAM_ADVANCED_CONTROL. Not enabling this parameter is actually not very sane.
* client API: add some render API extensions for timingGravatar wm42018-04-29
| | | | | | | | | | | | Attempts to enable the following things: - let a render API user do "proper" audio-sync video timing itself - make it possible to not re-render repeated frames if the API user has better mechanisms available (e.g. waiting for a DisplayLink cycle instead) - allow the user to delay or skip redraws if it makes sense Basically this information will be needed by API users who want to be "clever" about optimizing timing and rendering.
* client API: preparations for allowing render API to use DR etc.Gravatar wm42018-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
* client API: minor clarificationGravatar wm42018-04-20
| | | | This was a bit confusing.
* client API: clarify that Display pointers etc. need to stay validGravatar wm42018-04-16
| | | | | | | | | | | | Normally, MPV_RENDER_PARAM* arguments are copied, unless documented otherwise. Of course we can't copy X11 Display or Wayland wl_display types, but for arguments that are "summarized" in a struct (like MPV_RENDER_PARAM_OPENGL_FBO), a copy is expected. Also add some unused infrastructure to make this explicit, and to make it easier to add parameter types that require a copy. Untested.
* client API: add a first class hook API, and deprecate old APIGravatar wm42018-03-26
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* client API: deprecate mpv_get_wakeup_pipe()Gravatar wm42018-03-26
| | | | I don't think anything even uses it.
* client API: add a new way to pass X11 Display etc. to render APIGravatar wm42018-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* video: add an option to tune waiting for video timingGravatar wm42018-03-15
| | | | Probably mostly useful for the libmpv render API.
* client API: deprecate qthelper.hppGravatar wm42018-03-15
| | | | | | | It's a WTF that we have something as specific in the API. It could be argued that we should provide helpers for other language and GUI toolkit combinations. Obviously that's not going to scale, and it's somewhat likely that it will bitrot. The rest is said in the API changelog.
* client API: send MPV_EVENT_SHUTDOWN only onceGravatar wm42018-03-15
| | | | | | | | | | | | Before this change, mpv_wait_event() could inconsistently return multiple MPV_EVENT_SHUTDOWN events to a single mpv_handle, up to the point of spamming the event queue under certain circumstances. Change this and just send it exactly once to each mpv_handle. Some client API users might have weird requirements about destroying their state asynchronously (and not reacting immediately to the SHUTDOWN event). This change will help a bit to make this less weird and surprising.
* client API: rename mpv_detach_destroy() to mpv_destroy()Gravatar wm42018-03-15
| | | | | Since this has clearer semantics now, the old name is just clunky and confusing.
* client API: add mpv_create_weak_client()Gravatar wm42018-03-15
|
* client API: cleanup mpv_handle terminationGravatar wm42018-03-15
| | | | | | | | | | | | | | | This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
* client API: deprecate opengl-cb API and introduce a replacement APIGravatar wm42018-02-28
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* client API: clarify license, fix some typosGravatar wm42018-02-28
|
* vo: make opengl-cb first in the autoprobing orderGravatar wm42018-02-13
| | | | | | | This should be helpful for the new OSX Cocoa backend, which uses opengl-cb internally. Since it comes with a behavior change that could possibly interfere with libmpv/opengl_cb users, we mark it as explicit API change.
* client API: be more explicit about what can be done in wakeup callbacksGravatar wm42018-01-25
| | | | Don't leave any room for interpretation.
* client API: mention that SIGPIPE is sometimes blockedGravatar wm42018-01-18
| | | | | | ipc-unix.c does this out of convenience. Since signals are global process state, this deserves a mention, since applications could in theory rely on SIGPIPE being set to something else.
* libmpv/opengl_cb.h: mention OpenGL ES 2.0 supportGravatar Leo Izen2018-01-14
| | | | | opengl_cb.h should mention GLES 2.0 support, since this support is available. Now it does mention it.
* client API: remove ytdl=no defaultGravatar wm42018-01-13
| | | | | | | | | | | | | | With the recent changes to the script it does not incur a startup delay by default due to starting youtube-dl and waiting for it. This was the main reason for making libmpv have a different default. Starting sub processes from a library can still be a bit fishy, but I think it's ok. Still mention it in the libmpv header. There were already other cases where libmpv would start its own processes, such as the X11 backend calling xdg-screensaver. (The reason why this is fishy is because UNIX process management sucks: SIGCHLD and the wait() syscall make sub processes non-transparent and could potentially introduce conflicts with code trying to use them.)
* client API: be more explicit about how to make libmpv use config filesGravatar wm42018-01-02
|
* vo_gpu: make it possible to load multiple hwdec interop driversGravatar wm42017-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
* client API: minor bump + change entry for DRM related opengl-cb changesGravatar wm42017-10-23
| | | | Commit cfcee4cfe705 forgot those.
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersGravatar Lionel CHAZALLON2017-10-23
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* client API: more opengl_cb clarificationsGravatar wm42017-08-07
| | | | Also fix a typo in ra_gl.c. Too greedy for a separate commit.
* vo_opengl: move GL state resetting to vo_opengl_cbGravatar wm42017-08-05
| | | | | | | | | This code is pretty much for the sake of vo_opengl_cb API users. It resets certain state that either the user or our code doesn't reset correctly. This is somewhat outdated. With GL implicit state being so awfully large, it seems more reasonable require that any code restores the default state when returning to the caller. Some exceptions are defined in opengl_cb.h.
* client API: drop old "no-" option emulationGravatar wm42017-06-26
| | | | | | | You could do mpv_set_option(h, "no-fs", ""), which would behave like "--no-fs" on the command line. At one point, this had to be emulated for compatibility, and printed a deprecation warning. This was almost a year ago, so remove it.
* client API: document mpv_request_log_messages() return valueGravatar wm42017-06-14
|
* vo_opengl: drop TLS usageGravatar wm42017-05-11
| | | | | | | | | | | TLS is a headache. We should avoid it if we can. The involved mechanism is unfortunately entangled with the unfortunate libmpv API for returning pointers to host API objects. This has to be kept until we change the API somehow. Practically untested out of pure laziness. I'm sure I'll get a bunch of reports if it's broken.
* client API: add MPV_ENABLE_DEPRECATED symbolGravatar wm42017-04-20
| | | | | (Of course this is on by default, because otherwise we'd randomly break downstream applications.)
* Fix use of ISC licenseGravatar wm42017-04-15
| | | | | | | | | | The license text refers a "above copyright notice", so I guess it'd be good to actually provide such a notice. Add the license to some files that were missing it (since in theory, our Copyright file says that such files are LGPL by default). Remove the questionable remarks about the license in the client API.
* manpage, client API: add some clarifications when commands use OSDGravatar wm42017-04-01
| | | | | The APIs that run commands in a more API-like manner disable OSD and string expansion by default.
* input: add "async" flagGravatar wm42017-04-01
| | | | | | | | | | | Obviously, this has no effect on commands which do not support this explicitly. A later commit will enable this for screenshots. Also add some wording on mpv_command_async(), which has nothing to do with this. Having a more elegant, unified behavior would be nice. But the API function was not created for this - it's merely for running commands _synchronously_ on the core, but without blocking the client API caller (if the API user consistently uses only async functions).
* client API: clarify what stream_cb callbacks can doGravatar wm42017-03-17
| | | | See #4227.
* client API: update outdated recommendations about window embeddingGravatar wm42017-03-02
| | | | | | | Basically, the opengl-cb API causes fewer issues, even if it's a bit harder on the API user. See #4197.
* stream_cb: remove leftover doxygen lineGravatar wm42017-02-20
|
* vo_opengl: remove dxva2 dummy hwdec backendGravatar wm42017-02-20
| | | | | | | | | This was a hack to let libmpv API users pass a d3d device to mpv. It's not needed anymore for 2 reasons: 1. ANGLE does not have this problem 2. Even native GL via nVidia (where this failed) seems to not require this anymore
* vo_opengl: implement videotoolbox hwdec on iOSGravatar Aman Gupta2017-02-17
| | | | | | Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but using CVPixelBuffer APIs available on iOS instead of the equivalent IOSurface APIs in macOS.
* client API: adjust opengl_cb hardware decoding commentsGravatar wm42017-01-26
| | | | | | Replace the reprecated --hwdec-preload option. Add a comment about cuvid/cuda decoding.
* client API: correct a comment in the API doxygenGravatar wm42017-01-08
|
* client API: turn mpv_suspend() and mpv_resume() into stubsGravatar wm42016-11-22
| | | | | | | | | | | As threatened by the API changes document. This commit also removes or stubs equivalent calls in IPC and Lua scripting. The stubs are left to maintain ABI compatibility. The semantics of the API functions have been close enough to doing nothing that this probably won't even break existing API users. Probably.
* Fix some future release version numbersGravatar wm42016-11-21
| | | | | | Since the recent release was named 0.22.0 instead of 0.21.1, bump all mentions of 0.22.0 to 0.23.0. These were planned removals of deprecated versions, which obviously didn't happen in 0.22.0.
* client API: "priority" option is now runtime settableGravatar wm42016-09-28
| | | | | So it doesn't have to be in the list of options that can be set before mpv_initialize() only.
* qthelper: introduce new convenience functionsGravatar wm42016-09-26
| | | | (Why the heck is the C++ helper not in a separate repository?)
* player: do not let pseudo-gui override user config settingsGravatar wm42016-09-23
| | | | | | | | Seems like this confused users quite often. Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now has to be used to invoke pseudo GUI mode. The old way still works, and still behaves in the old way.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-06 04:53:05 +0000