summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
...
* vo_gpu_next: forwards compatibility with pl_cacheNiklas Haas2023-09-081-0/+13
| | | | | | | Interrim solution, forwards compatible with new and backwards compatible with old API. Eventually, we will want to discontinue the use of deprecated pl_icc_params.save/load and pl_renderer_save/load, but that requires minimum version bump.
* vd_lavc: disable cropping by decoderKacper Michajłow2023-09-081-0/+3
| | | | | | | | | Cropping by decoder has limitations with regards to aligment and hwdec. It doesn't work to offset top left corner with hwdec and even with software decoding it don't crop fully when resulting data would not be aligned. VO cropping is way more robust.
* mp_image: add missing crop initializationKacper Michajłow2023-09-081-0/+7
| | | | This enabled cropping of container signaled rect.
* vo: vulkan: allow picking devices by UUIDPhilip Langdale2023-09-041-9/+47
| | | | | | | | | | | | | | | We currently only allow specifying the Vulkan device to use by name. We did this to avoid confusion around devices being enumerated in an unpredictable order. However, there is a valid edge case where a system may contain multiple devices of the same type - which means they will have the same name, and so you can't control which one is used. This change implements picking devices by UUID so that if names don't work, you have some option available. As Vulkan 1.1 is a hard requirement for libplacebo, we can just use UUIDs without conditional checks. Fixes #10898
* vo_gpu_next: don't rotate gamut visualizationNiklas Haas2023-09-021-7/+5
| | | | | | | | | | Causes bad performance with interpolation because the changing hue angle invalidates the mixing cache, as a result of libplacebo implementations (specifically, the fact that this graph is drawn during the color management process, instead of as a separate overlay). Fix it by just hard-coding a particular, relatively interesting plane (pi/4 approximately maps onto the red-blue axis).
* Revert "aspect: change --video-pan-x/y to be relative to the destination rect"llyyr2023-09-021-1/+1
| | | | | | | | | | | | | There are way too many preexisting scripts that rely on this behavior for video panning, like for example scripts that allow you to use mpv as an image viewer. If this behavior is desired then it may be better to add a new option for panning relative to the destination instead. The restriction of video-pan-x/y being clamped to {-3, 3} also results in the video being impossible to pan if it was zoomed in beyond a certain degree. This reverts commit 7d6f9e37397ed57be0f1375afe8fddfc451aa152.
* vo_gpu: remove --tone-mapping-modeNiklas Haas2023-09-013-46/+7
| | | | | | | | | `--vo=gpu-next` no longer uses this option, being replaced entirely by a luminance-based approach internally. And even for `--vo=gpu`, the values other than 'hybrid' are universally inferior in quality. In the interest of gradually reducing the amount of option bloat here, remove this mostly-pointless option.
* win32: don't load dynamically always available functionsKacper Michajłow2023-09-011-46/+5
| | | | They are all available on Windows 7 and newer.
* win32/displayconfig: remove custom struct redefinitionKacper Michajłow2023-09-011-60/+0
| | | | | Those structs in MinGW-w64 are correct. I compared to Windows SDK and actually our version have not correct alignment.
* vo: add --video-cropKacper Michajłow2023-08-311-4/+11
| | | | | | Just cropping by VO that works with hwdec. Fixes: #12222
* mp_image: add image crop rect to mp_image_paramsKacper Michajłow2023-08-312-3/+24
|
* aspect: don't override src_start/src_endKacper Michajłow2023-08-311-2/+0
| | | | Rely on caller to set them.
* vo_gpu_next: improve --tonemapping-visualizeNiklas Haas2023-08-301-0/+25
| | | | | | | | | | | | | | | Pick a smarter rect, limit it to right half of screen (to allow more easily using it simultaneously with stats), and also auto-rotate through the hue plane by default (wrapping once every 10 seconds of playback). I briefly considered making it based on wallclock time instead of pts, but this has the rather unfortunate downside of only being updated sporadically as the user moves the mouse over OSC elements. (Of course, we could also forcibly redraw the screen continously to avoid it, but I'd rather not make such an invasive change for no real reason) This design also allows you to pause and focus on (via framestepping) individual parts of the hue graph that you're interested in.
* vo_gpu_next: add support for VOCTRL_HDR_METADATAKacper Michajłow2023-08-291-0/+34
|
* vo: add VOCTRL_HDR_METADATA to get mp_hdr_metadataKacper Michajłow2023-08-291-0/+2
|
* csputils: add mp_hdr_metadataKacper Michajłow2023-08-291-0/+18
|
* vo_dmabuf_wayland: unmap osd surface when not neededRobert Mader2023-08-281-1/+9
| | | | | | | Attaching a NULL buffer unmaps the surface, allowing compositors to skip blending the empty buffer. Closes #12236
* vo_gpu_next: fix --target-contrast=infNiklas Haas2023-08-281-1/+1
| | | | | | Somehow this overrode max_luma instead of min_luma... Fixes: 347fbd6fa357e854cfb0bc6d3c9b3d12994d5c0c
* vo_gpu_next: update tmp params before rendering frameNiklas Haas2023-08-271-7/+6
| | | | | Gives the correct queue size value for the subsequent pl_queue_update() calls, which avoids a bit of unnecessary overhead.
* vo_gpu_next: make option shim consistent with new APINiklas Haas2023-08-271-18/+20
| | | | | Avoids some unnecessary #ifdef and allows us to isolate the shim to a single location.
* vo_gpu_next: avoid duplicate code (cosmetic)Niklas Haas2023-08-271-5/+4
| | | | Also avoids 80col violation.
* vo_gpu_next: correctly set params.frame_mixerNiklas Haas2023-08-271-4/+3
| | | | | | | This was incorrectly adapted from the old options system, we forgot to ever actually assign p->frame_mixer to params.frame_mixer. Fixes: d2082841df8bc39c585fc9d4be6498d1a296fed8
* vo_gpu_next: don't nuke main options state in video_screenshotNiklas Haas2023-08-271-6/+13
| | | | | | | | This actually fixes a bug that was present in this code even before the new pl_options system, which is that `video_screenshot` would permanently leave `peak_detect_params.allow_delayed` as false, until something else forced options re-application due to options cache change.
* vo_gpu_next: don't override main options in draw_frameNiklas Haas2023-08-271-8/+10
| | | | | | | Instead, take a stack copy of the relevant struct. Avoids leaving temporary state dangling after this function returns. Fixes: 40b6afcfca81a30c29531a49b6368b53ad5d501f
* hwtransfer: use the right hardware config to find conversion targetsPhilip Langdale2023-08-263-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last piece in the puzzle for doing hardware conversions automatically is ensuring we only consider valid target formats for the conversion. Although it is unintuitive, some vaapi drivers can expose a different set of formats for uploads vs for conversions, and that is the case on the Intel hardware I have here. Before this change, we would use the upload target list, and our selection algorithm would pick a format that doesn't work for conversions, causing everything to fail. Whoops. Successfully obtaining the conversion target format list is a bit of a convoluted process, with only parts of it encapsulated by ffmpeg. Specifically, ffmpeg understands the concept of hardware configurations that can affect the constraints of a device, but does not define what configurations are - that is left up to the specific hwdevice type. In the case of vaapi, we need to create a config for the video processing endpoint, and use that when querying for constraints. I decided to encapsulate creation of the config as part of the hwdec init process, so that the constraint query can be down in the hwtransfer code in an opaque way. I don't know if any other hardware will need this capability, but if so, we'll be able to account for it. Then, when we look at probing, instead of checking for what formats are supported for transfers, we use the results of the constraint query with the conversion config. And as that config doesn't depend on the source format, we only need to do it once.
* hwtransfer: implement support for hw->hw format conversionPhilip Langdale2023-08-262-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we have not attempted to support hw->hw format conversion in the autoconvert logic. If a user needed to do these kinds of conversions, they needed to manually insert the hw format's conversion filter manually (eg: scale_vaapi). This was usually fine because the general rule is that any format supported by the hardware can be used as well as any other. ie: You would only need to do conversion if you have a specific goal in mind. However, we now have two situations where we can find ourselves with a hardware format being produced by a decoder that cannot be accepted by a VO via hwdec-interop: * dmabuf-wayland can only accept formats that the Wayland compositor accepts. In the case of GNOME, it can only accept a handful of RGB formats. * When decoding via VAAPI on Intel hardware, some of the more unusual video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats which gpu-next cannot handle, causing rendering to fail. In both these cases (at least when using VAAPI with dmabuf-wayland), if we could detect the failure case and insert a `scale_vaapi` filter, we could get successful output automatically. For `hwdec=drm`, there is currently no conversion filter, so dmabuf-wayland is still out of luck there. The basic approach to implementing this is to detect the case where we are evaluating a hardware format where the VO can accept the hardware format itself, but may not accept the underlying sw format. In the current code, we bypass autoconvert as soon as we see the hardware format is compatible. My first observation was that we actually have logic in autoconvert to detect when the input sw format is not in the list of allowed sw formats passed into the autoconverter. Unfortunately, we never populate this list, and the way you would expect to do that is vo-query-format returning sw format information, which it does not. We could define an extended vo-query-format-2, but we'd still need to implement the probing logic to fill it in. On the other hand, we already have the probing logic in the hwupload filter - and most recently I used that logic to implement conversion on upload. So if we could leverage that, we could both detect when hw->hw conversion is required, and pick the best target format. This exercise is then primarily one of detecting when we are in this case and letting that code run in a useful way. The hwupload filter is a bit awkward to work with today, and so I refactored a bunch of the set up code to actually make it more encapsulated. Now, instead of the caller instantiating it and then triggering the probe, we probe on creation and instantiate the correct underlying filter (hwupload vs conversion) automatically.
* 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-15