This helps the filter to adapt much faster to speed changes. Before this
commit, the filter just converted and output the full input frame, which
could cause problems with large input frames. This was made worse by
certain filters like dynaudnorm or loudnorm outputting pretty large
frames.
This commit changes the filter from trying to convert all input at once
to only outputting a single internally filtered frame. Internally, this
filter already output data in units of 60ms by default (controlled by
the "stride" sub-option), and concatenated as many output frames as
necessary to consume all input.
Behavior is still kind of bad when inserting the filter. This is because
the large frames can be buffered up after the insertion point, so the
speed change will be performed with a larger latency. The scaletempo
filter can't do anything against this, although it can be fixed by
inserting scaletempo as user filter as part of --af.
This commit introduces the multiply-pitch af-command. Users may bind
keys to this command in order to incrementally adjust the pitch of a
track. This will probably mostly be useful for musicians trying to
transpose up and down by semi tones without having to calculate
the correct ratio beforehand.
As an example, here is an input.conf to test this feature:
{ af-command all multiply-pitch 0.9438743126816935
} af-command all multiply-pitch 1.059463094352953
The future direction might be not having such a user-visible filter at
all, similar to how vf_scale went away (or actually, redirects to
libavfilter's vf_scale).
This is part of trying to get rid of --af-defaults, and the af
resample filter.
It requires a complicated mechanism to set the defaults on the resample
filter for backwards compatibility.
This does what af_volume used to do. Since we couldn't relicense it,
just rewrite it. Since we don't have a new filter mechanism yet, and the
libavfilter is too inconvenient, do applying the volume gain in ao.c
directly. This is done before handling the audio data to the driver.
Since push.c runs a separate thread, and pull.c is called asynchronously
from the audio driver's thread, the volume value needs to be
synchronized. There's no existing central mutex, so do some shit with
atomics. Since there's no atomic_float type predefined (which is at
least needed when using the legacy wrapper), do some nonsense about
reinterpret casting the float value to an int for the purpose of atomic
access. Not sure if using memcpy() is undefined behavior, but for now I
don't care.
The advantage of not using a filter is lower complexity (no filter auto
insertion), and lower latency (gain processing is done after our
internal audio buffer of at least 200ms).
Disavdantages include inability to use native volume control _before_
other filters with custom filter chains, and the need to add new
processing for each new sample type.
Since this doesn't reuse any of the old GPL code, nor does indirectly
rely on it, volume and replaygain handling now works in LGPL mode.
How to process the gain is inspired by libavfilter's af_volume (LGPL).
In particular, we use exactly the same rounding, and we quantize
processing for integer sample types by 256 steps. Some of libavfilter's
copyright may or may not apply, but I think not, and it's the same
license anyway.
These couldn't be relicensed, and won't survive the LGPL transition. The
other existing filters are mostly LGPL (except libaf glue code).
This remove the deprecated pan option. I guess it could be restored by
inserting a libavfilter filter (if there's one), but for now let it be
gone.
This temporarily breaks volume control (and things related to it, like
replaygain).
See "Copyright" file for caveats.
This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
This code could not be relicensed. The intention was to write new filter
code (which could handle both audio and video), but that's a bit of
work. Write some code that can do audio conversion (resampling,
downmixing, etc.) without the old audio filter chain code in order to
speed up the LGPL relicensing.
If you build with --disable-libaf, nothing in audio/filter/* is compiled
in. It breaks a few features, such as --volume, --af, pitch correction
on speed changes, replaygain.
Most likely this adds some bugs, even if --disable-libaf is not used.
(How the fuck does EOF notification work again anyway?)
Move it from af_lavrresample.c to a new aconverter.c file, which is
independent from the filter chain code. It also doesn't use mp_audio,
and thus has no GPL dependencies.
Preparation for later commits. Not particularly well tested, so have
fun.
This was _always_ called, even if the resampling was static, or the
filter was inserted for format conversion only. This should have been
fine, as I expected the function not to enable resampling when the
compensation is unset, and the source/target rates are the same. But
this is not the case, and it always enables resampling.
So explicitly avoid the call. If we have already called it successfully,
it's better not do avoid it (to overwrite the previous compensation
value), but it will also be cheap/no-op then.
Probably fixes#4716.
This API isn't deprecated (yet?), but it's still inferior and harder to
use than avcodec_free_context().
Leave the call only in 1 case in af_lavcac3enc.c, where we apparently
seriously close and reopen the encoder for whatever reason.
This is the last sample format that was only in mpv and not in FFmpeg
(except the spdif special formats). It was a huge pain, even if the
removed code in af_lavrresample is pretty small after all.
Note that this drops S24 from the ao_coreaudio AOs too. I'm not sure
about the impact, but I expect it doesn't matter.
af_fmt_change_bytes() was unused as well, so remove that too.
This case is a bit weird, because MPlayer certainly also has a file
named af_format.c. Both appear to have the function of converting audio
data between sample formats.
However, mpv's af_format.c is a rewrite, and doesn't actually do
conversion by itself. It's similar to vf_format.c, and forces the
generic filter chain code to insert conversion filters, instead of doing
conversion explicitly.
mpv's current af_format.c started out as af_force.c in d9582ad0a4. It
was renamed to af_format.c in e60b8f181d, while the old af_format.c was
split into two new filters. In 943c785619 the filename was changed to
af_format.c as well.
The new af_format.c does not contain any libaf code, except for some
potentially copy & pasted skeleton and boilerplate code. (We don't
account for this in per-filter file licenses, as the old libaf code
has to be removed fully, at which point the filters will have to be
ported to another framework, which will removed that boilerplate code.)
The old filters based on af_format.c were progressively replaced and
removed. Support for non-native endian and formats with signedness
different from native FFmpeg was completely removed in 831d7c3c40.
The old 24 bit conversion code was removed in 552dc0d564 (made
unnecessary by 5a9f817bfd).
Also list hwdec_vaglx.c as GPL-only, which doesn't have anything to do
with this commit.
All authors have agreed.
The initial commit d33703496c as well as the current code contain this
line:
* inspired by SoundTouch library by Olli Parviainen
We assume this is about the algorithm (not the code), and the author of
the original patch actually wrote all code himself.
The new replaygain code accidentally applied the linear gain as cubic
volume level. Fix this by moving the computation of the volume scale out
of the af_volume filter.
(Still haven't verified whether the replaygain code works correctly.)
Literally copy-pasted from the same commit for video filters. (Once new
code for filters is implemented, this will all go away or at least get
unified anyway.)
This was supposed to restrict output to formats supported by us. But we
usually support all FFmpeg sample formats anyway (if not, it will error
out gracefully, and we would add the missing format). Basically, it's
just useless bloat.
Basically, see the example in input.rst.
This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.
Some aspects of this changes are untested, so enjoy your alpha testing.
Remove low quality drc filter. Anyone whishing to have dynamic range
compression should use the much more powerful acompressor ffmpeg filter:
mpv --af=lavfi=[acompressor] INPUT
Or with parameters:
mpv --af=lavfi=[acompressor=threshold=-25dB:ratio=3:makeup=8dB] INPUT
Refer to https://ffmpeg.org/ffmpeg-filters.html#acompressor for a full
list of supported parameters.
Signed-off-by: wm4 <wm4@nowhere>
In a first pass, we check whether libavcodec is present.
Then we try to compile a snippet and check for FFmpeg vs. Libav. (This
could probably also be done by somehow checking the pkgconfig version.
But pkg-config can't deal with that idiotic FFmpeg idea that a micro
version number >= 100 identifies FFmpeg vs. Libav.)
After that we check the project-specific version numbers. This means it
can no longer happen that we accidentally allow older, unsupported
versions of FFmpeg, just because the Libav version numbers are somehow
this way.
Also drop the resampler checks. We hardcode which resampler to each with
each project. A user can no longer force use of libavresample with
FFmpeg.
The FFmpeg versions we support all have the APIs we were checking for.
Only Libav missed them. Simplify this by explicitly checking for FFmpeg
in the code, instead of trying to detect the presence of the API.
Looks quite like a bug. If you have a filter chain with only the
dynaudnorm filter, and send call av_buffersrc_add_frame(s, NULL), then
subsequent av_buffersink_get_frame() calls will return EAGAIN instead of
EOF.
This was apparently caused by a recent change in FFmpeg.
Some other circumstances (which I didn't fully analyze and which is due
to the playloop's absurd temporary-EOF behavior on seeks) then led the
decoder loop to send data again, but since libavfilter was stuck in the
EOF state now, it could never recover. It kept sending new input (due to
missing output), until the demuxer refused to return more audio packets.
Each time a filter error was printed.
Fortunately, it's pretty easy to workaround. We just mark the p->eof
flag as we send an EOF frame to libavfilter. The p->eof flag is used
only to recover from temporary EOF: it resets the filter if new data is
available again. We don't care much about av_buffersink_get_frame()
returning a broken EAGAIN state in this situation and essentially ignore
it, meaning if we get EAGAIN after sending EOF, we assume effectively
that EOF was fully reached.
This was in the parser code all along. As far as I can tell, *cp was
intended. There is no need to check cp for NULL (nor does it make any
sense to do so every time around the loop) for AF_CONTROL_COMMAND.
However, s->matrixstr can be NULL, so checking for that separately is in
order.
For stereo and typical L/R-first channel arrangements, this avoids
undesirable phasing artifacts, especially obvious when speed is changed
and then reset. Without this, there is a very audible change in the
stereo field even when librubberband is no longer actually making any
speed changes.
Normally I'd prefer a bunch of smaller functions with fewer parameters
over a single function with a lot of parameters. But future changes will
require messing with the parameters in a slightly more complex way, so a
combined function will be needed anyway. The now-unused "global"
parameter is required for later as well.
There are situations where the resampler is destroyed and recreated
during playback. If recreating the resampler unexpectedly fails, the
filter function is supposed to return an error. This wasn't done
correctly, because get_out_samples() accessed the resampler before the
check. Move the check up to fix this.
The code actually kept going out of EOF mode into resync mode back into
EOF mode when the playloop had to wait after an audio EOF caused by the
endpts. This would break seamless looping (as added by the next commit).
Apply endpts earlier, to ensure the filter_audio() function always
returns AD_EOF in this case.
The idiotic ao_buffer makes this an amazing pain in the ass.
The touched code is for seek resets and such - we simply want to reset
the entire resample state. But I noticed after a seek a tiny bit of
audio is missing (mpv's audio sync code inserted silence to compensate).
It turns out swr_drop_output() either does not reset some internal state
as we expect, or it's designed to drop not only buffered samples, but
also future samples.
On the other hand, libavresample's avresample_read(), does not have this
problem. (It is also pretty explicit in what it does - return/skip
buffered data, nothing else.)
Is the libswresample behavior a bug? Or a feature? Does nobody even
know? Who cares - use the hammer to unfuck the situation. Destroy and
deallocate the libswresample context and recreate it. On every seek.
The demuxer layer usually doesn't log per-stream information, and even
the replaygain information was logged only if it came from tags.
So log it in af_volume instead.
This commit adds an --audio-channel=auto-safe mode, and makes it the
default. This mode behaves like "auto" with most AOs, except with
ao_alsa. The intention is to allow multichannel output by default on
sane APIs. ALSA is not sane as in it's so low level that it will e.g.
configure any layout over HDMI, even if the connected A/V receiver does
not support it. The HDMI fuckup is of course not ALSA's fault, but other
audio APIs normally isolate applications from dealing with this and
require the user to globally configure the correct output layout.
This will help with other AOs too. ao_lavc (encoding) is changed to the
new semantics as well, because it used to force stereo (perhaps because
encoding mode is supposed to produce safe files for crap devices?).
Exclusive mode output on Windows might need to be adjusted accordingly,
as it grants the same kind of low level access as ALSA (requires more
research).
In addition to the things mentioned above, the --audio-channels option
is extended to accept a set of channel layouts. This is supposed to be
the correct way to configure mpv ALSA multichannel output. You need to
put a list of channel layouts that your A/V receiver supports.
