CMAF Mapping

[kixelated]

As proposed in #4, I think we can simplify the mapping:

|---------------------|----------------|----------------|-----------------|
| Warp                | Catalog Object | Payload Group  | Payload Object  |
|--------------------:|:---------------|----------------|-----------------|
| CMAF {{CMAF}}       | CMAF Header    | CMAF Segment   | CMAF Fragment   |
|---------------------|----------------|----------------|-----------------|

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.

[wilaw]

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.

[wilaw]

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 https://datatracker.ietf.org/doc/draft-wilaw-moq-cmafpackaging/

The WARP draft needs to be updated to reference this CMAF packaging draft.