| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
The original implementation had some errors with regards to android. Add
a couple of missing files, add the android library, fix the aviocontext
bytes_read check, fix egl-android, and rearrange/tidy up the vulkan
handling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the basic Vulkan Display context can theoretically drive the
display without the involvement of any non-Vulkan code, that prevents
us from using VAAPI acceleration. When initialising VAAPI without a
window system, we need to provide it with an opened DRM render fd
corresponding to the device to use.
In the context of using VK_KHR_display, that means we need to identify
which DRM device matches the selected Vulkan device, and then open its
render fd and set the necessary state that VAAPI expects to find.
With that done, the normal VAAPI<->Vulkan interop can kick in and we
get working acceleration
|
|
|
|
|
| |
Obvious oversight in the original PR for the meson build. The xv option
requires x11 to function. Check for this by using the require method.
|
|
|
|
|
|
|
|
|
|
|
| |
A few custom targets had some less than optimal names which created some
misleading "Generating custom-target-name with a custom command"
messages. Change those to be more descriptive/correct. In a few other
places, some checks were being done that could easily be
skipped/ignored in certain cases (like checking for windows-related
headers when gl-win32 isn't true). Also rearrange that to be smarter.
Finally, print some extra libplacebo messages for enabling/disabling
vo_gpu_next.
|
|
|
|
|
| |
Some systems have only a "lua.pc" file which contains version
information inside it. Check those as well.
|
|
|
|
|
|
|
|
| |
This test fails because the compiler object does not have -Wformat when
it tries this flag. To fix this this, we have to pass both -Wformat and
-Werror=format-security at the same time during the test. This requires
us to use has_multi_arguments so this flag needs to be pulled out of
this array and tested separately.
|
|
|
|
|
|
|
| |
youtube-dl and yt-dlp both support --sub-langs and --srt-lang in
addition to --sub-lang for defining languages of subtitles. This hook
only checked for sub-lang in --ytdl-raw-options and inserted --all-subs
in its absence.
|
|
|
|
|
|
|
| |
Constant data, most accessors are good but some were missing the
explicit notation.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
|
|
|
|
|
| |
Nearly all the code base correctly references the data as constant. But
a couple of instances - fix those.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
|
|
|
|
|
| |
Ever instance of m_obj_list is a constant and for all of them, the field
is true. Just remove the field all together.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Update the github workflows to also do meson builds for every OS.
Additionally, make every workflow execute the built mpv executable
(except for windows and FreeBSD's waf executable) to make sure that it
runs. As an aside, FreeBSD unfortunately is a bit less elegant since it
is in a VM.
|
|
|
|
|
|
| |
Adds support for the meson build system as well as a bit of
documentation. Compatibility with the existing waf build is
maintained.
|
|
|
|
|
|
|
|
|
|
|
| |
The extension is completely arbitrary since ebml_defs.c isn't a real c
file that actually is compiled at any point in time. It's just used as
an include. The reason for changing the extension is because meson needs
to add this to its list of sources for dependency/ordering purposes.
Understandably, meson will try to compile any .c file added to a c
project executable object. Obviously, this compilation will never
succeed, and this shouldn't be compiled anyways. Just make it .inc
instead.
|
|
|
|
|
| |
Like the previous commit, it's better to just output it to a file for
meson.
|
|
|
|
|
|
|
| |
Another modification for the upcoming meson build. Meson can capture the
stdout and redirect it to a file. However, this is considered a hack.
It's better to just add a few lines to this script and write a file
directly.
|
|
|
|
|
|
|
| |
Apple is great and forces us to do a lot of weird checks because they
randomly move the location of the swift libraries around. Make a
specific python script for checking various locations and write the
output to stdout for meson.
|
|
|
|
|
|
|
|
| |
Building for macos requires us to check the macos sdk path as well as
the sdk version that is on the system. To do this, let's steal the logic
that's in the compiler_swift.py check from the waf build. This returns a
comma-delinated string. The first entry is the absolute path to the sdk.
The second entry is the detected macos sdk version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
version.h is essential for building, and its generation was done by a
shell script. Strictly speaking, python should in general be more
portable (windows), and would be better for the upcoming meson build to
simply just execute a python script. version.py has some small
differences with version.sh which shouldn't matter but they are noted
below.
- version.sh accepted several arguments that seemed useless (like
--cwd). These were removed from version.py.
- version.py takes either no arguments (prints the version) or it takes
exactly one argument specifying the complete path of where the header
should be generated.
- version.sh attempted to read a file named "snapshot_version". The
comments noted that this was for "daily tarball snapshots". Such a
file does not exist in the source tree, and it's not really clear that
anyone actually uses this. This logic was removed from version.py.
- version.py reads the SOURCE_DATE_EPOCH environment variable. Some
distros use this for reproducible builds. Technically you could also
just disable the build date but this is only a couple of extra lines
and maybe it's prettier than UNKNOWN.
- version.py also doesn't attempt to display timezone information in the
build date. It only shows UTC time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
d2e8bc449986e012f257249a996386bd323febd0 was the the commit that
originally introduced the usage of this bit. As the message states, the
purpose was to force creating GLES 3 contexts on drivers that do not
return a higher version context than what was requested. With the recent
opengl refactors, mpv's gl selection has already moved away from such
complicated queries. Perhaps when that commit was added things were
different, but nowadays it seems like Mesa simply returns the highest
driver version available that is compatibile with the request (i.e.
requesting GLES 2 returns a GLES 3 context on my machine). In that case,
let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break
GLES 2 only machines. Fixes #9431.
|
|
|
|
|
| |
This is identical to eglCreateWindowSurface but should be
preferred as part of EGL's platform extension.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new GBM supporting nvidia drivers declare support for 10bit
surfaces using BGR ordering, rather than RGB, so add support for them.
We've also seen examples of hardware supporting BGR8888 but not
RGB8888 so let's support those too.
Of course, the nvidia EGL driver doesn't publish support for any 10bit
formats so you can't actually do 10bit display. Perhaps they'll
eventually fix that.
|
|
|
|
|
|
|
|
|
| |
The GBM supporting nvidia driver doesn't support creating surfaces
without modifiers and using modifiers is more and more recommended as
the right way to do this.
Enumerating modifiers is painfully verbose, but necessary if we are to
allow the driver to pick the best possible one.
|
|
|
|
|
|
|
|
| |
This fixes a mismatch between configure working and build time
failing with Linux + OSSv4, enabling compilation on Debian based
Linux systems with the oss4-dev package.
Fixes #9378
|
| |
|
|
|
|
|
|
|
|
| |
This logic, which was working around a libplacebo bug, ended up always
alpha blending - even for sources without an alpha channel. This caused
a minor slowdown to be constantly enabled.
Due to the recent bump to libplacebo v170, this is no longer needed.
|
|
|
|
|
| |
Without initializing, the random data causes the `pl_render_image_mix`
function to abort with a SIGSEGV.
|
|
|
|
|
|
|
|
| |
Completely untested, since Linux still can't into HDR in 2021. Somebody
please make sure it works.
Technically covers #8219, since gpu-context=drm can be combined with
vo=gpu-next.
|
|
|
|
| |
These are no longer needed with the minimum version bump.
|
|
|
|
|
|
|
|
| |
This required an upstream API change to implement in a way that doesn't
unnecessarily re-push or upload frames that won't be used. I consider
this a big enough bug to justify bumping the minimum version for it.
Closes #9401
|
|
|
|
|
|
|
|
|
| |
This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993
for unclear reasons (way to go me). This concept is clearly incorrect.
It doesn't matter what state the window is in. As soon as mpv detects a
scale change, it needs to reset the buffer scale of the window. Just
remove all this junk and put wl_surface_set_buffer_scale in
set_surface_scaling like it should be. Related issue: #9426.
|
|
|
|
|
|
|
| |
This one hits a lot of people. Probably because the man page explicitly
recommends it.
Fixes #9408
|
|
|
|
|
|
| |
I somehow completely forgot about this option existing.
Closes #9416
|
|
|
|
|
|
|
|
|
|
|
| |
Looking at this again I'm not sure it does anything useful at all. The
man page entry is also wrong: `bicubic` is not affected, only
`bicubic_fast`, and those filters are not configurable anyways.
So this would only ever be a debugging option, and I don't see a
pressing need for it.
No interface-change.rst update because it only just got added anyways.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
In practice, this is for wayland. vo_gpu_next doesn't check the
check_visible parameter since it didn't descend into the
vulkan/context.c file when starting a frame. To make this happen, just
call the start_frame function pointer but pass NULL as the ra_fbo. In
there, we can do the visibility checks and after that bail out of the
start_frame function if ra_fbo is NULL.
|
|
|
|
|
|
|
|
|
|
| |
This vulkan-specific parameter was poorly named and probably causes
confusion. Just rename it to check_visible instead to make clear what is
going on here. Only wayland uses it for now but in theory anyone else
can. As an aside, wayland egl accomplishes this by using an external
swapchain instead (an opengl-only concept in the mpv code). This may or
may not need to be changed in the future when gpu-next gets opengl
support.
|
|
|
|
| |
Fixes https://github.com/mpv-player/mpv/issues/9387
|
|
|
|
|
| |
It was pointed out on IRC that the name is misleading, since the actual
semantics of the macro is to assert first.
|
|
|
|
|
|
| |
vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default.
Fixes https://github.com/mpv-player/mpv/issues/9386
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #8799, this will eventually replace vo_gpu. However, it
is not yet complete. Currently missing:
- OpenGL contexts
- hardware decoding
- blend-subtitles=video
- VOCTRL_SCREENSHOT
However, it's usable enough to cover most use cases, and as such is
enough to start getting in some crucial testing.
|
|
|
|
| |
This one got me debugging for quite a while. Assert it for the future.
|
|
|
|
|
|
|
|
|
| |
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
|
|
|
|
|
| |
This can be used to do things like query the values of preprocessor
defines like version macros, among other potential uses.
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of people seem to do something like --tscale=box
--tscale-window=<function>. Just let them use --tscale=<function>
directly, by also accepting raw windows.
Kinda hacky but needed for feature parity with vo_gpu_next, which no
longer has `--tscale=box`. Note that because the option struct is still
shared, vo_gpu_next inherits the same option handling code, so we have
to export this feature for vo_gpu as well.
|
|
|
|
| |
So I can reuse it in vo_gpu_next.
|
|
|
|
| |
So I can re-use them for vo_gpu_next.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back when runtime updating of autofit/geometry was added for wayland and
x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and
ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive
assumption was that window-related geometry would always be available.
While this is true 99% of the time, this isn't a guarentee. It is
possible for certain things such as loading shaders to delay starting up
the player. This causes autofit/geometry options to be registered as a
runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling
some geometry-related functions but this happens before the actual
values are available. Hence, a nullptr was accessed which segfaults. At
least one user experienced this with a combination of options in wayland
but in theory the same thing could happen under x11.
The fix is simple. Just be sure to check that the required geometry is
available before doing any calculations. In wayland, this would be
wl->current_output. Additionally add an assert to set_geometry (we
should never use this function without wl->current_output) to be extra
sure. In x11, the check is on x11->window. Later when the reconfig for
each backend actually happens, the autofit/geometry set by the user
happens anyway so ignoring it in this case does no harm. Fixes #9381.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with the previous code - which used mp.get_user_path, is
that it returns a path even with --no-config, and even if the file
doesn't exist.
This is why we tested the "config" property, and also used
mp.utils.file_info to check that the file exists.
mp.find_config_file doesn't return a path with no-cofig and doesn't
return a path if the file doesn't exists. It's simpler and better.
|
|
|
|
| |
As it turns out the manual was very wrong about this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream libplacebo got refactored to use byte-sized strides rather than
texel-sized strides. This commit makes mpv's ra_pl wrapper take
advantage of that, rather than forcing a stride-fixing memcpy.
Note that, technically, we would still need a stride fixing memcpy in
cases when the true stride is not a multiple of the format's texel
*alignment*, however this is a much rarer case and extremely unlikely to
occur in practice, since all relevant formats use power-of-two texel
alignments.
|
| |
|
|
|
|
|
| |
Make it clearer that watch-later-options controls which options are not saved
and not which ones are restored.
|
|
|
|
|
|
|
|
|
|
|
| |
In the reconfig event, the keepaspect option was checked before setting
the window_size geometry to the new params obtained from the vo. This is
incorrect. If a user disabled keepaspect on wayland, the video's size
would not change on a reconfigure event (i.e. loading a new video in the
playlist with a different size). No other windowing backend (x11, win32,
etc.) behaves like this or uses keepaspect in its code like wayland did
in this case. Clearly, this is not correct. Such functionality should be
handled by a separate option entirely. Just remove this if statement.
|
|
|
|
| |
Add support for the newly added USB connector type and also SPI and Writeback.
|
|
|
|
|
| |
Avoid 'Segmentation fault' by using the connector type name UNKNOWN if
the connector type is not known to mpv.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bytes_read struct member in AVIOContext is now officially public,
so its usage no longer has to be specified as non-compliance with
FFmpeg's ABI/API rules.
That said, unfortunately there was a short period of time between
August 2021 and October 2021 where the struct member did not exist
in FFmpeg's git master, so keep a feature check for it alive for
now to enable building with those versions. Thankfully, no release
version of FFmpeg will be without this field, so it should be
possible to drop this check with time.
Finally, simplify the function in case the struct member is not
found. After all, there is zero reason to iterate through the AVIO
contexts if we cannot get the information we require.
|
| |
|