summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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 invoked with unsupported hwdec value, such as --hwdec=foobar, there was no indication that it doesn't exist. The reason it's not validated during options parsing is that the name is only evaluated when selecting hwdec for actual decoding, by matching it against runtime list of names from ffmpeg. Additionally, when selecting hwdec for decoding, matching the name came after filtering by codec, hence overall never-matched-name did not necessarily indicate it's unsupported (doesn't exist at all). Now we check the name before filtering by codec, and when done, warn if no hwdec with that name exists at all. This means that an unsupported name will now generate such warning whenever we try to choose a hwdec, i.e. possibly more than once. It's much better than no notification at all, and arguably adequate for a sort of configuration error (linked ffmpeg has no such hwdec name) which we don't validate during option parsing.
* 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
| | |