duration and position properties were observed as double which lead to a
lot of updates per second (high granularity). it is recommended to not
update the position of the touchbar too frequently, why we had a manual
1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
duration and position properties were observed as double which lead to
a lot of updates per second (high granularity). it is recommended to not
update the position of the remote command center to frequently, why we
had a manual 1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
generated with the Icon Composer project:
actool ./icon.icon \
--compile ./ \
--app-icon icon \
--enable-on-demand-resources NO \
--development-region en \
--target-device mac \
--platform macosx \
--include-all-app-icons \
--minimum-deployment-target 10.15 \
--output-partial-info-plist /dev/null \
--standalone-icon-behavior all
actool will generate an Assets.car file which is compatible with all the
new Theme variants of macOS 26 (default, dark, monochrome, tinted, etc).
it also generates an old icns file as a fallback, only default style.
since the new Assets.car file can't be used from cocoa directly, without
using private APIs, we still use the icns file when used from CLI.
this also means that from CLI only the default icon is used and the
macOS theming doesn't have any effect.
the macOS theming mechanism only works with the bundle and a Assets.car
file. all icons are generated on the fly depending on the Theme. this
generation has no public API and the mechanism would need to be
replicated by hand. to replicate this behaviour at least three different
icns would need to be generated, tinting needs to be implemented,
several system events need to be subscribed, and this wouldn't guarantee
the same look as the system mechanism. also none of the tools make it
possible to generate macOS 26 compatible icns file, besides for the
default file, since it at least is missing the necessary padding.
This reverts commit e9c43258b8.
yt-dlp implemented its own parsing to extract chapters from the
descriptions of videos without chapter markers in the player over 3
years ago in https://github.com/yt-dlp/yt-dlp/commit/0fe51254 (the PR is
even inspired by mpv). Actually it was present even earlier in
youtube-dl but was removed for unknown reasons in
https://github.com/ytdl-org/youtube-dl/commit/67299f23d8b1894120e875edf97440de87e22308.
So we can remove our parsing code, as it is dead code that never runs if
yt-dlp's JSON already contains chapters.
And it seems that such videos without chapter markers are rare or
non-existing by now anyway - we can't find any.
https://www.youtube.com/watch?v=1v_4dL8l8pQ is linked from the yt-dlp PR
with the above commit, but now yt-dlp returns the Key moments as
chapters, so it can't be used for testing.
Our parsing was actually worse than yt-dlp's, because #16085 added an
option to disable it to fix the misdetection reported in #16081, but
yt-dlp correctly returns no chapter for that video
(https://www.youtube.com/watch?v=1v_4dL8l8pQ). So this code branch was
only running for misdetections, and by removing it that option is not
needed.
This adds option `--audio-set-media-role` to configure whether mpv
should set media roles to supported audio APIs or not. Disabled by
default.
By default, WirePlumber restores the volume of each application to
whatever the last application with the same media role used. This is
completely insane behavior, and I couldn’t find any way for a user to
opt out of it on my end. The `state-stream.lua` script responsible for
this mess only uses media.role if the property is present, so the only
reliable workaround is simply not to set one at all.
This WirePlumber behavior is inherited from PulseAudio, which also
exhibits the same behavior to this day.
This commit also mirrors the same change made to ao_pulse in 2015:
b7325b2f64
See also: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know when the layer is opaque and direct-to-display is
possible.
log opaque state.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which EDR data is used/mapped to.
log EDR data changes to actually see which EDR data was chosen.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which colorspace is used/mapped to.
log colorspace changes to actually see which colorspace was chosen.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which pixel format is used/mapped to.
log pixel format changes to actually see which format was chosen. only
those 9 formats are valid for a CAMetalLayer.
https://developer.apple.com/documentation/quartzcore/cametallayer/pixelformat
playlist-remove has a required index argument, as indicated by the
documentation. However, in 332907e1d7
MP_CMD_OPT_ARG was mistakenly added, making it optional.
The effect of not specifying the argument is defaulting the index to 0
and always removing the first element in the playlist, which is not
expected.
Fix this by making the argument required.
Fixes: 332907e1d7
Unfortunately we don't have control over libplacebo and cannot
synchronize such changes, so just return `<unknown>` to be forward
compatible with any possible changed.
Note that this should be updated ASAP to support new values.
Previously this would be called on every frame presented, this only
needs to be called if display sync was active for the last frame but
isn't active anymore.
This hid the bug mentioned in #16947 if VO was active.
llyyr