summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* win32: apply geometry position to content instead of windowAvi Halachmi (:avih)2022-02-021-1/+6
| | | | | | | | | | | | | | The docs specify that the +-X+-Y geometry values position the content. This used to work correctly but got broken at 8fb4fd9a . Geometry size is unaffected - this only concerns position. Commit 8fb4fd9a made it center the window rather than the content by taking the borders into account during positioning, but forgot to make an exception when a position is specified explicitly. This commit adds this exception, and now if a specific position is requested then the borders are ignored, and the content is positioned correctly.
* wayland: always resize when scale changes on surface enterDudemanguy2022-01-271-0/+1
| | | | | | | | | | | | a02901cae77c86fb9de997a418296d1fc0e3eada changed how mpv was handling wl_surface_set_buffer_scale. It's correct in that constantly setting the surface scale on every resize (which mpv was previously doing) is unneccessary and not right. However, it introduced a slight regression if someone moved a surface to a new monitor with the same resolution but a different scale. It did not trigger a resize and thus the video would have incorrect dimensions. A later refactor changed how things looked inside here, but this regression wasn't fixed. A resize should always be triggered if the scale changes in this surface event. Fixes #9426.
* wayland: support extra mouse buttonsRyan Hendrickson2022-01-281-18/+22
| | | | | | | | | | | | | Mouse button event codes above `BTN_EXTRA` (the ones currently defined in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`) are mapped to `MP_MBTN9` and up. (Reminder that due to historical reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely misleading; the real forward and back buttons are `BTN_SIDE` and `BTN_EXTRA` and are already mapped correctly by mpv.) This functionality is analogous to what the X11 backend supports in `video/out/x11_common.c` and what the Cocoa backend supports in `video/out/cocoa/events_view.m`.
* wayland: actually handle 0x0 resizes correctlyDudemanguy2022-01-271-0/+8
| | | | | | | | | | | According to the xdg-shell protocol spec, a 0x0 size from the compositor means that "the client should decide its own window dimension". We were not doing this correctly. What should happen is that mpv should simply reuse the old window size if it is not maximized or fullscreened. This should work on all (reasonably recent) versions of mutter and an compositor that follows the spec. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
* Revert "wayland: ignore 0x0 resizes"Dudemanguy2022-01-271-3/+2
| | | | | | | | | | | | | | | So actually according to the xdg-shell spec, a 0x0 resize is meant to indicate that "the client should decide its own window dimension". Previously, this just accidentally worked. In mutter 41.3, they changed how 0x0 resizes were sent and what actually happened was that mpv tried to resize itself to 0x0. This was obviously broken, so the reverted commit naively just ignored 0x0. It actually seemed to work, but it ended up breaking older versions of mutter. It's also not exactly the correct fix so it deserves a revert. This reverts commit d16defac27fcfe3e5fc43af6e42c2e590988cd3d. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
* x11: sanitize window title to UTF-8 for EWMHDudemanguy2022-01-241-2/+7
| | | | | | | | | | Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager Hints) require that the string is UTF-8*. mpv was not doing this and thus violating the spec. Just sanitize the title for these two atoms. Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so those atoms are left the same. Fixes #8812. *: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
* wayland: sanitize toplevel title to UTF-8Dudemanguy2022-01-241-1/+5
| | | | | | | The xdg-shell protocol requires that the toplevel title is UTF-8*. Go ahead and leverage existing mpv tools to sanitize the title. Fixes #9694 *: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
* wayland: ignore 0x0 resizesDudemanguy2022-01-231-2/+3
| | | | | | | | | Apparently mutter can send us 0x0 resizes* for whatever reason. Probably there's some interal reason why this occurs, but for us trying to resize to 0x0 is obviously terrible and results in all kinds of brokenness. Just ignore any 0 values. Fixes #9748. *: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
* vo_gpu: add HOOKED_gatherNiklas Haas2022-01-151-0/+5
| | | | | Can be used conditionally (via #ifdef HOOKED_gather) to use textureGather in custom shaders.
* vo_gpu_next: fix SUBBITMAP_BGRANiklas Haas2022-01-111-1/+1
| | | | | | | | | The only way to fix the channel order here is to create the texture with bgra format. Incidentally, there used to be a way to set the component map for overlays directly, but no more. Shouldn't matter since everything supports bgra8 anyways, though. Fixes #9699
* sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRANiklas Haas2022-01-114-11/+11
| | | | | This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
* image_writer: replace deprecated av_init_packet()sfan52022-01-101-10/+9
|
* vo_gpu: placebo: add missing gamma functionsNiklas Haas2022-01-101-3/+10
| | | | | | | | | These got added upstream a while ago. Need to be added to the mapping helpers. It might be time to think about bumping the minimum dependency here. Reported-by: Uoti Urpala <uau@glyph.nonexistent.invalid>
* vo_gpu_next: forward dovi metadata to libplaceboNiklas Haas2022-01-091-0/+17
|
* vf_format: add dolbyvision sub-optionNiklas Haas2022-01-091-2/+8
| | | | | | | | | | Useful to strip dolbyvision from the output, in cases where the user does not want it applied. Doing this as a video filter gives users the abiilty to easily toggle this stripping at runtime in a way that properly propagates to any (potentially stateful) VO. It also thematically fits the rest of the options in vf_format, which are similarly concerned with modifying the video image parameters.
* mp_image: add dolbyvision metadataLynne2022-01-092-0/+12
| | | | Co-authored-by: Niklas Haas <git@haasn.dev>
* wayland: use `xkb_keymap_new_from_buffer`Julian Orth2022-01-081-1/+2
| | | | | | | | | | | Instead of `xkb_keymap_new_from_string`. The protocol does not require the keymap to be null terminated and if the size of the keymap is a multiple of the page size, using `_from_string` could lead to problems. Some compositors include a null byte and even include the null byte in `size`. Therefore we have to use `strnlen` to find the real length of the string. Note that `_from_string` internally uses `strlen` and then calls `_from_buffer`.
* wayland: map keymaps with `MAP_PRIVATE`Julian Orth2022-01-081-1/+1
| | | | | | | | | | While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is only required from version 7 on, using `MAP_PRIVATE` allows us to be compatible with compositors that have only been tested with newer applications. Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no advantage over `MAP_PRIVATE`.
* vo_gpu: add --tone-mapping-modeNiklas Haas2022-01-074-19/+56
| | | | | | | | | | | This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
* vo_gpu: add --gamut-mapping-modeNiklas Haas2022-01-074-13/+41
| | | | | | | Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
* vo_gpu_next: use new HDR metadata optionsNiklas Haas2022-01-073-77/+52
| | | | | Properly forward the HDR metadata from the mpi to the equivalent (new) fields in pl_color_space. Used by the new tone mapping code.
* vo_gpu_next: update for new tone mapping optionsNiklas Haas2022-01-074-26/+61
| | | | | | | This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
* vo_gpu: move image2D precision qualifier to point of usesfan52022-01-021-3/+1
| | | | | | | image2D is only defined from GLSL ES 3.1 onwards, so those statements broke GLES 2.0. Move the qualifier to a place that is only reached with the right version requirements. fixes commit 584ab29c88d6c5ffa03666bffbbc93e4f0740f67
* vd_lavc: enable hwdec for prores by defaultrcombs2021-12-291-1/+1
|
* vo_gpu_next: fix --target-peak scalingNiklas Haas2021-12-291-1/+1
| | | | This is in nits, so it needs to be converted.
* wayland: avoid doing unneccesary window resizesDudemanguy2021-12-201-7/+0
| | | | | | | | | | | | | | | | | Commits 04018c306196888861775b248a8596ae494f122b cd7a7a1de8d8bffa05170befef25b251711c994a introduced behavior that updated window geometry during wayland events (specifically surface and output). This is good but they also are too aggressive with automatically resizing. For example, if a window is manually resized by the user and then dragged to a different monitor with different geometry than the initial monitor, mpv will automatically resize itself to the window's resolution. The initial thought behind this logic was for autofit to automatically readjust itself on a new monitor, but doing that breaks other common use cases. An attempt could be made to distinguish between autofit and a manual resize but that introduces a lot of complexity for an edge case. It's better to simply not change the window geometry here. Internal values are recalculated and scaled of course, but wl->window_size and wl->geometry should not change.
* vo_gpu: stop hard-coding max compute group threadsPhilip Langdale2021-12-196-6/+13
| | | | | | | | | | We've been assuming that maximum number of compute group threads is never less than the 1024 defined by the desktop GL spec. Given that we haven't had working compute shaders for GLES and I guess the Vulkan spec defines at least as high a value, we've gotten away with it so far. But we should really look the value up and respect it.
* vo_gpu_next: implement VOCTRL_EXTERNAL_RESIZEsfan52021-12-192-1/+5
| | | | | | This is only needed on Android and supposed to handle a context resize without reconfiguring the image parameters. reconfig() already does exactly this so plug it in there.
* mp_image, f_decoder_wrapper: implement AV_FRAME_DATA_DISPLAYMATRIXAlex Xu (Hello71)2021-12-151-0/+8
| | | | | | fixes #9249 (JPEG orientation support) with ffmpeg commit [0]. [0] https://github.com/FFmpeg/FFmpeg/commit/e93c9986027d17917c3b4f533b28ee4a2ce7cd4c
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-155-37/+5
|
* vo_gpu: opengl: some fixes to make compute shaders work with GLESPhilip Langdale2021-12-124-10/+15
| | | | | | | | | It's supposed to work with GLES >= 3.1 but we had all sorts of bad assumptions in our version handling, and then our compute shaders turn out not to be GLSL-ES compliant. This change contains some necessary, but insufficient, tweaks to the shaders. Perhaps we'll make it actually work some day.
* vo_gpu: opengl: fix OpenGL ES version and extension handlingPhilip Langdale2021-12-122-5/+25
| | | | | | | | Some of the extension declarations did not include the ES version where they became core functionality, and in some of these cases, there was never actually an ES extension - it first appeared in core. We also had a number of buggy version checks where ES versions were compared against required desktop GL versions.
* vo_gpu: opengl: try and create context at version 440 againPhilip Langdale2021-12-071-0/+9
| | | | | | | | | | | | | | | | | | | | | nvidia follow the OpenGL spec very strictly, with two particular consequences: * They will give you the exact context version that you ask for, rather than the highest possible version that meets your request. * They will hide extensions that the specs say require a higher version than you request, even if it's technically possible to provide the extension at lower versions. In our case, we really want a variety of extensions, particularly compute shaders that are only available in 4.2 or higher. That means that we must explicitly include a high enough version in our list of versions to check for us to be able to get a 'good' enough context. As for which version? We restore the 4.4 version that we had in the old version selection logic. This is the highest version we ever asked for, and we have separate logic that clamps the GLSL version to 4.4, so anything newer wouldn't make a difference.
* vo_gpu: opengl: fix wrong glMemoryBarrierNiklas Haas2021-12-061-1/+1
| | | | This call was completely wrong.
* vo_gpu_next: fix UB in query_format()Niklas Haas2021-12-051-1/+1
| | | | | | | | | `plane_data_from_imgfmt` doesn't zero-initialize the struct, so this contained invalid values for e.g. `row_stride`, causing formats to *randomly* fail. (Especially any formats with specific alignment requirements) Might fix #9424 and #9425.
* wayland: ensure read and draw buffers are assignedKurt Kartaltepe2021-12-043-0/+9
| | | | | | | | | | | | | | | | | This is a workaround for nvidia proprietary drivers. The authors of those drivers interpret the spec such that eglMakeCurrent will not reconfigure the read and draw buffers. Thus windows wont display anything drawn by opengl. nvidia authors refer to https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt specifically Issues 2/3 which reference eglMakeCurrent. On mesa this is a non-issue and the read/draw targets are assigned with eglMakeCurrent. The context must be made current in order to query OpenGL strings. An earlier proposal to create the wayland window surface similarly to X11 during init was deemed inappropriate so instead we manually set the targets once we have created a window surface.
* opengl: support DebugMessageCallback on ESKurt Kartaltepe2021-12-021-0/+11
| | | | | This function is provided by a different extension on OpenGL ES so we add a separate gl_functions.
* vo_gpu_next: implement VOCTRL_SCREENSHOTNiklas Haas2021-11-281-2/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat annoying but still relatively straightforward. There are several ways to approach this, but I settled on reusing the pl_queue as a cheap way to get access to the currently mapped frame. This saves us from having to process `vo_frame` at all, and also avoids any overhead from re-uploading the same frame twice. (However maybe there's some circumstance in which `vo_frame` needs to be queried/updated first, to get a screenshot of the correct frame? I'm not sure.) I also had the option of going with either pl_render_image() on the extract pl_frame, or just calling pl_render_image_mix directly on it. I went for the latter, because in the optimal case, this allows the rendered frame to be directly retrieved from the cache, actually entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s during playback essentially free. (Except for the download cost, obviously) It would be even neater if we could make this VOCTRL asynchronous and thereby leverage libplacebo's asynchronous download capabilities. But oh well. That will have to wait for a sufficiently rainy day. Closes #9388
* vo_gpu_next: factor out some common helpersNiklas Haas2021-11-281-43/+63
| | | | In preparation of VOCTRL_SCREENSHOT support
* vo_gpu_next: guard sentinel in free_dr_bufNiklas Haas2021-11-261-0/+1
| | | | | | As noticed in #9526, apparently there's some case in which DR buffers get corrupted. Add an explicit sentinel check to try and figure out which cases these are.
* vo_gpu: hwdec_vaapi: avoid drm_fourcc.h dependencyDave Airlie2021-11-251-1/+4
| | | | Suggested by haasn
* wayland: increase the vblank waiting timeDudemanguy2021-11-251-0/+2
| | | | | | | | | | | This commit sucks bad, but everything else is worse is other ways. Basically, the current vblank waiting time in the vo_wayland_wait_frame function (calculated very carefully using presentation statistics) is randomly too short. Some compositors are quite variable when they actually return callback so our timeout expires too quickly and throws everything off. The fix? Add an arbitrary 5% to the vblank value and pray that nothing gets off that much. Why did they have to make swapinterval 1/fifo mode indefinitely block? Fixes #9504.
* wayland: initialize presentation time values as 0Dudemanguy2021-11-241-0/+3
| | | | | | | Better to avoid any wonky calculations on startup with garbage values. The others end up being derived from last_ust/last_msc. refresh_interval is referenced exactly once and could, in theory, result in some terribly erroneous vblank time.
* wayland: cancel prepared reads when no eventsKurt Kartaltepe2021-11-251-6/+8
| | | | | | | | | | | | | A read can be prepared on the wayland display FD that is never actually read. This occurs when events are triggered on other FDs in the fd set. This change cancels a prepared read if poll reported no events for it. This fixes some hangs due to how nvidia's EGL implementation polls on the wayland fd unlike mesa implementations. It is based on nvidia's proposed fix for qt's similar message pump in https://codereview.qt-project.org/c/qt/qtwayland/+/373473 Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
* vo_gpu: hwdec_vaapi: add dma-buf modifiers support.Dave Airlie2021-11-232-1/+20
| | | | | If the EGL extension is present, pass the modifiers for each plane to the EGL driver.
* vo_gpu_next: implement OpenGL context supportsfan52021-11-222-7/+78
| | | | | Wrapping the context is pretty straightforward. This is only complicated by needing to account for the upside-down framebuffer in a few places.
* vo_gpu_next: factor out context-specific code to gpu_next/context.csfan52021-11-223-27/+138
| | | | | | This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code when additional backends are added in the near future. Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
* video: opengl: teach start_frame() about out_fbo == NULLsfan52021-11-221-0/+2
| | | | | | This case was added in 662c793a557925319493297de8c941a636f18d73 for use in vo_gpu_next as a visibility test before rendering a frame. The OpenGL context doesn't have this so it just returns true.
* vo_gpu_next: respect tagged YUV colorspaceNiklas Haas2021-11-221-1/+2
| | | | Fixes 2b2442ee67913221e5c87cbc06010671e1b41c15
* vo_gpu_next: apply csp overrides for RGB/XYZ/YUV formatsNiklas Haas2021-11-221-11/+27
| | | | | | | | | | | | | This is needed when the color system is not explicitly tagged, but instead needs to be inferred by the VO. Note that there exists the function mp_image_params_guess_csp for this sort of stuff, but it contains a lot of baggage that I don't want to replicate, in order to move as much of this logic into pl_renderer as possible, and therefore also give it the best chance of knowing what shortcuts it can and can't take. Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
* vo_gpu_next: fix timings without interpolationDudemanguy2021-11-211-3/+5
| | | | | | | | | | Adding vsync_offset to the pts in pl_queue_update actually messes up frame timings if one isn't using interpolation. The easiest way to see this is to have the monitor's refresh rate at an integer multiple of a video during a panning shot (classic case). There will be very visible judder/stutter in this case that does not happen in vo_gpu. The cause of this is the addition of the extra vsync_offset. Just match the semantics of vo_gpu where this is only used when interpolating.
* vo_gpu_next: fix OOM on waylandNiklas Haas2021-11-201-7/+3
| | | | | | Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8 Fixes #9484
* wayland: fix a potential segfault on surface enterDudemanguy2021-11-201-0/+3
| | | | | | | | | | | | | | | | | | This possibility actually existed for years. The wayland protocol is asynchronous and there's no restriction on when a compositor can send a surface enter event. In mpv's case, the surface enter event is used to set some vital things regarded geometry/scaling etc. However, this implictly assumes that wl->current_output is actually initialized. The vast majority of the time, vo_wayland_reconfig will happen first which is where wl->current_output is, and should, be created. There's no rule/law that the ordering of events will always occur in this order. Plasma with certain auto-profile conditions can send the surface enter event before mpv does its initial reconfig. That segfaults of course. Just add a check to make sure we have wl->current_output here and return if we don't. This assumes that the compositor will send us another surface enterance event when mpv actually does the initial surface commit and roundtrip request later. Wayland logs indicate this does happen. Fixes #9492.
* wayland: support modifiers during axis eventsDudemanguy2021-11-201-4/+5
| | | | | | It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
* vo_gpu_next: always cache still framesNiklas Haas2021-11-191-1/+3
| | | | | | | Even when not display synced. Prevents redraw overhead for refreshes while paused. Also make the logic slightly clearer to follow (since it's inverted).
* vo_gpu_next: fix lancozs typo to lanczosLeo Izen2021-11-191-1/+1
| | | | | Fix typo in the warning to avoid ewa_lanczossharp because it might be removed in the future.
* vo_gpu: libplacebo: make version logging slightly clearerNiklas Haas2021-11-191-1/+2
| | | | Matches what `pl_log_create` does as well.
* vo_gpu_next: simplify and improve frame redrawing logicNiklas Haas2021-11-191-14/+6