summaryrefslogtreecommitdiffstats
path: root/audio/chmap.c
Commit message (Collapse)AuthorAgeFilesLines
* chmap: remove misleading "downmix" channel layout namewm42017-06-241-1/+0
| | | | | | | | I'm not even sure when/if FFmpeg produces those. It's just confusing. If you really need this, you can still use dl-dr. I expect that most use is unintentional. Probably fixes #4545.
* player: remove special-case for DL/DR speakerswm42016-08-041-38/+0
| | | | | | Pointless anyway. With superficial checking I couldn't find any decoder which actually outputs this, and AO chmap negotiation would properly ignore them anyway in most cases.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: remove MPlayer layoutswm42015-11-071-26/+0
| | | | Unused; last uses removed with the previous two commits.
* af_lavrresample: don't drop sl/sr channels for 7.1 on ALSAwm42015-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao_alsa: attempt to fix 7.1 over HDMI The last 2 channels of 7.1 (RLC/RRC in ALSA) were exported as sdl/sdr instead of sl/sr (I don't even know why I chose sdl/sdr, but SL/SR and RLC/RRC are different in the ALSA API). libsw/avresample do not move the sl/sr channels to sdl/sdr when rematrixing, so silence was sent for 2 channels. If my selection of sdl/sdr is essentially API abuse, there's no reason why they should do this differently. The mess here is really that ALSa doesn't map the HDMI layouts cleanly. Most ALSA drivers export 7.1 in a way compatible to our expectations, but Intel HDA/HDMI does not: mpv/ffmpeg: fl-fr-fc-lfe-bl-br-sl-sr ALSA/generic: FL FR FC LFE RL RR SL SR [1] ALSA/HDMI: FL FR LFE FC RL RR RLC RRC [2] The HDMI layout is layout 0x13 (going by CEA-861-B). The comment in the kernel code has to be correct too. The early standard defines only 1 other layout, which replaces RLC/RRC with FRC/FLC - this probably corresponds to what we call "7.1(wide)". So it appears when ALSA requests RLC/RRC, we should feed it sl/sr. To make it more complicated, Kodi/xbmc apparently also have to deal with ALSA being special, but instead of sending sl/sr to RLC/RRC, they swap the last two pairs of the layout, and send sl/sr to RL/RR and bl/br to RLC/RRC. Or I might have misunderstood their code. I don't have a 7.1-capable A/V receiver, so I can't test this. For now, go with the simpler solution, and wait until someone tests it. If the speakers end up swapped, a completely different solution will be needed. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/core/pcm_lib.c?id=refs/tags/v4.3#n2434 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/pci/hda/patch_hdmi.c?id=refs/tags/v4.3#n307
* audio: improve mp_chmap_to_lavc_unchecked() unknown chmap behaviorwm42015-10-261-2/+10
| | | | | | | | | | | | | | | | | | | | | | | Change it so that it will always return a bitmask with the correct number of channels set if an unknown channel map is passed. This didn't work for channel counts larger than 8, as there are not any standard channel layouts defined with more than 8 channels (both in mpv and FFmpeg). Instead, it returned 0. This will help when raising the maximum allowed channel count in mpv. Some code in af_lavrresample relies on it, more or less. One change is that unknown channel maps won't result in lavc standard channel layouts anymore, just a set of random speakers. This should be fine, as the caller of mp_chmap_to_lavc_unchecked() should handle these cases. For mp_chmap_reorder_to_lavc() this is not so clear anymore, but should also be ok. For normal channel maps, simply dropping NA channels is still the correct and wanted behavior. Currently, the mpv maximum channel count is 8. This commit is preparation for raising this limit.
* audio: output human-readable channel layouts toowm42015-06-251-0/+19
| | | | | This gets you the "logical" channel layout, instead of the exact thing we're sending to the AO. (Tired of the cryptic shit ALSA gives me.)
* chmap: make up some channel layout nameswm42015-06-121-0/+3
| | | | | Going by the existing names, these should make sense. HDMI knows about these layouts, but does not name them.
* audio: use unknown channel layouts if there is no standard layoutwm42015-06-121-5/+5
| | | | | | | | | This is just a conceptual issue, since for now every channel count has an associated standard layout. But should the max. channel count ever be bumped, some things would stop function if mp_chmap_from_channels() refused to work for any channel count within the allowed range.
* audio: fix messed up channel reorderingwm42015-06-121-2/+2
| | | | Quite a blunder, really.
* chmap: use av_popcount64()wm42015-05-211-9/+3
| | | | Saves us some code, and also happens to fix #1968.
* audio: simplify furtherwm42015-05-081-14/+8
| | | | | | Drop mp_chmap_diff() (which is unused too now), and implement mp_chmap_diffn() in a slightly simpler way. (Too bad there is no standard function for counting set bits.)
* audio: remove mp_chmap_contains()wm42015-05-081-10/+0
| | | | It's unsued now.
* audio: add chmap utility functionwm42015-05-081-0/+9
|
* audio: fix messed up assert()wm42015-05-071-1/+1
| | | | This made no sense and always evaluated to true.
* audio: remove UNKNOWN pseudo speakerswm42015-05-071-6/+6
| | | | | | Reuse MP_SPEAKER_ID_NA for this. If all mp_chmap entries are set to NA, the channel layout has special "unknown channel layout" semantics, which are used to deal with some corner cases.
* audio: define only a single NA speaker IDwm42015-05-071-18/+8
| | | | | Remove the requirement from mp_chmap that speaker entries must be unique. Use this to get rid of all the redundant NA speaker IDs.
* audio: introduce support for padding channelswm42015-05-051-18/+52
| | | | | | | | | | | | | | | | | | | Some audio APIs explicitly require you to add dummy channels. These are not rendered, and only exist for the sake of the audio API or hardware strangeness. At least ALSA, Sndio, and CoreAudio seem to have them. This commit is preparation for using them with ao_coreaudio. The result is a bit messy. libavresample/libswresample don't have good API for this; avresample_set_channel_mapping() is pretty useless. Although in theory you can use it to add and remove channels, you can't set the channel counts. So we do the ordering ourselves by making sure the audio data is planar, and by swapping the plane pointers. This requires lots of messiness to get the conversions in place. Also, the input reordering is still done with the "old" method, and doesn't support padded channels - hopefully this will never be needed. (I tried to come up with cleaner solutions, but compared to my other attempts, the final commit is not that bad.)
* audio: chmap: explicitly drop channels not supported by lavcwm42015-05-041-2/+5
| | | | Basically as before, but avoid undefined behavior.
* audio: drop unused functionwm42015-05-041-9/+0
|
* audio: accept 1.0 and 2.0 as aliases for mono and stereowm42015-02-261-0/+2
|
* chmap_sel: add multichannel fallback heuristicStefano Pigozzi2014-12-291-0/+23
| | | | | | | | | | | | 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.
* chmap: add a 7.1(rear) layout nameStefano Pigozzi2014-12-291-0/+1
| | | | This is common on Apple systems so it's handy to have a label for it.
* audio: make mp_chmap_to_str() return a stack-allocated stringwm42014-11-241-12/+14
| | | | Simplifies memory management.
* options: accept --audio-channels=autowm42014-10-301-0/+1
| | | | This sounds much more intuitive, while "empty" was a bit of a WTF.
* Add more constwm42014-06-111-3/+3
| | | | | | | 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.
* options: fix off-by-1 error in option help outputwm42014-03-151-1/+1
|
* m_option, m_config: mp_msg conversionswm42013-12-211-8/+8
| | | | | | | | Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-1/+1
| | | | Followup commit. Fixes all the files references.
* chmap: fix oddity due to ambiguous 6.1 ffmpeg channel layoutwm42013-05-131-2/+3
| | | | | | | | 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.)
* audio: fix ALSA 4 channel surround outputwm42013-05-131-1/+3
| | | | | | | | | 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.
* audio: add channel map selection functionwm42013-05-121-16/+24
| | | | | | | | | | | | | | | | | | | | 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.
* audio: add channel map APIwm42013-05-121-0/+478
Unused, will be used in the following commits. Let chmap.h define the number of maximum channels, because that is most convenient.