So the device buffer can be refilled quickly. Fixes dropouts in certain
cases: if all data is moved from the soft buffer to the audio device
buffer, the waiting code thinks it has to enter the mode in which it
waits for new data from the decoder. This doesn't work, because the
get_space() logic tries to keep the total buffer size down. get_space()
will return 0 (or a very low value) because the device buffer is full,
and the decoder can't refill the soft buffer. But this means if the AO
buffer runs out, the device buffer can't be refilled from the soft
buffer. I guess this mess happened because the code is trying to deal
with both AOs with proper event handling, and AOs with arbitrary
behavior.
Unfortunately this increases latency, as the total buffered audio
becomes larger. There are other ways to fix this again, but not today.
Fixes#818.
Apparently this can happen. So actually only return from waiting if ALSA
excplicitly signals that new output is available, or if we are woken up
externally.
This call was used limited the buffer size if installed RAM was below 16
MB. This stopped being useful a decade ago. The check could also
overflow on 32 bit systems. Just get rid of it.
This did not flush remaining audio in the buffer correctly (in case an
AO has an internal block size). So we have to make the audio feed thread
to write the remaining audio, and wait until it's done.
Checking the avoid_ao_wait variable should be enough to be sure that all
data that can be written was written to the AO driver.
This code handles buggy AOs (even if all AOs are bug-free, it's good for
robustness). Move handling of it to the AO feed thread. Now this check
doesn't require magic numbers and does exactly what's it supposed to do.
Until now, we've always calculated a timeout based on a heuristic when
to refill the audio buffers. Allow AOs to do it completely event-based
by providing wait and wakeup callbacks.
This also shuffles around the heuristic used for other AOs, and there is
a minor possibility that behavior slightly changes in real-world cases.
But in general it should be much more robust now.
ao_pulse.c now makes use of event-based waiting. It already did before,
but the code for time-based waiting was also involved. This commit also
removes one awkward artifact of the PulseAudio API out of the generic
code: the callback asking for more data can be reentrant, and thus
requires a separate lock for waiting (or a recursive mutex).
uint_least32_t could be larger than uint32_t, so the return values of
mp_ring_get_wpos/rpos must be adjusted. Actually just use unsigned long
as type instead, because that is less awkward than uint_least32_t.
This was originally added because we thought this would make a good
portable audio API, which would give us good behavior on Windows, Linux,
and OSX. But this hope was disappointed: it's not reliable enough (nice
deadlocks on Linux when seeking, i.e. resetting the audio device),
doesn't have enough features (no channel maps, no digital passthrough),
and in general just is not very good.
There were subtle and minor race conditions in the pull.c code, and AOs
using it (jack, portaudio, sdl, wasapi). Attempt to remove these.
There was at least a race condition in the ao_reset() implementation:
mp_ring_reset() was called concurrently to the audio callback. While the
ringbuffer uses atomics to allow concurrent access, the reset function
wasn't concurrency-safe (and can't easily be made to).
Fix this by stopping the audio callback before doing a reset. After
that, we can do anything without needing synchronization. The callback
is resumed when resuming playback at a later point.
Don't call driver->pause, and make driver->resume and driver->reset
start/stop the audio callback. In the initial state, the audio callback
must be disabled.
JackAudio of course is different. Maybe there is no way to suspend the
audio callback without "disconnecting" it (what jack_deactivate() would
do), so I'm not trying my luck, and implemented a really bad hack doing
active waiting until we get the audio callback into a state where it
won't interfere. Once the callback goes from AO_STATE_WAIT to NONE, we
can be sure that the callback doesn't access the ringbuffer or anything
else anymore. Since both sched_yield() and pthread_yield() apparently
are not always available, use mp_sleep_us(1) to avoid burning CPU during
active waiting.
The ao_jack.c change also removes a race condition: apparently we didn't
initialize _all_ ao fields before starting the audio callback.
In ao_wasapi.c, I'm not sure whether reset really waits for the audio
callback to return. Kovensky says it's not guaranteed, so disable the
reset callback - for now the behavior of ao_wasapi.c is like with
ao_jack.c, and active waiting is used to deal with the audio callback.
We don't need to combine __sync_add_and_fetch with a memory barrier,
since these intrinsics are documented as using a full barrier already.
Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives
atomic_fetch_add() the correct return value (although we don't use it).
Use __sync_fetch_and_add to emulate atomic_load(). This should enforce
the full barrier semantics better. (This trick is stolen from the
FreeBSD based stdatomic.h emulation.)
In most places where af_fmt2bits is called to get the bits/sample, the
result is immediately converted to bytes/sample. Avoid this by getting
bytes/sample directly by introducing af_fmt2bps.
The i_bps members of the sh_audio and dev_video structs are mostly used
for displaying the average audio and video bitrates. Keeping them in
bits-per-second avoids truncating them to bytes-per-second and changing
them back lateron.
This is incomplete; the video chain will still hold some vaapi objects
after destroying the decoder and thus the vaapi context. This is very
bad. Fixing it would require something like refcounting the vaapi
context, but I don't really want to.
mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each
of these has emulation wrappers. The wrappers are usually slower and
have fewer features than their native opposites. In particular the libva
vdpau driver is practically unmaintained.
Check the vendor string and print a warning if emulation is detected.
Checking vendor strings is a very stupid thing to do, but I find the
thought of people using an emulated API for no reason worse.
Also, make --hwdec=auto never use an API that is detected as emulated.
This doesn't work quite right yet, because once one API is loaded,
vo_opengl doesn't unload it, so no hardware decoding will be used if the
first probed API (usually vdpau) is rejected. But good enough.
So, basically this worked only with streams that were not local files,
because stream_dvd.c "intercepts" local files to check whether they
point to DVD images. This means if a stream is not writeable, we have to
try the next stream implementation.
Unbreaks 2-pass encoding.
Sometimes, Matroska files store monotonic PTS for h264 tracks with
b-frames, which means the decoder actually returns non-monotonic PTS.
Handle this with an evil trick: if DTS is missing, set it to the PTS.
Then the existing logic, which deals with falling back to DTS if PTS is
broken. Actually, this trick is not so evil at all, because usually, PTS
has no errors, and DTS is either always set, or always unset. So this
_should_ provoke no regressions (famous last words).
libavformat actually does something similar: it derives DTS from PTS in
ways unknown to me. The result is very broken, but it causes the DTS
fallback to become active, and thus happens to work.
Also, prevent the heuristic from being active if PTS is merely monotonic
instead of strictly-monotonic. Non-unique PTS is broken, but we can't
fallback to DTS anyway in these cases.
The specific mkv file that is fixed with this commit had the following
fields set:
Muxing application: libebml v1.3.0 + libmatroska v1.4.1
Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...]
But I know that this should also fix playback of mencoder produced mkv
files.
When Lua itself prints errors such as:
Error: [string "mp.defaults"]:387: syntax error near 'function'
It's unclear why the location is prefixed with "string ". And for some
reason, it disappears if you prefix the name with '@'. I suppose this is
done for the sake of luaL_loadstring. With the '@' prefix added, the
output is now:
Error: mp.defaults:387: syntax error near 'function'
We pass a pointer to a GLint to sscanf, using the %d format. That format
_always_ takes int, and not GLint (whatever the heck that is). If GLint
is always int, then it doesn't make a difference, but is still better
because it doesn't play russian roulette with pointers.
Don't emit "hard" references to OpenGL functions. Always use the
platform specific function to lookup OpenGL functions, such as
glXGetProcAddress() with GLX (x11).
This actually fixes the build if only Wayland is enabled (e.g. using
--disable-gl-x11 on Linux).
Note that some sources claim that wglGetProcAddress() (win32) does not
return function pointers for OpenGL 1.1 functions (even if they are
valid and necessary in OpenGL 3.0). But if that happens, the fallback
employed in gl_w32.c/w32gpa() should catch this.
Setting this property was added 12 years ago, and the code was always
incorrect. The underlying data type is "long", not "pid_t". It's well
possible that the data types are different, and the pointer to the pid
variable is directly passed to XChangeProperty, possibly invoking
undefined behavior.
It's funny, because in theory using pid_t for PIDs sounds more correct.
Binding multiple commands at once where always considered not
repeatable, because the MP_CMD_COMMAND_LIST wasn't considered
repeatable.
Fixes#807 (probably).
These are actually already included in osdep/io.h, but I think it's
cleaner to repeat them in the file where they are actually needed.
(osdep/io.h needs to have them for other reasons.)
Commit e2e450f9 started making use of luaL_register(), but OF COURSE
this function disappeared in Lua 5.2, and was replaced with a 5.2-only
alternative, slightly different mechanism.
So just NIH our own function. This is actually slightly more correct,
since it forces the user to call "require" to actually make the module
visible for builtin C-only modules other than "mp". Fix autoload.lua
accordingly.
This will load other files in the same directory when a single file is
played. It's an often requested feature, but we definitely don't want it
in the core.
We need this only because Lua's stdlib is so scarce. Lua doesn't intend
to include a complete stdlib - they confine themselves to standard C,
both for portability reasons and to keep the code minimal. But standard
C does not provide much either.
It would be possible to use Lua POSIX wrapper libraries, but that would
be a messy (and unobvious) dependency. It's better to implement the
missing functions ourselves, as long as they're small in number.
A playlist_move command that moves an entry onto itself (both arguments
have the same index) should do nothing, but it did something broken. The
underlying reason is that it checks the prev pointer of the entry which
is temporarily removed for moving.
wm4
Paweł Forysiuk
Marcoen Hirschberg
ChrisK2
Rudolf Polzer
Martin