Unique Identifier for a CMAF Track in a CMAF Presentation

[haudiobe]

There are cases for which you want to uniquely refer to a CMAF Track in a CMAF Presentation from outside. Examples are 1) id in a manifest 2) play this track 3) use only these three tracks 4) Metadata track that refers to tracks of the presentation 5) others

A problem is that the track id is not unique.

Possibly it would even be good to have a hierarchy for reference: presentation.switching_set.track.fragment

Is there anything that supports this or would it be a new requirement?

[mikedo]

5. Others: ATSC/DVB/3GPP external service metadata linkage with non-URL locators, e.g. ROUTE session.

[cconcolato]

I think something similar was proposed by Ali in the past.

[haudiobe]

I think something similar was proposed by Ali in the past.

Yes, we discussed this, but it stopped somehow. I do not wanna overdo, we just need an agreement if something exists and if not, if we need it.

[acbegen]

Well, it is still considered in the CMAF exploration document on CMAF storage. One way or another, we should have this.

[cconcolato]

@acbegen can you update this thread with the latest information from the CMAF exploration? Do you have any recommendation for the CMAF spec itself?

[RufaelDev]

I would suggest a kind box in udta with a schemeUri defined for the identification scheme and then a UUID generated to allow unique track identification as value. Question is if we need to define this scheme in CMAF, for example we could have an annex for identification ? apart from tracks there may be more identifier schemes like for the switching set, content id s etc, that could be carried in a similar manner ? does it make sense or is overloading kind for this inappropriate. We could define a schemeURI for track, switchingset, aligned switchingset, presentation and content type to be used optionally.

[mikedo]

No objection, but can we get more information about the need for a globally unique track identifier in CMAF? If there is a core requirement at the Segment layer, then maybe it should be taken up in FF AHG?

[haudiobe]

The comment includes some discussion around adding kind boxes and alike. This may all be possible, but referring to a track should be done by a simple track_id.

Generally, a better alignment with the file format is proposed, such that concepts from file format can more easily be moved to CMAF.

We propose: 1) Create a new brand ‘cmf1’ that requires a. The track header fulfills all requirements as if the CMAF presentation would be included in a single file b. that each track in the Switching Set has a unique track_id (as if they would be included in a single file) c. a switching set is treated as an alternate group and each switching set gets assigned a unique alternate_group identifier. 2) Use the text in clause 7.8 as a baseline for the new brand, 3) Identify if additional functionalities need to be carried over from the file format.

Addressed here: https://dms.mpeg.expert/doc_end_user/documents/137_OnLine/wg11/m58936-v2-m58936-Issues-r1.zip

[dwsinger]

I can't see a problem with any system, including dash/cmaf, saying that track IDs must be unique within some larger context than within one file; and making that optional by marking the files that obey that rule with a brand also seems OK, but of course verification of that brand is a more than a single-file check

[haudiobe]

I can't see a problem with any system, including dash/cmaf, saying that track IDs must be unique within some larger context than within one file; and making that optional by marking the files that obey that rule with a brand also seems OK, but of course verification of that brand is a more than a single-file check

I agree on all what is said. the issue that restrictions need to hold across files is not new in CMAF, it is also the case for cmfc and cmf2.

[RufaelDev]

@haudiobe we understand the idea ut we are not sure doing this will always be practical working with different files, also in the other issue there was a need for additional identification of switching set, presentation, content type that would not be possible based on the track_id only

[dwsinger]

Actually I do see a problem with the brand. If I have a set of files, marked with this brand, and they have unique trackIDs, we are all good.

Now if I do one of:

• add a file to this set that does not have a unique trackID
• take a file from this set and add it into another set, which has overlapping trackIDs

The assertion the brand makes about this file is no longer true, even though I have not altered the file.

[haudiobe]

Actually I do see a problem with the brand. If I have a set of files, marked with this brand, and they have unique trackIDs, we are all good.

Now if I do one of:

• add a file to this set that does not have a unique trackID
• take a file from this set and add it into another set, which has overlapping trackIDs

The assertion the brand makes about this file is no longer true, even though I have not altered the file.

The problem you are referring to is not a specific to this proposal. This is a general issue in CMAF if you want to make it an issue. We have constraints on switching sets for example, expressed for the brand. If you add a track to the switching set with the same brand, this may invalidate the brand of the other tracks. So while I understand the hypothetical issue, it is not introduced by this proposal.

[haudiobe]

@haudiobe we understand the idea ut we are not sure doing this will always be practical working with different files, also in the other issue there was a need for additional identification of switching set, presentation, content type that would not be possible based on the track_id only

Switching Set is addressed, as you can use the grouping. I believe it solves quite many problems.

[krasimirkolarov]

Addressed in m60334