summaryrefslogtreecommitdiffstats
path: root/audio/chmap_sel.c
Commit message (Collapse)AuthorAgeFilesLines
* chmap_sel: prefer inexact equivalents over perfect upmixwm42016-01-041-8/+14
| | | | | | | | | | | | | 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 layoutswm42015-11-071-11/+0
| | | | Unused; last uses removed with the previous two commits.
* audio: always log channel maps before determining final mapwm42015-10-261-0/+22
| | | | | 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 conversionswm42015-06-271-9/+39
| | | | | 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 commentwm42015-06-271-3/+0
|
* audio: fix channel map fallback selection (again)wm42015-06-251-36/+61
| | | | | | | | | | | | | | | | | | | | 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 handlingwm42015-06-121-17/+33
| | | | | 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 lastwm42015-06-121-3/+4
| | | | | This prevents that the potentially better pick by mp_chmap_sel_fallback() is overridden.
* audio: redo channel map fallback selectionwm42015-05-081-59/+27
| | | | | | | | | | | | | | | | | | | | 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 caseswm42015-04-281-12/+18
| | | | | | | | 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-casewm42015-04-271-3/+3
| | | | | | | | 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 codewm42015-03-151-2/+2
| | | | | | | The consequence was that some AOs (like ao_jack) could not output 8 channels. Fixes #1688.
* chmap_sel: add multichannel fallback heuristicStefano Pigozzi2014-12-291-0/+94
| | | | | | | | | | | | 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 commitwm42014-12-201-4/+4
| | | | | This would have always forced mono first (if supported by the AO), instead of stereo.
* audio: fix fallback if audio API does not support monowm42014-12-201-6/+5
| | | | This makes it fallback to stereo properly.
* audio: fix one of the previous commitswm42014-12-011-1/+1
| | | | | Fixes commit 52c51149. It broke multichannel (or possibly everything) for ao_alsa, ao_oss, ao_sndio.
* audio: allow more than 20 channel map entrieswm42014-12-011-5/+12
| | | | | | | | | | | | | 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 constwm42014-06-111-2/+2
| | | | | | | 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/sdrStefano Pigozzi2014-05-101-16/+21
| | | | | 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 layoutswm42013-07-071-0/+1
|
* audio: add channel map selection functionwm42013-05-121-0/+210
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.