| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I already added the equivalent logic for dmabuf_interop_pl previously
but I skipped the GL support because importing dmabufs into GL requires
explicitly providing the DRM format, and if you are taking a
multi-plane format and trying to treat each plane as a separate layer,
you need to come up with a DRM format for each synthetic layer.
But my initial testing has shown that the RockPRO64 board I've got to
work on drmprime hwdec will only produce NV12 in a single layer multi
plane format, and it doesn't have Vulkan support, so I have had to
tackle the GL multi-plane problem.
To that end, this change introduces the infrastructure to provide new
formats for synthetic layers. We only have lookup code for NV12 and
P010 as these were the only ones I could test.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Annoyingly, libva and libdrm use different structs to describe dmabufs
and if we are going to support drmprime, we must pick one format and do
some shuffling in the other case.
I've decided to use AVDRMFrameDescriptor as our internal format as this
removes the libva dependency from dmabuf_interop. That means that the
future drmprime hwdec will be able to populate it directly and the
existing hwdec_vaapi needs to copy the struct members around, but
that's cheap and not a concern.
|
| |
|
|
|
|
| |
With the files renamed, we can now disentangle the shared private
struct between the interops and hwdec_vaapi. We need this separation
to allow the future drmprime hwdec to use the interops.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the first in a series of changes that will introduce a drmprime
hwdec. As our vaapi hwdec is based around exporting surfaces as
drmprime dmabufs, we've actually got a lot of useful code already in
place in the GL/PL interops. I'm going to reorganise and adjust this
code to make the interops usable with the new hwdec as well.
The first step is to rename the files and functions. There are no
functional or other changes here. They will come next.
|
| | |
|
| |
|
|
|
|
| |
Avoids another pitfall on systems where the first card has a primary
node but is not capable of KMS. With this change --drm-context=drm
should work correctly out-of-the-box in all cases.
|
| |
|
|
|
|
|
|
| |
On S905X (meson) boards drmModeAtomicCommit called from
disable_video_plane in hwdec_drmprime_drm.c might still be running when
another call is made from queue_flip in context_drm_egl.c.
This causes EBUSY error in queue_flip, and causes mpv to hang.
|
| |
|
|
| |
plane_clear[p] is never NULL
|
| |
|
|
|
|
|
| |
The example given in #3024 would not play the correct video when
combined with `--ytdl-raw-options=yes-playlist=`.
Allowing `youtube:tab` as extractor and correcting the id check fixes
that.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is somewhat academic for now, as we explicitly ask for separate
layers and the scenarios where multi-plane images are required also use
complex formats that cannot be decomposed after the fact, but
nevertheless it is possible for us to consume simple multi-plane
images where there is one layer with n planes instead of n layers with
one plane each.
In these cases, we just treat the planes the same as we would if they
were each in a separate layer and everything works out.
It ought to be possible to make this work for OpenGL but I couldn't
wrap my head around how to provide the right DRM fourcc when
pretending a plane is a layer by itself. So I've left that
unimplemented.
|
| |
|
|
|
| |
This check was wrong/outdated. PL_QUEUE_MORE does not imply an empty
frame mix, it can still contain partial frames.
|
| |
|
|
|
|
| |
A VRAM memory leak was present in d3d11 when `idle=yes` and playback
stops for an item. This patch re-enables some of the code which is
only used during diagnostic which fixes the issue.
|
| |
|
|
|
|
|
|
|
|
| |
Generally, the hard-coded sizes used for the OSC elements are
comfortable regardless of the font used, but the timecode fields have
relatively many characters, and so are affected to a greater degree by
fonts with a wider or narrower average character width than expected.
This allow users to adjust the space reserved for the timecode fields to
compensate.
|
| |
|
|
|
|
| |
This option enables the use of the Unicode U+2212 Minus Sign character
when displaying the time remaining, instead of "-" (U+002D
Hyphen-Minus).
|
| |
|
|
| |
This path incorrectly assumes there is a current frame.
|
| |
|
|
|
| |
In some cases HTTP headers were not set, leading to some sites not
working despite being supported by yt-dlp/youtube-dl.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
libplacebo 4.157 [1] rename context.h to log.h, and left a compatibility
header. In 5.x, this header has been removed.
Since we require libplacebo 4.157 to build mpv, we can just use log.h to
fix compatibility with 5.x.
[1]: https://github.com/haasn/libplacebo/commit/2459200a133d1a0f36f092a32a2d5d443cfbee55
Signed-off-by: Coelacanthus <coelacanthus@outlook.com>
|
| |
|
|
|
| |
FreeBSD doesn't support /latest and /quarterly package repos on EOL
versions. 13.0 reaches EOL on 2022-08-31, so avoid CI breakage.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Using cmsFLAGS_HIGHRESPRECALC results in Little-CMS generating an
internal 49x49x49 3DLUT, from which it then samples our own 3DLUT. This
is completely pointless and not only destroys the accuracy of the 3DLUT,
but also results in no additional gain from increasing the 3DLUT
precision further.
The correct flag for us to be using is cmsFLAGS_NOOPTIMIZE, which
suppresses this internal 3DLUT generation and gives us the full
precision. We can also specify cmsFLAGS_NOCACHE, which is negligible but
in theory prevents Little-CMS from unnecessary pixel equality tests.
|
| | |
|
| |
|
|
| |
Don't use cube root volumes, pipewire uses linear volumes.
|
| |
|
|
|
|
|
|
| |
pw_core_disconnect frees the core, so accessing it afterward to
destroy the context is not allowed.
Instead, just destroy the context, the first thing it does is disconnect
all cores for us.
|
| |
|
|
|
| |
The listeners need to be cleared because removing them might invoke the
removed handler, which could otherwise point to invalid memory.
|
| |
|
|
|
|
|
|
| |
mpv only remembers volume for two channels.
Always apply the same volume to all channels in case of
non-stereo layout similarly to ao_pulse.
Don't try to do anything smart when averaging volumes,
normally they are equal anyway.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was introduced in 7fb972fd3997bfa389caa7c1eb899ea4b8444083 and
later revised in f5a094db047ee0162774301a2ce4ed685ca9d539. Transparency
in EGL/X11 has been broken upstream for years in Mesa unfortunately.
However, the first commit claimed to have found a way to preserve
transparency by doing a trick with picking EGLConfigs (the second commit
revises this but keeps the logic in place). However, it doesn't appear
that the first commit actually fixes anything (transparency doesn't work
on my machine) and no one else seems to have reported it working. On the
other hand, if Mesa does ever actually fix this, transparency would
immediately be broken since mpv would always set the EGL_ALPHA_SIZE to
0. Go ahead and remove this since it doesn't seem to have any actual
utility and is technically a bit of a timebomb (not that deleting two
lines is a lot of work but still) if upstream ever does fix this.
|
| | |
|
| |
|
|
| |
This option was added in mpv-player@ec236f7, but its name in the document description is incorrect
|
| |
|
|
|
|
|
|
|
|
| |
The meson build does a lot of checks and if you aren't familiar with the
internals of the meson.build, it may not be clear what is actually
enabled and what isn't. It turns out that meson has a handy function,
summary, exactly for this. This just prints a pretty summary of some
notable features in the build. It's not meant to be a comprehensive
list, but rather just what users are likely to care the most about (i.e.
x11, vulkan, etc.)
|
| |
|
|
| |
Fixes #9451
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was introduced in 04257417 without a clear explanation of the bug
it was solving, so I have no idea if it's still needed (or why it ever
was). And it definitely creates unexpected behavior, e.g. forced
clipping when converting between float and floatp.
I therefore think we should simply remove this logic and see if it
regresses anything else, then fix those other bugs *properly* (if
they're still around).
Fixes #9979
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit 7f4841ff sorted the bindings so that if the same key was bound
more than once, then the newest binding takes priority (sorted last).
However, it got the comparison function wrong, which means the result
of the sort depended on the algorithm and not on the actual data, so
the priority for keys with more than one binding was still arbitraty.
Fix the sort function, and finally ensure that later binding acutally
override earlier bindings of the same key.
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit kind of mixes several related things together. The main
thing is to avoid calling any XPresent functions or internal functions
related to presentation when the feature is not auto-whitelisted or
enabled by the user. Internally rework this so it all works off of a
use_present bool (have_present is eliminated because having a non-zero
present_code covers exactly the same thing) and make sure it updates on
runtime. Finally, put some actual logging in here whenever XPresent is
enabled/disabled. Fixes #10326.
|
| |
|
|
|
|
|
| |
The documentation states that the callback is optional, but it actually
was not.
Now it's optional, as docuented.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if the raw command_native_async returned an error then the
callback function was run directly. This meant that script writers
potentially had to account for both synchronous and asynchronous logic
in the callback, which can happen even with seemingly 'safe' commands
if the mpv event queue is full.
This was at odds with the Javascript implementation of
the function, which always runs the callback asynchronously.
Now the mp.add_timeout function is used to run the callback
asynchronously on error, replicating the Javascript implementation.
This provides consistency for developers in how the callback is handled
in Lua, and increases consistency between the Lua and Javascript APIs.
|
| |
|
|
|
|
|
|
|
|
|
| |
With the recent addition of the libxpresent, it should improve frame
timings for most users. However, there were known cases of bad behavior
(Nvidia) which lead to a construction of a whitelist instead of just
enabling this all the time. Since there's no way to predict whatever
combination of hardware/drivers/etc. may work correctly, just give users
an option to switch the usage of xorg's presentation statistics on/off.
The default value, auto, works like before (basically, Mesa drivers and
no Nvidia are allowed), but now one can force it on/off if needed.
|
| |
|
|
|
| |
A user noted that this worked correctly (i.e. vsync jitter of 0) so go
ahead and add it here as a safe driver for xpresent to use.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The old logic always reset the x11->has_mesa/has_nvidia values on every
loop through the provider. This meant that it would always just match
whatever the last provider happened to be. So in the case of a dual GPU
system, if nvidia was the very first provider and the integrated
intel/amd card was the second (in practice, this is probably mostly the
other way around), then mpv would set has_mesa to true and has_nvidia to
false and thus try to use presentation. This is not the intended
behavior. Just rework this by also checking x11->has_mesa/has_nvidia in
the loop so a true value from the previous iteration is preserved.
|
| |
|
|
|
|
|
|
| |
This code was taken from the older vo_vaapi driver, which does
use the vaapi format list, but the new driver has no use for
these formats, as it is only interested in va surfaces that
can be mapped to wl buffers. The format doesn't enter into
it at all.
|
| |
|
|
|
|
|
| |
Immediately after this, d3d11 is defined again and the rest of the
meson.build uses that. Probably, this dictionary was from the original
meson PR and removing it was forgotten at some point while stuff was
being rewritten.
|
| |
|
|
|
| |
strcasestr is a GNU extension, but we can just use bstr instead to do
the same thing.
|
| |
|
|
| |
This is needed for x11 which is in turn needed for vdpau.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately there's a certain company that makes graphics drivers that
are harder to deal with. The next commit aims to implement presentation,
but some empirical testing from users show that it's actually broken.
Give up and just tap into Xrandr so we can figure what drivers (or well,
providers by the extension terminology) are driving the screen.
Basically if we find intel, amd, or radeon, assume it's a Mesa driver.
If we find nvidia, then it must be nvidia. This detection requires randr
1.4 (which means using presentation in mpv secretly depends on randr
1.4), but this protocol version is nearly a decade old anyway so
probably 99.9% of users are fine. Do the version query check and all
that anyway just to be on the safe side.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wayland had some specific code that it used for implementing the
presentation time protocol. It turns out that xorg's present extension
is extremely similar, so it would be silly to duplicate this whole mess
again. Factor this out to separate, independent code and introduce the
mp_present struct which is used for handling the ust/msc values and some
other associated values. Also, add in some helper functions so all the
dirty details live specifically in present_sync. The only
wayland-specific part is actually obtaining ust/msc values. Since only
wayland or xorg are expected to use this, add a conditional to the build
that only adds this file when either one of those are present.
You may observe that sbc is completely omitted. This field existed in
wayland, but was completely unused (presentation time doesn't return
this). Xorg's present extension also doesn't use this so just get rid of
it all together. The actual calculation is slightly altered so it is
correct for our purposes. We want to get the presentation event of the
last frame that was just occured (this function executes right after the
buffer swap). The adjustment is to just remove the vsync_duration
subtraction. Also, The overly-complicated queue approach is removed.
This has no actual use in practice (on wayland or xorg). Presentation
statistics are only ever used after the immediate preceding swap to
update vsync timings or thrown away.
|
| |
|
|
|
|
|
|
| |
Technically this was wrong. If you passed -Dvdpau=enabled but did not
have x11 (a requirement for this), the build would silently just not
build the vdpau VO. The correct behavior is for it to be a hard error.
Accomplish this by using the require function and making sure that x11
is indeed being used before attempting to find the library.
|
| |
|
|
| |
Newer image builds already include Meson.
|
| |
|
|
|
|
|
|
|
| |
In win32 build, if libass and libfontconfig appear after libmingwex
during linking, crash happens whenever fontconfig calls to opendir().
Moving them before ffmpeg makes sure they always appear first.
More info on https://github.com/shinchiro/mpv-winbuild-cmake/issues/217.
|
| |
|
|
| |
There's no need to attach it with each frame.
|
| |
|
|
|
|
|
|
| |
resize only changes subsurface position, which is always synchronized
with the parent surface.
For reference, see :
https://wayland-book.com/surfaces-in-depth/subsurfaces.html
|
| |
|
|
| |
Not currently run, but adds coverage for compiled code.
|
| | |
|
| |
|
|
|
| |
This contains current as well as previous versions, while the root
directory only contains the latest version.
|
| | |
|
| |
|
|
|
|
|
|
| |
The first set iterates through all standard FFmpeg layouts and
checks that those |
