Consider static Descriptor OBUs for both simple and base profiles (one sample entry) about iamf

[sunghee-hwang]

In this case, IA sequence consists of one set of non-redundant Descriptor OBUs and followed by Data OBUs. The configuration of the Descriptor OBUs shall not be changed in the IA sequence. If the Descriptor OBUs need to be placed frequently for an application such as broadcasting or multicasting scenario, each of the Descriptor OBUs shall be marked as redundant by setting its obu_redundant_copy.

[sunghee-hwang]

@tdaede @cconcolato @jwcullen @yeroro,

Let me share my opinions regarding the required description for Standalone and Profile sections.

First of all, I think that we need restricted descriptions for Profiles for the secured implementation for V1.
However, standalone section may be generalized by considering future extension.

For Profiles,

1. IA sequence consists of Descriptor OBUs and follow by Data OBUs.
2. The configuration of Descriptor OBUs are not changed within IA sequence. If they are present in middle of IA sequence, all are marked as redundant.

For generalized Standalone section,

1. Magic Code OBU: I agree with the usage of this OBU to indicate the start of IA sequence and the next non-redundant Magic Code OBU indicates the start of a new IA sequence. So, the first Magic Code OBU or Non-redundant Magic Code OBU substantially enforces for IA decoders to be (re-)initialized.
   : Question is whether or not Magic Code OBU should be present in the middle of IA sequence the other Descriptor OBUs together.
2. Broadcasting Scenario: We need redundant Magic Code OBU anyway in the middle of the IA sequence. Magic Code OBU present the other Descriptor OBUs together.
3. Considering future extension (Short-lived contents): I think that it is one of most complicated scenario. In this case, we need to think of how to describe the situation which a new Audio Element coded by another codec is coming in the middle of the IA sequence. For this,
   : (a) we definitely need a new Audio Element OBU, a new zero or one Codec Config OBU, a new Mix Presentation OBU.
   : (b) A question is where we put the new OBUs.
   .(b-1) If we put them in the first Descriptor OBUs together (already scheduled scenario), then redundant Magic Code OBU presents the other Descriptor OBUs together.
   .(b-2) If we put them right before the new Data OBUs (not scheduled scenario before the service),
   -(c-1) If profile need to be updated. So, we may need Non-redundant Magic Code OBU. It is contradiction with 1.
   -(c-2) If the first Magic Code OBU already had the highest profile,
   .(d-1) we put them only
   .(d-2) we put them the previous Descriptor OBUs excluding Magic Code OBU (marked as redundant) together.
   .(d-3) we put them the previous Descriptor OBUs including Magic Code OBU (marked as redundant) together.

If we consider Broadcasting scenario with Short-lived contents, then I think that we need to take (d-3) which means that Descriptor OBUs including Magic Code OBU comes always together.