path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* tests: stop comparing floats against DBL_EPSILON, use FLT_EPSILONIlya Tumaykin2018-02-032-6/+7
| | | | Fixes #5253.
* tests: fix include after 6597998Ilya Tumaykin2017-10-171-1/+1
* chmap_sel: prefer inexact equivalents over perfect upmixwm42016-01-041-3/+8
| | | | | | | | | | | | | 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.)
* tests: fix #includeIlya Tumaykin2015-12-221-1/+1
* audio: fix channel map fallback selection (again)wm42015-06-251-0/+10
| | | | | | | | | | | | | | | | | | | | 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.
* test: update cmocka version to 1.0Stefano Pigozzi2015-06-133-24/+24
* chmap_sel: improve speaker replacement handlingwm42015-06-121-0/+15
| | | | | This didn't really work since the last time the channel map fallback code was touched. In some cases, quite bad results were selected.
* audio: simplify furtherwm42015-05-081-12/+3
| | | | | | 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-24/+0
| | | | It's unsued now.
* audio: redo channel map fallback selectionwm42015-05-081-1/+7
| | | | | | | | | | | | | | | | | | | | 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.
* test: simplify chmap_sel testswm42015-05-081-121/+44
* audio: remove UNKNOWN pseudo speakerswm42015-05-071-3/+1
| | | | | | 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: avoid downmixing in a certain special-casewm42015-04-271-0/+17
| | | | | | | | 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.)
* vo_opengl: add gamma-auto optionStefano Pigozzi2015-03-042-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]:
* chmap_sel: add multichannel fallback heuristicStefano Pigozzi2014-12-293-0/+229
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.