summaryrefslogtreecommitdiffstats
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* misc: add linked list helperswm42018-05-241-0/+162
| | | | | | | | | | | | | | | | This provides macros for managing intrusive doubly linked lists. There are many ways how to do those in a "generic" way in C. For example Solaris style lists are pretty nice: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/list.h https://github.com/illumos/illumos-gate/blob/master/usr/src/common/list/list.c I even have an independent implementation of this, which could be ISC licensed. But I think it's easier to vomit ~100 lines of preprocessor garbage, which has a lower footprint, and I think it wins slightly on the side of type safety, simplicity, and ease of use, even if it doesn't look as magically nice.
* json: add some non-standard extensionswm42018-05-241-3/+13
| | | | | Also clarify this and previously existing differences to standard JSON in ipc.rst.
* json: format slightly nicer escape sequenceswm42018-05-241-1/+2
| | | | | | Make use the escape sequences allowed by JSON. Also update the linked RFC to the newest one.
* test: add tests for json parser/formatterwm42018-05-241-0/+86
| | | | This should have been done sooner.
* 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 http://www.color.org/chardata/rgb/srgb.xalter). 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]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
* 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.