| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With earlier commit f8e62d3d82 ("egl_helpers: fix create_context
fallback behavior") we added a fallback for creating OpenGL context
while EGL_KHR_create_context is missing.
While it looked correct at first, it is missing the eglMakeCurrent()
call after creating the EGL context. Thus calling glGetString() fails.
Instead of doing that we can just remove some code - simply pass the
CLIENT_VERSION 2, as attributes which is honoured by EGL regardless of
the client API. This allows us to remove the special case and drop some
code.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ra_gl_ctx_test_version() helper is quite clunky, in that it pushes a
simple check too deep into the call chain. As such it makes it hard to
reason, let alone have the GLX and EGL code paths symmetrical.
Introduce a simple helper ra_gl_ctx_get_glesmode() which returns the
current glesmode, so the platforms can clearly reason about should and
should not be executed.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
- 320 -> 300 (in glx code path)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the documentation of the toggle says - the implementation can (and
will actually if they follow the GLX/EGL spec) return context version
greater than the one requested.
This happens with all Mesa drivers that I've tested as well as the
Nvidia binary drivers.
This toggle seems like a workaround for buggy drivers, yet it's lacking
context about the vendor and version.
Remove it for now - I'll be happy to reinstate it (partially or in full)
as we get concrete details.
This allows us to simplify ra_gl_ctx_test_version() making the whole
context creation business easier to follow by mere mortals.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Alike the GL commit earlier - the EGL spec essentially mandates that
implementation will return GLES 3.0+ (if supported by the driver), even
though only GLES 2 is requested.
The only thing we should watch out is - we should add both ES2_BIT and
ES3_BIT as EGL_RENDERABLE_TYPE.
This has been verified against the Mesa drivers (i965, iris, swrast) and
Nvidia binary drivers.
v2:
- int es_version -> bool es
- unloop create_context() execution
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently mpv requires a bare minimum of GL 2.1, although it tries to
use 3.2+ core contexts when possible.
The GLX and EGL spec effectively guarantee that the implementation will
give you the highest compatible version possible. In other words:
Requesting 3.2 core profile will always give you core profile and the
version will be in the 3.2 .. 4.6 range - as supported by the drivers.
Similarly for 2.1 - implementation will give you either:
- 2.1 .. 3.1, or
- 3.2 .. 4.6 compat profile
This has been verified against the Mesa drivers (i965, iris, swrast) and
Nvidia binary drivers.
As such, drop the list to 320, 210 and terminating 0.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
- update ^^ comment
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ioctls were disabled a while back since they error out and allegedly
cause problem with X running in another VT.
Omitting the ioctls is not cool, even as a workaround.
If they fail, the user is supposed to fallback appropriately - use a suid
wrapper, logind-like daemon or otherwise.
As of kernel 5.10, they should just work in nearly all cases, so let's
just reinstate the calls.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ioctls were disabled a while back since they error out and allegedly
cause problem with X running in another VT.
Omitting the ioctls is not cool, even as a workaround.
If they fail, the user is supposed to fallback appropriately - use a suid
wrapper, logind-like daemon or otherwise.
As of kernel 5.10, they should just work in nearly all cases, so let's
just reinstate the calls.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This behavior is more convenient and allows profile conditions like:
[video]
profile-cond=get('current-tracks/video/image') == false
[image]
profile-cond=get('current-tracks/video/image')
Otherwise, these profiles have to be manually applied and restored in a
script.
The note about discouraging the use of current-tracks in scripts is
removed, because it makes people avoid using this convenient property.
It was added in 720bcd79d03 without leaving an explanation of why you
shouldn't use it, and the only reason seems to be that it doesn't work
with lavfi-complex, but this commit changes that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes whether a video track is detected as an image, which is
useful for profile conditions, property expansion and lavfi-complex.
The lavf demuxer sets image to true when the existing check detects an
image.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the image check to where the number of frames is available of
comparison, which allows not detecting jpg and png videos as images, and
detecting 1-frame gifs as images. This works with the mjpeg and png
videos in the FATE suite, though unfortunately the bmp video is still
detected as an image since it has nb_frames = 0.
aliaspix streams are also now considered images.
Attached pictures are now treated like standalone images, so audio with
attached pictures now has mf-fps as container-fps instead of
unavailable, which makes it consistent with external cover art, which
was already being assigned mf-fps.
Unfortunately images in a codec commonly used for videos are never
detected, and detection was inaccurate even using the now private
codec_info_nb_frames field in AVStream, and mediainfo gets them wrong
too, so I guess it's just a lost cause.
|
| |
|
|
|
|
| |
The custom init script should be considered a configuration file, and
as such it should be ignored when the user wants vanilla mpv - and now
it is ignored with --no-config.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to [no-]input-default-bindings, but affects only
builtin bindings (while input-default-bindings affects anything which
config files can override, like scripting mp.add_key_binding).
Arguably, this is what input-default-binding should have always done,
however, it does not.
The reason we add a new option rather than repurpose/modify the
existing option is that it behaves differently enough to raise
concerns that it will break some use cases for existing users:
- The new option is only applied once on startup, while
input-default-bindings can be modified effectively at runtime.
- They affects different sets of bindings, and it's possible that
the set of input-default-bindings is useful enough to keep.
Implementation-wise, both options are trivial, so keeping one or the
other or both doesn't affect code complexity.
It could be argued that it would be useful to make the new option
also effective for runtime changes, however, this opens a can of
worms of how the bindings are stored beyond the initial setup.
TL;DR: it's impossible to differentiate correctly at runtime between
builtin bindings, and those added with mp.add_key_bindings.
The gist is that technically mpv needs/uses two binding "classes":
- weak/builtin bindings - lower priority than config files.
- "user" bindings - config files and "forced" runtime bindings.
input-default-bindings affects the first class trivially, but
input-builtin-bindings would not be able split this class further
at runtime without meaningful changes to a lot of delicate code.
So a new option it is. It should be useful to some libmpv clients
(players) which want to disable mpv's builtin bindings without
breaking mp.add_key_bindings for scripts.
Fixes #8809
(again. the previous fix 8edfe70b only improved the docs, while
now we're actually making the requested behavior possible)
|
| | |
|
| |
|
|
| |
This image has finally become public.
|
| |
|
|
|
| |
This was removed from common.h upstream since it was a cyclic
dependency. We need to re-import it into utils.h manually.
|
| |
|
|
| |
No longer needed with the bump to v3.104.
|
| |
|
|
|
| |
This is only needed for back-compat with libplacebo v2, and will break
due to upstream removal starting with libplacebo v4.
|
| |
|
|
| |
Switching to v3 allows us to drop the use of deprecated/removed members.
|
| |
|
|
|
|
|
|
| |
Currently using mpv --msg-level=help, shows an instance of --msglevel
(missing dash). Seems like the help message was only partially updated
with the -msglevel -> --msg-level transition.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, animation-end was handled at render(), however,
it's not called on idle, which resulted in state.anitype ~= nil, with
nothing to reset it during idle, which caused in an infinite tick()
loop (starts on first mouse move).
Now tick resets the animation on idle, and also, as a safety measure,
if we're past 1s after the animation deadline.
The safety measure is because the osc states are complex, and it's
easier to detect a "we really shouldn't be animating now" at tick()
itself rather than detecting the exact states where animation should
be reset. Generally, the safety mmeasure is not needed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 .
For unversioned 'lua.pc', use the name luadef51/luadef52 .
Autodetection remains the same (5.2 names, luajit, 5.1 names).
The old names are still supported, but not auto-detected.
Before this patch, if one wanted to choose a specific lua version when
more than one is installed, then the names were a mess, e.g. 51obsd is
also the name detected on Arch linux, and other (distro) names are
also not unique to a specific distro/platform.
So to ask mpv to choose the package name (specifically, the pkg-config
file name), one needs to look at the mpv sources and find the
(arbitrary) distro name which has the same lua version naming as they
do on their own system, e.g. --lua=51obsd on Arch. This is a pain.
Now we add generic names:
- luadef51/luadef52 - generic pkg-config lua.pc (version is inside).
- lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc
(the names are curated, e.g. --lua=foo won't detect foo.pc).
- The legacy names (e.g. 51deb) are still supported, but undocumented,
and the new generic names take precedence during auto-detection.
The fact that the generic names all start with "lua" has an additional
benefit that it shows right after "lua" at the output of mpv -v,
while the old names start with numbers, so they're first at the list,
making it hard to understand that e.g. "51obsd" is the lua version.
None of these names are actually used at the mpv code. The C code
checks the version using the lua headers (LUA_VERSION_NUM).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lua version names which are autodetected/chosen (such as "51deb")
are used for two things:
- as key for storing the pkg-config compile/link flags.
- as ID for config.h and elsewhere - they're sanitized to use "_".
Due to some inconsistensies, if the sanitized ID is different than
the original name, then the compile/link flags are stored with the
original name as key, while the retrieval happens with the sanitized
ID - and therefore fails to find the correct flags.
The solution is to use the original name only for display purpose at
the output of configure, while using the sanitized version for
everything else, so that storage and retrieval use the same key.
Currently there's no issue and the patch has no effect, because the
sanitizer considers all the current names as valid IDs.
However, the next commit will add names which the sanitizer modifies,
such as "lua-5.1", so this commit makes such names work too.
|
| |
|
|
|
|
|
|
| |
Unfortunately, this functionality in large part based on a struct
member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
|
| |
|
|
|
|
|
|
|
|
| |
This CI builder bases on openSUSE Tumbleweed, and recently had
its glibc updated. This led to new syscalls such as 'clone3' not
being allowed through the security layer.
Can be reverted after Github Actions updates their security policy.
actions/virtual-environments#3812
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes whether a video track is detected as an image. This is
useful for profile conditions, property expansion and lavfi-complex, and
is more accurate than any detection even Lua scripts can perform, since
they can't differentiate between images and videos without container-fps
and audio and with duration 1 (which is the duration set by the mf
demuxer with the default --mf-fps=1).
The lavf demuxer image check is moved to where the number of frames is
available for comparison, and is modified to check the number of frames
and duration instead of the video codec. This doesn't misdetect videos
in a codec commonly used for images (e.g. mjpeg) as images, and can
detect images in a codec commonly used for videos (e.g. 1-frame gifs).
pix files are also now detected as images, while before they weren't
since the condition was checking if the AVInputFormat name ends with
_pipe, and alias_pix doesn't.
Both nb_frames and codec_info_nb_frames are checked because nb_frames is
0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing
--demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4,
wmv3).
The duration is checked as well because for some uncommon codecs and
containers found in FFMpeg's FATE suite, libavformat returns nb_frames =
0 and codec_info_nb_frames = 1. For some of them it even returns
duration = 0, so they are blacklisted in order to never be considered
images.
The extra codecs that would have to be blacklisted without checking the
duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO,
AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO,
AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and
AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg.
The lower limit for duration is 10 because that's the duration of
1-frame gifs.
Streams with codec_info_nb_frames 0 are not considered images because
vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we
can't rely on just the duration to detect them because they could be
livestreams without an initial duration, and actually even if we could
for these codecs libavformat returns huge negative durations like
-9223372036854775808.
Some more images in the FATE suite that are really frames cut from a
video in an uncommon codec and container, like cine/bayer_gbrg8.cine,
could be detected by allowing codec_info_nb_frames = 0, but then any
present and future video codec with nb_frames = 0 and
codec_info_nb_frames = 0 would need to be added to the blacklist. Some
even have duration > 10, so to detect these images the duration check
would have to be removed, and all the previously mentioned extra codecs
and containers would have to be added added to the blacklists, which
means that images that use them (if they exist anywhere) will never be
detected. These FATE images aren't detected as such by mediainfo either
anyway, nor can a Lua script reliably detect them as images since they
have container-fps and duration > 0 and != 1, and you probably will
never see files like them anywhere else.
For attached pictures the lavf demuxer always set image to true, which
is necessary because they have duration > 10. There is a minor change in
behavior for which audio with attached pictures now has mf-fps as
container-fps instead of unavailable, but this makes it consistent with
external cover art, which was already being assigned mf-fps.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
Even if you add a video's file type to --mf-type and open it with the mf
protocol, only the first frame is used, so setting image to true is
still accurate.
When converting an image to the extensions listed in demux/demux_mf.c,
tga and pam files are currently the only ones detected by the mf demuxer
rather than lavf. Actually they are detected with the image2 format, but
it is blacklisted; see d0fee0ac33a.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, loading ~~/.init.js was inside a try block, in order to
quietly ignore errors if the file doesn't exist.
However, that also prevented any real errors from showing up even when
the file does exist, and the script continued as if everything is OK,
while in fact the custom init script didn't complete correctly.
Now we first check if the file exists, and then load it without
try/catch, so that any error shows up normally (and abort the script).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The value of the border option should always match what the actual state
of the window is. Previously if a compositor rejected the request by
mpv, it did not correct itself. Also add some code to keep track of
decoration requests. Anytime the state is changed, make the last saved
request again (doesn't hurt and seems like intuitive behavior).
Unfortunately, this isn't foolproof since options only send callback if
the value is changed. (ex. on sway if the floating window has no border,
and then is titled, setting the border value to "yes" does nothing since
tiling the window already set the border value to "yes").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes handle leak that happened whenever tvservice callback was invoked.
Powering on the TV causes HDMI unplug and attached events to be sent to
the tvservice callback.
This meant you could only power on/off your TV a finite number of times
before you were unable to allocate additional resources from VideoCore
(usually resulting in a "Could not get DISPMANX objects." error).
Furthermore because the VideoCore kernel driver does not cleanup handles
when a process dies, the only way to recover from the leak was to reboot
the RPI.
|
| |
|
|
|
|
|
|
|
|
|
| |
Because youtube-dl is inactive and the yt-dlp fork is becoming more
popular, make mpv use yt-dlp without any extra configuration.
yt-dlp is ordered before youtube-dl because it's more obscure, so users
who have yt-dlp installed are more likely to want to use it rather than
youtube-dl.
Fixes #9208.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In Linux kernel commit 819fbd3d8ef36c09576c2a0ffea503f5c46e9177
these two header files were moved to staging (though they've since
been moved out again by Linus.)
We do not actually use this, and it's in a state of maybe-removal
from the kernel as of Linux 5.14. Get rid of it; mpv still builds
fine without it, so it wasn't needed anyways.
Fixes #9233.
|
| |
|
|
|
|
|
|
|
| |
Without this, cases where the parser cannot return data right away
will end up utilizing the following fed packet's timestamps. This
will in turn cause an unnecessary offset in the audio stream
timestamps.
An example of such buffered parser in libavcodec is the EAC3 one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, timeBeginPeriod(1) was set once when mpv starts,
and the timers remained hi-res till mpv exits.
Now we do the same as before on Windows version < 10.
On Windows 10+ we now use timeBeginPeriod if needed, per timeout.
To force a mode regardless of Windows version, set env MPV_HRT:
- "always": the old behavior - hires timers as long as mpv runs.
- "perwait": sets 1ms timer resolution if timeout <= 50ms.
- "never": don't use timeBeginPeriod at all.
It was observed that on Windows 10 we lose about 0.5ms accuracy of
timeouts with "perwait" mode (acceptable), but otherwise it works
well for continuous timeouts (one after the other) and random ones.
On Windows 7 with "perwait": continous timeouts are accurate, but
random timeouts (after some time without timeouts) have bad
accuracy - roughly 16ms resolution instead of the requested 1ms.
Windows 8 was not tested, so to err on the side of caution, we keep
the legacy behavior "always" by default.
|
| |
|
|
|
|
|
|
|
| |
This brings enabled features on the same level as disabled and
auto-detected features by having both alternatives available.
Looking at the commit message of 652895abdce4bc1ff2f00c7f21c0d0d722680806
this seems to have been the intent from the start, but this specific
definition was missing from the option creation in Features.
|
| |
|
|
|
|
|
|
|
| |
In wayland_common, wl->window_size keeps track of the window's size when
it is not in the fullscreen or maximized state. GET_UNFS_WINDOW_SIZE is
meant to report the size except for when it is fullscreen (hence UNFS).
However, the actual function was merely returning the wl->window_size so
it was wrong for maximized windows. Workaround this by returning
wl->geometry instead when we have the maximized case. Fixes #9207.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its define (HAVE_FFMPEG_STRICT_ABI) is now utilized in a single
location, where an internal libavformat struct member is utilized.
This struct member is now (after around 10 years) finally removed
from public visibility in FFmpeg's master.
After a review of functionality, the information in bytes_read is
passed onto the demuxer layer, and then utilized for
{cache,hack}_unbuffered_read_bytes. This information is then utilized
for:
1. Calculation of bytes_per_second in demux/demux.c::update_cache,
which fills the information for properties "cache-speed" as well as
"raw-input-rate" (of which stats.lua is the most prominent user).
2. bytes_per_second also affects how often update_cache is called in
addition to the two locations it is called unconditionally in
(read_packet, demux_update).
In other words, the information provided does not appear to control
crucial mpv functionality, but rather its lack would seem to mostly
affect the speed of certain properties updating, or having valid
v |
