Code change:
3. <del> Each codec bitstream MUST be packaged in to a sequence of Objects within a separate track. </del> <ins> WARP delivers CMAF-packaged media bitstreams.  This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. </ins> <del> Media tracks SHOULD be media-time aligned.  CMAF CMAF Aligned Switching Sets meet this requirement.  A receiver SHOULD be able to cleanly switch between media tracks at group boundaries. </del> <ins> Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to consumers which object mapping mode is being used for a given Track, a new track field is defined as per table 1. </ins> <del> Each group MUST be independently decodeable.  Assigning a new group ID to each CMAF Fragment (see CMAF Sect 6.6.1) meets this requirement. </del> <ins> 3.1. The packaging mode value is defined by Table 2. 3.2. WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements: Time-aligned tracks MUST be advertised in the catalog as belonging to a common render group. The presentation time of the first media sample contained within the first MOQT Object of each equally numbered MOQT Group MUST be identical. A consequence of this restriction is that a WARP receiver SHOULD be able to cleanly switch between time-aligned media tracks at group boundaries. 3.3. The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is the RECOMMENDED encryption method. ToDo - details of how keys are exchanged and license servers signaled.  May be best to extend catalog spec to allow the specification of content protection schema, along with any pssh or protection initialization data. </ins> 4.

Related discussion:
text: Modifies document to reference external CMAF packaging draft. .
As proposed in , I think we can simplify the mapping: To clarify: There are any number of frames in a chunk (moof/mdat pair). There are any number of chunks in a fragment (styp and moof/mdat pairs). There are any number of fragments in a segment. (concatenated together) A fragment* is independently decodable. In order to minimize latency, there should be a chunk per frame, which is the same recommendation as LL-DASH. If the object has a length in the header, then there should be a chunk per fragment too, but I desperately want to avoid that. That way there would be no latency impact for using a single OBJECT for the entire group.
The catalog object has to be more than just a CMAF header, since it must described multiple tracks and also communicate their subscription names. On the GROUP and OBJECT mapping, I agree. The core requirement is that a sequence of OBJECTS is independently decodable if the client starts with the first object in a GROUP. This is satisfied with the restriction that a Group marks a fragment boundary, which is also satisfied by saying that the GROUP MUST represent a segment boundary, since each CMAF segment holds one of more fragments. COnsider the case of a 2s GOP at 30fps. The first OBJECT holds an I frame, the rest Ps. It would be compliant to mark a new GROUP every 30 Objects. It would also be compliant to mark a new group every 60 objects, which is the equivalent of transmitting a 4s segment comprising 2x2s fragments.
As an outcome of the discussions at ETF 117, I wrote an ID to describe how CMAF packaged content can be utilized with moq-transport. This ID is available here URL The WARP draft needs to be updated to reference this CMAF packaging draft.