summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* cocoa-cb: add pinch to resize window gestureder richter2020-01-262-0/+11
| | | | | | | the event returns a delta ratio so we can just add it to the current window-scale. Adds support for #3214
* cocoa-cb: never set a window size smaller than the set minSizeder richter2020-01-261-0/+5
| | | | this prevents a vanishing window if the size is set too small.
* cocoa-cb: fix race condition on quitder richter2020-01-261-0/+1
| | | | | | it was possible for mouse events to be triggered when the core was already being shut down. to prevent this properly close and remove the window and additional remove the reference to MPVHelper object.
* cocoa-cb: add support for forcing the dedicated GPU for renderingder richter2020-01-262-5/+14
| | | | | | | | this deprecates the old cocoa backend only option and moves it to the general macos ones. add support for the new option in the cocoa-cb layer creation and use the new option in the olde cocoa backend. Fixes #7272
* cocoa-cb: don't set App icon when called from bundleder richter2020-01-261-1/+3
| | | | | | | | | due to the bundle config the icon is set automatically via the bundle system mechanisms. this also makes it possible to set the icon to a custom one with the standard macOS copy paste method via the file info dialogue. Fixes #6874
* vo_gpu: hwdec_vaapi: set correct hw_imgfmt valuewm42020-01-171-0/+1
| | | | | | | As documented on struct mp_hwdec_ctx, hw_imgfmt specifies the hardware surface wrapper format for which supported_formats is valid. If this was not set, f_hwtransfer ignored supported_formats, and assumed all formats were supported.
* wayland: support maximize/minimize on startupDudemanguy2020-01-121-0/+6
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started on wayland. If the compositor doesn't support maximization or minimization, then these options just do nothing.
* wayland: unscrew up cursorsdudemanguy2020-01-121-6/+4
| | | | | | | | | | | | | | Fixes #7345 There was a multitude of issues with cursor handling in wayland and behavior seemed to vary for strange reasons across compositors and also bad things were being done in wayland_common. The problem is complicated and involved fullscreen states being set incorrectly under certain instances and so on. The best solution is to just remove most of the extra cruft. In handle_toplevel_config, instead of automatically assuming is_fullscreen and is_maximized are false, we should use whatever value is currently set vo_opts which matters when we initially launch the window.
* vaapi: reduce log levels furtherwm42020-01-112-8/+11
| | | | | Try to exclude mostly uninteresting information from verbose logging, but still include it in debug logging.
* vo_gpu: hwdec_vaapi: silence warning during probingwm42020-01-111-1/+4
| | | | | | | | | | | | | | hwdec_vaapi tries to probe all available surface formats in advance. For that, we iterate over _all_ profiles in an attempt to collect possible surface formats. This means we try profiles we normally wouldn't use for decoding or filtering, and which could be "unrelated" services. It seems some drivers report at least one profile, for which vaQueryConfigEntrypoints() fails (because the profile is not supported; not sure why it lists it, then). So turn the error message into a verbose message to avoid confusing output. Fixes: #7347
* wayland: don't set cursor before pointer idDudemanguy2020-01-111-1/+1
| | | | | | | | | | | This shouldn't really matter, but it's probably best to avoid. vo_wayland_control would execute set_cursor_visibility while wl->pointer existed but it didn't check if wl->pointer_id existed. So wl_pointer_set_cursor would be set to a null surface with an id of 0. Instead, just wait until we have an actual, non-zero pointer id so that the cursor is set with the correct, actual id and not a fictious 0 id. This ensures that the pointer isn't set until it enters the wl_surface which is what we want.
* cocoa-cb: don't active window when minimized or hidden on file changeder richter2020-01-091-1/+6
| | | | Fixes #7195
* cocoa-cb: add runtime dpi change and use proper fallback for initial dpider richter2020-01-092-4/+7
| | | | | | | | at the time of the initial dpi query the window is not instantiated yet. we use a proper fallback in that case, eg the target configured screen or the main screen if none is set. also change some weird oversight and a small optimisation.
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-091-3/+3
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* vo_gpu: fix crash if dither texture fails to allocatewm42020-01-081-0/+3
| | | | | | | Theoretically possible (and quite unlikely due to the small texture size). The code was originally written with the assumption that texture allocations can't fail, and it was never updated out of laziness. Untested.
* wayland: don't exit the option loopDudemanguy2020-01-041-16/+12
| | | | | More than one option may change at the same time so don't break out of this loop.
* wayland: disable by default for gnomeDudemanguy2020-01-011-0/+4
| | | | | | | | | It turns out that gnome wayland still has very serious issues that make it unusable for playback with mpv. Other compositors mostly behave fine (Plasma is just missing feature but it's not seriously broken), so GNOME gets the special honor of having a warning printed out. The only solution for GNOME users at this time of writing is to either use the Xorg session or use another wayland compositor.
* Revert "vo_gpu: move wayland below X11 in autoprobe order"Dudemanguy2020-01-011-6/+6
| | | | This reverts commit a6d8e9b7ff0166ee6db69c41c0cfc319e03f4c80.
* vo_gpu: move wayland below X11 in autoprobe orderwm42019-12-301-6/+6
| | | | | | | I'm sick of mpv being accused of not doing it right. You can't do it right on Wayland? Long live X11. Fixes: #7307
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-294-1/+52
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* vo_gpu: hwdec_vaegl: remove support for old-style interopPhilip Langdale2019-12-284-130/+5
| | | | | | | | | | | | | In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they introduced a new surface export API that is more efficient, and we've been supporting that and the old API ever since (Feb 2018). If we drop support for the old API, we can do some fairly nice cleanup of the code. Note that the pkgconfig entries are explicitly versioned by the API version and not the library version. I confirmed the upstream pkgconfig files.
* vo_gpu: hwdec_vdpau: remove direct_modePhilip Langdale2019-12-283-170/+47
| | | | | | | | | | | | | | | | | | | | | | | | As we are less and less interested in vpdpau, with nvdec and vaapi being better choices in general on nvidia and AMD respectively, we might consider removing direct_mode, where we bypass the vdpau mixer and work directly with yuv textures. Normally, working with yuv textures would be great, but vdpau built in an assumption that all frames are delivered as separate fields, causing us to have to re-interleave them. nvidia then introduces a new OpenGL extension that can return the yuv frames as frames, but we can't just unconditionally switch to that as we'd want to keep supporting older hardware where the drivers are no longer getting new features. The end result is that we wouldn't be able to get rid of the old code paths. Removing direct_mode means we always use the mixer, and work with rgba frame textures. There are some theoretical limitations to this, but in practice they probably don't matter much - unsupported colourspaces don't matter because without 10bit decoding support, we can't use them anyway, and apparently we're not doing separate chroma scaling these days, so scaling the rbga doesn't really lose anything (and the vdpau hq scaling option remains available).
* w32_common: remove implicit fallthroughJames Ross-Gowan2019-12-291-2/+3
| | | | | | GCC 9.2 warns about this. It was always a bit sketchy, so get rid of it. VK_F10 generates WM_SYSKEYDOWN, so it only needs to be handled in the WM_SYSKEYDOWN case.
* cocoa-cb: force redraw when screen or size changesder richter2019-12-241-0/+2
| | | | | | | | | in certain circumstances the video was not redrawn even when the size or the backing scale factor changed. this could lead to a lower resolution output than intended. now it redraws the video when screen properties or the window size changes.
* cocoa-cb: implement hidpi scale reportingder richter2019-12-242-0/+7
|
* vd_lavc: remove hwdec-by-default special case for RPIwm42019-12-241-1/+1
|
* vd_lavc: more hwdec autoselect nonsensewm42019-12-241-17/+49
| | | | | | | | | | | | | Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force hwdec=vaapi in the global config file in their mpv package. But to be honest it's probably something more people want. This is implemented as explicit whitelist. On Windows, HEVC/Intel is sometimes broken, but it's still whitelisted, and in theory we'd need a detailed whitelist of device names etc. (like for example browsers tend to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately the only one, so it's whitelisted too. There may be a larger number of hwdec wrappers that work anyway, and I'm for example ignoring Android.
* vo_gpu: vulkan: set allow_suboptimal when possibleNiklas Haas2019-12-221-0/+5
| | | | | This was added in libplacebo v1.29.0 and allows making resizes slightly smoother for clients that already handle resize events (such as mpv).
* video/out/x11: add fs-screen fallbackNicolas F2019-12-221-0/+3
| | | | | | | | | | | | | Apparently there are two different options for controlling which screen an mpv window goes onto: --fs-screen and --screen. The former explicitly only controls which screen a fullscreened window goes onto, but does not appear to actually care about this option at runtime for X11, so pressing f will always fullscreen to the screen mpv is currently on. This means the option is of questionable usefulness for starters. Making it worse, if you use --screen=1 --fs, mpv will actually fullscreen on screen 0, because --fs-screen isn't set. Instead of doing that, fall back to whatever --screen is set to.
* x11: implement hidpi scale reportingwm42019-12-201-0/+3
| | | | | | | (X11 does not support different per-screen DPI (or only via hacks), so this is pretty simple. If other backends are going to implement this, then they should send VO_EVENT_WIN_STATE if the DPI for the mpv window changes by moving it to another screen or such.)
* command: add property returning hidpi scalewm42019-12-201-0/+1
|
* x11: fix X property out of bounds memory readswm42019-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | The size overflow check was inverted: instead of allowing reading only the first dst_size bytes of the property, it allowed copying past the property buffer (as returned by xlib). xlib doesn't return the size of the buffer in bytes, so it has to be computed and checked manually. Wouldn't it be great if C allowed me to write the overflow check in a readable way, so it doesn't trick me into writing dumb security bugs? Relying on X security is even dumber than creating a X security bug, though, so this was not a real problem. But I found that one specific call tried to read more than what the property provided, so reduce that. Also, len*ib obviously can't overflow, so there's an additional layer of dumb to this whole thing. While we're at dumb things, why the hell does xlib use "long" for 32 bit types. It's a god damn pain.
* vd_lavc: add gross workaround for nvdec/libavcodec broken API issuewm42019-12-181-4/+10
| | | | | | | | | | | | | | | | | libavcodec's nvdec wrapper can return invalid frames, that do not have any data fields set. This is not allowed by the API, but why would they follow their own API? Add a workaround to specifically detect this situation. In practice, this should fall back to software decoding if it happens too often in a row. (But single errors are still tolerated, because I don't know why.) Untested due to lack of hardware from the regrettable graphics company. Better do this here than deal with the moronic project we unfortunately depend on. See: #7185
* cocoa-cb: report fullscreen state for legacy fullscreender richter2019-12-171-0/+2
| | | | | report the fs screen state when the fullscreen is externally triggered for the legacy fullscreen.
* command, vo: remove old option change notification mechanismswm42019-12-172-15/+1
| | | | | | | These all have been replaced recently. There was a leftover in window.swift. It couldn't have done anything useful in the current state of the code, so drop these lines.
* video/w32_common: follow updates to the border option instead of VOCTRL_BORDERJan Ekström2019-12-181-4/+3
|
* video/w32_common: follow updates to the ontop option instead of VOCTRL_ONTOPJan Ekström2019-12-181-3/+2
|
* video/w32_common: move minimized state signaling to where it happensJan Ekström2019-12-181-3/+3
| | | | | WM_SIZE is the message we receive from which we can infer if we got minimized or not.
* video/w32_common: switch full screening to options cacheJan Ekström2019-12-181-9/+22
| | | | | | | | | | | | * Instead of following VOCTRL_FULLSCREEN, check for option changes. * Instead of signaling VO_EVENT_FULLSCREEN_STATE, update the cached option structure and have it propagated to the origin. Additionally, gets rid of all the straight usage of the VO options structure. Done in a similar style to the Wayland common file, where in case of reading the value, the "payload" from cache is utilized.
* x11: fix --hidpi-window-scale=no on hidpi screenswm42019-12-161-1/+1
| | | | | | | | | | In this combination, the [current-]window-scale properties still incorrectly applied scaling. For some reason, vo_calc_window_geometry2() handled this option (basically ignored the dpi_scale parameter passed to it), but since the DPI compensation for window-scale is implemented in x11_common.c, we need to check and honor this option here too. (What a mess.)
* x11: scale window-scale by DPIwm42019-12-161-6/+8
| | | | | | | | | | | | | | | | | "window-scale" is 1.0 by default; however, x11 implicitly set that to 2.0 on hidpi screens. This made the default 2.0, which was inconsistent with the option. The "window-scale" property jumped from 1.0 to 2.0 when a window was created. Avoid this by factoring the DPI into the window-scale. This makes the UNFS_WINDOW_SIZE return a virtual size; since this value is used for the window-scale property only, this is fine and has no further consequences. (Originally, this was possibly meant to be used for other purposes, but I'm perfectly fine with redoing this again should that ever happen.) This changes user-visible behavior, and it's as if setting window-scale multiplies its argument by 2 suddenly. Hopefully no user will get angry.
* vo_gpu: opengl: make it work with EGL 1.4wm42019-12-164-4/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This tries to deal with the crazy EGL situation. The summary is: - using eglGetDisplay() with multiple windowing platforms doesn't really work, but Mesa had an awful hack for it - this hack can be disabled at build time, and some distros sometimes accidentally or intentionally do so - Mesa will probably eventually disable it by default - we switched to eglGetPlatformDisplay(), but this requires EGL 1.5 - the very regrettable graphics company (also known as Nvidia) ships drivers (for old hardware I think) that are EGL 1.4 only - that means even though we "require" EGL 1.5 and link against it, the runtime EGL may be 1.4 - trying to run mpv there crashes in the dynamic linker - so we have to go through some more awful compatibility hacks This commit tries to do it "properly", but using EGL 1.4 as base. The plaform selection mechanism is a messy extension there, which got elevated to core API in 1.5 (but OF COURSE in incompatible ways). I'm not sure whether the EGL 1.5 code path (by parsing the EGL_VERSION) is really needed, but if you ask me, it feels slightly saner not to rely on an EGL 1.4 kludge forever. But maybe this is just an instance of self-harm, since they will most likely never drop or not provide this API. Also, unlike before, we actually check the extension string for the individual platform extensions, because who knows, some EGL implementations might curse us if we pass unknown platform parameters. (But actually, the more I think about this, the more bullshit it is.) X11 and Wayland were the only ones trying to call eglGetPlatformDisplay, so they're the only ones which are adjusted in this commit. Unfortunately, correct function of this commit is unconfirmed. It's possible that it crashes with the old drivers mentioned above. Why didn't they solve it like this: struct native_display { int platform_type; void *native_display; }; Could have kept eglGetDisplay() without all the obnoxious extension BS.
* vd_lavc: fix broken assert()wm42019-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | This assert() sometimes triggered (and still triggers) with lavc API bugs. It tries to check that at least 1 plane is set to a non-NULL value. Obviously, a valid frame returned by successful decoding should never have it. The problem is that some hwdecs use integer surface IDs cast to a pointer. Recently, it happened that newer Intel drivers started using surface ID 0 under certain circumstances (for unknown reasons), which triggers this assert. Just get rid of it. For the sake of #7185, add an assert() specifically for nvdec. That failure needs to be further analyzed, is probably a FFmpeg bug, and without this assert() would just crash somewhere further down the video chain. Fixes: #7261
* vo_gpu: x11egl: log EGL config IDwm42019-12-151-2/+6
| | | | Somewhat useful for debugging.
* vd_lavc: simplify decode return error checkingwm42019-12-151-11/+16
| | | | | | | | | | | | This code checked AVFrame.buf[0] instead of the decode return code to see whether a frame was decoded. This is sort of suspicious; while I think that the lavc API actually guarantees it, it's not intuitive anyway. In addition, the code was unnecessarily roundabout. Replace it with a proper error code check. Remove the other error return (that was, or should have been, redundant before). The no-frame path is now cleanly separated. Add an assert on the frame-returned path; if this fails, lavc violated its own API.
* mac: replace old event tap for media key support with MediaPlayerder richter2019-12-152-7/+7
| | | | | | | | | | | | | | | the old event tap has several problems, like no proper priority support or having to set accessibility permissions for mpv or the terminal. it is now replaced by the new MediaPlayer which has proper priority support and isn't as greedy as previously. this only includes Media Key support and not any of the other features included in the MediaPlayer framework, like proper Now Playing data (only set dummy data for now). this is only available on macOS 10.12.2 and higher. also removes some unnecessary redefines. Fixes #6389
* cocoa-cb: update and add more options to use new options handlingder richter2019-12-152-10/+41
| | | | | this updates and add the maximized, minimized, keepaspect and ontop options to use the new options handling
* cocoa-cb: use m_config_cache and new VOCTRL for option handlingder richter2019-12-152-37/+38
| | | | | | | | this removes the direct access of the mp_vo_opts stuct via the vo struct and replaces it with the m_config_cache usage. this updates the fullscreen and window-minimized property via m_config_cache_write_opt instead of the old mechanism via VOCTRL and event flagging. also use the new VOCTRL_VO_OPTS_CHANGED event for fullscreen and border changes.
* cocoa_common: remove deprecated VOCTRLs/VO_EVENTswm42019-12-122-36/+0
| | | | | | | | | | | | See commit 4e4252f9169edc and the following as an example how this would have to be done if done properly. Since I'm unable to test on OSX, and nobody is interested in fixing this code (including myself, actually), just remove the deprecated definitions to make sure the code still builds. This will break runtime switching of fullscreen, ontop, border. (The way the minimized state is reported was also deprecated, but commit 40c2f2eeb05 already broke it anyway.)
* wayland: remove unnecessary VO_EVENT_FULLSCREEN_STATEwm42019-12-121-3/+0
| | | | | This is needed and used only for VOCTRL_GET_FULLSCREEN, which the wayland code got rid of.
* vo_gpu: x11egl: cleanup EGL correctlywm42019-12-121-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...probably. The EGL backend had a strange problem: when recreating the window, EGL surface creation sometimes mysteriously failed. For example, keeping the "_" key down (cycles video by default) destroys and recreates the window in rapid succession, which will often enough show the "Could not create EGL surface!" message. This was puzzling because due to mpv's architecture, the X11 Window and even the X11 Display were fully destroyed, the thread on which they ran was destroyed, and then everything was recreated. There shouldn't have been any state that could make subsequent EGL initialization fail. It turns out mpv forgot to free EGLSurfaces in the x11 code. EGL is a pretty crazy API (full of thread local and global state with weird lifetime requirements), and for example it seems EGLDisplay cannot be explicitly released, but apparently implicitly dies when the native display is closed (at least EGL 1.5 claims eglTerminate() does _not_ invalidate the display, only certain objects linked to it). It appears that Mesa still referenced at least EGLSurface in some form, and either some pointer or some X11 ID was dangling, and when it randomly matched when eglCreateWindowSurface() was called, it failed. Fix this by calling eglTerminate(), which supposedly destroys (or rather unreferences) contexts and surfaces created from the display (but absurdly not the display itself). Now why can't you just destroy