The test ended up failing if cuda.h wasn't present, even if cuda.h
isn't used during the actual build.
This test is attempting to establish if the ffmpeg being built
against has dynlink_cuda support. While it might theoretically be
possible to build against the older normally-linked-cuda version
of ffmpeg, it seems more trouble than it's worth.
For some reason, some types of accesses didn't warn, for example when
using mp.observe_property() in Lua. This was because the deprecation
handling code explicitly checks certain accesses. I'm not quite certain
why it was done this way. Just make it warn always.
This could be backported to the current release, if we cared.
This was a typo in the extensiuon spec and was probably always broken.
Could have led to broken builds when used with ancient ANGLE headers
(or possibly generic EGL headers).
The latest 375.xx nvidia drivers add support for P016 output
surfaces. In combination with an ffmpeg change to return those
surfaces, we can display them.
The bulk of the work is related to knowing which format you're
dealing with at the right time. Once you know, it's straight forward.
As threatened by the API changes document.
We can actually keep the deprecated --playlist-pos and --cache options,
since they are aliases and not used by the corresponding properties.
They are inconsistent, but do no harm. Keep them for now for the sake of
the command line user.
mpv_identify.sh partially stopped working, because it was never updated.
The shell magic can't deal with property names that contain "/", so we
can't replace "samplerate" with "audio-params/samplerate" - just remove
these properties. (How about you use ffprobe?)
As threatened by the API changes document.
This commit also removes or stubs equivalent calls in IPC and Lua
scripting.
The stubs are left to maintain ABI compatibility. The semantics of the
API functions have been close enough to doing nothing that this probably
won't even break existing API users. Probably.
At least with Nvidia drivers, some thread tries to access D3D11 objects
after ANGLE unloads d3d11.dll. Fix this by holding a reference to
d3d11.dll ourselves.
Might fix the crash in #3348. (I wish I knew why though.)
Since the recent release was named 0.22.0 instead of 0.21.1, bump all
mentions of 0.22.0 to 0.23.0. These were planned removals of deprecated
versions, which obviously didn't happen in 0.22.0.
Run "playlist-remove current" while the last playlist entry is being
played stopped playback. Fix this and return to the first entry instead.
Fixes#3808.
If video reaches EOF, subtitle timing will be switched to timing without
video frames. This means it calls osd_set_force_video_pts() and
overrides the PTS of whatever video frame is current (since the video
frame's PTS has nothing to do with the current playback position
anymore).
This was not reset when seeking back into video. Subtitles wouldn't show
up, or if there was a subtitle displayed, it would get stuck with it. In
particular, this could happen even if EOF was only temporary (such as
with --keep-open).
Fix this by clearing the override PTS whenever a video frame is shown.
Fixes#3770.
- win32-console-wrapper.c was inconsistently using the explicit Unicode
versions of some Windows API functions and structures.
- vo.c should use llabs for int64_t, since long is 32-bit on Windows.
- vo_direct3d.c had a potential use of an uninitialized variable if it
took the first goto error_exit.
This fixes the build in mingw-w64/Clang on MSYS2. It also disables the
use of gnu_printf in Clang, which was what was causing most of the
warnings. The Clang-compiled mpv binary appears to work, but there are
no guarantees yet, since until now mpv has only been tested with
mingw-w64/GCC on Windows.
Fixes#3800
This fixes waf setting the wrong LIBDIR for DEST_OS=win32 in
waflib/Tools/c_config.py:get_cc_version()
Any scripts assuming the implib and pkgconfig are in the wrong
place should be changed to move the .dll instead.
We're too lazy to maintain a full changelog, but there are still a bunch
of places which document specific changes. A user really should check
them on each update, even if there are transition periods (including
printing warnings etc.) for most changes. It's a good idea to give them
more exposure by adding them to the README.
The "default" entry (which is and always was mpv/mplayer's default) does
not have a description set in the ALSA API. (While "sysdefault"
strangely has.)
Instead of an empty description, this should show something nice, so
reuse the ao.c code for naming default devices (see previous commit).
It's still a bit ugly that audio-device-list will have a default entry
for "Autoselect device" and "Default (alsa)", but then again we probably
want to allow the user to force ALSA (i.e. prevent fallbacks to other
AOs) just because ALSA is so flaky and makes this a legitimate feature.
This will make it easier for AOs to add explicit default device entries.
(See next commit.)
Hopefully this change doesn't lead accidentally to bogus "Default"
entries to appear, but then it can only happen if the device ID is
empty, which would mean the underlying audio API returned bogus entries.
Use the device name as fallback. This is ugly, but still better than
skipping the description entirely. This can be an issue on ALSA, where
the API can return entries without proper description.
Deactivating this options makes it possible to
circumvent the default OS X behavior of using
points. Windows on HiDPI resolutions won't open
in double the size anymore and videos are display
in their native resolution when windowed.
Fixes#3716
av_reduce(&num, &den, 1, 14112000, 1000000) can return num=0, den=1.
This means a 1/14112000 timebase (as used by the mp3 demuxer) would
become invalid.
The intention of mp_get_codec_timebase() is to always return a valid
timebase. av_reduce() probably does the logically correct thing - so add
a fallback to the safe default timebase.
Also, increase the av_reduce() parameter to INT_MAX. Let's just pray
this doesn't cause any actual problems. libavformat does the same, but
might be in a different position due to using av_rescale() etc., while
we convert between fractional timestamps and floats.
This is a bit unintuitiv, but it appears hwdec backends have to unset
hwdec_priv manually in their uninit function. Normally with this idiom
you'd expect the common code to do this (and maybe even freeing the priv
struct). Since other hwdec backends do this quite consistently, just fix
vdpau for now.
Also add an assert to detect similar bugs sooner.
Fixes#3788.
The previous commit means subtitles were reinitialized on every seek
(even within a segment). This commit restores the old behavior.
To check whether the segment changed at all, we don't reset the current
start/end values. This assumes the decoder wrapper is always fed by a
stream which doesn't mix segment and non-segment packets, which is
currently always true.
This is needed to put the decoders into the correct state. In
particular, decoders will not initialize the current segment without
this flag. The intention of not setting the flag for seeks within the
segments were to avoid costly decoder reinits, but it seems this is
better handled explicitly in the decoder wrappers.
