Roughly follows MPlayer svn commits 36492 and 36493. We also remove
the volume peak reporting. (There are much better libavfilter filters
for this, I think.)
It's true that ALSA uses alloca() in some of its API functions, but
since this is hidden behind macros in the ALSA headers, we have no
reason to include alloca.h ourselves.
Might help with portability (FreeBSD).
Drop the author and comment fields. They were completely unused - not
even printed in verbose mode, just dead weight.
Also use designated initializers and drop redundant flags.
Set the input/output format in filter init. This doesn't change anything
functionally, but it makes the forced format show up in the filter chain
init verbose output (which sometimes prints the filter chain before all
filters have been configured).
af_format is the old audio conversion filter. It could do all possible
conversions supported by the audio chain. However, ever since the
addition of af_lavrresample, most conversions are done by
libav/swresample, and af_format is used as fallback.
Separate out the fallback cases and remove af_format. af_convert24 does
24 bit <-> 32 bit conversions, while af_convertsignendian does sign and
endian conversions. Maybe the way the conversions are split sounds a bit
odd. But the former changes the size of the audio data, while the latter
is fully in-place, so there's at least different buffer management.
This requires a quite complicated algorithm to make sure all these
"partial" conversion filters can actually get from one format to
another. E.g. s24le->s32be always requires convertsignendian and
convert24, but af.c has no idea what the intermediate format should
be. So I added a graph search (trying every possible format and
filter) to determine required format and filter. When I wrote this,
it seemed this was still better than messing everything into
af_lavrresample, but maybe this is overkill and I'll change my
opinion. For now, it seems nice to get rid of af_format though.
The AC3->IEC61937 conversion isn't supported anymore, but I don't think
this is needed anywhere. Most AOs test all formats explicitly, or use
the AF_FORMAT_IS_IEC61937() macro (which includes AC3).
One positive consequence of this change is that conversions always
include dithering (done by libav/swresample), instead of possibly going
through af_format, which doesn't do anything fancy.
Rename af_force to af_format. It's essentially compatible with command
line uses of af_format. We retain a compatibility alias for af_force.
At least not with ffmpeg.
Honestly, I have no idea how little endian AC3 works at all, since
ao_pcm doesn't do anything special about it, and treats it like s16le.
Maybe it's broken and ffmpeg has special logic to detect it.
Was disabled by default, was never used, internal support was
inconsistent and poor, and there has been virtually no interest in
creating translations.
And I don't even think that a terminal program should be translated.
This is something for (hypothetical) GUIs.
Changing volume when audio is disabled was a feature request (github
issue #215), and was introduced with commit 327a779.
But trying to fix github issue #280 (volume is not correct in no-audio
mode, and if audio is re-enabled, the volume set in no-audio mode isn't
set), I concluded that it's not worth the trouble and the current
implementation is questionable all around. (For example, you can't
change the real volume in no-audio mode, even if the AO is open - this
could happen with gapless audio.) It's hard to get right, and the
current mixer code is already hilariously overcomplicated. (Virtually
all of mixer.c is an amalgamation of various obscure corner cases.)
So just remove this feature again.
Note that "options/volume" and "options/mute" still can be used in
idle mode to adjust the volume used next time, though these properties
can't be used during playback and thus not in audio-only mode.
Querying the volume still "works" in audio-only mode, though it can
return bogus values.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36461 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes playback of http://mpg123.org/test/44and22.mp3
Cherry-picked from MPlayer SVN rev. #36461, a patch by
Thomas Orgis, committed by by Reimar Döffinger.
Output silence to the output buffer during underruns. This removes small
occasional glitches that happen before the AUHAL is actually paused from the
`audio_pause` call.
Fixes#269
Trying to connect multiple mpv clients to JACK with the
JackUseExactName option would fail unless the user manually
specifies a unique client name. This changes the behavior
to automatically generate a unique name if the requested
one is already in use.
Calling them separately doesn't really make sense, and all existing
calls to them usually combined them. One subtitle difference was that
af_init() didn't wipe the filter chain if initialization of the chain
itself failed, but that didn't really make sense anyway.
Also remove af_init() from the code for setting balance in mixer.c. The
mixer should be in the initialized state only if audio is fully
initialized, so the af_init() call made no sense.
Note that the filter "editing" code in command.c doesn't really do a
nice job of handling errors in case recreating an _old_ (known to work)
filter chain unexpectedly fails, and this obscure/rare case might be
differently handled after this change.
Note that this is intentionally never done if the AO or softvolume is
different, or if the current volume control method is thought to control
system wide volume (such as ALSA) or otherwise user controllable (such
as PulseAudio). The intention is to keep things robust and to avoid
messing with the user's audio settings as far as possible, while still
providing the ability to resume volume if it makes sense.
Refactor how mixer.c does volume/mute restoration and initialization.
Move to handling of --volume and --mute to mixer.c. Simplify the
implementation of these and hopefully fix bugs/strange behavior related
to using them as file-local options (this uses a somewhat dirty trick:
the option values are reverted to "auto" after initialization). Put most
code related to initialization and volume restoring in probe_softvol()
and restore_volume(). Having this code all in one place is less
confusing.
Instead of trying to detect whether to use softvol at runtime, detect it
at initialization time using AOCONTROL_GET_VOLUME (same with mute,
AOCONTROL_GET_MUTE). This implies we expect SET_VOLUME/SET_MUTE to work
if the GET variants work. Hopefully this is always the case.
This is also preparation for being able to change volume/mute settings
if audio is disabled, and for allowing restoring value with playback
resume.
Softvol always used a linear multiplier for volume control. This was
converted to dB, and then back to linear in af_volume. Remove this non-
sense. We still try to keep the command line argument to af_volume in
dB, though.
It's quite unlikely, but functions like mp_find_user_config_file() can
return NULL, e.g. if $HOME is unset.
Fix all the code that didn't check for this correctly yet.
This is basically a libavcodec API oddity: it can happen that
avcodec_decode_audio4() returns 0 (meaning 0 bytes were consumed). It
requires you to feed the complete packet again to decode the full
packet, and to successfully decode the following packets.
We ignored this case with the argument that there's the danger of an
endless decode loop (because nothing of that packet is apparently
decoded, so it would retry forever), but change it in order to decode
mpc8 files correctly.
Also add some comments to explain the mess.
af_str2fmt_short(), which is used by the command line option parser,
allowed passing a hex number. The user could set arbitrary integers as
internal audio formats, even formats which don't exist or make no sense.
This is not very useful, so get rid of it.
Having to use -1 for that is generally quite annoying.
Audio formats are created from bitmasks, and it can't be excluded that
0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it
is never 0. Along with AF_FORMAT_F and the special formats, all valid
formats are covered and guaranteed to be non-0.
It's possible that this commit will cause some regressions, as the
check for invalid audio formats changes a bit.
Use the new MP_ macros for some AOs instead of mp_msg.
Not all AOs are converted, and some only partially. In some cases, some
additional cosmetic changes are made.
The --speed option and the speed property used float. Change them to
double.
Change the commands that manipulate the property (speed_mult/add) to
double as well. Since the cycle command shares code with the add
command, we change that as well.
The reason for this change is that this allows better control over
speed, such as stepping by semitones. Using floats is also just plain
unnecessary.
Using the default output audio unit should provide a much better user
exeperience since it changes automatically the output device based on which
becomes the default one.
This was removed in d427b4fd. I now found a sample that causes underruns when
moving to a chapter and apparently this is also a problem when taking
screenshots.
Reverts one of the changes from 18777ecf. `kAudioObjectPropertyScopeOutput`
was introduced in the 10.8 SDK while `kAudioDevicePropertyScopeOutput` was
moved to `AudioHardwareDeprecated.h`. Since the deprecation is silent for now
(no warnings), just use the old constant.
Either way, they both evaluate to 'outp', and in the 10.8 SDK the deprecated
constant is defined in terms of the non-deprecated one.
Fixes#155
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
This is not done automatically by CoreAudio. I am told that it would a PITA
to have to switch back the format manually on the device (especially if the
same device is used for lpcm output).
b2f9e0610 introduced this functionality with code that was quite 'monolithic'.
Split the functionality over several functions and ose the new macros to get
array properties.
Introduce some macros to deal with properties. These allow to work around the
limitation of CoreAudio's API being `void **` based. The macros allow to keep
their client's code DRY, by not asking size and other details which can be
derived by the macro itself. I have no idea why Apple didn't design their API
like this in the first place.
* ao_coreaudio_utils: contains several utility function
* ao_coreaudio_properties: contains functions to set and get audio object
properties.
Conflicts:
audio/out/ao_coreaudio.c
The condition was checked wrongly on asbd which is the input format
description. This lead to the condition always being true, thus selecting lpcm
streams for digital input.
The initialization is split more clearly between compressed and lpcm case.
For the compressed case, format selection is simplified a lot and negotiation
removed. The way it was written it just passed back to the core the original
requested format, not what was found available on hardware.
Since this is most likely useless for the compressed case, I didn't bother
with this. In the future I'd like to split this AO in two one that only uses
the AUHAL and the other with direct access to the hardware so that even
passthrough of lcpm can be possible. This would decrease the latency,
audiophiles would like that.
Split out some utility functions that use the CoreAudio API but are not related
the main task of the AOs (which is to move data correctly to the ringbuffer).
These are mainly need for the verbosity of the CoreAudio API and are just
obscuring the 'real' code.
Read only the requested amount by the AUHAL (instead of all the buffered data).
No idea what the deal is with pausing the audio units if there is no audio to
play, maybe to avoid underruns of some sort. Anyway from my tests this
condition never occurred so I'm removing it all.
Make the VF/VO/AO option parser available to audio filters. No audio
filter uses this yet, but it's still a quite intrusive change.
In particular, the commands for manipulating filters at runtime
completely change. We delete the old code, and use the same
infrastructure as for video filters. (This forces complete
reinitialization of the filter chain, which hopefully isn't a problem
for any use cases. The old code forced reinitialization too, but it
could potentially allow a filter to cache things; e.g. consider loaded
ladspa plugins and such.)
This code is supposed to run if dynamic filter insertion (such as when
inserting a volume filter in mixer.c) fails. Then it removes all filters
and recreates the default list of filters. But the code just blew up and
entered an endless loop, because it removed even the sentinel in/out
filters. This could happen when trying to use softvol controls while
using spdif, but also other situations. Fix it by calling the correct
code.
Also remove these obnoxious yoda-conditions.
MSDN tells me to multiply the samplerates by 4 (for setting up the S/PDIF
signal frequency), but doesn't mention that I'm only supposed to do it
on the new, NT6.1+ IEC 61937 structs. Works on my Realtek Digital Output,
but as I can't connect any hardware to it I can't hear the result.
Also, always ask for little-endian AC3. I'm not sure if this is supposed
to be LE or NE, but Windows is LE on all platforms, so we go with LE.
Entirely untested as this troper has no S/PDIF hardware.
Refuses trying any other format if we can't use passthrough, or we would
end up sending white noise at the user.
Do an strstr match against the device description and, if we have only
a single match, take it. This works as long as the devices in the system
don't change, but it's not supposed to be reliable; if one wants
reliability, one uses the device ID string.
Formatting.
This could turn valid parameters into syntax errors by the mere presence
or abscence of a device (e.g. USB audio devices), so don't do that.
We do validate that, if the parameter is an integer, it is not negative.
We also respond to the "help" parameter, which does the same as the "list"
suboption but exits after listing.
Demote the validation logging to MSGL_DBG2.
Validates by trying to pick the device using the device enumerator and
aborting with out of range on failure.
Refactors find_and_load_device to not use the wasapi_state; it might be
called during validation. Adds missing CoInitialize/CoUninitialize calls.
Remove unused variables (the SAFE_RELEASE macros keep them referenced so
compiler warnings don't help finding them...).
Remove the IMMDeviceEnumerator from the wasapi_state, it's only needed
during initialization and initialization is now well factored enough to
get rid of it.
Try and connect to unplugged devices as well when using the device ID
string.
Omit "{0.0.0.00000000}." on devices that start with that substring,
re-add when searching for devices by ID.
Log the device ID of the default device.
Log the friendly name of the used device.
Consistently refer to endpoints/devices as devices, as this is more
consistent with mpv terminology.
Uses WASAPI in shared mode by default, add :exclusive flag to choose
exclusive mode (duh). WASAPI works somewhat different in shared mode:
the OS suggests the sample format to use, and the GetBuffer call is
done slightly differently.
The shared mode driver does not consume audio as fast as it notifies
the thread; we need to check how much we're allowed to write. Not doing
this correctly results in spamming the console with
AUDCLNT_E_BUFFER_TOO_LARGE errors.
When guessing formats for exclusive mode, try several sample size and
sample rate combinations instead of just falling back to s16le@44100hz.
If none of the rates are accepted, tries remixing >6 channels to 5.1
channels. Failing that, tries remixing to stereo. Failing everything,
including the CD Red Book format, what else is left to test?
Calculate buffer_block_size based on the configured channels and bytes
per sample; MSDN docs say nBlockAlign is not guaranteed to be set for
anything but integer PCM formats.
Adds the :list suboption to ao_wasapi0, which enumerates the audio endpoints
in the system.
Adds the :device=<n> suboption, which either takes an ID string (as output by
list) or a device number and uses the requested device instead of the system
default.
These two options were supported by ALSA and OSS only. Further, their
values were specific to the respective audio systems, so it doesn't make
sense to keep them as top-level options.
This changes how device names are handled. Before this commit, device
names were mangled in strange ways to avoid clashing with the option
parser syntax. "." was replaced with ",", and "=" with ":" (the user had
to do the inverse to get the correct device name).
The "new" option parser has multiple ways to escape option strings, so
we don't need this confusing hack anymore.
Add an explicit note to the manpage as well.
Seeking calls thread_reset, but doesn't call thread_play. thread_reset
would disable WASAPI events, but they would never get re-enabled unless
the user paused and then unpaused.
Keep track of whether the stream is paused or not (there already was a
field for that, but it was apparently unused), and if it's not paused,
call thread_play after thread_reset. Fixes mpv freezing after seeks.
Fixes format specifies that assume windows TYPEDEFS are as long as they look
like they are.
Remove calls to _beginthreadex and _endthreadex, these are only present on
microsoft's C runtimes. Replace by the otherwise identical CreateThread and
ExitThread calls.
This actually requires fixes to devicetopology.h, but the problem has been
(kinda) reported to mingw-w64:
<Kovensky> I see that those KSJACK* structs are supposedly declared in
devicetopology.h itself, but for some reason (some of?) the decls that use
them aren't seeing them?
<Kovensky> ok, it seems that it expects ks.h and ksmedia.h to declare those
structs, but it doesn't
<Kovensky> the included files declare KDATAFORMAT, KSIDENTIFIER and LUID (and
the associated pointer typedefs)
<Kovensky> but everything else is essentially inside #if 0
<Kovensky> changing the #ifndef _KS_ to only include KDATAFORMAT, KSIDENTIFIER
and LUID (and putting the KSJACK stuff outside that #ifndef) makes the
header compile
<Kovensky> it solves my immediate problem, but if that happened to begin with
there's probably something more wrong with the ks headers :S
Matroska has an output sample rate (OutputSamplingFrequency), which in
theory should be forced instead of whatever the decoder outputs. But it
appears no software (other than mplayer2 and mpv until now) actually
respects this. Even worse, there were broken files around, which played
correctly with (in theory) broken software, but not mplayer2/mpv. Hacks
were added to our code to play these files correctly, but they didn't
catch all cases.
Simplify this by doing what everyone else does, and always use the
decoder's sample rate instead. In particular, we try to handle all
sample rate issues like libavformat's Matroska demuxer does.
It turns out that some code that was removed earlier was still needed.
avcodec_decode_audio4() can decode packets "partially". In that case,
you have to "slice" the packet and call the decode function again.
Codecs which need this are obscure and in low numbers. One sample that
needs it is here:
rsync://fate-suite.ffmpeg.org/fate-suite/lossless-audio/luckynight-partial.shn
(This one decodes in rather small increments.)
The new code is much simpler than what has been removed earlier,
though. The fact that we own the packet returned by the demuxer helps
a lot.
Not sure what should happen if avcodec_decode_audio4() returns 0.
Currently, we throw away the packet in this case. We don't want to be
stuck in an endless loop (could happen if the decoder produces no
output either).
This is not directly related to the handling of format changes itself,
but playing audio normally after the change. This was broken: the output
byte rate was not recalculated, so audio-video sync was simply broken.
Fix this by calculating the byte rate on the fly, instead of storing it
in sh_audio.
Format changes are relatively common (switches between stereo and 5.1
in TV recordings), so this fixes a somewhat critical bug.
pts_bytes can't just be changed at the end. It must be offset to the pts
value, which is reset with each packet read from the demuxer. Make sure
the pts_byte field is always reset after receiving a new PTS, i.e.
increment it after actually writing to the output buffer.
Flush the AVFormatContext's write buffer, because otherwise the audio
PTS will jump around too much: the calculation doesn't use the exact
output buffer size if there's still data in the avio buffer.
Partial packet reads were needed because the video/audio parsers were
working on top of them. So it could happen that a parser read a part of
a packet, and returned that to the decoder. With libavformat/libavcodec,
packets are already parsed, and everything is much simpler.
Most of the simplifications in ad_spdif could have been done earlier.
Remove some other stuff as well, like the questionable slave mode start
time reporting (could be replaced by proper code, but we don't bother).
Remove the unused skip_audio_frame() functionality as well (it was used
by old demuxers). Some functions become private to demux.c, like
demux_fill_buffer(). Introduce new packet read functions, which have
simpler semantics. Packets returned from them are owned by the caller,
and all packets in the demux.c packet queue are considered unread.
Remove special code that dropped subtitle packets with size 0. This
used to be needed because it caused special cases in the old code.
We don't need to deal with partial packet reads, manually using an audio
parser, or having to call the libavcodec decoder multiple times per
packet.
Actually, I'm not sure about the last point. ffplay still does this, but
the ffmpeg demuxing.c example doesn't.
The audio parser was needed only by the "old" demuxers, and
demux_rawaudio. All other demuxers output already parsed packets.
demux_rawaudio is usually for raw audio, so using a parser with it
doesn't usually make sense. But you can also force it to read
compressed formats with fixed packet sizes, in which case the parser
would have been used. This use case is probably broken now, but you
will be able to do the same thing with libavformat demuxers.
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.
Remove them to facilitate further cleanups.
The core didn't use these fields, and use of them was inconsistent
accross AOs. Some didn't use them at all. Some only set them; the values
were completely unused by the core. Some made full use of them.
Remove these fields. In places where they are still needed, make them
private AO state.
Remove the --abs option. It set the buffer size for ao_oss and ao_dsound
(being ignored by all other AOs), and was already marked as obsolete. If
it turns out that it's still needed for ao_oss or ao_dsound, their
default buffer sizes could be adjusted, and if even that doesn't help,
AO suboptions could be added in these cases.
Some still do, because they use the value in other places of the init
function. ao_portaudio is tricky and reads ao->bps in the stream
thread, which might be started on initialization (not sure about that,
but better safe than sorry).
Currently every single AO was implementing it's own ringbuffer, many times
with slightly different semantics. This is an attempt to fix the problem.
I stole some good ideas from ao_portaudio's ringbuffer and went from there.
The main difference is this one stores wpos and rpos which are absolute
positions in an "infinite" buffer. To find the actual position for writing /
reading just apply modulo size.
The producer only modifies wpos while the consumer only modifies rpos. This
makes it pretty easy to reason about and make the operations thread safe by
using barriers (thread safety is guaranteed only in the Single-Producer/Single-
Consumer case).
Also adapted ao_coreaudio to use this ringbuffer.
This is hopefully the start of something good. ca_ringbuffer_read and
ca_ringbuffer_write can probably cleaned up from all the NULL checks once
ao_coreaudio.c gets simplyfied.
Conflicts:
audio/out/ao_coreaudio.c
Whatever this was supposed to be originally, it doesn't have much value
anymore. It just forced ad_mpg123 to upmix mono to stereo by default
(the audio chain can do that). As an option, it was mostly useless and
misleading, so get rid of it.
This was overlooked with commit 32a898f, because OSS4 volume control is
typically not available on Linux. BSD does have this feature, so the
broken code broke compilation there.
Fixes crashes when playing with certain numbers of channels. The core
assumes AOs accept data aligned on channels * samplesize, and ao_jack's
play() function broke that assumption:
mpv: core/mplayer.c:2348: fill_audio_out_buffers: Assertion `played % unitsize == 0' failed.
Fix by aligning the buffer and chunk sizes as needed.
Audio and video had their own (very similar) functions to initialize an
AVPacket (ffmpeg's packet struct) from a demux_packet (mplayer's packet
struct). Add a common function for these.
Also use this function for sd_lavc_conv. This is actually a functional
change, as some libavfilter subtitle demuxers add weird out-of-band
stuff as side-data.
GetTimer() is generally replaced with mp_time_us(). Both calls return
microseconds, but the latter uses int64_t, us defined to never wrap,
and never returns 0 or negative values.
GetTimerMS() has no direct replacement. Instead the other functions are
used.
For some code, switch to mp_time_sec(), which returns the time as double
float value in seconds. The returned time is offset to program start
time, so there is enough precision left to deliver microsecond
resolution for at least 100 years. Unless it's casted to a float
(or the CPU reduces precision), which is why we still use mp_time_us()
out of paranoia in places where precision is clearly needed.
Always switch to the correct time. The whole point of the new timer
calls is that they don't wrap, and storing microseconds in unsigned int
variables would negate this.
In some cases, remove wrap-around handling for time values.
The ALSA device was not closed when initialization failed.
The ALSA error handler (set with snd_lib_error_set_handler()) was not
unset when closing ao_alsa. If this is not done, the handler will still
be called when other libraries using ALSA cause errors, even though
ao_alsa was long closed. Since these messages were prefixed with
"[AO_ALSA]", they were misleading and implying ao_alsa was still used.
For some reason, our error handler is still called even after doing
snd_lib_error_set_handler(NULL), which should be impossible. Checking
with the debuggers, inserting printf(), as well as the alsa-lib source
code all suggest our error handler should not be called, but it still
happens. It's a complete mystery.
Mostly copied from vf_lavfi. The parts that could be shared are minor,
because most code is about setting up audio and video, which are too
different.
This won't work with Libav. I used ffplay.c as guide, and noticed too
late that their setup methods are incompatible with Libav's. Trying to
make it work with both would be too much effort. The configure test for
av_opt_set_int_list() should disable af_lavfi gracefully when compiling
with Libav.
Due to option parser chaos, you currently can't have a "," as part of
the filter graph string - not even with quoting or escaping. This will
probably be fixed later.
The audio filter chain is not PTS aware. So we have to do some hacks
to make up a fake PTS, and we have to map the output PTS back to the
filter chain's method of tracking PTS changes and buffering, by
adjusting af->delay.
FFmpeg (as well as Libav) have two layouts called "6.1":
AV_CH_LAYOUT_6POINT1 and AV_CH_LAYOUT_6POINT1_BACK. We call them "6.1"
and "6.1(back)". Change the default layout for 7 channels as well to
return the same layout as av_get_default_channel_layout(). (Looks a bit
questionable, but for now it's better to follow FFmpeg.)
It turns out that ALSA's 4 channel layout is different from mpv's and
ffmpeg's 4.0 layout. Thus trying to do 4 channel output led to incorrect
remixing via lib{av,sw}resample.
Fix the default layouts for the internal filter chain as well, although
I'm not sure if it matters at all.
The libavresample version of the current Libav stable release lacks the
avresample_set_channel_mapping() function. (FFmpeg's libswresample seems
to be fine, because they added swr_set_channel_mapping() first.)
Add a cheap/slow workaround to do channel reordering on our own. We
don't use the recently removed MPlayer code (see commit 586b75a),
because that is not generic enough.
The functionality should be the same as with full-featured
libavresample, and any differences are bugs. It's probably slower,
though.
af_reinit() is responsible for inserting automatic conversion filters
for channel remixing, format conversion, and resampling. We don't
require that a single filter can do all these (even though
af_lavrresample does nearly all of this, sometimes af_format has to be
used instead for format conversions). This makes setting up the chain
more complicated, and a way is needed to prevent endless appending of
conversion filters if a conversion is not possible.
Until now, this used a stupidly simple yet robust static retry limit to
detect failure. This is perfectly fine, and the limit (20) was good
enough to handle about ~5 filters. But with more filters, and if each
filter requires 3 additional conversion filters, this would fail. So
raise the limit to 4 retries per filter. This is still stupidly simple
and robust, but won't arbitrarily fail if the filter count is too large.
To make this easier, get rid of the direct mapping of the
AF_FORMAT_BITS_MASK bit field to number of bytes. This way we can throw
away the unused AF_FORMAT_48BIT and don't have to add ..._56BIT.
The snd_pcm_hw_params_test_format() call actually crashes in alsa-lib if
called with SND_PCM_FORMAT_UNKNOWN, so the already existing fallback
code won't work in this case.
Make all AOs use what has been introduced in the previous commit.
Note that even AOs which can handle all possible layouts (like ao_null)
use the new functions. This might be important if in the future
ao_select_champ() possibly honors global user options about downmixing
and so on.
The point is selecting a minimal fallback. The AOs will call this
through the AO API, so it will be possible to add options affecting
the general channel layout selection.
It provides the following mechanism to AOs:
- forcing the correct channel order
- downmixing to stereo if no layout is available
- allow 5.1 <-> 5.1(side) fallback
- handling "unknown" channel layouts
This is quite weak and lots of code/complexity for little gain. All AOs
already made sure the channel order was correct, and the fallback is of
little value, and could perhaps be done in the frontend instead, like
stereo downmixing with --channels=2 is handled. But I'm not really sure
how this stuff should _really_ work, and the new code will hopefully
provides enough flexibility to make radical changes to channel layout
negotiation easier.
If one of the input or output is an unknown layout, but the other is
known, it can still happen that channels are remixed randomly. Avoid
this by forcing default layouts in this case. (Doesn't work if the
channel counts are different.)
Now mpv's channel map is used to map each channel to a speaker. This
allows in theory for playback of any layout for which ao_openal
actually has a speaker defined. Also add the back-center (BC) speaker,
which allows playback of 6.0 audio. Enabling more layouts by adding
other speakers would be possible, but I'm not sure about the speaker
positions.
This allows supporting 5 channel audio (which can be eother 5.0 or 4.1).
Fallback doesn't work yet. It will do nonsense if the channel layout
doesn't match perfectly, even though it's similar.
Add a CHECK_ALSA_ERROR macro to report ALSA errors. This is similar to
what vo_vdpau does. This removes lots of boiler plate, it almost gives
me the feeling the ao_alsa initialization code is now readable. This
change is squashed with the reformatting, because both changes are
just as noisy and useless.
Using demux_rawaudio and the --rawaudio-channels option is useful for
testing channel map stuff. The libavcodec PCM decoder normalizes the
channel map to ffmpeg order, though. Prevent this by forcing the
original channel map when using the mp-pcm pseudo decoder entry (used by
demux_rawaudio and stream/tv.c only).
Like most other AOs, ao_pulse set the channel count only, always using a
default layout. Try to set the exact layout.
For this, we need a big lookup table to map waveex/lavc/mpv speaker
position to PulseAudio's, since PA_CHANNEL_POSITION_ is apparently not
compatible to waveext, and I haven't seen any API functions that would
help mapping them.
Completely untested. (Let's leave that to someone else...)
This helps passing the channel layout correctly from decoder to audio
filter chain. (Because that part "reuses" the demuxer level codec
parameters, which is very disgusting.)
Note that ffmpeg stuff already passed the channel layout via
mp_copy_lav_codec_headers(). So other than easier dealing with the
demuxer/decoder parameters mess, there's no real advantage to doing
this.
Make the --channels option accept a channel map. Since simple numbers
map to standard layouts with the given number of channels, this is
downwards compatible. Likewise for demux_rawaudio.
This is done in af_lavrresample now, and as part of format negotiation.
Also remove the remaining reorder_channel calls. They were redundant
and did nothing.
This actually breaks audio for 5/6/8 channels. There's no reordering
done yet. The actual reordering will be done inside of af_lavrresample
and has to be made part of the format negotiation.
mp_audio has some redundant fields. Setters like mp_audio_set_format()
initialize these properly.
Also move the mp_audio struct to a the file audio.c.
We can remove a mysterious line of code from af.c:
in.format |= af_bits2fmt(in.bps * 8);
I'm not sure if this was ever actually needed, or if it was some kind of
"make it work" quick-fix that works against the way things were supposed
to work. All filters etc. now set the format correctly, so if there ever
was a need for this code, it's definitely gone.
Schedule mpv's playloop as a high frequency timer inside the main Cocoa event
loop. This has the benefit to allow accessing menus as well as resizing the
window without the playback being blocked and allows to remove countless hacks
from the code that involved manually pumping the event loop as well simulating
manually some of the Cocoa default behaviours.
A huge improvement consists in removing NSApplicationLoad. This is a C function
defined in the Cocoa header and implements a minimal OSX application under ther
hood so that you can use the Cocoa GUI toolkit from C/C++ without having to
respect the Cocoa standards in terms of application initialization. This was
bad because the behaviour implemented by NSApplicationLoad was hard to customize
and had several gotchas especially in the menu department.
mpv was changed to be just a nib-less application. All the Cocoa part is still
generated in code but the event handling is now not dissimilar to what is
present in a stock Mac application.
As a part of reviewing the initialization process, I also removed all of
`osdep/macosx_finder_args`. The useful parts of the code were moved to
`osdep/macosx_appication` which has the broaded responsibility of managing the
full lifecycle of the Cocoa application. By consequence the
`--enable-macosx-finder` configure switch was killed as well, as this feature
is always enabled.
Another change the users will notice is that when using a bundle the `--quiet`
option will be inserted much earlier in the initializaion process. This results
in mpv not spamming mpv.log anymore with all the initialization outputs.
Add dummy input and output filters to remove special cases in the format
negotiation code (af_fix_format_conversion() etc.). The output of the
filter chain is now negotiated in exactly the same way as normal
filters.
Negotiate setting the sample rate in the same way as other audio
parameters. As a side effect, the resampler is inserted at the start of
the filter chain instead of the end, but that shouldn't matter much,
especially since conversion and channel mixing are conflated into the
same filter (due to libavresample's API).
Anything this option did has been removed in the preceding 3 commits.
Note that even though these options sounded like a good idea (like
setting accuracy vs. speed tradeoffs), they were not really properly
implemented.
All this option did was deciding whether the resample filter was to be
insert at the beginning or end of the filter chain. Always do what the
option set for accuracy did. I doubt it makes much of a difference.
libavresample does most things in just one go anyway, so it won't
matter.
Dangerous and misleading. If it turns out that this is actually needed
to make certain setups work right, it should be added back in a better
way (in a way it doesn't cause random crashes).
The only thing this option did was changing the behavior of af_volume.
The option decided what sample format af_volume would use, but only if
the sample format was not already float. If the option was set, it would
default to float, otherwise to S16.
Remove use of the option and all associated code, and make af_volume
always use float (unless a af_volume specific sub-option is set).
Silence maximum value tracking. This message is printed when the filter
is destroyed, and it's slightly annoying. Was enabled due to enabling
float by default.
Switch the internal channel order to libavcodec's. If the channel number
mismatches at some point, use libavresample for up- or downmixing.
Remove the old af_pan automatic downmixing.
The libavcodec channel order should be equivalent to WAVEFORMATEX order,
at least nowadays. reorder_ch.h assumes that WAVEFORMATEX and libavcodec
might be different, but all defined channels have the same mappings.
Remove the downmixing with af_pan as well as the channel conversion with
af_channels from af.c, and prefer af_lavrresample for this. The
automatic downmixing behavior should be the same as before (if the
--channels option is set to 2, which is the default, the audio output
is forced to 2 channels, and libavresample does all downmixing).
Note that mpv still can't do channel layouts. It will pick the default
channel layout according to the channel count. This will be fixed later
by passing down the channel layout as well.
af_hrtf depends on the order of the input channels, so reorder to ALSA
(for which this code was written). This is better than changing the
filter code, which is more risky.
ao_pulse can accept waveext order directly, so set that as channel
mapping.
If format negotiation fails, and additional filters are inserted to fix
this, don't try to reinitialize the filter immediately. Instead, correct
the audio format, and let the caller retry.
Add a retry counter to af_reinit() to ensure that misbehaving filters
can't put the format negotiation into an endless loop.
Refactor to remove the duplicated format filter insertion code. Allow
other format converting filters to be inserted on format mismatches.
af_info.test_conversion checks whether conversion between two formats
would work with the given filter; do this to avoid having to insert
multiple conversion filters at once and such things. (Although this
isn't ideal: what if we want to avoid af_format for some conversions?
What if we want to split af_format in endian-swapping filters etc.?)
Prefer af_lavrresample for conversions that it supports natively,
otherwise let af_format handle the full conversion.
Make sure automatically inserted filters are removed on full reinit
(they are re-added later if they are really needed). Automatically
inserted filters were never explicitly removed, instead, it was
expected that redundant conversion filters detach themselves. This
didn't work if there were several chained format conversion filters,
e.g. s16le->floatle->s16le, which could result from repeated filter
insertion and removal. (format filters detach only if input format and
output format are the same.)
Further, the dummy filter (which exists only because af.c can't handle
an empty filter chain for some reason) could introduce bad conversions
due to how the format negotiation works. Change the code so that the
dummy filter never takes part on format negotiation. (It would be better
to fix format negotiation, but that would be much more complicated and
would involving fixing all filters.)
Simplify af_reinit() and remove the start audio filter parameter. This
means format negotiation and filter initialization is run more often,
but should be harmless.
The format was locked to s16. Extend it to accept all other ffmpeg
sample formats, and even allow different in- and output formats. The
generic filter code will still insert af_format on format mismatches,
though.
