summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* wayland: set appid before initial surface commitDudemanguy2022-06-111-3/+3
| | | | | | | | | This shouldn't have mattered but apparently qtile is unable to get the app id if you set it after the initial surface commit. Wayland is a mess anyway so just shuffle this around so that the frame callback and surface commit are the last things registered in vo_wayland_init. This works around qtile and, in theory, doesn't appear to break anything else. Fixes #10280.
* wayland_gl: fix a typoDudemanguy2022-06-111-1/+1
| | | | | Somehow in commit 661b5542de21d46d4d7c4693e564f4eec0526812, my editor snuck in a ￥ sign in here. Oops.
* wayland_gl: wait until resize to create egl_windowDudemanguy2022-06-101-34/+32
| | | | | | | | | | | | | Some wayland compositors (i.e. weston) get extremely picky about committed buffer sizes not matching the configured state. In particular, weston throws an error on you if you attempt to launch with --window-maximized and use opengl (vo_vaapi_wayland actually errors as well in this case, but that's a different issue). The culprit here is actually wl_egl_window_create. This creates an initial buffer at the sizes passed in the arguments which is what weston doesn't like. Instead, move the egl_window creation call to the resize function. This ensures that mpv is using the size obtained via the toplevel event, and it should always be the buffer size we want.
* wayland_gl: use wl->scaling when creating egl_windowDudemanguy2022-06-071-2/+3
| | | | | | | | | | | | | This was actually always bugged, but we just got lucky that compositors ignored it. The egl window was created only using wl->geometry's coordinates but those do not include the scale factor. So technically, the initial window creation always had the wrong size (off by whatever the scaling factor is). The resize call later fixes it because that correctly uses wl->scaling so in practice nothing bad was seen. wlroots's master branch has started sending an error in this case however and this is what trips it. Fix it correctly by using the scale factor. This is what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix (but was incorrect).
* wayland: rearrange initialization logicDudemanguy2022-06-071-10/+8
| | | | | | | | | cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
* wayland: remove some unneeded lines from reconfigDudemanguy2022-06-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | Just a couple of small changes. First, the obvious one is to remove the bogus wl->window_size = wl->vdparams; line in the configure conditional. The reconfig always unconditionally sets the window_size here so there's no need to duplicate it. The more important change is to remove the usage of set_surface_scaling. This function is just to handle when scaling changes and for setting the initial scale, it was called in the reconfig. This, however, causes some weird issues in the latest sway/wlroots where it can try to divide a buffer by an inappropriate scale factor. This is possibly due to some weird ordering of events and only occured in opengl for some reason. Luckily, it turns it out it's not neccessary to set the scaling here at all. The surface enter event is already setup to handle scale changes. On an HIDPI display, mpv will initially assume a scale of 1 but the surface actually enters the wl_output, it will automatically readjust and resize itself to the appropriate scale value. This works on the initial launch of the mpv window as well, so there's no need to special case this in the reconfig event. This has the nice bonus of avoiding that sway/wlroots issue as well since the buffer_scale is set much later. Fixes #10263.
* vo_gpu_next: fix OSD rendering of screenshotsNiklas Haas2022-06-061-5/+6
| | | | | | | | | | | | | | One downside of this approach is that it bypasses the mixer cache, but while this is not ideal for performance reasons, the status quo is also simply broken so I'd rather have a slower implementation that works than a faster implementation that does not. And as it turns out, updating the OSD state and invalidating the mixer cache correctly is sufficiently nontrivial to do in a clean way, so I'd rather have this code that I can be reasonably certain does the right thing. Fixes #9923 as discussed. Also fixes #9928.
* video/out/dither: remove custom index_t typedefWessel Dankers2022-06-041-26/+24
| | | | | | | | Apparently _t names are reserved, and in this case it wasn't very useful anymore (it was useful while developing it, but this code is almost 10 years old now). Fixes a compilation error on Solaris.
* wayland: force vo_vaapi_wayland scaling to 1Dudemanguy2022-05-301-1/+2
| | | | | | | | | | | | | The wayland stuff is designed to update/rescale itself whenever the wl_output scale changes. This is great, but vo_vaapi_wayland should not actually attempt to handle any hidpi stuff. The point of this VO is to hand off as much to the compositor as possible, so we do want the compositor to do the scaling here (enjoy your bilinear). This fixes some incorrect rendering that could occur with scaling values not equal 1 due to mismatches between buffer coordinates and the surface local coordinates. It also eliminates the need to specify --no-hidpi-window-scale on hidpi displays (has the same practical effect).
* vo: move allocate_memfd method to wayland_commonAaron Boxer2022-05-304-36/+26
|
* vo_vaapi_wayland/wayland_common: code style fixesDudemanguy2022-05-303-138/+177
| | | | | | | | A bad person (AKA me) merged this stuff without paying close enough attention to the code style. Reformat this to be in-line with the rest of the wayland code and general mpv style (braces for functions on the next line, horizontally aligning arguments, some cosmetic cleanups for wayland_common.h, etc.).
* wayland: use mp_tag_str not drm_format_stringDudemanguy2022-05-304-455/+3
| | | | | | | | | | | So it turns out that mpv already has an mp_tag_str which makes a readable string out of fourccs (drm formats are these). drm_format_string, on the other hand, has a ton of baggage with having to check different libdrm versions for certain headers, adding compile-time defines (because there are no version defines in the libdrm headers), etc. It's a lot simpler to just use what mpv already has and it returns what you actually care about: i.e. is this format supported or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
* vo: allow vaapi_wayland and vaapi_x11 to coexistAaron Boxer2022-05-301-2/+3
|
* wayland: don't depend on the order of global announcementsJulian Orth2022-05-281-4/+10
| | | | E.g. wl_subcompositor could be announced before wl_compositor.
* vo: add new vaapi-wayland driverAaron Boxer2022-05-246-1/+953
| | | | | | | This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
* various: remove trailing whitespaceGuido Cella2022-05-142-2/+2
|
* wayland: use wl_output v4 for display-namesDudemanguy2022-05-131-2/+4
| | | | | | | | 5774ce759a6c7fe0727cfbd4458957abfd96a7b7 added the new output name event and used them for the --fs-screen-name option. It turns out that the display-names property could also make use of these names, so go ahead and use output->name in this case if we have them. If not, fallback to output->model like before.
* context_drm_egl: support monitor parDudemanguy2022-05-051-0/+9
| | | | | | These values and options were simply never looked at in the drm egl context. This pretty much is just a copy and paste of what is in vo_drm. Fixes #10157.
* video/image_writer: tag colorspace in AVCodecContextLeo Izen2022-05-041-2/+4
| | | | | If screenshot-tag-colorspace=yes, then set the corresponding fields in AVCodecContext, not just in AVFrame.
* video/image_writer: fix high-depth JPEG XL screenshotsLeo Izen2022-04-291-1/+5
| | | | | | | Allow screenshot-high-bit-depth=yes to work with JPEG XL screenshots when screenshot-sw=no is set. They already work as expected when screenshot-sw=yes is set, but this allows the hardware screenshots to work this way too.
* build: add avcodec jpegxl dependency versionsLeo Izen2022-04-281-5/+3
| | | | | Add the libavcodec version check for AV_CODEC_ID_JPEGXL to the build system rather than to any file that references it.
* wayland: use wl_surface_damage_bufferDudemanguy2022-04-272-5/+5
| | | | | | | | | | | | | | | | Since 2018, wl_surface_damage_buffer has been explicitly preferred and recommended over wl_surface_damage*. mpv was still using the old function in a couple of spots. The only difference is that we need to pass buffer coordinates instead of surface coordinates. In vo_wlshm, this is done by using vo->dwidth/vo->dheight since that is always used whenever wl_buffers are created. In the case of the cursor surfaace, we actually already passed buffer coordinates to it (img->width/height) which was probablly technically wrong with wl_surface_damage, but it doesn't really matter in practice. This requires bumping wl_compositor to version 4 which is no problem since this dates back to 2015*. https://gitlab.freedesktop.org/wayland/wayland/-/commit/921d0548035673a1bf6aeb9396b9bc728133411e https://gitlab.freedesktop.org/wayland/wayland/-/commit/3384f69ecf043d62a4e036c0353c2daa01d7c4d0
* video/image_writer: add Jpeg XL screenshotsLeo Izen2022-04-262-0/+20
| | | | | | | Add Jpeg XL as a possible output format for screenshots, which should make it possible to take fast screenshots with much better quality than JPEG, or take lossless high-bit-depth screenshots with lower file sizes than PNG.
* various: fix typosCœur2022-04-2514-19/+19
|
* vo_gpu_next: avoid 0x0 resizesDudemanguy2022-04-241-2/+4
| | | | | | | | | | | It is possible for vo_gpu_next to attempt a resize before the windowing backend is fully initialized. In practice, this can happen on wayland which means libplacebo attempts a 0x0 resize. Depending on the API, a 0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns a 0 in this case which mpv doesn't do anything with anyway. In the case of opengl, this usage is explictly forbidden and will result in a warning which may confuse users. Solve this by just not trying a resize if dwidth and dheight in the vo are not available. Fixes #10083.
* vo_wlshm: use draw_frame instead of draw_imageDudemanguy2022-04-211-3/+3
| | | | | | | | draw_image is an old API that was deprecated long ago. However when wlshm was originally added, it used draw_image. There's no particular reason for this and it can trivially be switched to draw_frame instead. This has some real advantages (notably --vo=wlshm --idle --force-window actually works).
* vd_lavc: fixup unchecked usage of AV_CODEC_EXPORT_DATA_FILM_GRAINJan Ekström2022-04-131-0/+7
| | | | | | | | | | | | | | This fixes build failures with avcodec 58.113.100 or before, matching FFmpeg release versions 4.0 to 4.3. This flag was added in between avcodec 58.113.100 and 58.114.100 during the FFmpeg 4.4 development cycle. It lacks its own version bump, so instead a check for the define is utilized instead. Additionally, warn the user if they request GPU film grain with too old of an FFmpeg. Fixes #10088
* vd_lavc: fix decoder initialization when no VO is availableJan Ekström2022-04-111-6/+20
| | | | | | | | | | | | | | | | | The VO is available during decoder initialization mostly for direct rendering purposes, so if f.ex. a complex filter chain is utilized, there is no video renderer information available via mp_filter_find_stream_info during creation of the decoder filter. Thus, check for whether the VO is available before attempting to check the capabilities flag from it. Additionally - to simplify logic - makes explicitly requesting GPU film grain to always disable decoder film grain functionality. The warning is still shown if the VO is available and no support for film grain application is available. Fixes #10079
* vd_lavc: remove duplicate vd_ffmpeg_ctx pointer from init_avctxJan Ekström2022-04-111-2/+1
| | | | | Seems like in some functions this was called p and in others ctx, and thus it was added as the `p` pointer was not available.
* wayland: use wl_output v4 for --fs-screen-nameDudemanguy2022-04-111-3/+30
| | | | | | | | | | In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-117-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because wayland is a special snowflake, mpv wound up incorporating a lot of logic into its render loop where visibilty checks are performed before rendering anything (in the name of efficiency of course). Only wayland actually uses this, but there's no reason why other backends (x11 in this commit) can't be smarter. It's far easier on xorg since we can just query _NET_WM_STATE_HIDDEN directly and not have to do silly callback dances. The function, vo_x11_check_net_wm_state_change, already tracks net wm changes, including _NET_WM_STATE_HIDDEN. There is an already existing window_hidden variable but that is actually just for checking if the window was mapped and has nothing to do with this particular atom. mpv also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same as being minimized but according to the spec, that's not neccesarily true (in practice, it's likely that these are the same though). Anyways, just keep track of this state in a new variable (hidden) and use that for determing if mpv should render or not. There is one catch though: this cannot work if a display sync mode is used. This is why the previous commit is needed. The display sync modes in mpv require a blocking vsync implementation since its render loop is directly driven by vsync. In xorg, if nothing is actually rendered, then there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so it returns immediately. This, of course, results in completely broken video. We just need to check to make sure that we aren't in a display sync mode before trying to be smart about rendering. Display sync is power inefficient anyways, so no one is really being hurt here. As an aside, this happens to work in wayland because there's basically a custom (and ugly) vsync blocking function + timeout but that's off topic.
* 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-053-1/+21
|
* vo_gpu_next: apply film grain if such metadata is presentLynne2022-04-051-0/+5
|
* vf_format: support forwarding/stripping film grain metadataLynne2022-04-051-0/+6
|
* mp_image: support film grain parametersLynne2022-04-052-0/+12
|
* vd_lavc: hide a deprecation warning in already handled compatible codeJan Ekström2022-04-031-1/+3
| | | | | | | | | | | The field has been deprecated, yet the upcoming new default is not yet the default. Thus, until lavc major hits 60 and the default behavior finally gets changed, we have to explicitly set the field's value. The deprecation had already been handled by adding the required version limitation for this code in bbbf3571edfbb0e849d3ef60148743352b84fe84 , this change merely just removes the warning which would otherwise appear until lavc major version gets bumped to 60.
* 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-2111-31/+54
| | | | | | | | | 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.
* hwdec: warn on unsupported hwdec option valueAvi Halachmi (:avih)2022-03-071-5/+10
| | | | | | | | | | | | | | | | | | | | | | | Previously, when mpv was i