[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 08:44:11 CEST 2016
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>:
>> 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 . 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 .
>>> We used to have a field for that but it was never used AFAIK
>>> 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.
>> 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?
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?
More information about the Matroska-devel