ASS must only automatically break at ASCII spaces (\x20), but other
subtitle formats might expect more breaking oppurtinities.
Especially non-ASS subs in scripts, which typically do not use (ASCII)
spaces to seperate words, like e.g. CJK, might overflow the screen
if the conversion didn't insert additional linebreaks (ffmpeg does not).
Thus try to enable Unicode linebreaking for converted subs and the OSD
if libass is new enough. The feature may still be unavailable at runtime
if libass wasn't build with Unicode linebreaking support.
Previously, running a debug build of mpv would crash with this output
when preinit() at vo_libmpv.c:732 calls control(vo, VOCTRL_PREINIT, NULL):
Swift/Optional.swift:247: Fatal error: unsafelyUnwrapped of nil optional
This comes from this line of code:
var data = UnsafeMutableRawPointer.init(bitPattern: 0).unsafelyUnwrapped
Unsafely unwrapping a UnsafeMutableRawPointer.init has always been UB,
but the Swift runtime began asserting on it in debug builds a couple macOS
versions ago.
Previously we would only call list_devs() on available AOs if an AO
*did not* have a hotplug_init() callback or for the first one that *did*
have it.
This is problematic when multiple fully functional hotplug-capable AOs
are available.
The second one would not be able to contribute discovered devices.
This problem prevents ao_pipewire from introducing full hotplug support
with hotplug_init().
When a platform has multiple valid AOs that can provide hotplug events
we should try to use the one that also provides playback.
Concretely this will help when introducing hotplug support for
ao_pipewire.
Currently ao_pulse is probed by ao_hotplug_get_device_list() before
ao_pipewire and on the common setups where both AOs could work pulse
will be selected for hotplug handling.
This means that hotplug_init() of ao_pipewire will never be called and
list_devs() has to do its own initialization.
But if ao_pulse is non-functional or not compiled-in suddenly
ao_pipewire *must* implement hotplug_init() for hotplugging events to
work for all.
Also if the hotplug ao_pulse connects to a PulseAudio instance that is
not emulated by the same PipeWire instance as the playback ao_pipewire
the hotplug events are useless.
30 characters are not a lot.
Also when the name is calculated from the allocation site the line
number will be the at the end of the name, so truncating it is
especially inconvenient.
I'm adding support in ffmpeg for the XV36 format which will be used
by VAAPI for 12bit 4:4:4 content. It's an undefined-alpha channel
variant of Y412 which is itself a 12bit+4bits padding variant of Y416.
We currently have a repacker for full four channel cccc16, and for
three channel ccc16, but nothing for ccc16x16 with the undefined alpha
channel.
It's simple enough to add one using the existing macros.
uau did some investigation and noticed that we do not send a wakeup
event when we encounter end-of-stream in ao_read_data(), in contrast to
the equivalent logic for push AOs in ao_play_data().
Inserting that wakeup fixes the original problem of lack of
reinitialization on a format change without the problems we saw with
the previous attempted fix.
Fixes#10566
We have previously had a problem where pull AOs (such as pipewire)
would not reinitialize on a format change when going between two
audio-only files. In such a situation, playback would stop after the
first file.
We initially attempted to fix this by explicitly draining on EOF, which
solves that problem but introduces a blocking step where we don't
actually want one, breaking gapless audio, and causing dropped frames
at the end of playback for files with video in them too.
So, let's undo these changes and do something better in the next
commit.
The error description in #10545 could indicate that we are overflowing
we are corrupting the buffer metadata ourselves through out-of-bound
writes.
This check is also present in pw-cat so it seems to be expected for
b->requested to exceed the actual available buffer space.
Potential fix for #10545
52aed495cb ("audio: drain ao on EOF") introduced logic to drain an AO
when EOF of the input has been reached.
When no AO however is present this leads to a NULL-dereference.
Fixes#10556
Facing down the multitude of ways to somehow wrangle the get_fn pointer
out of the GL environment and into libplacebo, I decided the easiest is
to just store it inside the GL struct itself.
The lifetime of this get_fn function is a bit murky, since it's not
clear on whether or not it survives the VO init call (especially in the
case of the GL render API, which explicitly states that parameters do
not need to survive the call they're passed to), so just add a
disclaimer.
(It's fine for us to use like this because `gpu_ctx_create` is still
part of VO init)
Closes https://code.videolan.org/videolan/libplacebo/-/issues/216
Guido Cella
Leo Izen
Niklas Haas
Oneric
rcombs
DeadNews
Christoph Heinrich
Thomas Weißschuh
Philip Langdale
Vitaly Zaitsev
Cairn
25792431
Tillmann Karras
sfan5
Avi Halachmi (:avih)
enly1
Owen Rafferty
The-head-obamid