summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
...
* win32_common: fixes minimized window being focused on launchmwalmer2023-08-201-1/+1
| | | | | | mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used. Resolves: #9641
* drm_common: skip cards that don't have connected outputsllyyr2023-08-201-0/+29
| | | | | | It's possible for systems to have multiple cards, and the first capable card to not have a connected output. Skip such cards and continue iterating until we find one with a connected output.
* x11: set sizehint for fs-screen and fs-screen-nameDudemanguy2023-08-201-1/+5
| | | | | | | Without doing this, --fs --fs-screen=1 wouldn't actually end up on the desired screen since the sizehint was never sent. Also check the screen-name variants for an empty string as well so the option can properly "undo" itself (not sure if this has any practical effect).
* x11: remove xinerama and refactor window geometryDudemanguy2023-08-202-80/+72
| | | | | | | | | | | mpv mixes xinerama and randr usage together which gets kind of confusing and is also pretty stupid. Xinerama is completely unneccesary today since randr can do everything it can do and much more. Remove it. This reworks a lot of the window/geometry handling stuff to be centered completely around xrandr_display plus some other tweaks to the geometry handling. An important concept is that current_icc_screen is changed into current_screen and used more generously since it is useful for things besides just icc profiles.
* x11: require randr 1.4Dudemanguy2023-08-201-26/+19
| | | | | | There really is no reason to not just hard require randr 1.4. xorg added 1.4 support in 2012 and someone somehow using an xorg server older than that today surely has several other problems.
* context_drm_egl: don't free egl properties if they are nullArthur Williams2023-08-201-3/+6
| | | | | | | If we failed to create a gbm surface, we would call drm_egl_uninit to free up any state we had allocated. However, we would segfault if we tried to cleanup properties there were never initialized. Null checks have been added to guard against this.
* vo_gpu_next: correctly clear removed hooksNiklas Haas2023-08-191-0/+1
| | | | | | | | Before d208284, this was implicitly reset back to 0 at the start of every update_options(). But we no longer explicitly reset par->params, so we need to do it manually here for the hooks. Fixes: https://github.com/mpv-player/mpv/issues/12203
* vo_gpu_next: fix typo in video_screenshot()Niklas Haas2023-08-191-1/+1
| | | | | | | Undefined behavior (bad initializer). Somehow didn't trigger a warning on my end... Fixes: a8192eda6cfc909fc9f5f62e36523b53c0300eff
* vo_gpu_next: add --libplacebo-optsNiklas Haas2023-08-191-0/+7
| | | | To help test not-yet-exposed options, and for debugging purposes.
* vo_gpu_next: don't re-set frame_mixerNiklas Haas2023-08-191-1/+2
| | | | This is already set by map_scaler, just disable it if unwanted.
* vo_gpu_next: move allow_delayed to move appropriate placeNiklas Haas2023-08-191-1/+1
| | | | No need to override this so late in the general (non-screenshot) code.
* vo_gpu_next: switch to new pl_options systemNiklas Haas2023-08-191-99/+124
| | | | | | | | | | | | | | | With a backwards compatibility shim for older versions of libplacebo in which we simply define the relevant subset of this struct ourselves and initialize it to known-good values, to be able to continue using our options assigning code. It's worth pointing out that our use of scalers deviates from how pl_options was intended to be used, as a consequence of backwards compatibility with pre-308 versions of libplacebo. But this should work fine in practice, since we don't care about serializing these custom scalers correctly. Users can still override them using the built-in pl_options scalers when loading custom scalers via --libplacebo-options. (To be added in the next commit)
* vo_gpu_next: fix leak of --icc-profile-auto on uninitNiklas Haas2023-08-181-1/+1
| | | | | | This was already correctly freed when acquiring a new profile, but never freed on uninit. Fix by reparenting the profile onto `p`, which is what vo_gpu also does.
* vo_gpu_next: drop redundant PL_HAVE_LCMS checkNiklas Haas2023-08-181-20/+1
| | | | | This header is installed unconditionally starting with libplacebo v4.208.0, so we are safe to remove the check.
* vo_gpu_next: use pl_dispatch_info_move to avoid useless data copyKacper Michajłow2023-08-181-21/+46
| | | | | Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.
* libplacebo: drop PL_API_VER compatibility pathsNiklas Haas2023-08-181-30/+1
|
* ra_pl: drop PL_API_VER compatibility pathsNiklas Haas2023-08-181-65/+1
|
* vo_gpu_next: drop PL_API_VER compatibility pathsNiklas Haas2023-08-181-46/+0
| | | | v6.292 implied by minimum dependency.
* meson: remove redundant libplacebo-next checkNiklas Haas2023-08-181-1/+1
| | | | Now implied by the minimum libplacebo version.
* hwdec_cuda: drop old PL_API_VER compatibility pathNiklas Haas2023-08-181-90/+0
| | | | LIBPLACEBO_NEXT is now implied by libplacebo being available
* vo_gpu: allow --hdr-peak-decay-rate=0.0Niklas Haas2023-08-182-4/+7
| | | | | | | | | | | | | | This completely disables all smoothing. Despite what the manual claims, a decay rate of 1.0 does *not*. It's worth pointing out that this depends on the following commit to work properly in --vo=gpu-next, but I don't think working around such a minor detail is worth the trouble, considering people building nightly mpv are probably also building nightly libplacebo it should just work (tm). See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8 See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
* vo: clear vsync_offset if drawing while pausedDudemanguy2023-08-161-0/+3
| | | | | | | | | | | | | | | libplacebo doesn't like it when the queue_params PTS is less than the actual PTS of the frame for the first frame and skips mixing it during interpolation. This can happen if you seek while paused because mpv will always keep the vsync_offset value as if it was still playing. So in some cases, this can be a negative value and thus the PTS will end up decreasing and libplacebo interprets this frame as a first frame. This skips mixing the frame and thus you get a black screen. To fix this this, just realize that vsync timings are completely meaninglessly in while paused. If you are not actively pushing frames, there's no reason to care about vsync_offset. So just clear it and make it zero when the VO's internal state is paused and we're trying to render a frame. Makes libplacebo happy and fixes #11958.
* win32: fix display resolution calculation on mulitple monitorsDudemanguy2023-08-151-3/+3
| | | | | | | It was actually always wrong, and no one ever noticed. This currently returns the size of the entire display area and not one actual monitor. Fix this by calling get_monitor_info and then doing the appropriate subtractions. Checked by @CrendKing and fixes #12172.
* wayland: clear all keys on keyboard_handle_leaveDudemanguy2023-08-141-0/+4
| | | | | | | | There was no known problem with this, but according to the wayland spec*, "After this event client must assume that no keys are pressed...", so go ahead and do that. *: https://gitlab.freedesktop.org/wayland/wayland/-/blob/72da004b3eed19a94265d564f1fa59276ceb4340/protocol/wayland.xml#L2449
* wayland: clear saved mpkey more aggressivelyDudemanguy2023-08-141-1/+1
| | | | | | | | | | | | | Introduced by 1f8013ff3fddd788a517656e09f5ce5d7efd928d. We try to save the mpkey so it can be used in the modifier event that comes next if appropriate and also clear it when needed. The problem is that the condition for clearing is too strict and things like mismatched cases and so on can make mpkey on the corresponding key release event not match the saved mpkey even though in reality they were the same key. Loosen the check by simply always clearing the saved mpkey as long as there was some key found and the state is up. We don't handle multiple keys at the same time anyways (they're interpreted in a sequence), so it should be hopefully OK.
* wayland: use fallback for display-fps/width/heightDudemanguy2023-08-131-5/+17
| | | | | | | | | During initialization, the mpv window was not available and wayland simply just reported nothing. But this can be a nuisance and there are cases where having a values is better than nothing (vapoursynth). So if current->output isn't available yet, fallback to find_output instead. This is influenced by what is set by options like --screen and --screen-name, but we'll consider that a feature not a bug.
* x11: add --x11-wid-title optionDudemanguy2023-08-131-2/+3
| | | | | | | | | | This deliberately wasn't being done when mpv was embedded (fbccddb48b4c71c18300b092ef7a3860be2a659a). There are some applications that would benefit from mpv setting a title since they don't do so themselves (such as tabbed), but at the same time some others would probably rather not have this behavior (like smplayer). Add an option that allows an embedded mpv to set the title if the user wishes. Fixes #11528.
* x11_common: drop unnecessary NULL checkNRK2023-08-131-3/+1
| | | | similar to free(), XFree() is a no-op if argument is NULL
* x11_common: avoid unnecessary XUnmapWindow() callNRK2023-08-131-3/+1
| | | | | | | | XDestroyWindow() is called immediately after, which also unmaps window if needed. according to the manpage: > If the window specified by the w argument is mapped, it is unmapped > automatically.
* vo_gpu_next: actually fix screenshots with PARDudemanguy2023-08-081-2/+10
| | | | | | | | | | | 983e8f0100b98bd8aed48e5fe86dd5682174b04e resulted in the correct dimensions, but it was not actually right because vo_gpu_next still had the src and dst rects the same. This just needs to work like how vo_gpu does where the src is the image params and the dst is desired output. So basically, just copy that code over here. Fixes #12108 and as a bonus, overriding the aspect ratio now results in correct screenshots (previously didn't work at now and then with the above commit it had correct dimensions but still incorrect output).
* vo_gpu_next: take into account PAR when taking screenshotsDudemanguy2023-08-071-1/+2
| | | | | | Using the width and height params directly doesn't actually work if PAR is something other than 1. Instead, use mp_image_params_get_dsize and calculate the correct dimensions which matches the vo_gpu behavior.
* vo_gpu_next: add ability to use named hook paramsNiklas Haas2023-08-071-1/+14
| | | | Closes: https://github.com/mpv-player/mpv/issues/12093
* vo_gpu_next: increase non-interpolation queue sizeNiklas Haas2023-08-071-1/+1
| | | | | | | | | | | | | | | 1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is designed to always know the next frame (in addition to the current). Before haasn/libplacebo@112bb886, this was was (wrongly) silently omitted by the pl_queue code, but that fix exposed this. While it's technically API misuse on mpv side, due to the mpv vo code having its own internal queueing and timing control, it shouldn't actually make any difference in practice (and likely, the error message showing up is the only meaningful bug here - the issue is entirely cosmetic). Fixes: https://github.com/mpv-player/mpv/issues/12101
* vo_gpu_next: update for new pl_filter configuration APINiklas Haas2023-08-061-9/+33
| | | | | | | | | | Configuration of filter parameters was moved from pl_filter_function (of which the user had to make a copy) to pl_filter_config, with the pl_filter_function remaining immutable. Implement this new logic in a way that can reasonably exist side-by-side with the old configuration API. Once we drop support for PL_API_VER below 303, we can drastically simplify this code.
* win32: signal VO_EVENT_DPI on dpi changesDudemanguy2023-08-061-0/+1
| | | | | | | The win32 code already updates itself on dpi changes. However, it never signalled mpv's core when this happened which meant that the display-hidpi-scale property never changed. Simply send the VO_EVENT_DPI event when appropriate. Fixes #12081.
* vo_gpu/vo_gpu_next: fix setting an empty dscaleDudemanguy2023-08-052-1/+7
| | | | | | | | | The manual currently says that if dscale is unset, --scale will be applied. However, this only works at init time. If you change the dscale filter to be empty later, vo_gpu will segfault and vo_gpu_next will throw an error and refuse the changes. That's because when the option is unset at runtime, the value becomes "" not NULL and the vo's never accounted for this. Fixes #12031.
* vo_gpu_next: add --hdr-peak-percentileNiklas Haas2023-08-043-0/+4
|
* vo_vdpau: set hwdec image formatbilldoor12023-08-021-0/+1
|
* drm: bump minimum version to 2.4.105LaserEyess2023-07-311-4/+0
| | | | | Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this #ifdef is no longer needed
* build: remove outdated generated directoryDudemanguy2023-07-315-18/+69
| | | | | | | | | | | | | | | | This only existed as essentially a workaround for meson's behavior and to maintain compatibility with the waf build. Since waf put everything in a generated subdirectory, we had to put make a subdirectory called "generated" in the source for meson so stuff could go to the right place. Well now we don't need to do that anymore. Move the meson.build files around so they go in the appropriate place in the subdirectory of the source tree and change the paths of the headers accordingly. A couple of important things to note. 1. mpv.com now gets made in build/player/mpv.com (necessary because of a meson limitation) 2. The macos icon generation path is shortened to TOOLS/osxbundle/icon.icns.inc.
* draw_bmp: fix overflowing coordinates in mark_rcsDudemanguy2023-07-302-8/+0
| | | | | | | | | | | | | | | | This is yet another unfortunate side effect of the width % SLICE_W == 0 special case. While looping through these rectangles, the rc->x1 value on the final loop can be greater than the actual total width. This will cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the current VOs that use that work around it by adjusting the values returned, but the better fix is to correct what's actually given in the rectangles so you can safely use the values. As for the fix, it's simply ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP. Previously, the code would always naively add SLICE_W (256) to rc->x0 which would easily extend past the actual width in many cases. The adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory vo_direct3d should work now since we can just trust the values given to us in the rectangles. How nice.
* vo_gpu_next: fix assertion on waylandNiklas Haas2023-07-291-2/+7
| | | | | | | This code failed to handle the case of the swapchain submission being skipped because the window was invisible. Fixes: f9dc695b580c394bf4f9833d36e91b7fcbe009ea
* vo_gpu_next: delay swapchain submit until flip_frame()Niklas Haas2023-07-291-2/+5
| | | | Presents frames at the correct time when DS is disabled.
* wayland: restore xkb_keysym_to_utf8 handlingDudemanguy2023-07-241-5/+10
| | | | | | | | | In 1f8013ff3fddd788a517656e09f5ce5d7efd928d, I mistakenly thought this was only used for modifier presses way back in the commit it was introduced in, but it actually also handles non-english keys/letters. Instead of returning early, we should try xkb_keysym_to_utf8 first and then return if that doesn't do anything so the modifier can then be handled in the appropriate event. Fixes #12009.
* build: internally rename gl-wayland to egl-waylandDudemanguy2023-07-231-1/+1
| | | | | | This has always been a pet peeve of mine and in fact I named the option in meson "egl-wayland" with the intention of finally doing this. We call everything that's egl "egl-foo" internally except for wayland.
* Revert "vo_gpu_next: use pl_dispatch_info_move to avoid useless data copy"sfan52023-07-231-46/+21
| | | | | | | | We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next for this release, since this is the what most Linux distributions are shipping. The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not likely to ship the newest libplacebo release soon. This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
* vo_dmabuf_wayland: correctly handle force-windowDudemanguy2023-07-231-1/+7
| | | | | | | | | Since this works by mpctx giving us a dummy image, we can be reasonably be confident that when we receive a matching imgfmt with no underlying hw_subfmt that this is simply force window from the player. Just allow this to go through the usual wayland logic and skip the hwdec checking. When we get the real image later, it will still error out on the compositors that don't have proper support.
* vo_vaapi: restore hardware video decodingGusar3212023-07-221-0/+1
| | | Commit e50db42 changed how hwdec interop works. Adjust vo_vaapi accordingly by setting the appropriate image format.
* vo_vaapi: fix segfault in draw_osdGusar3212023-07-221-0/+4
| | | | | | When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video. Fixes issue #10436
* vo_drm: remove VOCTRL_SCREENSHOT_WINDudemanguy2023-07-211-5/+0
| | | | | With the generic screenshot window implemented, this is no longer needed since vo_drm already uses software scaling.
* wayland_common: remove questionable gcd impl and global statesfan52023-07-192-22/+9
|
* wayland: don't treat tiled and maximized windows the sameDudemanguy2023-07-192-3/+9
| | | | | | | | | | | | mpv has historically always treated the various tiled states in xdg-shell as maximized (probably because it was easier). Well it turns out that there are some tiling compositors (hyprland) that allow tiled windows to maximize themselves. This can lead to some scenarios where mpv ends up doing a maximize on hyprland which actually works since it's not a no-op like on sway. Fix this by separating out the tiled state from maximize. It works mostly the same, but the main difference is that there's no request to tile yourself like there is with maximize. Should fix #11954.
* wayland: add locked_size convenience shorthandDudemanguy2023-07-192-8/+10
| | | | | | | There's a lot of checks that are along the lines of !maximized && !minimized or vice versa. Make a locked_size boolean and store the value of this in here to avoid writing long lines since the next commit will add yet another condition to this.
* vo_gpu_next: add --hdr-contrast-recovery/smoothnessNiklas Haas2023-07-183-0/+12
| | | | New upstream feature. Disabled by default.
* wayland: handle modifier keys correctlyDudemanguy2023-07-172-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't know why we've been doing this wrong for so long or how I didn't notice until now. Wayland specifically has an event for handling modifiers. We even named it "keyboard_handle_modifiers" in the code. What we should do is just get the modifier and save it after the xkb state is updated. Then later if the user does something else (press another key or clicks the mouse button), the saved modifier key is applied. If you let go of the modifier at any point, the xkb will just update its state again and we save a 0 again here (i.e. no modifier). There is one bit of an edge case however. If a key is pressed BEFORE the modifier, then we have to handle the mp_input_put_key in the modifier event instead since the ordering is not guarenteed. What we do here is keep track of the mpkey as well as the mpmod. However if we are unable to find a matching mpkey and the key state is pressed down, assume it's a modifery key that was pressed and don't update mpkey. That way whenever the modifier event does happen, it can correctly handle this and we know that the keys must be pressed down if we end up there in the code path. As another fun historical note, the xkb_keysym_to_utf8 line was actually written by wm4 himself in 460ef9c7a4bd2527f7f17eb8c95eeff3b67455f8 nearly 10 years ago. As the commit shows, it was clearly intended to handle modifiers (if lookupkey finds nothing, then try to find a mod instead). Of course, this is extremely dated and wayland hasn't worked like that in ages. This branch never actually did anything, and thus we'll remove it here along with modifier lookup changes. This solves bizarre issues with modifiers not working with random keys while working fine with others (don't ask me why). Fixes #10286 and fixes #11945.
* vo_gpu_next: add --target-contrast optionKacper Michajłow2023-07-173-0/+33
| | | | For better control over target display levels.
* wayland: wrap resize requests in prepare_resizeDudemanguy2023-07-161-9/+19
| | | | | | | | | | | | | | | | | | | 828dd65ef84b4d8e95e70752b9eb0833909d1d23 started this and put it in the most common place, but any resize mpv is doing should be accompanied by that function call to correctly inform the compositor of the window bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it makes sense to just put these in the same function. A slight thing to note is that xdg_surface_set_window_geometry uses surface local coordinates which means they are divided by the wl->scaling factor. If possible, we should use surface local coordinates directly if available (like in the toplevel config) to avoid potential rounding errors. Otherwise, just calculate it out. The linked commit actually broke some weston resizes in weird ways (window disappearing or completely freezing). Don't ask me why and I didn't attempt to find out why either, but with this it all appears to work normally again (the other compositors don't appear to be any different, and they shouldn't be), so we'll go with this since it fixes soemthing and it also is more conceptually correct.
* vo_dmabuf_wayland: error out if compositor doesn't support the formatDudemanguy2023-07-141-2/+71
| | | | | | | | | | | | This was never implemented so in cases where the compositor didn't have support for the underlying format, the window would just be black and quite unhelpful. Well it turns out that fixing this is actually really easy because mpv has reconfig2 which returns the entire mp_image on every reconfig. We can just use that mp_image to try and obtain the format and modifier pair and then use that to check against what we know the compositor supports. If there are any problems, error out gracefully. Some code duplication with the vaapi/drmprime importers, but it's probably better to keep these separate. Fixes #11198 and fixes #11664
* build: make dmabuf-wayland a build option and require drmDudemanguy2023-07-141-7/+1
| |</