Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching set using single initialization constraints #43

Open
nicholas-fr opened this issue Oct 3, 2022 · 2 comments
Open

Switching set using single initialization constraints #43

nicholas-fr opened this issue Oct 3, 2022 · 2 comments
Labels
Deferred Deferred to future work

Comments

@nicholas-fr
Copy link

Currently we have tracks conforming to "general constraints" and to "single initialization constraints" as they are referred to in CMAF in clause 9.2.11. However, we only have a switching set that switches between tracks conforming to general constraints (for test 8.5 switching set playback).

Do we need a second switching set composed of tracks confirming to single initialization constraints (as defined in CMAF clause 9.2.11.4)?

For such a switching set, for AVC we only have tracks t2 and t15 to choose from currently.
It would seem appropriate to have tracks with different codec levels, as well as tracks with different resolutions and frame rates and bitrates. We could create variants of the tracks used for ss1 that conform to single initialization constraints (t19,t20,t23,t24,t25,t28,t32,t34).

Is this something we need to address?

@nicholas-fr
Copy link
Author

To further clarify, to my understanding there are 3 initialisation switching use cases:

  1. Single/common CMAF Header (w/ sample entry for each track i.e. multiple sample entries) + fragments without in-band parameter sets (avc1).
  2. Single/common CMAF Header (without parameter sets) + fragments with in-band parameter sets (avc3).
  3. Multiple CMAF Headers (with sample entry, 1 for each track) + fragments without parameter sets (avc1).

I believe our current switching set (ss1) test 8.5 addresses use case 3 (multiple initialization switching).
The other 2 use cases are single initialization switching (as defined in CMAF 7.3.4.2), which we don't test.

Do we need to define additional switching set tests?

@nicholas-fr
Copy link
Author

To summarize, after further review I believe there are the following 5 cases:

Single initialization:

  1. Common CMAF header in all tracks, containing sample entries sufficient to decode and display every track (i.e. with parameter sets) + fragments without in-band parameter sets (avc1).
  2. Common CMAF header in all tracks, without sample entries (i.e. without parameter sets) + fragments with in-band parameter sets (avc3).
  3. Common CMAF header in all tracks, containing sample entries sufficient to decode and display every track (i.e. with parameter sets) + fragments with in-band parameter sets (avc3).

Multiple initialization:

  1. Different CMAF header per track, containing sample entry sufficient to decode and display the track (i.e. with parameter sets) + fragments without in-band parameter sets (avc1).
  2. Different CMAF header per track, without sample entry (i.e. without parameter sets) + fragments with in-band parameter sets (avc3).

New tests and test content (switching sets) are needed to cover the different initialization constraints allowed for switching set playback (8.5).

The current 8.5 test and test vectors used to form switching set ss1 (t19,t20,t23,t24,t25,t28,32,t34) cover what's referred to in the AVC test content sparse matrix as:

  • "Regular Switching Set, do not apply CMAF clause 7.3.4.2 and 9.2.11.4"

This matches with case 4 from the list referenced above:

  1. Different CMAF header per track, containing sample entry sufficient to decode and display the track (i.e. with parameter sets) + fragments without in-band parameter sets (avc1).

So the current tests do not cover single initialization.

I believe the next step is to confirm which of the 3 single initialization cases are relevant (based on input from MPEGGroup/CMAF#41 and any comments here).

@gitwjr gitwjr added the Deferred Deferred to future work label Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deferred Deferred to future work
Projects
None yet
Development

No branches or pull requests

2 participants