add a list of tracks to group them together

[robUx4]

For now this Pull Request just adds the bare minimum that we agree on.

I think we also need

• TrackSetUUID so it can be addressed in tags (this time we can use a proper UUID)
• TagsTrackSetUUID to address a track set (give names in multiple languages)
• TrackSetDisplay to set a quick name for a TrackSet (in addition to tags)
• Set which group is the default one to use
• Set if the group is exclusive or not (other tracks hidden when selected)
• TrackSetType (default, commentary, channel) not sure about the type, the Commentary might be a flag, but the channel might need more info

Fixes #717

[robUx4]

Also it might need a paragraph to explain how it's supposed to work. Except it's a Matroska v5 thing so it can't go in the main spec document. So we need to start a new one for Matroska v5.

cc @mcr @SpencerDawkins I suppose this should be a clean new document and not the previous one augmented with new things.

[hubblec4]

The good is we have a start.
The bad is, you forgot again the Edition.

Why now is there only a generic TrackUID element?
I guess you thought it is more simple, but there is a reason why the 3 track types are separated....
but hey, you are Steve, with a lot of experience of TRACKSETEX :-)

Can you remember that we have implemented the EditionDisplay for the reason, that when a user deletes the Tags, all Edition names are lost, the same will happen here.

To use an UUID is also again a waste of space. Always 16 Bytes are in use. A normal UID is also good and do the same job.

At the first time we also don't need TrackSet-Types.
I use Haali TRACKSETEX is so different ways, this has nothing to do with the Track-Flags.

Sometime it feels I speak with a wall :-)
or you hate me, because all of the feature which I want to implement in Matroska you said always NO. This is now the 4th times.

[robUx4]

but hey, you are Steve, with a lot of experience of TRACKSETEX :-)
Sometime it feels I speak with a wall :-)
or you hate me, because all of the feature which I want to implement in Matroska you said always NO. This is now the 4th times.

Again, keep your sarcasm and personal attacks to yourself. It violates the code of conduct. I have better things to do than endure this.

I guess you thought it is more simple, but there is a reason why the 3 track types are separated....

I don't know the reason. I can't think of why it should be that way. If we have 3 audio commentary tracks and 20 translations for each, we are not going to generate all the possible combinations of tracks, nor just the ones we allow or not. We should list:

• audio track 1 and its 20 translations
• audio track 2 and its 20 translations
• audio track 3 and its 20 translations

Can you remember that we have implemented the EditionDisplay for the reason, that when a user deletes the Tags, all Edition names are lost, the same will happen here.

You're referring to #606. I guess we could do the same, but for the same reasons given in that Pull Request: "tags with TagEditionUID as the target might be sufficient and more versatile.". We even have a section in the specs that says Tag names have priority over strings found in the format: https://github.com/ietf-wg-cellar/matroska-specification/pull/656/files.

To use an UUID is also again a waste of space. Always 16 Bytes are in use. A normal UID is also good and do the same job.

A normal UID is a UUID. The Matroska UIDs are not the usual thing people expect from a UID. Just like with the BCP47 strings languages, going forward we should use IETF technologies when they exist. However, given the value is local to the file so it can be addressed by tags, I guess the same format as TagTrackUID, TagEditionUID, TagChapterUID and TagAttachmentUID would be more logical for code consistency. (in a properly typed language they would have all different incompatible types, so they wouldn't need to have a similar format)

[hubblec4]

I guess you thought it is more simple, but there is a reason why the 3 track types are separated....

I don't know the reason. I can't think of why it should be that way.

One reason is that there must be a way to deselect a track type.
Halli provides this for the subtitles and it so important that this feature is there.

For example:
An mkv with two audio tracks, English and German, and one German subtitle track with the forced captions.
With my Haali TRACKSETEX editor I generate two TrackSet entries.
TrackSet 1: German -> german audio + german forced captions
TrackSet 2: English -> english audio + NO subtitle

When I start this mkv the german audio and the german forced captions are used by default.
To change to English audio I use the second TrackSet this guaranteed me there is no longer a subtitle in use.
And when I want watch in German again I use the first TrackSet.

A next reason is, to have the option not to change a current active track type.
With only one TrackUID element for all track types there is only one option, the track type is present or not.
What is when I don't set a TrackUID to a video track?
Is then no video used?
And is it then always necessary to set a TrackUID to play a video track?