summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* wayland: don't set mouse pos on state changeDudemanguy2020-08-022-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sway 1.5 started sending more pointer motion events to mpv which broke the autohiding behavior. The cursor would appear again if you fullscreened. Sway had a good reason to do this because certain applications had inconsistencies between hardware cursor and software cursor without rebasing on state changes[1]. So mpv needs to take this special case into consideration. Initially, simply checking mouse coordinates for changes was considered, but this doesn't work. All coordinates are surface-local in wayland so something can appear to move in the local coordinate space but not globally. You're not allowed to know global mouse coordinates in wayland, and we don't care about local coordinate changes in mpv so this approach isn't viable. Instead, let's just keep track of a local state change. If the toplevel surface changes in some way (fullscreen, maximized, etc.), then just set a bool that lets us ignore the mp_input_set_mouse_pos function. This keeps the cursor from appearing simply because the state was changed (i.e. fullscreening). For compositors that don't send pointer motion events on a state change, this does technically mean that the initial mp_input_set_mouse_pos is never set. In practice, this isn't a noticeable difference though because moving a mouse generates a ton of motion events so you'll immediately see it on the second motion event. [1] https://github.com/swaywm/sway/issues/5594
* wayland: avoid potential deadlocksDudemanguy2020-07-311-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wl_display_dispatch is dangerous because it will block forever if the event queue is empty. Any direct calls to this function should just be replaced with wl_display_dispatch_pending which accomplishes the same thing for mpv's purposes without any chance of blocking. The other potential trap is wl_display_roundtrip. It can internally call wl_display_dispatch which in certain circumstances could potentially block. There are cases where we need the server to finish processing client requests before doing anything else so this can not be cleanly avoided. The dangerous call is the usage of wl_display_roundtrip in vo_wayland_wait_frame. In the majority of cases, this shouldn't be a problem because the previous wl_display_read_events should always queue up some events on the fd for wl_display_roundtrip to send. However, the compositor could potentially send us an error in the display queue that could lead to bad behavior when wl_display_roundtrip is called. The wl_display_roundtrip can't be removed because we are relying on its semi-blocking capabilities, but the logic can be slightly adjusted to be safer. The obvious thing to do is to make sure we check the pollfd for any errors. If one is returned, then we call wl_display_cancel_read and try again. The less obvious trick is to call wl_display_dispatch_pending and move wl_display_roundtrip outside of the blocking + timeout loop. This change has some subtle but important differences. Previously, vo_wayland_wait_frame would read an event and wait on the server to process it one-by-one. With this change, the events are dispatched as soon as possible to the server and then we wait on all of those (potentially multiple) events to be processed after we have either received frame callback or the loop times out. After that is done, we can then check for if there are any errors on the display. If it's all clear, we can run wl_display_roundtrip without any worries. If some error happens, then don't execute the function at all.
* wayland: correctly signal the end of drag-and-dropDudemanguy2020-07-291-1/+1
| | | | | | | | | | | | Previously, the compositor was signaled that a drag-and-drop ended with wl_data_offer_finish in check_dnd_fd. This is, however, erroneous because it is outside of the data_device_listener and in some cases caused errors with certain compositors. check_dnd_fd itself does not need to know or care about anything that happens in wayland. It just needs to read data from an fd. The simple fix is to just always signal the end of a drag-and-drop in data_device_handle_drop. check_dnd_fd can free memory and close the fd later, but it should not talk to the compositor. Fixes #7954.
* wayland: fix a potential race in wait_eventsDudemanguy2020-07-291-4/+7
| | | | | | | The read of the wayland display fd in vo_wayland_wait_events was incorrect and technically vulnerable to race conditions. The correct usage as per the client api is to use wl_display_prepare_read as well as wl_display_read_events.
* wayland: remove unused declarationDudemanguy2020-07-191-1/+0
| | | | Should have been removed in 055a490 but was forgetten.
* vo_gpu: clip highlights before tone-mappingNiklas Haas2020-07-191-4/+5
| | | | | | | | | | | | Rather than after tone-mapping. This prevents overflow when the pre-tonemapped signal contains inputs exceeding sig_peak. I also realized that with this clipping in place, post-clipping no longer needs to be done, so this isn't even particularly slower. The only two exceptions to the rule are "clip" and "linear", which relied on the post-clipping to do their tone mapping properly. Fixes #7929
* vo_gpu: vulkan: print libplacebo API verNiklas Haas2020-07-161-0/+1
| | | | | | | | This normally gets printed by libplacebo itself when initializing the context, but due to the way our code is structured (for convenience) we don't have the log hook enabled by the time this function call is relevant. So instead just print it manually as an easier work-around than restructuring the code.
* zimg: add slice threading and use it by defaultwm42020-07-152-20/+111
| | | | | | | | | | | | | | | | | | | | | | | This probably makes it much faster (I wouldn't know, I didn't run any benchmarks ). Seems to work as well (although I'm not sure, it's not like I'd perform rigorous tests). The scale_zimg test seems to mysteriously treat color in fully transparent alpha differently, which makes no sense, and isn't visible (but makes the test fail). I can't be bothered with investigating this more. What do you do with failing tests? Correct, you disable them. Or rather, you disable whatever appears to cause them to fail, which is the threading in this case. This change follows mostly the tile_example.cpp. The slice size uses a minimum of 64, which was suggested by the zimg author. Some of this commit is a bit inelegant and weird, such as recomputing the scale factor for every slice, or the way slice_h is managed. Too lazy to make this more elegant. zimg git had a regressio around active_region (which is needed by the slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the bug was never released, so just add a warning to the manpage.
* zimg: refactor (move around fields)wm42020-07-152-78/+106
| | | | | | | | The intention is to add slice-threading to the wrapper. For that purpose, move all zimg related state to a new struct mp_zimg_state. There is now an array of instances of this struct. The intention is to have one instance for each thread. As of this commit, this is hardcoded to 1 thread; the following commit extends this.
* vo_gpu: hwdec_vaapi: handle lack of object size with AMD driversPhilip Langdale2020-07-141-0/+26
| | | | | | | | | | | | | It turns out that the AMD driver doesn't bother to set the size field in the descriptor for an exported VA surface. I guess they assume the caller can always use lseek() and don't bother. So, we need to use lseek() in these situations. Modified-by: Niklas Haas <git@haasn.xyz> Guarded this behind PL_API_VER >= 88 to prevent it from exploding on older libplacebo versions, where vaapi support does not yet work properly on AMD due to lack of DRM modifiers.
* vo_gpu: hwdec_vaapi: add support for DRM format modifiersNiklas Haas2020-07-141-2/+5
| | | | | This is required to get non-corrupted textures when importing vaapi planes on AMD drivers.
* cocoa-cb: fix unfs window size when toggling out of fullscreender richter2020-07-121-1/+3
| | | | | | | | | | we properly set the unfs window size on live resize end. due to a race condition in the fullscreen events, which is also a live resize, the unfs window size is incorrectly set to a fullscreen size. this happens when the end fs screen event triggers before the end of live resize one. this just adds a second condition to not be un fullscreen when updating the unfs window size.
* x11: add option to make window appear on a specific workspacewm42020-07-121-2/+3
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* sws_utils: do not mutate src/dst parameterswm42020-07-081-24/+20
| | | | | | Probably did not cause any practical problems, but it sure seems unclean. sws_utils users might also rely on these fields being exactly the same as the actual input/output. It's better to avoid this.
* x11: remove terrible xdg-screensaver hackwm42020-07-082-47/+1
| | | | | | | | | | | | | | I'm tired of dealing with this frequent spawning of xdg-screensaver when debugging and what not. xdg-screensaver was never a serious tool anyway, it's more like some self-deprecating joke by FDO folks. This will affect X11 on GNOME and other DEs. I'm singling out GNOME though, because they are the ones actively sabotaging any sane technical solutions and community cooperation. I have been accused of taking it out on innocent GNOME users, while none of this will reach GNOME developers. Of course that is not the intention.
* client API: add software rendering APIwm42020-07-084-1/+212
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* Warn if on GNOMEwm42020-07-071-0/+7
| | | | GNOME actively fights the standard we try to rely on.
* vo_gpu: vulkan: add ability to disable eventsNiklas Haas2020-06-301-0/+5
| | | | | | | | | | | libplacebo exposes this feature already, because this particular type of bug is unusually common in practice. Simply make use of it, by exposing it as an option. Could probably also bump the libplacebo minimum version to get rid of the #if, but that would break debian oldoldstable or something. Fixes #7867.
* vo_gpu: fix typo in struct namesfan52020-06-241-1/+1
|
* vo_gpu: use highp float if available for GLESStephen Salerno2020-06-211-0/+5
| | | | | | Using mediump float on GLES causes problems with kernel resampling, PQ HDR, and possibly others. The issues are fixed by using highp, which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-193-0/+14
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: fix scaler/window validation to allow unsettingNiklas Haas2020-06-181-0/+4
| | | | | | | | | | --dscale= and --*scale-window= (i.e. an empty string) are respectively valid settings for their options (and, in fact, the defaults). This fixes the bug that it was impossible to reset e.g. tscale-window back to the default "unset" setting after setting it once. Credit goes to @CounterPillow for locating the cause of this bug.
* vo_x11: partially restore operation on bad endian systemswm42020-06-171-6/+22
| | | | | | | | | | | | | For testing in VMs I guess? This features a very broken hack that probably works. Though I didn't test the packed format case. Again, the mismatch is essentially due to big endian byte addresses decreasing as bit addresses increase, so you can't represent a bit position in a byte stream with a single address, which the mpv metadata does. OSD is broken because repack.c doesn't support big endian. You'll have to live with it.
* video: some concessions to big endian hostswm42020-06-171-8/+11
| | | | | | | | | | | | | | | | | | | | | | The recent changes to the image format metadata broke big endian, and that was intentional. Some things are inherent to little endian (like the idea to coalesce bit and byte offsets into a single bit offset), and they don't be fixed. But some obvious things can be fixed, such as marking LE vs. BE formats the right way around on BE hosts. The metadata is formally still in LE, except that if the LE/BE flag matches the host endian, the host endian can be used when accessing packed formats with bit shifts, or when computing byte aligned component byte offsets. The former may work because formats with LE/BE variants use the same bit offsets after byte swapping, the latter may work because little endian is the natural concept for addressing memory. But it will "subtly" fail to do the right thing in some cases, and code using this can't know, so have fun. Many things are broken, but this makes e.g. vo_gpu mostly work. My general opinion about BE computers is that you should get a better computer, you can get one for free from any garbage dump.
* video: alias IMGFMT_RGB30 to AV_PIX_FMT_X2RGB10wm42020-06-171-0/+4
| | | | | | | IMGFMT_RGB30 was added first; FFmpeg added AV_PIX_FMT_X2RGB10 later. This is exactly the same, so treat them as such. For some reason, libswscale still seems to output incompatible data - not sure what this is about, but I'm not going to debug it.
* repack: handle endian in a more general waywm42020-06-171-6/+7
| | | | | | | | Instead of applying this only to "regular" formats, do it with all formats. For some reason, some repackers still have their own endian code. These could probably be removed, but whatever.
* img_format: fight ffmpeg pixdesc some morewm42020-06-171-28/+49
| | | | | | | | | | | | | | | | | | | | | This change attempts to fix detection of how endian swapping is to be performed. Details can be found in the code comments. It should not change anything, other than fixing handling of the X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and the component location metadata was discarded due to an internal consistency check. With this commit, it is handled correctly. At first I thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears to be correct. The problem with this format is that it's the first packed RGB format that requires bit shift to access, and where the endian word size is larger than the (rounded up) component size, all while pixdesc would "require" you to perform 3 memory accesses (instead of 1), and the code tries to reverse this. It appears that trying to use the pixdesc metadata is much, much more work than just duplicating it in a saner form. To be fair, most problems are with big endian, and the mpv internal format does not care much about endian _hosts_.
* vo_gpu: placebo: add fallback code for stride mismatchNiklas Haas2020-06-161-12/+52
| | | | | | | | | | | | | | | For cases in which the requirements of the GPU API prevent directly uploading a texture with a given stride, we need to fix the stride manually in host memory. This incurs an extra memcpy, but there's not much we can do about it. (Even in `ra_gl` land, the driver will just hide this memcpy from the user) Note: This code could be done better. It could only copy as many texels as needed, and it could pick a stride that's a multiple of `gpu->limits.align_tex_xfer_stride` for better performance. Patches welcome (tm) Fixes #7759
* vo_gpu: add BT.2390 tone-mappingNiklas Haas2020-06-153-7/+58
| | | | | | | | | | | | Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-153-6/+10
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* vo_gpu: move coherent specifier to the correct locationNiklas Haas2020-06-102-2/+2
| | | | | | | | | | glslang accepted this, perhaps erronneously, but mesa does not. It seems to be incorrect. A caveat is that this means *all* SSBOs are now coherent, but since we only use SSBOs for peak detection, that's a non-issue. (And besides, marking something as coherent when we don't perform any synchronization commands on it should be a no-op anyway) Fixes #7823
* cocoa-cb: properly reset window isMoving state on title bar clicksder richter2020-06-061-0/+2
| | | | | | | | | since the title bar catches the mouse up and down events, the underlying events view doesn't reset the isMoving state and no mouse movements are signalled to the core. now we also reset the state in mouse up events on the title bar. Fixes #7807
* vo_gpu: fix display corruption with window screenshotswm42020-06-061-0/+1
| | | | | | | | | The "screenshot window" command (ctrl+s by default) somehow broke video colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused. I don't know the cause, but the rest of the code seems to imply gl_video_reset_surfaces() needs to be called manually to flush some caches, and it fixes the issue, so I assume there's no great mystery here.
* vo_gpu: mark peak detection buffer coherentNiklas Haas2020-06-061-1/+1
| | | | This is required for buffer memory barriers to actually work
* vo_gpu: make storage images/buffers as restrictNiklas Haas2020-06-061-2/+2
| | | | | This informs the GPU that we don't alias it with any other descriptors (which we don't).
* vulkan/wayland: fix another build breakageDaniel Bermond2020-06-051-1/+1
| | | | | | | | | | | | | | | Commit 07b0c18 introduced some build breakages. Some breakages were fixed on c1fc535 and a1adafe. This one is still remaining. This commit fixes the following build error: [153/521] Compiling video/out/vulkan/context_wayland.c ../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory 26 | #include "video/out/wayland/presentation-time.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Relevant to: #7802
* wayland: fix buildwm42020-06-042-3/+3
| | | | | | Broken by previous commit. I've split a commit incorrectly. Fixes: #7802
* build: change filenames of generated fileswm42020-06-043-9/+9
| | | | Force them into a more consistent naming schema.
* options: add --video-scale-x/ywm42020-06-031-4/+4
| | | | | | Requested. Fixes: #6303
* vaapi: correct broken NULL checkwm42020-06-031-1/+1
| | | | | | | Clearly, we want to check whether vaGetDisplayDRM() returned NULL. out_display itself is already implied non-NULL. Fixes: #7739
* vo: refine wakeup condition, and wake up more in audio sync modewm42020-06-011-3/+3
| | | | | | | | | | | Commit 6a13954d67143fb lowered the frequency of wakeups with this condition. But it seems it sometimes the audio sync mode really should get the wakeup before the frame is rendered. Normally, vo_thread is supposed to perform this wakeup. Now the wakeup frequency is twice of what should be needed - whatever, maybe it can be fixed properly once or if timing is moved to the VO entirely in the future. Fixes: #7777 (probably, untested)
* x11_common: added ICCCM WM_HINTSArthur Williams2020-05-241-0/+11
| | | | | | | | | | | | | | | | | | When the window is mapped, some ICCCM WM_HINTS are set. The input field is set to true and state is set to NormalState. To quote the spec, "The input field is used to communicate to the window manager the input focus model used by the client" and "[c]lients with the Passive and Locally Active models should set the input flag to True". mpv falls under the Passive Input model, since it expects keyboard input, but only listens for key events on its single, top-level window instead of subordinate windows (Locally Active) or the root window (Globally Active). From the end users prospective, all EWMH/ICCCM compliant WMs (especially the minimalistic ones) will allow the user to focus mpv, which will allow mpv to receive key events. If the input field is not set, WMs are allowed to assume that mpv doesn't require focus.
* vo_x11: allow OSD rendering outside of video regionwm42020-05-221-65/+52
| | | | | | | | | | | | | | | | | | | | | | | | I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
* mp_image: add helper for clearing regions outside of a rectanglewm42020-05-222-0/+16
| | | | Not sure if generally useful; the following commit uses it.
* video: add AV_PIX_FMT_UYYVYY411 conversion supportwm42020-05-221-30/+52
| | | | | | | | | | It may be completely useless, and I can't verify it as no known samples or other known/accessible software using it, but why not? Putting this together with he 422 code requires making it slightly more generic. I'm still staying with a "huge" if tree instead of a table to select the scanline worker callback, because it's actually small and not huge (although it not being generic still feels slightly painful).
* repack: use new imgfmt metadata in more caseswm42020-05-211-74/+59
| | | | | | Now everything is super generic and super undebuggable. Some awkwardness because the new metadata is basically a transposed version of the mp_regular_imgfmt metadata, which was used for component info before.
* img_format: expose another helperwm42020-05-212-2/+6
|
* mp_image: reimplement mp_image_clear()wm42020-05-211-25/+104
| | | | | | | | | | | | The old code ignored many corner cases, and even wrote "blacker than black" to YUV images. Use the new pixel format metadata and other recently added gimmicky crap, which should make this more correct. Even the almighty fuc