Subject: Re: [Cellar] Status of the ChannelPositions element

From: Tobias Rapp <[email-masked]>
Date: Wed, 4 Oct 2017 15:35:59 +0200

On 25.09.2017 17:33, Steve Lhomme wrote:
> 2017-09-25 17:24 GMT+02:00 Tobias Rapp <[email-masked]>:
>> On 24.09.2017 15:49, Steve Lhomme wrote:
>>> [...]
>>>
>>> I like the 2 elements approach. For stereo, multichannel and
>>> object-based things can be quite different. It's at least good to know
>>> if a track is either 3 of these types (there might be more) before
>>> selecting it. And the way we store the actual mapping for each can be
>>> different. But we need a way to specify how each format is going to be
>>> stored. We may even have 3 elements: multichannel, ac-3 style, binary
>>> blob with a custom mapping.
>>
>>
>> Not sure how channel mapping is done for AC-3. Do you refer to the "Audio
>> Coding Mode"?
>>
>> So it seems we agree that using a "ChannelPositionType" /
>> "ChannelPositionData" element pair would be the most flexible option. What
>> would be the purpose of the third element you mentioned?
> 
> For arbitrary values. For example you have just top and bottom
> channels or north/south/east/west. 

In my two-element proposal this would map to another index value for 
"ChannelPositionType" and an according new data structure variant for 
"ChannelPositionData".

Or did you mean that there is a separate element for each way of storing 
the information and the specification defines that only _one_ of the 
elements is stored per audio track within the file? In that case there 
would be elements like "ChannelPositionMask" (for storing the positions 
as a bitmask), "ChannelPositionAmbisonic" (for storing an ambisonics 
matrix), "ChannelPositionObjects" (for storing a Dolby Atmos object 
mapping), "ChannelPositionCompass" (for storing north/south/east/west), etc.

In the latter case the element identifier would be the "type" indicator 
for the data format. This is also fine with me, if this is preferred.

 > I don't know if there are existing
 > ways to define all kinds of channel formats, or even some formats that
 > are kind of generic and we can reuse.

I currently know of the bitmask approach used in Wave files 
(WAVEFORMATEXTENSIBLE, field "dwChannelMask") and the MP4/ISOBMFF "chnl" 
box which supports named channel configurations, spherical positions or 
objects (ISO/IEC 14496-12:2015E, based on ISO/IEC 23001-8:2013). Now I 
learned a bit about Opus ambisonics.

Finding a way to combine all of these formats into a one-and-only 
generic format looks difficult to me. I guess there will be different 
formats with increasing complexity.

Regards,
Tobias

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 04 Oct 2017 21:09:14 +0200

Hey,

most if not all of you have been in favor of changing the wording from
"timecode" to "timestamp". My objections to such a change aren't
absolute. As I don't feel strongly enough to veto such a change, I'm now in
favor of it.

I've therefore spent the last couple of days changing all of MKVToolNix'
usage of "timecode" to "timestamp", including:

• the code
• all user-visible program output and GUI controls
• all command line options
• all file formats
• the documentation (safe for older usage in NEWS.md)
• all translations

The MKVToolNix programs remain backwards compatible insofar as they will
continue to accept the old options and file formats as well (e.g. mkvmerge
now lists "--timestamp-scale …" in its help output but accepts both
"--timestamp-scale" and "--timecode-scale").

What I'm not a big fan of is mixing different verbiage. That's why I
decided to change everything, even the output of tools such as mkvinfo. I
realize that this may break existing applications that parse mkvinfo's
output. I consider this to be the lesser of several evils:

1. Leaving mkvinfo's output with "timecode" but changing all other output
   and GUI controls to "timestamp" would be confusing to users.
2. Leaving all of MKVToolNix' user-visible output and GUI controls with
   "timecode" but having the specification change to "timestamp" would also
   be confusing to users.
3. Changing all of MKVToolNix to use "timestamp" would break existing
   third-party programs, but it would leave MKVToolNix itself in a
   consistent state with itself and the upcoming changed specification.

I chose 3, also as I don't consider mkvinfo's output to be machine-readable
(if people want stable interfaces they should parse the file itself,
potentially by using existing libraries such as ffmpeg's libavformat, or
use tools whose output is designed to be machine-readable such as
MediaInfo's various formats).

The change is now complete with revision
ab4c565647e335471c70ea5da6bf81eaf9b39f12. If anyone wants to give the
changes a try, you can get new pre-builds for Windows here:

https://mkvtoolnix.download/windows/pre/

Kind regards,
mosu

---

From: hubblec4 <[email-masked]>
Date: Thu, 5 Oct 2017 14:35:20 +0200

Hey,

Thanks for your work in this big task.
I think option 3 is the best. The break of other tools is not so 
important like to stay in synch with the specs.
I'm sure other developers will follow your changes.

Best regards
Martin Below

Am 04.10.2017 um 21:09 schrieb Moritz Bunkus:
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar