summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* sws_utils: use zimg by default if availablewm42020-02-121-0/+1
| | | | | This seems stable enough to use. Change the default, and remove it from the sw-fast profile.
* zimg: correct output to odd (chroma un-aligned) sizeswm42020-02-121-10/+18
| | | | | | | | | | As suggested by the zimg author: active_region is not supported on outputs (and the API returns an error), so instead scale to the "full" surface, but adjust the source rectangle such that the cropped output image happens to cover the correct region. Does this even work? Since Balmer Peak doesn't work, I can't really say, but it seems to look correct.
* zimg: fix typos in a commentwm42020-02-121-3/+2
| | | | | | Also remove the "o" case, which was never implemented (probably was an idea to output alpha formats, now obsoleted by zimg's full alpha support).
* vo_drm, wo_wlshm: mention that it's software scalingwm42020-02-112-2/+2
| | | | (But does anyone even read --vo=help output?)
* vo_x11: don't call X11 "crap"wm42020-02-111-1/+1
| | | | | | X11 is in fact beautiful and superior to Wayland. Instead, just state what the problem is in most cases: software scaling. (We have accelerated X11 rendering in vo_gpu and others.)
* zimg: add pal8 unpackerwm42020-02-101-0/+39
| | | | Some pngs are paletted, so this is vaguely interesting.
* img_format: add alias for ffmpeg pal8 formatwm42020-02-102-0/+4
| | | | For the next commit.
* zimg: rename zplanes fieldwm42020-02-101-4/+4
| | | | | | | | | This was a confusing name, because 1. there's also a z_planes[] field, and 2. it was not specific to zimg indexes. Possibly there used to be an idea involved about supporting alpha to non-alpha formats by discarding the alpha plane, but zimg does this now (and zimg will correctly blend the alpha component too).
* zimg: support gray/alpha conversionwm42020-02-101-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | The special thing about this format is 1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3 are not present, which causes some messy details. 2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are not present, while FFmpeg/mpv put the alpha plane as plane 1. In theory, 2. could be avoided, since FFmpeg actually doesn't have a any 2 plane formats (alpha is either packed, or plane 3). But having to skip "empty" planes would break expectations. zplanes is not equivalent to the mpv plane count (actually it was always used this way), while zimg does not really have a plane count, but does, in this case, only use plane 0 and 3, while 2 and 3 are unused and unset. z_planes[] (not zplanes) is now always valid for all 4 array entries (because it uses zimg indexes), but a -1 entry means it's an unused plane. I wonder if these conventions taken by mpv/zimg are not just causing extra work. Maybe component IDs should just be indexes by the "natural" order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a field that specifies the component ID for it, or just strictly assume that 2/4 component formats always use the last component for alpha.
* zimg: fix some confusion about plane permutationwm42020-02-101-4/+9
| | | | | | | | | | | | | We reorder the planes between mpv and zimg conventions. It turns out the code still confused when which convention was used. So the way it actually works is that the _only_ place where zimg order is used is the zimg_image_buffer.plane[] array. plane_aligned[] and zmask[] were accessed incorrectly, although I guess it rarely had a reason to fail (plane reordering is mostly for RGB, which has planes of all the same size). Adjust some comments accordingly too.
* img_format: add gray/alpha planar formatswm42020-02-102-2/+74
| | | | | | | | | | | | The zimg wrapper "needs" these formats as intermediary when repacking the normal gray/alpha packed format. The packed format is used by the png decoder and encoder, and is thus interesting. Unfortunately, mpv-only formats are a mess right now, because all the existing code is focused around using the FFmpeg metadata for pixel formats. This should be improved, but not now, so make the mess worse. This commit doesn't add support for it to the zimg wrapper yet.
* zimg: add alpha supportwm42020-02-091-18/+63
| | | | | | | | | | | libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
* vo: fix typo in commentwm42020-02-091-1/+1
|
* vf_format: add w, h parameterswm42020-02-091-3/+11
| | | | Yes, this thing became vf_scale through the back door.
* cocoa-cb: fix auto-selection of title bar style with older SDKsder richter2020-02-081-0/+4
| | | | | returning a nil value only works when build with a +10.14 SDK otherwise we need to fallback to the old mechanism.
* cocoa-cb: simplify cursor hiding and make it less greedyder richter2020-02-083-12/+7
| | | | | | | | | | | | | | | | | | for reasons unknown to me the NSCursor (un)hide functions can be completely unreliable and the cursor can have an unknown state. this only happens on some system and wasn't able to reproduce this. it's probably some dumb race condition that might be possible to work around, though because of the lack of reproducibility on my end it's hard to test. i decided to rework the cursor hiding code yet again and make it a lot less greedy. the cursor will now always unhide when moved and there will never be a situation again the cursor can't be unhidden again. on the other hand there might be edge cases now where the cursor won't hide immediately and you have to move it slightly to make it disappear again. this should be an acceptable tradeoff. Fixes #6886
* wayland: adjust vo_wayland_wait_frame logicDudemanguy2020-02-071-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Wayland uses vo_wayland_wait_frame plus some polling with a timeout for blocking on vsync. Here are a couple of changes that seem to be improvements. First, the poll time is always rounded up instead of truncated. When rendering frames longer than the standard 16.666 ms timeout, it seems that truncating the poll time slightly early may cause some vsync jitter spikes. Waiting longer, even if it's too long, appears to behave better. The second change is to use wl_display_roundtrip instead of wl_display_dispatch_pending. wl_display_dispatch_pending dispatches all events immediately. This is good to avoid blocking, but it's not guaranteed to wait long enough for all events to be processed on the display fd. The preceding wl_display_read_events routine ensures that all events on the display fd are queued. We just need a semi-blocking routine to dispatch them for the most reliable vsync. wl_display_roundtrip will dispatch any events for us, but also wait for a reply from the display server. This makes it ideal for this role. If the compositor doesn't reply to the client something else is probably horribly broken and wrong anyway. It's also not a permanently blocking call like wl_display_dispatch. If there's no frame callback (i.e. the window is hidden), then it does not dispatch any events and returns immediately.
* wayland: toplevel config fixesDudemanguy2020-02-062-3/+18
| | | | | | | | | | | | | | | | | | | | | | | There were a couple of erroneous things in the handle_toplevel_config function. Firstly, looping through the different states was not handled correctly. Launching a window as maximized (can happen in sway for example) was always stuck on true and would never be set to false. Fix this by always checking if XDG_TOPLEVEL_STATE_MAXIMIZED is found or not. Also do a similar thing for the fullscreen state. Additionally, there were some issues with resizing windows and window-scale going back to old sizes. The root of this problem is that the width and height arguments of handle_toplevel_config aren't actually guarenteed to be the actual width and height of the surface. There are times when mpv will set the surface size on its own (like with window-scale) which will be unknown to the toplevel listener. To complicate matters, there are times when we do want to use the width and height arguments (like when resizing with the mouse). Fix this by checking if the width and height arguments reported by handle_toplevel_config changed from the previous call of the function. If the value is different, then we go ahead and use them when setting mpv's geometry. If not, then we just ignore it.
* drm_atomic: do not set immutable propertiesAnton Kindestam2020-02-021-1/+6
| | | | | | | | | | | | | | | On some platforms the ZPOS property might exist, but be immutable. This is at least the case on Intel Sandy Bridge since Linux kernel 5.5.0. Trying to set an immutable property will cause. drmModeAtomicCommit to fail with -EINVAL. On other platforms we might want to set ZPOS to tweak the layering of planes. To reconcile these two, simply have drm_object_set_property check if a property is immutable before attempting to add it to the atomic commit, instead returning an error code (which is, as previously, ignored in the case of ZPOS as we don't strictly need it)
* wayland: remove wayland-frame-wait-offset optiondudemanguy2020-01-314-8/+5
| | | | | | | | | | | | | | | | | This originally existed as a hack for weston. In certain scenarios, a frame taking too long to render would cause vo_wayland_wait_frame to timeout which would result in a ton of dropped frames. The naive solution was to just to add a slight delay to the time value. If a frame took too long, it would likely to fall under the timeout value and all was well. This was exposed to the user since the default delay (1000) was completely arbitrary. However with presentation time, this doesn't appear to be neccesary. Fresh frames that take longer than the display's refresh rate (16.666 ms in most cases) behave well in Weston. In the other two main compositors without presentation time (GNOME and Plasma), they also do not experience any ill effects. It's better not to overcomplicate things, so this "feature" can be removed now.
* w32_common: support minimized and maximized propertiesJames Ross-Gowan2020-01-261-5/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for setting window-minimized and window-maximized in Windows. The minimized and maximized state can be set independently. When the window is minimized, the value of window-maximized will determine whether the window is restored to the maximized state or not. Changing state is done with ShowWindow(), which has commands that change the window state and activate it (eg. SW_RESTORE) and commands that change the window state without activating it (eg. SW_SHOWNOACTIVATE.) It would be nice if we could use commands that don't activate the window, so scripts could change the window state in the backrgound without bringing it to the foreground, but there are some problems with that. There is no command to maximize a window without activating it, so SW_MAXIMIZE is used instead. Also, restoring a window from minimize without activating it seems buggy. On my Windows 10 1909 PC, it always moves the window to the back of the z-order. SW_RESTORE is used instead of SW_SHOWNOACTIVATE because of this. This also changes the way the window is initially shown. Previously, the window was made visible as a consequence of the SWP_SHOWWINDOW flag in the first call to SetWindowPos. In order to set the initial minimized or maximized state of the window, the window is shown with the ShowWindow function instead, where the ShowWindow command is determined by whether the window should be initially maximized or minimized. Even when showing the window normally, we should still call ShowWindow with the SW_SHOW command instead of using SetWindowPos, since the first call a process makes to ShowWindow(SW_SHOW) has special behaviour where it uses the show command in the process' STARTUPINFO instead of the command passed to the function, which should fix #5724. Note: While changes to window-minimized while in fullscreen mode should work as expected, changing window-maximized while in fullscreen does not work and won't result in the window changing state, even after leaving fullscreen. For this to work correctly, the fullscreen logic needs to be changed to apply the new maximized state on leaving fullscreen. Fixes: #5724 Fixes: #7351
* cocoa-cb: add pinch to resize window gestureder richter2020-01-262-0/+11
| | | | | | | the event returns a delta ratio so we can just add it to the current window-scale. Adds support for #3214
* cocoa-cb: never set a window size smaller than the set minSizeder richter2020-01-261-0/+5
| | | | this prevents a vanishing window if the size is set too small.
* cocoa-cb: fix race condition on quitder richter2020-01-261-0/+1
| | | | | | it was possible for mouse events to be triggered when the core was already being shut down. to prevent this properly close and remove the window and additional remove the reference to MPVHelper object.
* cocoa-cb: add support for forcing the dedicated GPU for renderingder richter2020-01-262-5/+14
| | | | | | | | this deprecates the old cocoa backend only option and moves it to the general macos ones. add support for the new option in the cocoa-cb layer creation and use the new option in the olde cocoa backend. Fixes #7272
* cocoa-cb: don't set App icon when called from bundleder richter2020-01-261-1/+3
| | | | | | | | | due to the bundle config the icon is set automatically via the bundle system mechanisms. this also makes it possible to set the icon to a custom one with the standard macOS copy paste method via the file info dialogue. Fixes #6874
* vo_gpu: hwdec_vaapi: set correct hw_imgfmt valuewm42020-01-171-0/+1
| | | | | | | As documented on struct mp_hwdec_ctx, hw_imgfmt specifies the hardware surface wrapper format for which supported_formats is valid. If this was not set, f_hwtransfer ignored supported_formats, and assumed all formats were supported.
* wayland: support maximize/minimize on startupDudemanguy2020-01-121-0/+6
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started on wayland. If the compositor doesn't support maximization or minimization, then these options just do nothing.
* wayland: unscrew up cursorsdudemanguy2020-01-121-6/+4
| | | | | | | | | | | | | | Fixes #7345 There was a multitude of issues with cursor handling in wayland and behavior seemed to vary for strange reasons across compositors and also bad things were being done in wayland_common. The problem is complicated and involved fullscreen states being set incorrectly under certain instances and so on. The best solution is to just remove most of the extra cruft. In handle_toplevel_config, instead of automatically assuming is_fullscreen and is_maximized are false, we should use whatever value is currently set vo_opts which matters when we initially launch the window.
* vaapi: reduce log levels furtherwm42020-01-112-8/+11
| | | | | Try to exclude mostly uninteresting information from verbose logging, but still include it in debug logging.
* vo_gpu: hwdec_vaapi: silence warning during probingwm42020-01-111-1/+4
| | | | | | | | | | | | | | hwdec_vaapi tries to probe all available surface formats in advance. For that, we iterate over _all_ profiles in an attempt to collect possible surface formats. This means we try profiles we normally wouldn't use for decoding or filtering, and which could be "unrelated" services. It seems some drivers report at least one profile, for which vaQueryConfigEntrypoints() fails (because the profile is not supported; not sure why it lists it, then). So turn the error message into a verbose message to avoid confusing output. Fixes: #7347
* wayland: don't set cursor before pointer idDudemanguy2020-01-111-1/+1
| | | | | | | | | | | This shouldn't really matter, but it's probably best to avoid. vo_wayland_control would execute set_cursor_visibility while wl->pointer existed but it didn't check if wl->pointer_id existed. So wl_pointer_set_cursor would be set to a null surface with an id of 0. Instead, just wait until we have an actual, non-zero pointer id so that the cursor is set with the correct, actual id and not a fictious 0 id. This ensures that the pointer isn't set until it enters the wl_surface which is what we want.
* cocoa-cb: don't active window when minimized or hidden on file changeder richter2020-01-091-1/+6
| | | | Fixes #7195
* cocoa-cb: add runtime dpi change and use proper fallback for initial dpider richter2020-01-092-4/+7
| | | | | | | | at the time of the initial dpi query the window is not instantiated yet. we use a proper fallback in that case, eg the target configured screen or the main screen if none is set. also change some weird oversight and a small optimisation.
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-091-3/+3
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* vo_gpu: fix crash if dither texture fails to allocatewm42020-01-081-0/+3
| | | | | | | Theoretically possible (and quite unlikely due to the small texture size). The code was originally written with the assumption that texture allocations can't fail, and it was never updated out of laziness. Untested.
* wayland: don't exit the option loopDudemanguy2020-01-041-16/+12
| | | | | More than one option may change at the same time so don't break out of this loop.
* wayland: disable by default for gnomeDudemanguy2020-01-011-0/+4
| | | | | | | | | It turns out that gnome wayland still has very serious issues that make it unusable for playback with mpv. Other compositors mostly behave fine (Plasma is just missing feature but it's not seriously broken), so GNOME gets the special honor of having a warning printed out. The only solution for GNOME users at this time of writing is to either use the Xorg session or use another wayland compositor.
* Revert "vo_gpu: move wayland below X11 in autoprobe order"Dudemanguy2020-01-011-6/+6
| | | | This reverts commit a6d8e9b7ff0166ee6db69c41c0cfc319e03f4c80.
* vo_gpu: move wayland below X11 in autoprobe orderwm42019-12-301-6/+6
| | | | | | | I'm sick of mpv being accused of not doing it right. You can't do it right on Wayland? Long live X11. Fixes: #7307
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-294-1/+52
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* vo_gpu: hwdec_vaegl: remove support for old-style interopPhilip Langdale2019-12-284-130/+5
| | | | | | | | | | | | | In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they introduced a new surface export API that is more efficient, and we've been supporting that and the old API ever since (Feb 2018). If we drop support for the old API, we can do some fairly nice cleanup of the code. Note that the pkgconfig entries are explicitly versioned by the API version and not the library version. I confirmed the upstream pkgconfig files.
* vo_gpu: hwdec_vdpau: remove direct_modePhilip Langdale2019-12-283-170/+47
| | | | | | | | | | | | | | | | | | | | | | | | As we are less and less interested in vpdpau, with nvdec and vaapi being better choices in general on nvidia and AMD respectively, we might consider removing direct_mode, where we bypass the vdpau mixer and work directly with yuv textures. Normally, working with yuv textures would be great, but vdpau built in an assumption that all frames are delivered as separate fields, causing us to have to re-interleave them. nvidia then introduces a new OpenGL extension that can return the yuv frames as frames, but we can't just unconditionally switch to that as we'd want to keep supporting older hardware where the drivers are no longer getting new features. The end result is that we wouldn't be able to get rid of the old code paths. Removing direct_mode means we always use the mixer, and work with rgba frame textures. There are some theoretical limitations to this, but in practice they probably don't matter much - unsupported colourspaces don't matter because without 10bit decoding support, we can't use them anyway, and apparently we're not doing separate chroma scaling these days, so scaling the rbga doesn't really lose anything (and the vdpau hq scaling option remains available).
* w32_common: remove implicit fallthroughJames Ross-Gowan2019-12-291-2/+3
| | | | | | GCC 9.2 warns about this. It was always a bit sketchy, so get rid of it. VK_F10 generates WM_SYSKEYDOWN, so it only needs to be handled in the WM_SYSKEYDOWN case.
* cocoa-cb: force redraw when screen or size changesder richter2019-12-241-0/+2
| | | | | | | | | in certain circumstances the video was not redrawn even when the size or the backing scale factor changed. this could lead to a lower resolution output than intended. now it redraws the video when screen properties or the window size changes.
* cocoa-cb: implement hidpi scale reportingder richter2019-12-242-0/+7
|
* vd_lavc: remove hwdec-by-default special case for RPIwm42019-12-241-1/+1
|
* vd_lavc: more hwdec autoselect nonsensewm42019-12-241-17/+49
| | | | | | | | | | | | | Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force hwdec=vaapi in the global config file in their mpv package. But to be honest it's probably something more people want. This is implemented as explicit whitelist. On Windows, HEVC/Intel is sometimes broken, but it's still whitelisted, and in theory we'd need a detailed whitelist of device names etc. (like for example browsers tend to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately the only one, so it's whitelisted too. There may be a larger number of hwdec wrappers that work anyway, and I'm for example ignoring Android.
* vo_gpu: vulkan: set allow_suboptimal when possibleNiklas Haas2019-12-221-0/+5
| | | | | This was added in libplacebo v1.29.0 and allows making resizes slightly smoother for clients that already handle resize events (such as mpv).
* video/out/x11: add fs-screen fallbackNicolas F2019-12-221-0/+3
| | | | | | | | | | | | | Apparently there are two different options for controlling which screen an mpv window goes onto: --fs-screen and --screen. The former explicitly only controls which screen a fullscreened window goes onto, but does not appear to actually care about this option at runtime for X11, so pressing f will always fullscreen to the screen mpv is currently on. This means the option is of questionable usefulness for starters. Making it worse, if you use --screen=1 --fs, mpv will actually fullscreen on screen 0, because --fs-screen isn't set. Instead of doing that, fall back to whatever --screen is set to.
*