The first set iterates through all standard FFmpeg layouts and
checks that those which fit MP_NUM_CHANNELS succeed.
The second set iterates through built-in named channel layouts,
and attempts to convert them to AVChannelLayouts.
This is the new FFmpeg channel layout structure, which now
combines channel count and layout into a single location.
Only unspecified (channel count only) and native (channel layout
mask based) layouts are currently supported for the initial move
towards non-deprecated APIs.
This shouldn't have mattered but apparently qtile is unable to get the
app id if you set it after the initial surface commit. Wayland is a mess
anyway so just shuffle this around so that the frame callback and
surface commit are the last things registered in vo_wayland_init. This
works around qtile and, in theory, doesn't appear to break anything
else. Fixes#10280.
Some wayland compositors (i.e. weston) get extremely picky about
committed buffer sizes not matching the configured state. In particular,
weston throws an error on you if you attempt to launch with
--window-maximized and use opengl (vo_vaapi_wayland actually errors as
well in this case, but that's a different issue). The culprit here is
actually wl_egl_window_create. This creates an initial buffer at the
sizes passed in the arguments which is what weston doesn't like.
Instead, move the egl_window creation call to the resize function. This
ensures that mpv is using the size obtained via the toplevel event, and
it should always be the buffer size we want.
The `absolute` value was incorrectly labelled as the default instead of
the value named `default`, which was somewhat confusing. When the newer
default option was added in 679e410 it seems like wm4 forgot to remove
the label in the manual on the previous default.
TL;DR: previously a JavaScript VM was created + destroyed whenever
a sub track was initialized, even if no jsre filter was set.
Now a JS VM is created only if jsre filters were set.
Sub filters are initialized once when a subtitle track is chosen, and
then whenever the sub track changes or when some sub options change.
Sub filters init is synchronous - playback is suspended till it ends.
A filter can abort init early (get disabled) depending on conditions
specific to each filter. The regex and jsre filters aborted early
if the filter is disabled (default is enabled) or if the track is not
ass (relativey rare, e.g. bitmap subs).
The init then iterates over the filter strings, and if the result is
empty (common - no filter was added, but also if all strings failed
regex init) then it's also aborted during init.
While this iteration step is cheap with filter regex, with jsre it
requires instanciating the JS VM (mujs) in advance in order to parse
the filter strings at the list, and the VM is then destroyed if the
list ends up empty.
This VM create+destroy is fast but measurable (0.2 - 0.7 ms, slowest
measured on 2010 MacBook Air), but can be avoided altogether if we
check that the filter list is not empty before we create the VM.
So now we do just that.
This way mingw-w64 becomes the first CI workflow to build gpu-next.
Unfortunately, currently neither wscript or meson has gpu-next or
libplacebo-next as an option that one can require.
This was actually always bugged, but we just got lucky that compositors
ignored it. The egl window was created only using wl->geometry's
coordinates but those do not include the scale factor. So technically,
the initial window creation always had the wrong size (off by whatever
the scaling factor is). The resize call later fixes it because that
correctly uses wl->scaling so in practice nothing bad was seen.
wlroots's master branch has started sending an error in this case
however and this is what trips it. Fix it correctly by using the scale
factor. This is what cd3b4edea0 tried to
fix (but was incorrect).
cd3b4edea0 is not correct and had some
unexpected breakage with geometry/resizing. Rather than completely
revert it, this commit restores the set_surface_scaling call as well as
rearranges some other things in the wayland init/reconfig process to
make it simplier. The next commit properly fixes what
cd3b4edea0 tried to fix.
Just a couple of small changes. First, the obvious one is to remove the
bogus wl->window_size = wl->vdparams; line in the configure conditional.
The reconfig always unconditionally sets the window_size here so there's
no need to duplicate it. The more important change is to remove the
usage of set_surface_scaling. This function is just to handle when
scaling changes and for setting the initial scale, it was called in the
reconfig. This, however, causes some weird issues in the latest
sway/wlroots where it can try to divide a buffer by an inappropriate
scale factor. This is possibly due to some weird ordering of events and
only occured in opengl for some reason.
Luckily, it turns it out it's not neccessary to set the scaling here at
all. The surface enter event is already setup to handle scale changes.
On an HIDPI display, mpv will initially assume a scale of 1 but the
surface actually enters the wl_output, it will automatically readjust
and resize itself to the appropriate scale value. This works on the
initial launch of the mpv window as well, so there's no need to special
case this in the reconfig event. This has the nice bonus of avoiding
that sway/wlroots issue as well since the buffer_scale is set much
later. Fixes#10263.
One downside of this approach is that it bypasses the mixer cache, but
while this is not ideal for performance reasons, the status quo is also
simply broken so I'd rather have a slower implementation that works than
a faster implementation that does not.
And as it turns out, updating the OSD state and invalidating the mixer
cache correctly is sufficiently nontrivial to do in a clean way, so I'd
rather have this code that I can be reasonably certain does the right
thing.
Fixes#9923 as discussed. Also fixes#9928.
This is mainly for other user scripts that may conflict with the osc
logo in some way. Although it is possible to listen for
shared-script-properties, this has many edge cases that could easily pop
up. A user could want other OSC things to happen at the same time (say
osc-message). They just don't want the logo. The idlescreen option
disables all idlescreen related things (including the santa hat) if it
is set to "no". A new script message (osc-idlescreen) is also added so
users can easily toggle the value (passing "cycle" or just explictly
setting "yes" or "no"). Some more discussion on this is found in the
below github issues.
https://github.com/mpv-player/mpv/issues/10201https://github.com/CogentRedTester/mpv-file-browser/issues/55
Apparently _t names are reserved, and in this case it wasn't very
useful anymore (it was useful while developing it, but this code is
almost 10 years old now).
Fixes a compilation error on Solaris.
The wayland stuff is designed to update/rescale itself whenever the
wl_output scale changes. This is great, but vo_vaapi_wayland should not
actually attempt to handle any hidpi stuff. The point of this VO is to
hand off as much to the compositor as possible, so we do want the
compositor to do the scaling here (enjoy your bilinear). This fixes some
incorrect rendering that could occur with scaling values not equal 1 due
to mismatches between buffer coordinates and the surface local
coordinates. It also eliminates the need to specify
--no-hidpi-window-scale on hidpi displays (has the same practical
effect).
A bad person (AKA me) merged this stuff without paying close enough
attention to the code style. Reformat this to be in-line with the rest
of the wayland code and general mpv style (braces for functions on the
next line, horizontally aligning arguments, some cosmetic cleanups for
wayland_common.h, etc.).
So it turns out that mpv already has an mp_tag_str which makes a
readable string out of fourccs (drm formats are these).
drm_format_string, on the other hand, has a ton of baggage with having
to check different libdrm versions for certain headers, adding
compile-time defines (because there are no version defines in the libdrm
headers), etc. It's a lot simpler to just use what mpv already has and
it returns what you actually care about: i.e. is this format supported
or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
If the player is started with --idle and the osc-tracklist script-message
is called then the tracks_osc table will be nil,
which caused the OSC to crash due to attempting to index a nil value.
This appears to be because the osc_tracklist variable is both
initialised and updated by (ultimately) the render() function, which
is not run when the player is idling.
Rather than mess with the existing OSC logic it's easier to either
add this single check, or alternatively to initialise the the tracks_osc
table somewhere before this.
Both mpv's main function and the client API use mp_initialize to start
up. In general, these work the same however the client API had one
slight, unnecessary limitation: you can't start it up with idle=no. In
practice, the libmpv profile (used with the client API) sets idle to
yes, so it's rarely encountered, but there's no particular reason why
this policy needs to be enforced. It turns out that mp_initialize does a
quick check to see if there are any entries in the playlist and if idle
mode is set. If not, it prints the help message and exits. Basically,
it's just the part that handles the terminal message when you type "mpv"
with no arguments. Unfortunately with idle=no, the client API also hits
this code path, exits prematurely with 1 and thus returns an API error.
Fortunately, the fix is very simple. If the client API is used instead
of the "normal" mpv executable, then the mp_initialize function gets a
NULL for the options argument. When starting mpv from the terminal (when
you would want to see the before mentioned help text), there will always
be at least an argv[0] (the mpv executable name itself) so we can
reliably distinguish between the two. The other case where there could
be no argv is if the pseudo-gui profile is used, but this always
enforces idle so we don't have to worry about it either. In other words,
with this combination of conditions (options, no idle, and no playlist
entries), we can be sure this is from a user calling mpv in the terminal
with no arguments. Therefore, other cases can be allowed which means
client API users can initialize with idle=no. Fixes#10162.
Normally with the keep-open option, mpv is supposed to set the
eof-reached property to true so clients can possibly do interesting
things at this step. However, there was actually an edge case where this
property notification did not occur. If you use keep-open and then seek
in the file past the end (so mpv stops), property notification is not
actually sent in this case. Internally, mpv does a very exact seek at
this step which also ends playback, but it does not set STATUS_EOF to
the ao and vo before the core idle state is updated. To fix this edge
case, it's simply just a matter of explictly setting STATUS_EOF after
seek_to_last_frame in handle_keep_open. This logic will only ever
trigger if keep-open is being used and the seek goes past the end of the
file, so we know that there will always be an EOF here.
5774ce759a added the new output name event
and used them for the --fs-screen-name option. It turns out that the
display-names property could also make use of these names, so go ahead
and use output->name in this case if we have them. If not, fallback to
output->model like before.
Windows is weird and symbols weren't actually being exported. This is
because __GNUC__ is defined and picked up in the conditional, but
__attribute__((visibility("default"))) doesn't actually export anything
to the dll. Instead, just check if we have win32 defined first and then
always set __declspec(dllexport). Fixes#10171.
ffmpeg 5.1 adds support for IPFS (the ipns:// and ipfs:// protocols).
This patch enables those protocols to be fist-class citizens in mpv.
Thus allowing for playing IPFS resources on mpv like:
"mpv ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T"
Some compiler flags were passed to mpv in order to get it to build as a
gui application on windows. However on the meson build, this always
resulted in mpv being built as a console application. This is because
the function for making executables in meson specifically has a kwarg
called win_subsystem* which defaults to 'console'. That always added
link arguments at the end which compiled mpv.exe as a console
application. The correct thing to do is to remove all of the
subsystem-related flags in the meson build and use the win_subsystem
kwarg as intended by setting it to 'windows,6.0'. For mpv.com, we can
remove the -Wl,--subsystem,console flag since meson will set this by
default in that executable. This makes mpv.exe function correctly and
open with the pseudo-gui while mpv.com acts as a console wrapper.
1a0603835e
These values and options were simply never looked at in the drm egl
context. This pretty much is just a copy and paste of what is in vo_drm.
Fixes#10157.
Jan Ekström
Dudemanguy
Sagnac
Avi Halachmi (:avih)
AtticFinder65536
Niklas Haas
Simon Ser
Wessel Dankers
Aaron Boxer
Julian Orth
Emanuele Torre
CogentRedTester
Guido Cella
Mark Gaiser
Leo Izen