github/mpv
1
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-11-11 00:15:33 +01:00
Code Releases Activity
15478ca31c
mpv/audio/chmap_sel.h

49 lines
1.7 KiB
C
Raw Normal View History

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-09 15:12:16 +02:00
/*
* This file is part of mpv.
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef MP_CHMAP_SEL_H
#define MP_CHMAP_SEL_H
#include <stdbool.h>
#include "chmap.h"
struct mp_chmap_sel {
// should be considered opaque
bool allow_any, allow_waveext;
bool speakers[MP_SPEAKER_ID_COUNT];
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
struct mp_chmap *chmaps;
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-09 15:12:16 +02:00
int num_chmaps;
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
struct mp_chmap chmaps_storage[20];
void *tmp; // set to any talloc context to allow more chmaps entries
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-09 15:12:16 +02:00
};
void mp_chmap_sel_add_any(struct mp_chmap_sel *s);
void mp_chmap_sel_add_waveext(struct mp_chmap_sel *s);
void mp_chmap_sel_add_waveext_def(struct mp_chmap_sel *s);
void mp_chmap_sel_add_alsa_def(struct mp_chmap_sel *s);
void mp_chmap_sel_add_map(struct mp_chmap_sel *s, const struct mp_chmap *map);
void mp_chmap_sel_add_speaker(struct mp_chmap_sel *s, int id);
bool mp_chmap_sel_adjust(const struct mp_chmap_sel *s, struct mp_chmap *map);
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-28 09:38:22 +01:00
bool mp_chmap_sel_fallback(const struct mp_chmap_sel *s, struct mp_chmap *map);
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-09 15:12:16 +02:00
bool mp_chmap_sel_get_def(const struct mp_chmap_sel *s, struct mp_chmap *map,
int num);
#endif
Copy Permalink