Code change:
Each catalog update MUST be mapped to a discreet moq-transport object. <del> 4.1. Object Delivery Order MUST match the Object sequence number. The media object payload: MUST consist of a Segment Type Box (styp) followed by any number of media fragments.  Each media fragment consists of a Movie Fragment Box (moof) followed by a Media Data Box (mdat).  The Media Fragment Box (moof) MUST contain a Movie Fragment Header Box (mfhd) and Track Box (trak) with a Track ID ("track_ID") matching a Track Box in the initialization fragment. MUST contain a single ISOBMFF track. MUST contain media content encoded in decode order.  This implies an increasing decoding time stamp (DTS). MAY contain any number of frames/samples. MAY have gaps between frames/samples. MAY overlap with other objects.  This means timestamps may be interleaved between objects. Two options are RECOMMENDED for packaging CMAF content into WARP media objects: the first is to package a complete CMAF Fragment (see CMAF sect 6.6.1) into a single object within each group.  This results in there being a single GOP (Group of Pictures) in the media object and a single media object per group. The second is to package a CMAF chunk (see CMAF sect 6.6.5), in which the mdat holds a single frame of video, or sample of audio, into each object and to assign a unique group ID to each fragment. This approach is RECOMMENDED to minimize latency. </del> 5. <del> A WARP publisher MUST publish a catalog track object before publishing any media track objects. At the completion of a session, a publisher should publish a catalog object with track count of 0.  This SHOULD be interpreted by receivers that the publish session is complete. </del> <ins> The MOQT Groups and MOQT Objects need to be mapped to moq-transport Streams.  Irrespective of the packagingmode in place, each MOQT Object MUST be mapped to a new moq-transport Stream. </ins> 6. <del> 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. </del> <ins> A WARP publisher MUST publish a catalog track object before publishing any media track objects. </ins> <del> ToDo - details of how keys are exchanged and license servers signalled. </del> <ins> At the completion of a session, a publisher MUST publish a catalog update that removes all currently active tracks.  This action SHOULD be interpreted by receivers to mean that the publish session is complete. </ins> 7.

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.