Commit Graph

14 Commits

Author SHA1 Message Date
Ilya Tumaykin c7824f7c9d tests: fix include after 6597998 2017-10-17 09:29:02 +02:00
wm4 dac5b598f5 chmap_sel: prefer inexact equivalents over perfect upmix
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.)
2016-01-04 19:17:56 +01:00
Ilya Tumaykin 8673343957 tests: fix #include 2015-12-22 15:18:50 +01:00
wm4 fd1194de3c audio: fix channel map fallback selection (again)
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.
2015-06-25 17:32:00 +02:00
Stefano Pigozzi 63e4cb5163 test: update cmocka version to 1.0 2015-06-13 00:01:58 +02:00
wm4 afdc060bb3 chmap_sel: improve speaker replacement handling
This didn't really work since the last time the channel map fallback
code was touched. In some cases, quite bad results were selected.
2015-06-12 19:23:46 +02:00
wm4 00130651da audio: simplify further
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.)
2015-05-08 21:22:39 +02:00
wm4 8d5924f2c9 audio: remove mp_chmap_contains()
It's unsued now.
2015-05-08 21:14:23 +02:00
wm4 3560a50029 audio: redo channel map fallback selection
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.
2015-05-08 19:33:17 +02:00
wm4 5142b0e3f3 test: simplify chmap_sel tests 2015-05-08 19:29:46 +02:00
wm4 55e777f10b audio: remove UNKNOWN pseudo speakers
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.
2015-05-07 23:20:06 +02:00
wm4 d3c7fd9d7c audio: avoid downmixing in a certain special-case
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.)
2015-04-27 23:21:58 +02:00
Stefano Pigozzi c028d782c1 vo_opengl: add gamma-auto option
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
2015-03-04 10:06:08 +01:00
Stefano Pigozzi 54aea7d5de 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-29 17:56:53 +01:00