summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* wayland: unify visibility checking codeDudemanguy2022-04-117-23/+33
| | | | | | | | | | | A bit of a personal pet peeve. vulkan, opengl, and wlshm all had different methods for doing wayland's "check for visibility before drawing" thing. The specific backend doesn't matter in this case and the logic should all be shared. Additionally, the external swapchain that the opengl code on wayland uses is done away with and it instead copies vulkan by using a param. This keeps things looking more uniform across backends and also makes it easier to extend to other platforms (see the next couple of commits).
* vo_gpu/d3d11: add message ID based log level mappingJan Ekström2022-04-111-6/+64
| | | | | | | | | | | | | This lets us remap various messages which might now be happening at each frame onto the trace level, thus unaffecting the initial debug log level. Additionally - thanks to this ability - the previously globally denied message queue abandonment messages can now be handled and mapped to trace log level, as on that log level they may be of use. Recommended by rossy and based on his libplacebo commit 6d72f6445566eddb0493447d0bda72d98a99d40c .
* vo_gpu/d3d11: mimic libplacebo backbuffer usageJan Ekström2022-04-111-7/+10
| | | | | | Instead of always having the reference outside of calling resize, request a backbuffer at start and relieve the backbuffer at submission for presentation.
* vo_gpu/d3d11: enable receival of color depth without active backbufferJan Ekström2022-04-111-2/+12
| | | | | | | Query the description of the swap chain, which should in all theory contain the format of the backbuffer. Then utilize a newly added ra_d3d11 function to map the format to an ra_format. After that, utilize the depth of the first plane of the format, as previously.
* vo_gpu/d3d11: add helper function to get ra_format from DXGI_FORMATJan Ekström2022-04-112-0/+16
|
* vo_gpu_next: switch to unpooled hwdec mappingNiklas Haas2022-04-113-64/+85
| | | | | | | | | | | | This makes use of the new frame acquire/release callbacks to hold on to hwdec images only as long as necessary. This should greatly improve the smoothness/efficiency of hwdec interop, by not holding on to them for longer than needed. This also avoids the need to pool hwdec mappers altogether. Should fix #10067 as well, since frames are now only mapped when we actually use them.
* x11: fix screen-name optionDudemanguy2022-04-081-0/+1
| | | | | | | | | | | 9a7b2015e1a711a57b6e660774c36956ac59a7f6 added the --screen-name option for x11, but it was unfortunately broken. The commit does correctly handle vo_x11_update_screeninfo and select the correct screen. However, vo_x11_sizehint was missed. Specifically, the force_pos bool was always false because it only took into account --screen being set and not --screen-name. To fix this, just add an extra condition to the force_pos bool so it becomes true if there's a string in --screen_name. Fixes issue #9877.
* egl_helpers: request at least 8 alpha bits if necessaryOlivier Perret2022-04-071-1/+1
| | | | | | Previously on wayland, it would result in an egl config with only 2 alpha bits, which technically matches what was requested, but is not very useful. Fixes #9862
* drm: context_drm_egl: add support for enabling VRRPhilip Langdale2022-04-055-0/+29
| | | | | | | | | | | | | | Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used with DRM by setting the VRR_ENABLED property on a crtc if the connector reports that it is VRR_CAPABLE. This is a useful feature for us as it is common to play 24/25/50 fps content on displays that are nominally locked to 60Hz. VRR can allow this content to play at native framerates. This is a simple change as we just need to check the capability and set the enabled property if requested by the user. I've defaulted it to disabled for now, but it might make sense to default to auto in the long term.
* vd_lavc: add vo caps and option to set GPU film grain applicationLynne2022-04-052-1/+7
|
* vo_gpu_next: apply film grain if such metadata is presentLynne2022-04-051-0/+5
|
* Revert "vo_gpu_next: remove unnecessary dependency"Niklas Haas2022-04-011-2/+1
| | | | | | This reverts commit 1c2dde91d369987199782f4914f56019e5a2272c. Fixes #10037
* vo_gpu_next: remove unnecessary dependencyNiklas Haas2022-03-291-1/+2
| | | | | | Pulling in <libplacebo/utils/libav.h> in particular triggers the notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built without Vulkan support.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-217-20/+21
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* vo_gpu_next: also include stride alignment in DR sizeNiklas Haas2022-03-141-2/+3
| | | | Fixes #9976
* vulkan: correctly inherit proc_addr pointerNiklas Haas2022-03-131-0/+1
| | | | | | As found out by @philipl, failing to pass this from the VkInstance to the VkDevice is bad style. We might want to override the get_proc_addr pointer in the future.
* vo_gpu: hwdec_vaapi: Improve logging when probing surface formatsPhilip Langdale2022-03-102-4/+25
| | | | | | | | | | | Our logging here today is very poor. We don't make it clear what formats we are probing, or even that a certain format failed in most cases. In the case where we do log the error, we don't make it clear which format it was that failed. The end result is that we have no idea what the possible and final format spaces are, which makes it very hard to debug whether things are working correctly, or to work on supporting additional formats.
* vo_gpu_next: fix crash when disabling DR at runtimeNiklas Haas2022-03-081-5/+6
| | | | | | | This code fails if we have DR buffers, but none of them correspond to the current frame. Normally only happens if e.g. changing the decoder at runtime, since DR buffers are not properly reinit in that case. (Arguably a separate bug)
* vo_gpu_next: don't leak mpi on failed uploadNiklas Haas2022-03-081-32/+37
| | | | | | | The current map_frame() code fails to clean up after itself on the failure paths. But if map_frame returns false, no cleanup code is ever attempted. Add the relevant calls to clean up state manually, throughout.
* vo_gpu_next: properly keep track of DR allocationsNiklas Haas2022-03-071-27/+39
| | | | | | | | | | | | | | | | | | | So, turns out the approach in 7f67a553f doesn't work for all codecs. In particular, sometimes lavc will internally allocate a new AVBuffer that just points at the old AVBuffer but has a different opaque field for some reason. In these cases, the DR metadata doesn't survive the round-trip through libavcodec. I explored several alternative ways of solving this problem, including adding new mp_image fields, but in the end none of them survived the round-trip through AVFrame and back. The `priv` and `opaque` fields in respectively `mp_image` and `AVFrame` are also too heavily overloaded to be of much help. In the end, bite the bullet and use the same approach as done in `vo_gpu`, which is to just keep track of a list of all allocations. This is a really ugly way of doing things IMO, but ultimately, completely safe.
* vo_gpu_next: don't allocate dr_buf as part of the AVBufferRefNiklas Haas2022-03-061-20/+9
| | | | | | | | | | | | | | | | | | Some decoders, notably hevcdec, will unconditionally memset() the entire AVBufferRef based on the AVBufferRef size. This is bad news for us, since it also overwrites our `struct dr_buf`. Rewrite this code to make it more robust - keep track of the DR buf metadata in a separate allocation instead. Has the unfortunate downside of technically being undefined behavior if `opaque` is not at least 64 bits in size, though, but avoids this issue. Maybe there's a better way for us to unconditionally keep track of DR allocation metadata. I could try adding it into the `mp_image` itself. Maybe on a rainy day. For now, this works. Fixes #9949 Might fix #9526
* hwdec: fix out-of-date preprocessor variable nameNiklas Haas2022-03-041-1/+1
| | | | This was renamed to HAVE_VAAPI_LIBPLACEBO.
* vo_gpu_next: add D3D11 RA texture wrapping/unwrapping for hwdecJames Ross-Gowan2022-03-033-5/+44
| | | | This mostly copies the API used in the GL backend.
* vo_gpu_next: add support for hardware decodingNiklas Haas2022-03-032-36/+166
| | | | | | | | | | | | | | | | There are two major ways of going about this: 1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing hwdec mappers, and then add code in vo_gpu_next to rewrap those ra_tex objects into pl_tex. 2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose it to the hwdec mappers, then directly use the resulting pl_tex. I ultimately opted for approach 1 because it enables compatibility with more hardware decoders, specifically including ones that use native OpenGL calls currently. The second approach only really works with cuda_vk and vaapi_pl.
* vo_gpu_next: configure the VO queue size dynamicallyNiklas Haas2022-03-031-12/+21
| | | | | | This avoids decoding/caching more frames in advance than necessary. In particular, this is very important for hwdec, which generally can't have too many decoded frames in a pool at the same time.
* vo_gpu_next: expose EGLDisplay to pl_gpuNiklas Haas2022-03-031-0/+7
| | | | Straightforward and enables the import/export of dmabufs.
* vo_gpu: move hwdec loading code to common helperNiklas Haas2022-03-036-153/+193
| | | | | | | So I can reuse it in vo_gpu_next without having to reinvent the wheel. In theory, a lot of the stuff could be made more private inside the hwdec code itself, but for the time being I don't care about refactoring this code, merely sharing it.
* hwdec: release images as soon as possible after mappingNiklas Haas2022-03-033-4/+15
| | | | | | | | | | We don't need to hold on to buffers longer than necessary. Doesn't matter for vo_gpu but greatly matters for vo_gpu_next, since it persists hwdec mapped textures for longer periods. Unfortunately, only provides benefits for hwdecs which do explicit copies in their decode path, which currently just means cuda and d3d11va.
* hwdec_vaapi_vk: rename to vaapi_plNiklas Haas2022-03-033-13/+12
| | | | | | | | There's really nothing vulkan-specific about this hwdec wrapper, and it actually works perfectly fine with an OpenGL-based ra_pl. This is not hugely important at the time, but I still think it makes sense in case we ever decide to make vo_gpu_next wrap OpenGL contexts to ra_pl instead of exposing the underlying ra_gl.
* hwdec_vaapi_gl: properly zero initialize priv structNiklas Haas2022-03-031-6/+8
| | | | | | | | | Easiest way is by just using a designated struct initializer. If we don't, `p->images` ends up inheriting random data, which leaks into e.g. eglDestroyImageKHR. It's a small miracle this never blew up before. Or maybe it did. Who knows.
* vo_gpu_next: remove/simplify plane flipping hacksNiklas Haas2022-02-251-37/+9
| | | | | | | | | libplacebo v198 fixed this properly by adding the ability to flip planes directly, which is done automatically by the swapchain helpers. As such, we no longer need to concern ourselves with hacky logic to flip planes using the crop. This also removes the need for the OSD coordinate hack on OpenGL.
* vo_gpu_next: avoid rendering subtitles as HDR/wide gamutNiklas Haas2022-02-251-1/+9
| | | | Fixes #9911
* vo_gpu_next: refactor subtitle renderingNiklas Haas2022-02-213-30/+56
| | | | | | | | | | | | | | | Render subs at the output resolution, rather than the video resolution. Uses the new APIs found in libplacebo 197+, to allow controlling the OSD resolution even for image-attached overlays. Also fixes an issue where the overlay state did not get correctly updated while paused. To avoid regenerating the OSD / flushing the cache constantly, we keep track of OSD changes and only regenerate the OSD when the OSD state is expected to change in some way (e.g. resolution change). This requires introducing a new VOCTRL to inform the VO when the UPDATE_OSD-tagged options have changed. Fixes #9744, #9524, #9399 and #9398.
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-173-12/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we have treated hwdec interop loading as a completely separate step from loading the hwdecs themselves. Some hwdecs need an interop, and some don't, and users generally configure the exact hwdec they want, so interops that aren't relevant for that hwdec shouldn't be loaded to save time and avoid warning/error spam. The basic approach here is to recognise that interops are tied to hwdecs by imgfmt. The hwdec outputs some format, and an interop is needed to get that format to the vo without read back. So, when we try to load an hwdec, instead of just blindly loading all interops as we do today, let's pass the imgfmt in and only load interops that work for that format. If more than one interop is available for the format, the existing logic (whatever it is) will continue to be used to pick one. We also have one callsite in filters where we seem to pre-emptively load all the interops. It's probably possible to trace down a specific format but for now I'm just letting it keep loading all of them; it's no worse than before. You may notice there is no documentation update - and that's because the current docs say that when the interop mode is `auto`, the interop is loaded on demand. So reality now reflects the docs. How nice.
* vo_gpu_next: don't crash on negative plane stridesNiklas Haas2022-02-111-5/+34
| | | | | | | | | | | | | | This is an annoying special case only really needed because of the `vflip` filter. mpv handles this by directly adjusting the plane transform. The libplacebo API, unfortunately, does not allow passing the required information for this to work smoothly. Long-term I plan on adding support for plane flipping in libplacebo directly, but for the meantime, we will have to work-around it by moving the flipping to the whole-image `crop` instead. Not an ideal solution but better than crashing. Fixes #9855
* vo_gpu: d3d11_helpers: don't create UNORDERED_ACCESS backbuffers in Win7James Ross-Gowan2022-02-091-0/+10
| | | | | | | | | | | | | | We're getting bug reports that the recent change to add extra usage flags to swapchain buffers (for gpu-next) breaks mpv on some Windows 7 systems, and it seems like this is only happening with flip-model swapchains. Creating swapchains with DXGI_USAGE_UNORDERED_ACCESS should be valid. At least, it's not specifically disallowed, unlike some other flags[1]. So, just disable it for flip-model swapchains in Windows 7, rather than disabling it everywhere. [1]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-usage
* wayland: partially fix drag and drop handlingDudemanguy2022-02-071-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drag and drop in wayland is weird and it seems everyone does this slightly differently (fun). In the past, there was a crash that occured (fixed by 700f4ef5fad353800fa866b059663bc1dd58d3b7) which involved using the wl_data_offer_finish in an incorrect way that triggered a protocol error (always fatal). The fix involved moving the function call to data_device_handle_drop which seemingly works, but it has an unfortunate side effect. It appears like GTK applications (or at least firefox) close the pipe after this function is called which makes it impossible for mpv to read data from the fd (well you could force it open again in theory but let's not do that). Who knows if that was the case when that commit was made (probably not because I'd think I would have noticed; could just be a dummy though), but obviously having broken dnd for a major application isn't so fun (this works with QT and chromium anyway). Ideally one would just simply check the pipe in data_device_handle_drop, but this doesn't work because it doesn't seem the compositor actually sends mpv the data by then. There's not actually a defined event when you're supposed to be able to read data from this pipe, so we wait for the usual event checking loop later for this. In that case, wl_data_offer_finish needs to go back into check_dnd_fd, but we have to be careful when calling it otherwise we'd just commit protocol errors like before. We check to make sure we even have a valid wl->dnd_offer before trying to indicate that it is finished and additionally make sure there is a valid dnd_action (after checking the fd, it's always set back to -1). This doesn't fix everything though. Specifically, sway with focus_follows_mouse (the default) and GTK as the data source still doesn't work. The reason is that when you do a drag and drop in sway with that option on, a new wl_data_device.data_offer event is sent out instantly after the drop event. This happens before any data is sent across the fd and before mpv even has a chance to check it. What GTK does, when getting this new data_offer event, is close the pipe (POLLHUP). This means mpv can't read it when we reach the event loop and thus no data is ever read and broken drag and drop. From the client side, this isn't really fixable since the wayland protocol doesn't have a clear indication of when clients are supposed to read from the fd and both the compositor and data source are doing things totally out of our control. So we'll consider this weird case, "not our bug" at least. The rest should work.
* vo_gpu_next/context: get graphics API-specific contexts from pl_gpuJan Ekström2022-02-061-36/+31
| | | | | | | | | | | | | | By receiving the graphics API-specific contexts from the generic pl_gpu instance, it is not necessary to store them separately. As the current priv struct stores nothing else, this allows its removal. This removal cleans up related compiler warnings regarding unused variables in case of opengl and d3d11 being disabled in mpv/libplacebo. Functions to receive the underlying vulkan,gl,d3d11 structure were added in libplacebo version 4.182. Our current requirement for gpu-next is 4.190, and thus we can freely utilize these helper functions.
* vo_gpu: hwdec_vaapi: Don't probe formats for irrelevant endpointsPhilip Langdale2022-02-061-0/+8
| | | | | | | | | | | | | | While testing support for the exotic formats used by Intel vaapi for 4:2:2 and 4:4:4 surfaces, I realised that we were enumerating all endpoints and checking formats for them. The problem with this is that decoding (VLD) endpoints are only a subset of what vaapi exposes. All the encoding endpoints are there too, and there is also the None profile that we don't care about, but which generates ffmpeg warnings if you try and examine it. So, let's only look at VLD endpoints. This will speed things up a little bit and make the logging less noisy.
* libplacebo: switch to new target format APINiklas Haas2022-02-031-1/+6
| | | | | `target_dummy` got deprecated in version v4.169. We unfortunately have to hide this behind an #if for the time being.
* libplacebo: switch to new GPU limits APIsNiklas Haas2022-02-031-6/+11
| | | | | `caps` is deprecated, and replaced by individual fields in `pl_glsl_version` / `pl_gpu_limits`.
* libplacebo: switch to v4 naming conventionNiklas Haas2022-02-035-50/+46
| | | | | All of these const struct pointers got typedefs, clean up the code accordingly.
* libplacebo: update log helpersNiklas Haas2022-02-038-38/+35
| | | | | Use the pl_log APIs introduced in libplacebo v4, replacing the deprecated pl_context concept.
* libplacebo: bump minimum dependency to 4.157Niklas Haas2022-02-031-10/+3
| | | | | | This has been the latest stable release for about half a year now. This version in particular lets us get rid of all the deprecation warnings in the older code. (See the following commits)
* vo_gpu_next: create shader cache dir if missingNiklas Haas2022-02-031-0/+1
| | | | | Failing to do this results in the shader cache not actually ever being written, ergo no shader caching being done. Oops.
* build: rename libplacebo version checkNiklas Haas2022-02-031-1/+1
| | | | | Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture the intent, since this will become libplacebo v5 eventually (tm).
* wayland: always start rendering after a resizeJulian Orth2022-02-031-0/+6
| | | | | | | | | | | | | | | | | | | The wayland backend contains logic to detect if the window is hidden. If so, we skip rendering as an optimization. However, if we receive multiple resize events in rapid succession, we will send the compositor new buffers faster than the refresh rate of the monitor. Therefore the compositor will not send us frame events which we incorrectly interpret as the window being hidden. Once the last buffer has actually been rendered, the compositor sends us a frame event. However, if at that point playback is paused, there is no logic to restart rendering of frames that we skipped due to the above optimization. Therefore we never send the compositor new buffers corresponding to the new size of the window and the surface will either be too small or too large. The simplest solution is to always render a few frames after we receive a resize event.
* filter kernels: add cosine windowgaramond132022-02-031-0/+6
| | | | filter kernels: add cosine window
* vo_gpu_next: initial attempt at adding d3d11 supportJan Ekström2022-02-021-7/+87
|
* vo_gpu_next/context: common'ize things that would be common for non-vulkanJan Ekström2022-02-021-10/+25
| | | | This prepares us to not duplicate all of this code for d3d11.
* vo_gpu/d3d11: enable access to the underlying ra_ctx swap chainJan Ekström2022-02-022-0/+22
| | | | This enables us to utilize it from gpu-next.
* vo_gpu/d3d11: add more usage flags to the swapchain imagesJames Ross-Gowan2022-02-021-1/+8
| | | | | | | | vo_gpu_next and libplacebo expect swapchain images to be able to be blitted to, which for libplacebo on FL11_0 and up means they have to have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader to emulate certain kinds of blits. For libplacebo's benefit, set all applicable usage flags on swapchain images.
* vo_gpu/d3d11: early exit in start_frame if output fbo is nullptrJan Ekström2022-02-021-0/+3
|
* 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 enter