aboutsummaryrefslogtreecommitdiffhomepage
path: root/audio/chmap_sel.c
Commit message (Collapse)AuthorAge
* Relicense some non-MPlayer source files to LGPL 2.1 or laterGravatar wm42016-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* chmap_sel: prefer inexact equivalents over perfect upmixGravatar wm42016-01-04
| | | | | | | | | | | | | 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.)
* chmap: remove MPlayer layoutsGravatar wm42015-11-07
| | | | Unused; last uses removed with the previous two commits.
* audio: always log channel maps before determining final mapGravatar wm42015-10-26
| | | | | Until now, this was done only in debug verbosity, while some AOs logged equivalent information in verbose mode. Clean this up.
* chmap_sel: add a mechanism for preferred conversionsGravatar wm42015-06-27
| | | | | And use it for the mono case. This is slightly more formal and will make it easier to add more such cases.
* chmap_sel: remove outdated incomplete commentGravatar wm42015-06-27
|
* audio: fix channel map fallback selection (again)Gravatar wm42015-06-25
| | | | | | | | | | | | | | | | | | | | 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.
* chmap_sel: improve speaker replacement handlingGravatar wm42015-06-12
| | | | | This didn't really work since the last time the channel map fallback code was touched. In some cases, quite bad results were selected.
* chmap_sel: do naive speaker replacements lastGravatar wm42015-06-12
| | | | | This prevents that the potentially better pick by mp_chmap_sel_fallback() is overridden.
* audio: redo channel map fallback selectionGravatar wm42015-05-08
| | | | | | | | | | | | | | | | | | | | 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.
* audio: separate fallbacks for upmix and downmix casesGravatar wm42015-04-28
| | | | | | | | 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.
* audio: avoid downmixing in a certain special-caseGravatar wm42015-04-27
| | | | | | | | 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.)
* audio: fix off by one error in channel map selection codeGravatar wm42015-03-15
| | | | | | | The consequence was that some AOs (like ao_jack) could not output 8 channels. Fixes #1688.
* chmap_sel: add multichannel fallback heuristicGravatar Stefano Pigozzi2014-12-29
| | | | | | | | | | | | 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.
* audio: fix previous commitGravatar wm42014-12-20
| | | | | This would have always forced mono first (if supported by the AO), instead of stereo.
* audio: fix fallback if audio API does not support monoGravatar wm42014-12-20
| | | | This makes it fallback to stereo properly.
* audio: fix one of the previous commitsGravatar wm42014-12-01
| | | | | Fixes commit 52c51149. It broke multichannel (or possibly everything) for ao_alsa, ao_oss, ao_sndio.
* audio: allow more than 20 channel map entriesGravatar wm42014-12-01
| | | | | | | | | | | | | 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.
* Add more constGravatar wm42014-06-11
| | | | | | | 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.
* chmap_sel: add channel replacement for sl/sr <-> sdl/sdrGravatar Stefano Pigozzi2014-05-10
| | | | | 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.
* ao_jack: allow more control about channel layoutsGravatar wm42013-07-07
|
* audio: add channel map selection functionGravatar wm42013-05-12
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.