1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 16:33:02 +00:00
Commit Graph

22 Commits

Author SHA1 Message Date
wm4
8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
wm4
dac5b598f5 chmap_sel: prefer inexact equivalents over perfect upmix
Given 5.1(side), this lets it pick 5.1 from [5.1, 7.1]. Which was
probably the original intention of this replacement stuff. Until now,
the opposite was done in some cases.

Keep the old heuristic if the replacement is not perfect. This would
mean that a subset of the channel layout is an inexact equivalent, but
not all of it.

(My conclusion is that audio output APIs should be designed to simply
take any channel layout, like the PulseAudio API does.)
2016-01-04 19:17:56 +01:00
wm4
2dc18a2f82 chmap: remove MPlayer layouts
Unused; last uses removed with the previous two commits.
2015-11-07 15:22:30 +01:00
wm4
ec27d573f4 audio: always log channel maps before determining final map
Until now, this was done only in debug verbosity, while some AOs logged
equivalent information in verbose mode. Clean this up.
2015-10-26 15:52:08 +01:00
wm4
0969502316 chmap_sel: add a mechanism for preferred conversions
And use it for the mono case. This is slightly more formal and will make
it easier to add more such cases.
2015-06-27 12:09:30 +02:00
wm4
e0a7e094bc chmap_sel: remove outdated incomplete comment 2015-06-27 11:13:12 +02:00
wm4
fd1194de3c audio: fix channel map fallback selection (again)
The speaker replacement nonsense sometimes made blatantly incorrect
decisions. In this case, it prefered a 7.1(rear) upmix over outputting
5.1(side) as 5.1, which makes no sense at all. This happened because 5.1
and 7.1(rear) appeared equivalent to the final selection, as both of
them lose the sl-sr channels. The old code was too stupid to select the
one with the lower number of channels as well.

Redo this. There's really no reason why there should be a separate final
decision, so move the speaker replacement logic into the
mp_chmap_is_better() function.

Improve some other details. For example, we never should compare the
plain number of channels for deciding upmix/downmix, because due to NA
channels this is essentially meaningless. Remove the NA channels when
doing this comparison. Also, explicitly handle exact matches.
Conceptually this is not necessary, but it avoids that we have to
needlessly shuffle audio data around.
2015-06-25 17:32:00 +02:00
wm4
afdc060bb3 chmap_sel: improve speaker replacement handling
This didn't really work since the last time the channel map fallback
code was touched. In some cases, quite bad results were selected.
2015-06-12 19:23:46 +02:00
wm4
55624a70ee chmap_sel: do naive speaker replacements last
This prevents that the potentially better pick by
mp_chmap_sel_fallback() is overridden.
2015-06-12 19:21:01 +02:00
wm4
3560a50029 audio: redo channel map fallback selection
Instead of somehow having 4 different cases with each their own weight,
do it with a single function that decides which channel layout is the
better fallback.

This is simpler, and also introduces new (fixed) semantics. The new test
added to test/chmap_sel.c actually works now. This is a mixed case with
no perfect upmix or downmix, but the better choice is the one which
loses the least channels from the original layout.

One test also changes. If the input is 7.1(wide-side), and the available
layouts are 7.1 and 5.1(side), the latter is now chosen instead of the
former. This makes sense: both layouts contain 6 out of 8 channels from
the original layout, but the 5.1(side) one is smaller. This follows the
general logic. The 7.1 layout has FLC/RLC speakers instead of BL/BR,
and judging by the names, "front left center" is completely different
from "back left". If these should be exchangeable, a separate exception
would have to be added.
2015-05-08 19:33:17 +02:00
wm4
c4aa136155 audio: separate fallbacks for upmix and downmix cases
We always want to prefer upmix to downmix, as long as it makes sense.
Even if the upmix is not "perfect" (not just adding channels), we want
to prefer the upmix.

Cleanup for commit d3c7fd9d.
2015-04-28 22:01:55 +02:00
wm4
d3c7fd9d7c audio: avoid downmixing in a certain special-case
As indicated by the added test. In this case, fallback and downmix have
the same score, but fallback happens to give better results. So prefer
fallback over downmix.

(This is probably not a correct solution.)
2015-04-27 23:21:58 +02:00
wm4
c4f4b09014 audio: fix off by one error in channel map selection code
The consequence was that some AOs (like ao_jack) could not output 8
channels.

Fixes #1688.
2015-03-15 17:07:06 +01:00
Stefano Pigozzi
54aea7d5de chmap_sel: add multichannel fallback heuristic
Instead of just failing during channel map selection, try to select a close
layout that makes most sense and upmix/downmix to that instead of failing AO
initialization. The heuristic is rather simple, and uses the following steps:

1) If mono is required always prefer stereo to a multichannel upmix.
2) Search for an upmix that is an exact superset of the required channel map.
3) Search for a downmix that is the exact subset of the required channel map.
4) Search for either an upmix or downmix that is the closest (minimum difference
   of channels) to the required channel map.
2014-12-29 17:56:53 +01:00
wm4
5b32f30aa1 audio: fix previous commit
This would have always forced mono first (if supported by the AO),
instead of stereo.
2014-12-20 16:48:30 +01:00
wm4
d07c6566cd audio: fix fallback if audio API does not support mono
This makes it fallback to stereo properly.
2014-12-20 16:21:52 +01:00
wm4
4be7bdcc0f audio: fix one of the previous commits
Fixes commit 52c51149. It broke multichannel (or possibly everything)
for ao_alsa, ao_oss, ao_sndio.
2014-12-01 18:28:00 +01:00
wm4
b0ed93d87d audio: allow more than 20 channel map entries
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).

Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)

Fixes #1306.
2014-12-01 15:28:06 +01:00
wm4
99f5fef0ea Add more const
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
2014-06-11 00:39:14 +02:00
Stefano Pigozzi
e7d1c12131 chmap_sel: add channel replacement for sl/sr <-> sdl/sdr
This can be use useful for the 7.1 rear layout. In particular it looks like
OS X likes to use sdl/sdr as opposed to sl/sr.
2014-05-10 14:07:45 +02:00
wm4
2c732a46ba ao_jack: allow more control about channel layouts 2013-07-07 18:37:55 +02:00
wm4
ab8f28a672 audio: add channel map selection function
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.
2013-05-12 21:24:57 +02:00