summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* build: internally rename gl-wayland to egl-waylandDudemanguy2023-07-231-1/+1
| | | | | | This has always been a pet peeve of mine and in fact I named the option in meson "egl-wayland" with the intention of finally doing this. We call everything that's egl "egl-foo" internally except for wayland.
* Revert "vo_gpu_next: use pl_dispatch_info_move to avoid useless data copy"sfan52023-07-231-46/+21
| | | | | | | | We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next for this release, since this is the what most Linux distributions are shipping. The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not likely to ship the newest libplacebo release soon. This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
* vo_dmabuf_wayland: correctly handle force-windowDudemanguy2023-07-231-1/+7
| | | | | | | | | Since this works by mpctx giving us a dummy image, we can be reasonably be confident that when we receive a matching imgfmt with no underlying hw_subfmt that this is simply force window from the player. Just allow this to go through the usual wayland logic and skip the hwdec checking. When we get the real image later, it will still error out on the compositors that don't have proper support.
* player/video: check for forced eofDudemanguy2023-07-221-0/+4
| | | | | | | | | | | It's a bit of an edge case, but since we now allow the disabling of the software fallback it's possible to have a situation where hwdec completely fails and the mpv window is still lingering from the previous item in the playlist. What needs to happen is simply that the vo_chain should uninit itself and handle force_window if needed. In order to do that, a new VDCTRL is added that checks vd_lavc if force_eof was set. player/video will then start the uninit process if needed after getting this.
* vd_lavc: respect vd-lavc-software-fallback optDudemanguy2023-07-221-2/+10
| | | | | | | | | | There's an option that's supposed to stop mpv from falling back to software decoding if hardware decoding fails. Except that it doesn't work and can fallback to software decoding anyway. Correct this by checking if all possible hwdec failed after the loop in select_and_set_hwdec and that we have this option. If so, flag a bool to force eof. In decode_frame afterwards, we then simply immediately return an EOF.
* vo_vaapi: restore hardware video decodingGusar3212023-07-221-0/+1
| | | Commit e50db42 changed how hwdec interop works. Adjust vo_vaapi accordingly by setting the appropriate image format.
* vo_vaapi: fix segfault in draw_osdGusar3212023-07-221-0/+4
| | | | | | When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video. Fixes issue #10436
* vo_drm: remove VOCTRL_SCREENSHOT_WINDudemanguy2023-07-211-5/+0
| | | | | With the generic screenshot window implemented, this is no longer needed since vo_drm already uses software scaling.
* image_writer: use proper specifier for int64_tNRK2023-07-201-1/+2
|
* zimg: fix broken sig_peak handlingsfan52023-07-191-2/+3
| | | | | | | | | | | | In sum there were three issues: 1. nominal_peak_luminance is an output parameter, not input 2. mpv internally uses MP_REF_WHITE which we need to scale by 3. the value should be left at its default for SDR Together with the last change this means mpv can sucessfully take HDR screenshots with --screenshot-sw without resulting in a brightly colored mess. Though note that zimg does not perform proper tonemapping.
* image_writer: move tag_csp check into image_writer_flexible_csp()sfan52023-07-191-0/+2
| | | | | | | This ensures the sRGB fallback to happen in all situations involving the image writer code, notably --screenshot-sw. fixes: cbbe2e52210d9885a0897e9c7833267a60456c56
* image_writer: replace sprintf usagesfan52023-07-191-4/+2
| | | | also fixes the buffer being cut off (?!)
* image_writer: share some code between write_lavc and write_avifsfan52023-07-191-45/+39
| | | | | | | As a consequence: - write_avif now respects tag-colorspace=no - write_lavc additionally sets colorspace and chroma_location (of no consequence for png or jpeg)
* image_writer: error check avif-pixfmt optionsfan52023-07-191-0/+5
|
* image_writer: fix still-picture option for AVIFsfan52023-07-191-1/+1
| | | | Gets rid of validation warnings on the produced files.
* image_writer: remove duplicate packet writing codesfan52023-07-191-29/+4
|
* wayland_common: remove questionable gcd impl and global statesfan52023-07-192-22/+9
|
* wayland: don't treat tiled and maximized windows the sameDudemanguy2023-07-192-3/+9
| | | | | | | | | | | | mpv has historically always treated the various tiled states in xdg-shell as maximized (probably because it was easier). Well it turns out that there are some tiling compositors (hyprland) that allow tiled windows to maximize themselves. This can lead to some scenarios where mpv ends up doing a maximize on hyprland which actually works since it's not a no-op like on sway. Fix this by separating out the tiled state from maximize. It works mostly the same, but the main difference is that there's no request to tile yourself like there is with maximize. Should fix #11954.
* wayland: add locked_size convenience shorthandDudemanguy2023-07-192-8/+10
| | | | | | | There's a lot of checks that are along the lines of !maximized && !minimized or vice versa. Make a locked_size boolean and store the value of this in here to avoid writing long lines since the next commit will add yet another condition to this.
* vo_gpu_next: add --hdr-contrast-recovery/smoothnessNiklas Haas2023-07-183-0/+12
| | | | New upstream feature. Disabled by default.
* vd_lavc: repeatedly attempt to fallback if hwdec fails in receive_framePhilip Langdale2023-07-171-2/+14
| | | | | | | | | | | | | | | | | There is an additional failure path I didn't account for in my previous work. While I ensured that a late hwdec failure in receive_frame can be recovered from by trying the next hwdec, there is a specific combination where if an hwdec fails in receive_frame, and the next hwdec is a full decoder (eg: v4l2m2m), and that also fails, we are left with no decoder and so the entire decoding process ends and playback is stopped. Basically, we must keep re-attempting the fallback in receive_frame until we get a valid decoder (software or hardware). This edge case will rarely be encountered as there are only a couple of decoder based hwdecs. Fixes #11947
* wayland: handle modifier keys correctlyDudemanguy2023-07-172-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't know why we've been doing this wrong for so long or how I didn't notice until now. Wayland specifically has an event for handling modifiers. We even named it "keyboard_handle_modifiers" in the code. What we should do is just get the modifier and save it after the xkb state is updated. Then later if the user does something else (press another key or clicks the mouse button), the saved modifier key is applied. If you let go of the modifier at any point, the xkb will just update its state again and we save a 0 again here (i.e. no modifier). There is one bit of an edge case however. If a key is pressed BEFORE the modifier, then we have to handle the mp_input_put_key in the modifier event instead since the ordering is not guarenteed. What we do here is keep track of the mpkey as well as the mpmod. However if we are unable to find a matching mpkey and the key state is pressed down, assume it's a modifery key that was pressed and don't update mpkey. That way whenever the modifier event does happen, it can correctly handle this and we know that the keys must be pressed down if we end up there in the code path. As another fun historical note, the xkb_keysym_to_utf8 line was actually written by wm4 himself in 460ef9c7a4bd2527f7f17eb8c95eeff3b67455f8 nearly 10 years ago. As the commit shows, it was clearly intended to handle modifiers (if lookupkey finds nothing, then try to find a mod instead). Of course, this is extremely dated and wayland hasn't worked like that in ages. This branch never actually did anything, and thus we'll remove it here along with modifier lookup changes. This solves bizarre issues with modifiers not working with random keys while working fine with others (don't ask me why). Fixes #10286 and fixes #11945.
* vo_gpu_next: add --target-contrast optionKacper Michajłow2023-07-173-0/+33
| | | | For better control over target display levels.
* wayland: wrap resize requests in prepare_resizeDudemanguy2023-07-161-9/+19
| | | | | | | | | | | | | | | | | | | 828dd65ef84b4d8e95e70752b9eb0833909d1d23 started this and put it in the most common place, but any resize mpv is doing should be accompanied by that function call to correctly inform the compositor of the window bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it makes sense to just put these in the same function. A slight thing to note is that xdg_surface_set_window_geometry uses surface local coordinates which means they are divided by the wl->scaling factor. If possible, we should use surface local coordinates directly if available (like in the toplevel config) to avoid potential rounding errors. Otherwise, just calculate it out. The linked commit actually broke some weston resizes in weird ways (window disappearing or completely freezing). Don't ask me why and I didn't attempt to find out why either, but with this it all appears to work normally again (the other compositors don't appear to be any different, and they shouldn't be), so we'll go with this since it fixes soemthing and it also is more conceptually correct.
* vd_lavc: map `hwdec=yes` to `hwdec=auto-safe`Philip Langdale2023-07-141-2/+2
| | | | | | To remain consistent with our belief that `auto-safe` should be the recommended mode when turning on hw decoding, let's remap `yes` from `auto` to `auto-safe`.
* vd_lavc: add `drm` and `drm-copy` to the `auto-safe` listPhilip Langdale2023-07-141-0/+2
| | | | | | | | | We have supported `hwdec=drm` for some time now, and on devices where this method is present, it is the preferred, and only, method available. Combine that with the fact that software decoding on embedded devices will not turn out well, and it's clear that we should put `drm` and `drm-copy` on the `auto-safe` list to maximise usability in simple configurations.
* vd_lavc: try other hwdecs when falling back after an hwdec failurePhilip Langdale2023-07-141-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Today, if hwdec initialisation succeeds, we move on to attempting decoding, and if decoding fails, we enter a fallback path that will only do software decoding. This is suboptimal because some hwdecs and codec combinations can pass hwdec init, but then fail at hwaccel init, or even frame decoding. In these situations, we will never attempt other hwdecs in the `auto` or manually specified lists which might work. One good example is someone tries to use `vulkan,auto` and tries to play av1 content. The vulkan decoding will fail at hwaccel init time, and then fallback to software instead of going through the auto list which would allow vaapi, nvdec, etc to play the file. Instead, let's not give up immediately, and try the next hwdec after a failure, just like we do if hwdec init fails. The key part of this change is to keep track of the hwdecs we have tried, so that each time we run through hwdec selection, we don't try the same one over and over again. If we really get through the whole list with no success, we will then fall back to software decoding. Fixes #11865
* vo_dmabuf_wayland: error out if compositor doesn't support the formatDudemanguy2023-07-141-2/+71
| | | | | | | | | | | | This was never implemented so in cases where the compositor didn't have support for the underlying format, the window would just be black and quite unhelpful. Well it turns out that fixing this is actually really easy because mpv has reconfig2 which returns the entire mp_image on every reconfig. We can just use that mp_image to try and obtain the format and modifier pair and then use that to check against what we know the compositor supports. If there are any problems, error out gracefully. Some code duplication with the vaapi/drmprime importers, but it's probably better to keep these separate. Fixes #11198 and fixes #11664
* build: make dmabuf-wayland a build option and require drmDudemanguy2023-07-141-7/+1
| | | | | | | It makes more sense as an option at this point. Also libdrm is not optional at all. You have to get a drm format and modifier for this to even work (the VO will just fail without DRM). Just hard require it and remove the guards. vaapi can remain optional.
* wayland: use xdg_surface_set_window_geometryDudemanguy2023-07-131-0/+1
| | | | | | | | | mpv has never used this because we never really seemed to need it, but it actually has a purpose. This informs the compositor of the actual dimensions of the mpv window and avoids errors with sizes not matching (particularly with weston). It's a better way to fix the "maximizing causing an error on weston" issue since it also works for dmabuf-wayland (which always had this problem).
* Revert "wayland_gl: wait until resize to create egl_window"Dudemanguy2023-07-131-32/+37
| | | | | | | | | | | | | | The original reason for this commit was to prevent a compositor error on weston when going into the maximized state. The configured dimensions of mpv didn't match its actual size and Weston is super strict about this so it threw a compositor error which is fatal. It only happened in opengl and this seemed like an OK workaround, so I went with this. However, there's actually a far easier way to solve this problem and we don't need this anymore. This has the benefit of avoiding a harmless warning message that appears with gpu-next on opengl. The next commit is the proper solution. Closes #10324. This reverts commit 661b5542de21d46d4d7c4693e564f4eec0526812.
* vo_dmabuf_wayland: guard in destroy_osd_buffersDudemanguy2023-07-121-0/+3
| | | | *sigh*
* vo_dmabuf_wayland: stop lazy loading hwdecDudemanguy2023-07-121-17/+12
| | | | | | | | | The implementation was copied from vo_gpu/vo_gpu_next but fundamentally it doesn't make sense for this VO. Hardware decoding is not optional in vo_dmabuf_wayland. We should be sure to request and load all supported formats in the preinit and fail if there are any problems. There should be no functional change from before, but it's more conceptually correct this way.
* vo_dmabuf_wayland: don't try to get pts without frame->currentDudemanguy2023-07-121-1/+2
| | | | Fixes a segfault with --force-window=immediate.
* vo_dmabuf_wayland: add osd supportDudemanguy2023-07-123-10/+230
| | | | | | | | | | | | | | | | | | This adds osd support via shm buffers using a similar approach that the normal buffers do, but it differs in a few key areas. One thing to note is that sway and weston actually handle this extremely differently which required all the abstractions here. In particular, weston does not cope well with destroying the wl_buffer from shm outside of the release handler at all (i.e. it segfaults). The workaround here is to simply attach a NULL to the osd surface and do a surface commit before we destroy the buffers. This is reasonable enough and seems to work well although it's pretty weird. Sway is more straightforward although it actually releases the osd buffer when the window goes out of sight. Also, I found that it doesn't always release every buffer before you close it unlike weston seems to do which is part of the reason all this bookkeeping is required. I don't know if there's any other compositor out there that can possibly handle vo_dmabuf_wayland right now, but suffering through these two is good enough for now I think.
* vo_dmabuf_wayland: init wl_list at the top of preinitDudemanguy2023-07-121-2/+2
| | | | | | Otherwise, we could fail and skip to uninit without initalizing this which then will segfault because the list is null and accessed while trying to destroy buffers.
* vo_dmabuf_wayland: stop guarding viewport interfacesDudemanguy2023-07-121-4/+2
| | | | | | It's entirely pointless. Not having viewport is already a fatal error for this VO as it cannot possibly work without that protocol. Just drop all these redundant if's.
* video/image_writer: check for write errorsNRK2023-07-111-3/+2
| | | | | | make sure that fwrite is error checked. and if any data was still remaining on the buffer, it will be flushed - and errors checked - via the fclose() call below.
* video/image_writer: fix file leak in error pathNRK2023-07-111-0/+1
| | | | regression from de7f4fb1e
* wayland: add xdg_toplevel.wm_capabilities handlerllyyr2023-07-101-0/+10
| | | | Fixes crash when compositors advertise xdg_toplevel version >= 5
* wayland: add support for suspended toplevel stateDudemanguy2023-07-091-2/+14
| | | | | | | mpv already guesses when the window is hidden so plugging in a proper event that actually tells us this is really trivial. Note that there's some redundancy with setting wl->hidden in a few spots, but nothing can really be done about that as long as the crappy hack is still in place.
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-092-12/+63
| | | | | | This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
* vd_lavc: fix delay_queue for videos with frames < max_delay_queueKacper Michajłow2023-07-091-3/+3
| | | | | | | | | | In case there are no packets from demuxer we cannot send EAGAIN, because we will not proceed and get stuck with one frame in queue and never output it. Just respect avcodec_receive_frame ret code and act accordingly. The only case to care about is EOF when we have to drain already queued frames. Fixes playback of 1-2 frame videos.
* vd_lavc: prefer d3d11va-copy over dxva2-copyKacper Michajłow2023-07-091-1/+1
| | | | | | There is no reason to prefer dxva2. I believe it was mistake from initial commit that added the hwdec list that has been propagated through years.
* vo_wlshm: bail out of resize if width/height is 0Dudemanguy2023-07-081-0/+4
| | | | | | | It can happen during initialization and of course nothing good will happen if we let this go through (i.e. segfault). Return and wait for geometry to finish setting up in the wayland stuff before doing the initial resize.
* wayland: fix memory leak with multiple monitorsDudemanguy2023-07-081-7/+5
| | | | | | | | | Very dumb. I can't remember if it was always like this or if I broke it at some point, but clearly each wl_output should just be freed in remove_output. Freeing it if it happens to be wl->current_output only works for that one monitor, so remove that whole line. This has to happen before we close the wayland connection so reorder the uninit a little bit.
* various: correctly ignore cache files with --no-configDudemanguy2023-07-062-10/+18
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* vo_gpu/vo_gpu_next: enable gpu shader and icc cache by defaultDudemanguy2023-07-042-0/+2
| | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and saved cached files. In particular, it made a separate boolean option for actually enabling cache and left the *-dir options as purely just a path (i.e. having a dir set didn't mean you save cache). This technically regressed people's configs, so let's just turn the cache on by default. Linux users already expect random stuff in ~/.cache and well everyone else can just live with some files possibly appearing in their config directory.
* vo_gpu: fix some cache related memory leaksDudemanguy2023-07-042-2/+3
| | | | I goofed this up.
* player: add --input-cursor-passthrough optionDudemanguy2023-07-042-2/+44
| | | | | | | | | | | | | Add an option for allowing pointer events to pass through the mpv window. This could be useful in cases where a user wants to display transparent images/video with mpv and interact with applications beneath the window. This commit implements this functionality for x11 and wayland. Note that whether or not this actually works likely depends on your window manager and/or compositor. E.g. sway ignores pointer events but the entire window becomes draggable when you float it (nothing under the mpv window receives events). Weston behaves as expected however so that is a compositor bug. Excuse the couple of completely unrelated style fixes (both were originally done by me).
* vo_gpu_next: remove synchronization from info_callbackKacper Michajłow2023-07-021-9/+0
| | | | VOCTRL is processed on VO thread.
* vo_gpu_next: use pl_dispatch_info_move to avoid useless data copyKacper Michajłow2023-07-021-21/+45
| | | | | Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.
* vo_x11: don't rely on XFree to free calloc-ed dataNRK2023-07-021-1/+6
|
* vo_x11: check for calloc() failureNRK2023-07-021-3/+5
|
* win32: add support for drag-and-drop optionDudemanguy2023-07-013-3/+16
|
* options: add no to drag-and-dropDudemanguy2023-07-012-19/+23
| | | | | Suggested by @sfan5. Naturally, "no" disables all drag and drop behavior.
* video/image_writer: add avif screenshot supportcloud116652023-07-012-17/+296
| | | | | | | | | | Notes: - converts the (image) write() api to filenames, because using avio with FILE* is a pain. - adds more debug logs for screenshots. build: rename av1 dependency to avif_muxer wscript: unify lavf dependency with meson
* vd_lavc: do inline string array initialisation for hwdec_apiPhilip Langdale2023-06-291-3/+1
| | | | | I couldn't work out the correct syntax, but NRK0 pointed out an example of where we'd done it elsewhere in the codebase.
* vd_lavc: let the user provide a priority list of hwdecs to considerPhilip Langdale2023-06-291-76/+81
| | | | | | | | | | |<