summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* input: add missing keypad key definesChristoph Heinrich2023-08-252-10/+10
| | | | | | | | So far all the keypad keys except for `0` and `,` mapped to the same MP_KEY_* independent of numlock state, even though different key codes are received. Now all the alternative functions map to appropriate MP_KEY_* defines, with missing ones added.
* win32: don't ignore --screen and --fs-screenKacper Michajłow2023-08-231-8/+14
| | | | | Fixes: 57ba77fc736f6976bc114974f5955c972139740f Fixes: #12220
* input: add new keys: Back, Tools, ZoomIn, ZoomOutJames Cuzella2023-08-232-0/+4
| | | | | | | | | | | | | | | | | These were the only keys missing to support mapping all keycodes on a [popular RF Remote][1] used with Linux HTPC apps. Note that X11/XWayland + xkbcomp still warns about keycodes > 255, due to the 8-bit limit in Xorg but `mpv` on Wayland is able to handle these. For X11 users, there are [a couple options][2]: - [Gianni Ceccarelli's patched `xf86-input-evdev`][3] - [Use udev hwdb to map scancodes to keycodes][4] [1]: https://www.mythtv.org/wiki/Air_mouse_rf_remote [2]: https://unix.stackexchange.com/a/436233/7688 [3]: https://www.thenautilus.net/SW/xf86-input-evdev/ [4]: https://wiki.archlinux.org/title/Map_scancodes_to_keycodes
* vo_gpu_next: move line to correct location (cosmetic)Niklas Haas2023-08-211-1/+1
|
* vo_gpu_next: correctly handle GAMUT_AUTONiklas Haas2023-08-211-3/+3
| | | | Fixes: https://github.com/mpv-player/mpv/issues/12208
* vo_gpu_next: reword error message on empty screenshotNiklas Haas2023-08-211-1/+1
| | | | | This can happen under perfectly legitimate circumstances if no file is loaded yet.
* aspect: change --video-pan-x/y to be relative to the destination rectKacper Michajłow2023-08-201-1/+1
| | | | | | | | | | | | | | | | It makes it more usable to virtually move dst rect instead of scaled src. The issue with the latter is that it is affected by video-zoom paramters. For example if we do `--video-pan-x=-0.5` in normal case it will move video -50%, but if we apply video-zoom/scale the video will float towards the middle in unintuitive way. Extreme case is when one do --video-zoom-x=0.01, now it is impossible to move video unless you specify huge video-pan-x value, but it is limited to [-3, 3]. So you cannot do anything. With this changes regardless of video scale/zoom, video-pan will keep center of scaled video in one place.
* aspect: don't allow scaled_src_size be 0Kacper Michajłow2023-08-201-0/+1
| | | | | | | It doesn't make sense to have zero here and it breaks, logic below. Width was still campled to 1, but with broken offset. This fixes things like video-scale-x=0
* meson: rename all features with underscoressfan52023-08-201-8/+8
| | | | The convention is to use dashes.
* context_drm_egl: remove references to VAAPI in error messagessfan52023-08-201-3/+2
| | | | | VAAPI is not the only hwdec that won't work when the render node isn't available.
* context_drm_egl: more correctness fixes for uninit proceduresfan52023-08-201-6/+5
| | | | | | | | | | | | | - uninit gl before the VO - destroy EGL surface before context: reverse of the creation order. I also checked other code which doesn't even call this and leaves it up to eglTerminate, which frees everything anyway. But this seems more correct since we're destroying the gbm surface afterwards. - check against at EGL_NO_DISPLAY instead of 0: there is probably no EGL implementation where this makes a difference, it is more correct regardless - remove pointless eglDestroyContext call - check render_fd before close
* w32_common: try to get the monitor from the window boundsZenos2023-08-201-1/+5
|
* w32_common: don't fit to screen when VO_WIN_FORCE_POS is setZenos2023-08-201-1/+1
|
* 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.
* vf_vapoursynth: save display resolution as a variableDudemanguy2023-08-131-0/+8
| | | | | | | | | | | | | | mpv has a generic method for getting the display resolution, so we can save it in vf_vapoursynth without too much trouble. Unfortunately, the resolution won't actually be available in many cases (like my own) because the windowing backend doesn't actually know it yet. It looks like at least windows always returns the default monitor (maybe we should do something similar for x11 and wayland), so there's at least some value. Of course, this still has a bunch of pitfalls like not being able to cope with multi monitor setups at all but so does display_fps. As an aside, the vapoursynth API this uses apparently requires R26 (an ancient version anyway), so bump the build to compensate for this. Fixes #11510
* 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
* mp_image: properly infer color levels for some pixfmtsKacper Michajłow2023-08-071-1/+29
| | | | | | | | | | | ffmpeg does not tag yuv levels for GRAY formats, but apparently they should be infered as full range. Instead of defaulting to limited range always. Fixes (M)JPEG playback. This mimic ffmpeg's behaviour. See: https://github.com/FFmpeg/FFmpeg/blob/d295b6b6936c9c691a4871851fdaec04d407e54b/libswscale/utils.c#L926-L962 Fixes: #12089
* 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.
* vd_lavc: repeatedly attempt to fallback if hwdec fails in reinitPhilip Langdale2023-08-061-2/+5
| | | | | | | | | | | | | | | In the same way that fallback in receive_frame() needs to be repeated until we get a working decoder, we have to do the same thing in reinit(). Calling force_fallback() only once can still yield a non functional decoder. The reason why we have these multiple paths which each require their own fallback logic is that we can fail at different stages: * hwdec init * decoder init <- repeated fallback was missing here * frame decoding Fixes #12084
* 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.
* video_writer: fix gamma for YUV screenshotssfan52023-07-261-2/+2
| | | | | | reproduction steps: take any lossy WebP screenshot and check the colors (or JPEG without libjpeg support, or AVIF with tag-colorspace=no) fixes: 6d9e72cd89652aaf73fa5a8256c439221e86b94a
* image_writer: log pixfmt conversionsfan52023-07-261-0/+2
|
* zimg: fix abort on subsampled input with odd heightssfan52023-07-261-1/+8
| | | | | | | | | | | We make the assumption that there is more buffer available than indicated, this needs to be considered in this specific location too as mp_image_crop understandab