summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* timer: rename mp_time_us_to_timespec to reflect what it actually doesKacper Michajłow2023-09-292-3/+3
|
* vo_dmabuf_wayland: assume counter-clockwise rotationsDudemanguy2023-09-291-1/+4
| | | | | | | | | | | | | | In practice, most compositors implement the rotation clockwise which matches mpv's option, but amusingly this is actually incorrect. According to the spec*, wayland buffer rotations are counter-clockwise. So with this assumption in mind, in order for the rotation to match mpv's usual semantics, the 90 degree and 270 degree positions need to be flipped. Of course, this will make the VO rotate the wrong way on most compositors, but this is what the spec says (sway master is known to currently be correct). Fixes #12508 (sort of but will break the rotation direction on other compositors. Oh well). *: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output-enum-transform
* hwdec_drmprime: add nv16 supporthbiyik2023-09-292-0/+3
| | | | | | | | | NV16 is the half subsampled version of NV12 format. Decoders which support High 4:2:2 of h264 provide the frame in NV16 format to establish richer colorspace. Similar profiles are also available in HEVC and other popular codecs. This commit allows NV16 frames to be displayed over drmprime layers. Signed-off-by: hbiyik <boogiepop@gmx.com>
* wayland: don't double close display fdJack Mitchell2023-09-271-5/+2
| | | | | | | | Calling wl_display_disconnect closes the file descriptor, no need to manually do it ourselves beforehand which causes a double close on the fd. Signed-off-by: Jack Mitchell <jack.mitchell@tuxable.co.uk>
* win32: add option to change backdrop styleDeadSix2023-09-271-0/+17
|
* win32: pass window handle to the window-id propertyDeadSix272023-09-251-0/+6
| | | uses the same mechanic as for x11
* vo_gpu: remove --scaler-lut-sizeNiklas Haas2023-09-254-14/+9
| | | | | | | Pointless bloat option, hard-coded as 256 now in libplacebo and no reason not to also hard-code in mpv. See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
* vo_gpu: remove --scale-cutoff etcNiklas Haas2023-09-255-13/+5
| | | | | | | Pointless bloat option, hard-coded as 1e-3 now in libplacebo and no reason not to also hard-code in mpv. See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
* wayland: remove gnome-specific idle-inhibit warningDudemanguy2023-09-241-4/+0
| | | | | | | Unbelievably, mutter actually supports the idle inhibit protocol now after many years of pain*. Let's remove this hacky warning. *: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3145
* cuda: move --cuda-device to cuda_opts groupDudemanguy2023-09-222-10/+10
| | | | Also change a ta_free to talloc_free for consistency reasons.
* opengl/context_win: move opengl-dwmflush to wingl_opts groupDudemanguy2023-09-221-8/+23
| | | | Gets rid of yet another mp_read_option_raw call.
* libmpv_gl: replace mp_read_option_raw callDudemanguy2023-09-221-5/+5
|
* video/out/gpu: replace mp_read_option_raw callDudemanguy2023-09-221-3/+3
|
* win32: don't remove WS_CAPTION from styleKacper Michajłow2023-09-211-23/+16
| | | | | | | | Apparently removing WS_CAPTION disables some window animations. Instead adjust non-client area to not draw title bar. Note that we do not account for difference in real border size and invisible one, but seems to work correctly.
* win32: enable custom WM_NCHITTEST also when title bar is hiddenKacper Michajłow2023-09-211-1/+1
|
* win32: set window_corners to default for fullscreenKacper Michajłow2023-09-211-6/+10
| | | | | | I don't think in fullscreen mode it makes sense to enable rounded corners. We can add another option if someone needs it, but for now `window_corners` affects only the window as one would expect.
* win32: add --window-cornersKacper Michajłow2023-09-211-0/+11
| | | | Allows to set preference for window corners rounding for DWM.
* win32: fix fit_window_on_screen to account for invisible bordersKacper Michajłow2023-09-211-0/+12
| | | | Fixes too small initial window size.
* win32: reduce top border thickness to imitate DWM invisible bordersKacper Michajłow2023-09-211-0/+30
| | | | DWM makes part of left, right and bottom border invisible.
* win32: add an option to control window title bar stateKacper Michajłow2023-09-211-1/+5
| | | | Fixes: #11432
* win32: add an option to change window affinityDeadSix2023-09-211-0/+14
|
* wayland: ensure at least a scale factor of 1 when drawing cursorDudemanguy2023-09-211-2/+3
| | | | | | | | | | | | | | | | | | | With the addition of fractional scaling support, wl->scaling was converted to a double. Some compositors (Plasma) can report values under 1 for fractional scaling, so this meant wl->scaling could be some small fractional value. This is fine except that when using the legacy code for drawing the mouse cursor (i.e. not the cursor-shape protocol), it still uses the old integer scaling method in core wayland. The reason for this is simply because fractionally scaling the mouse cursor surface is nonsense and nobody even has cursor images for anything besides a select few sizes anyways (32x32, 48x48, etc.). The existing integer scaling sort of works but it's pretty bad too and you can get some weird sizes anyway. This is why cursor-shape is preferred since it fixes this. Anyways, since buffer scaling for the cursor only takes integers, there could be truncation to 0 in the previously mentioned fractional scale this. This naturally causes the compositor to send us an error and mpv quits. The fix is to always make sure that the scale value used for the cursor is at least 1. Anything less makes no sense. Fixes #12309.
* win32: explicitly guard dark mode calls by Windows versionKacper Michajłow2023-09-211-2/+14
| | | | | Fixes: #11610 Fixes: 9feeb324eddd9ed73ae667e10275f663d70f7544
* vo_gpu_next: use proper color for subtitlesKacper Michajłow2023-09-211-19/+28
| | | | | All SUBBITMAP_LIBASS are converted to sRGB beforehand, for the rest we need to use video color space.
* vo_gpu: don't override scaler options with default onesKacper Michajłow2023-09-211-2/+10
| | | | | | | There was assumption in the code that default settings are compatible with dumb mode and are only one that should be used in this case. Force bilinear if dumb mode is enabled.
* vo_gpu: allow deband-iterations to be 0llyyr2023-09-211-1/+1
| | | | | THis allows adding grain without debanding. libplacebo already supported this, so no changes are required there.
* drm: remove selecting the card number with --drm-connectorDudemanguy2023-09-211-18/+1
| | | | | | f56043759494dd584c8d82e7890f92fada18e34b deprecated this since the --drm-device path option was added as a replacement. Drop the card number selection logic.
* vo_sixel: change exit-clear handling to OPT_REPLACEDDudemanguy2023-09-211-2/+1
| | | | Easier to keep track of when we do want to remove it.
* options: remove a few options marked with .deprecation_messageDudemanguy2023-09-211-2/+0
| | | | | | | | | | | A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the options still possibly do something but they have a deprecation message. Most of these are old and have no real usage. The only potentially controversial ones are the removal of --oaffset and --ovoffset which were deprecated years ago and seemingly have no real replacement. There's a cryptic message about --audio-delay but who knows. The less encoding mode code we have, the better so just chuck it.
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-219-46/+0
| | | | | | | | | | | | | We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting around in the code. This is harmless, but the vast majority of these are ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit that touched the majority of these and of course that only changed how options were declared so all of this stuff was deprecated even before that. No use in keeping these, so just delete them all. As an aside, there was actually a cocoa_opts but it had only a single option which was replaced by something else and empty otherwise. So that entire thing was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were added in 0.35 or later were kept as is.
* vo_dmabuf_wayland: support osd rendering when there's no videoDudemanguy2023-09-212-25/+29
| | | | | | | | | | | | | The osd support was originally written with the requirement that we have actual frames getting delivered to the VO. This isn't always the case though. If you force a window on a blank audio file for example, then there will be no frame thus draw_frame did nothing. Since the previous commit allows us to reliably detect this, we can rearrange the code around a little bit to make this possible. A key change is to make the osd_subsurface have wl->surface as the parent. This is seemingly required otherwise the osd_surface buffers are never visible above the empty video_surface when we have a black window. Also nuke the desync call since it's completely pointless. Fixes #12429.
* mp_image: add force_window fieldDudemanguy2023-09-212-0/+2
| | | | | | It's useful for some VOs (dmabuf-wayland) to know if the image params are actually real or fake ones sent by the core for the purpose of force_window.
* vo_gpu_next: fix unscaled screenshot with --blend-subtitlesKacper Michajłow2023-09-211-4/+4
| | | | Need to use correct adjusted dst.
* vo_gpu: match libplacebo debanding defaultsNiklas Haas2023-09-201-2/+2
| | | | | | | | | The defaults were awful and horribly regressed many files while also not fixing banding on files that actually needed it, sometimes even *increasing* banding due to the low threshold. Fixes: 12ffce0f224056f91a20c9f0b197f4973931efbe See-Also: haasn/libplacebo@e1e43376d16d5112ee1254534664b0b85110139b
* vo_gpu: match libplacebo peak detection defaultsNiklas Haas2023-09-201-3/+3
| | | | | | | | | This probably makes `vo_gpu` tone mapping worse, or something, but who cares. The status quo for a while now has been to use `vo_gpu_next` if you care about HDR rendering at all. See-Also: haasn/libplacebo@ec60dd156b82753a2e2d8a399899244605f4d1bf See-Also: haasn/libplacebo@0903cbd05d7fc0391cbd99954924a39b855c8a1b
* vo_gpu: default to dscale=hermiteNiklas Haas2023-09-201-1/+1
| | | | | | | | | | This new filter is slightly sharper, and significantly faster, than mitchell. It also tends to preserve detail better. All in all, there is no reason not to use it by default, especially from a performance PoV. (In vo_gpu_next, hermite is implemented efficiently using hardware accelerated bilinear interpolation) See-Also: https://code.videolan.org/videolan/libplacebo/-/commit/75b3947b2c07803456483ec6976c037bad91b5dd
* builtin.conf: modernize internal profilesKacper Michajłow2023-09-191-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to provide simple to understand quality/performance level profiles for the users. Instead of default and gpu-hq profile. There main profiles were added: - fast: can run on any hardware - default: balanced profile between quality and performance - high-quality: out of the box high quality experience. Intended mostly for dGPU. Summary of three profiles, including default one: [fast] scale=bilinear cscale=bilinear (implicit) dscale=bilinear dither=no correct-downscaling=no linear-downscaling=no sigmoid-upscaling=no hdr-compute-peak=no [default] (implicit mpv defaults) scale=lanczos cscale=lanczos dscale=mitchell dither-depth=auto correct-downscaling=yes linear-downscaling=yes sigmoid-upscaling=yes hdr-compute-peak=yes [high-quality] (inherits default options) scale=ewa_lanczossharp cscale=ewa_lanczossharp (implicit) hdr-peak-percentile=99.995 hdr-contrast-recovery=0.30 allow-delayed-peak-detect=no deband=yes scaler-lut-size=8
* vo: change tscale to oversample by defaultKacper Michajłow2023-09-191-2/+1
| | | | Keep it sharp, let users opt-in more blurry result.
* vo: make cscale follow scale by defaultKacper Michajłow2023-09-192-2/+19
|
* vo: enable correct-downscaling, linear-downscaling, sigmoid-upscalingKacper Michajłow2023-09-191-0/+3
|
* vo: avoid unnecessary redraws when the OSD showsDudemanguy2023-09-191-6/+6
| | | | | | | | | | | | | | | | 296d40dc6f38401085d005bb4627f8afff46b041 changed how the vo handled redraw requests in order to fix a race condition that can occur with pausing. However, there was a slight oversight because a redraw request that occurred while the core was unlocked and the video was still playing would still be kept true (previously, this was always cleared). That redraw is essential if mpv is paused otherwise the old issue comes back, but if the video is playing it's unnecessary since the next loop around will simply draw whatever we needed. The extra redraw could cause a frame drop for some people in certain instances, so the solution is to simply always clear redraw requests if !in->paused. This eliminates the extra redraw but still keeps it when pausing. Fixes #12426 and fixes #11579.
* filter_kernels: remove bcspline filterllyyr2023-09-181-11/+1
| | | | | | After fixing the B and C params for bcspline, it ended up being the same thing as bicubic. There's no reason to have two names for the same filter, so remove bcspline and keep bicubic to match libplacebo.
* filter_kernels: fix bcspline paramsllyyr2023-09-181-1/+1
| | | | | bcspline is defined as B=1, C=0 in ImageMagick (as CubicFilter) and libplacebo, so we should match that.
* filter_kernels: add hermite filterllyyr2023-09-181-0/+1
| | | | Matches HermiteFilter from Imagemagick (B=C=0, R=1)
* vo_gpu_next: fix blur and taper values being zerollyyr2023-09-181-2/+4
| | | | | This would always apply the config blur and taper values to the kernel, even if it was zero because the user didn't specify any.
* vo_dmabuf_wayland: support 90 degree rotationsDudemanguy2023-09-171-0/+3
| | | | | | | All we have to do is set VO_CAP_ROTATE90 and then use buffer transform. Maybe ideally we would rotate with vavpp instead if possible, but this would be a convoluted mess that I'm not really interested in dealing with right now.
* win32: remove noisy debug logKacper Michajłow2023-09-171-1/+0
| | | | It is quite unnecessary to log every window move.
* vo_gpu: remove --scale-wblur etcNiklas Haas2023-09-161-1/+1
| | | | | | | | | | No need for this since it's entirely redundant with just changing the filter radius directly. In fact, that's the whole *point* of the filter radius - it does not modify the filter, it modifies the scaling of the window. Of course, this does not work for non-resizable kernels. But, really, who cares?
* filter_kernels: add ewa_lanczos4sharpestNiklas Haas2023-09-161-0/+6
| | | | Mainly for vo_gpu_next.
* filter_kernels: refine ewa_lanczossharp/soft constantsNiklas Haas2023-09-161-6/+6
| | | | | | Replaced by mathematically and numerically precise constants, the result of exact computation. Also updates the description to provide more explanation and motivation.
* filter_kernels: use true jinc radiusNiklas Haas2023-09-161-4/+4
| | | | | For all filters. For consistency between vo_gpu and vo_gpu_next. Also makes ewa_lanczossharp less special.
* filter_kernels: replace magic jinc radius by constant (cosmetic)Niklas Haas2023-09-161-6/+8
|
* filter_kernels: properly sharpen/blur filter radiusNiklas Haas2023-09-163-7/+11
| | | | | | | | | | | | | We currently always scaled the window to the size of the configured radius. However, this is wrong - we should instead be scaling it to the size of the sharpened/blurred kernel. Since the window is always stretched to the configured size of the filter, we can accomplish this easily by just multiplying the blur value into the filter radius directly, and then using that adjusted radius in place of `f.radius` everywhere. On a side note, this gives a very minor performance boost to ewa_lanczossharp for no downside.
* vo_gpu: slight bump to hard-coded option size limitsNiklas Haas2023-09-161-3/+3
| | | | ewa_lanczos4sharpest, for example, overflows this buffer.
* vo_gpu_next: remove ewa_lanczossharp nagNiklas Haas2023-09-161-6/+0
| | | | | | | Upstream finally caved in to peer pressure and added this filter. Of course, this also removes the fallback for people on older versions of libplacebo, but people using mpv git master are probably using libplacebo git master anyway. It's time to debloat this code.
* vo_gpu: vo_gpu_next: support --icc-3dlut-size=autoNiklas Haas2023-09-152-1/+11
| | | | | | | | | | | | And make it the default. In libplacebo, this uses internal heuristics to pick a good size based on the actual ICC characteristics. This is significantly less wasteful than always generating a 64x64x64 3DLUT (the old status quo). In vo_gpu, for simplicity, just default to 65x65x65. Note that this provides slightly better accuracy than the old default of 64x64x64 for technical reasons, and matches what libplacebo defaults to for typical display profiles.
* vo_gpu_next: update for new ICC profile APINiklas Haas2023-09-151-38/+60
| | | | | | | | | Upstream has moved from passing struct pl_icc_profile to directly attaching a managed pl_icc_object, plus providing a new function pl_icc_update to update the ICC profile object parameters (if needed). To facilitate this move, pull our ICC params back out of pl_options and update the target ICC object directly.
* present_sync: allow future timestampsDudemanguy2023-09-141-4/+3
| | | | | | | | | | | | | | | | | | | | | | The original OML sync implementation (which is where this calculation originally comes from) made now_monotonic and ust_mp_time unsigned. This is fine except it has the assumption that now_monotonic is always greater than ust. This actually isn't always the case. In wayland, I observed instances where the reported timestamp is in the future. Of course, it's a valid question to wonder if this even makes sense but these UST values are essentially opaque black boxes to us anyways. It's entirely plausible that the gpu is expecting the actual presentation of the last swap to be a bit in the future, the compositor gets this and reports this to us. So we'll consider such stats as valid. Note that xorg doesn't have this problem because it's roughly one swap buffer call behind because of how the event loop works (honestly something that should be fixed). Of course, the problem with the unsigned type here is that it overflows on the subtraction so make it signed and allow the appropriate negative value to happen if it does. Note that this will simply result in a small addition to mp_time_us() which is exactly what we want here (timestamp slightly in the future). Some small style changes included just because.
* vo_gpu_next: map --scaler-resizes-onlyNiklas Haas2023-09-141-0/+3
|
* vd_lavc: by default enable cropping by decoderKacper Michajłow2023-09-101-0/+1
| | | | | | | | | | | | | | | | | | | | | While this resolves limitations of lavc decoder crop, it also introduces artifacts with some of the source files or hwdec. Depending on chroma sampler it is possible to sample outside the decoder crop area, pulling dirty pixels into the image. Some decoders left them zeroed, not black. To fix that we would need specifc solution during mapping of avframes. As most of the files require the crop only in bottom/right area, the AVCodecContext::apply_cropping works ok for those. For all other cases that require more fancy cropping like 1440x1080+240+0 user can manually set `--vd-apply-cropping=no`. Limitations of the lavc crop are explained here: https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a4745c7455c317272c4e139d6f369936c Fixes: 826ce82cad315f7a48f9c971d3a5fa005a9eab46
* vo: change vsync_interval to doubleDudemanguy2023-09-092-12/+12
| | | | | | | | | | | | | | | So strangely enough, estimated_vsync_interval is stored as a double but nominal_vsync_interval is not and neither is the vsync_interval. Those are stored as int64_t. This loss of precision can matter even in common cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666 (repeating) being calculated as the vsync interval, you would get 16666 since the decimals are truncated. This is not really good at all and affects the calculated speed values you get when using display sync. For consistency and better precision, these should all be doubles just like estimated_vsync_interval. Technically this means that we won't be able to store as high of an integer value but such values would be absurdly huge and never actually needed. Also estimated_vsync_interval already can't handle such a case anyway.
* screenshot: support crop with --screenshot-swKacper Michajłow2023-09-091-2/+18
|
* vo_gpu_next: support --blend-subtitles when taking screenshootKacper Michajłow2023-09-091-3/+25
|
* vo_gpu: support crop in gl_video_screenshotKacper Michajłow2023-09-091-3/