[Matroska-devel] [Cellar] Channel Positions for Multichannel LPCM Track Inside Matroska

Hendrik Leppkes via Matroska-devel matroska-devel at lists.matroska.org
Wed May 18 09:39:29 CEST 2016

On Wed, May 18, 2016 at 9:00 AM, Steve Lhomme <slhomme at matroska.org> wrote:
> 2016-05-18 8:44 GMT+02:00 Hendrik Leppkes <h.leppkes at gmail.com>:
>> On Wed, May 18, 2016 at 8:38 AM, Steve Lhomme via Matroska-devel
>> <matroska-devel at lists.matroska.org> wrote:
>>> 2016-05-10 11:17 GMT+02:00 Nithin Mathew Kurien <nithinmkurien at gmail.com>:
>>>> Hi,
>>>> On Sun, May 8, 2016 at 5:35 PM, Steve Lhomme <slhomme at matroska.org> wrote:
>>>>> 2016-04-24 17:39 GMT+02:00 Nithin Mathew Kurien <nithinmkurien at gmail.com>:
>>>>> > Hi,
>>>>> >
>>>>> > Currently the specification for storing a multichannel LPCM track
>>>>> > (CodecID
>>>>> > A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way to
>>>>> > indicate the channel positions of the track. Due to this, players find
>>>>> > it
>>>>> > difficult to map the channels to the correct speaker positions when
>>>>> > playing
>>>>> > such a track. MakeMKV employs a workaround for this problem. It stores
>>>>> > the
>>>>> > track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE
>>>>> > structure in CodecPrivate. This structure contains a field called
>>>>> > dwChannelMask which specifies the channel positions [3]. This is
>>>>> > identical
>>>>> > to the way LPCM is stored inside AVI files. The problem with this
>>>>> > approach
>>>>> > is that most players do not recognise the CodecID A_MS/ACM, except for a
>>>>> > few
>>>>> > open-source players like Kodi [4].
>>>>> We used to have a field for that but it was never used AFAIK
>>>>> https://matroska.org/technical/specs/index.html#ChannelPositions
>>>>> This is how it used to be, describing each speaker position with an
>>>>> angle. I don't know there is a standard way to express this. I'd
>>>>> assume the distance to the center should play a role too.
>>>>> https://web.archive.org/web/20071211091532/http://www.matroska.org/technical/specs/channelposition/index.html
>>>> This notation is appropriate for speaker positions in the horizontal plane,
>>>> but there is a problem. The LFE channel is omni-directional; so how do we
>>>> denote whether the LFE channel is present or not, in this notation?
>>> I agree, it's not sufficient. The idea was that it would be universal
>>> enough to cover mapping from all existing formats (which should be our
>>> goal). But missing LFE is a problem. Also you're right, there could be
>>> speakers up and down. So maybe a spherical position (2 angles ?), the
>>> type of frequency carried (LFE or all or all except LFE) and maybe an
>>> optional distance ?
>> Honestly who is ever going to convert all sorts of  information into
>> this format, and back?
> Back is not always an option. We could support features that don't
> exist elsewhere. There's not always to fit everything we support into
> other formats.
>> Mappings to established channel order fields would be extremely
>> complex, which would result in it not getting used and the MS mode
>> staying the choice of mode to store multichannel PCM.
>> Why not offer a bog-standard WAV-like channel order field?
> As long as it supports everything under the sun and more, it's fine.
> Can it handle Dolby Atmos mapping ?

Atmos is object-based audio, it does not conform to any sort of
channel mapping, as it requires the decoder to "map" it to the
speakers the user has, so in short, its different to everything else
and the codec itself should just handle it.

But that seems to be the answer to everything recently isn't it, why
chose something that works everywhere else when we can invent
something infinitely more complex to cover the last specific edge
Its really not a direction I like. Give us something that works and
doesn't require infinite complexity to be able to store or extract the
same information as other containers.

- Hendrik

More information about the Matroska-devel mailing list