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

Steve Lhomme via Matroska-devel matroska-devel at lists.matroska.org
Wed May 18 09:00:37 CEST 2016

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 ?

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list