- What it is: the Coded Multisource Media Format, a container for media in one or more coded representations, specified in ETSI TS 103 973.
- Why: several sources each hold a different coded version of the same media, so a client can draw from all of them at once.
- Not a new media format: an encoder takes an already packaged format, such as ISO BMFF or CMAF, as its source.
Why multisource
Media delivery today relies on a single representation of the coded media across storage, distribution and delivery (ETSI TS 103 973 V1.2.2 clause 4.0). CDNs copy media to many points of presence, but a client is usually served through one network path from one CDN until it switches, and switching is not always seamless. Services that use several CDNs replicate identical representations in each of them.
CMMF moves from a single encoded version of the source media to multiple coded representations, each a unique, useful version (ETSI TS 103 973 V1.2.2 clause 4.0). A client can then balance its load across the best-performing paths and sources, and less redundant information is stored and transmitted. One CMMF bitstream may hold everything needed to reconstruct the source; in other uses, several bitstreams are needed.
CMMF is designed as an additional, independent layer in the media delivery stack (ETSI TS 103 973 V1.2.2 clause 4.0; ETSI TS 103 973 V1.2.2 clause 4.1). It supplements packaged formats, and does not replace them.
Creating and decoding a CMMF bitstream
Encoding, in real time or from a file: (ETSI TS 103 973 V1.2.2 clause 4.2.1)
1 (ETSI TS 103 973 V1.2.2 clause 4.2.1). Partition the source data into source blocks. 2 (ETSI TS 103 973 V1.2.2 clause 4.2.1). Partition each source block into source symbols of equal size, padding the last symbol with zeros if necessary. 3 (ETSI TS 103 973 V1.2.2 clause 4.2.1). Encode the source symbols with the chosen code type into coded symbols, together with the coding parameters a decoder needs, such as the symbol index, the block index, a coefficient vector or a pseudo-random number generator seed.
Coded and repair symbols can be packaged one by one, grouped by block, or grouped across several blocks (ETSI TS 103 973 V1.2.2 clause 4.2.2; ETSI TS 103 973 V1.2.2 clause 4.2.1). Besides block coding, CMMF supports sliding-window constructions for use cases with strict latency, where the source is not available in full at once.
Decoding reverses the steps: decode each block's coded symbols into source symbols, concatenate them and remove the padding, then concatenate the blocks into the original media (ETSI TS 103 973 V1.2.2 clause 4.2.3).
Code types
| code_type | Code |
|---|---|
| 0 | xCD-1, defined in annex A of TS 103 973 |
| 1 (ETSI TS 103 973 V1.2.2 clause 6.1.4.5) | Raptor, RFC 5053 |
| 5 (ETSI TS 103 973 V1.2.2 clause 6.1.4.5) | Reed-Solomon over GF(2^8), RFC 5510 |
| 6 (ETSI TS 103 973 V1.2.2 clause 6.1.4.5) | RaptorQ, RFC 6330 |
Client devices decode at least one of the supported code types (ETSI TS 103 973 V1.2.2 clause 6.1.4.5). Raptor is also the FEC scheme of MBMS download, and RaptorQ that of ROUTE Repair Flows (TS 26.346 V19.3.0 clause 7.2.2; TS 26.346 V19.3.0 clause 7.2.12.1; RFC 9223 section 2.4). When CMMF is used as a content delivery protocol in the sense of RFC 5052, the data is partitioned with the algorithm of RFC 5052 section 9.1, and the FEC Object Transmission Information is carried in the bitstream (ETSI TS 103 973 V1.2.2 clause 6.1.4.6; RFC 5052 section 9.1).
Delivery architecture
TS 103 973 gives a notional reference architecture with four components:
- Application Provider: produces the source media and configures the service (ETSI TS 103 973 V1.2.2 clause 4.3.3). It holds the source transport objects (for example CMAF, DASH or HLS segments), the media information (such as manifests) and, where it is aware of CMMF, the CMMF configuration information.
- CMMF Bitstream Generator/Source: generates CMMF bitstreams of coded representations of the source transport objects (ETSI TS 103 973 V1.2.2 clause 4.3.3). There may be one, next to the Application Provider, or one at each point of presence, creating bitstreams in real time or offline.
- CMMF Receiver: obtains CMMF bitstreams from one or more generators, decodes them and recovers the source media (ETSI TS 103 973 V1.2.2 clause 4.3.3). It needs no single bitstream in full, only enough data from all of them; it may also combine parts of source objects with coded ones.
- Media Application/Client: plays back the recovered media, and may steer the receiver (ETSI TS 103 973 V1.2.2 clause 4.3.3).
Reference points join them: C1 to C6 for media and configuration information, S1 and S2 for unmodified source transport objects, S3 for source transport objects from the CMMF Receiver to the Media Application/Client, R1 for coded and repair transport objects, and M1 for control from the client to the receiver (ETSI TS 103 973 V1.2.2 clause 4.3.3).
Objects are organised as transport objects in a delivery session made of one or more transport sessions, identified, for example, by a TOI and a TSI, as in FLUTE (ETSI TS 103 973 V1.2.2 clause 4.3.2).
Content delivery protocols
Annex D of TS 103 973 maps CMMF to the FEC building block principles of RFC 5052, and defines two content delivery protocol (CDP) instantiations:
- FDT-based: the configuration information is a File Delivery Table as defined in RFC 6726, with minimum extensions for CMMF: the Extended FDT (EFDT). It reuses FDT extensions from TS 26.346.
- URL translation-based: a CMMF configuration information document gives the procedures that map the URL of a source object to the URLs of its CMMF transport objects (ETSI TS 103 973 V1.2.2 clause D.3.1; ETSI TS 103 973 V1.2.2 clause D.3.3.2.1).
Bitstream profiles
Annex F defines bitstream profiles (ETSI TS 103 973 V1.2.2 clause F.0). A set of bitstreams for the same source conforms to a profile for a code type when every bitstream conforms and the set holds enough coded symbols for a decoder of that code type to rebuild the source.
The text is not consistent on the code types
Table 40 in clause 6.1.4.5 assigns code_type 0 to xCD-1 (annex A), 1 to Raptor (RFC 5053), 5 to Reed-Solomon (RFC 5510) and 6 to RaptorQ (RFC 6330); annex F gives required fields for code_types 0, 1, 5 and 6 (ETSI TS 103 973 V1.2.2 clause 6.1.4.5; ETSI TS 103 973 V1.2.2 Introduction (Motivation)). This page lists table 40.
Sources for this page
- At a glance: ETSI TS 103 973 V1.2.2, Scope (clause 1), Introduction, clauses 4.0 and 4.1, annex D (clause D.0), History.
- Why multisource: ETSI TS 103 973 V1.2.2, clauses 4.0 and 4.1 (ETSI TS 103 973 V1.2.2 clause 4.0).
- Creating and decoding: ETSI TS 103 973 V1.2.2, clauses 4.2.1 to 4.2.3 (ETSI TS 103 973 V1.2.2 clause 4.2.1).
- Code types: ETSI TS 103 973 V1.2.2, clause 6.1.4.5 (table 40) and clause 6.1.4.6; TS 26.346 V19.3.0, clause 7.2.12.1; RFC 9223, section 2.4 (ETSI TS 103 973 V1.2.2 clause 6.1.4.5; ETSI TS 103 973 V1.2.2 clause 6.1.4.6; TS 26.346 V19.3.0 clause 7.2.12.1; RFC 9223 section 2.4).
- Delivery architecture: ETSI TS 103 973 V1.2.2, clauses 4.3.2 and 4.3.3 (ETSI TS 103 973 V1.2.2 clause 4.3.3).
- Content delivery protocols: ETSI TS 103 973 V1.2.2, clauses D.0, D.2.1 and D.3 (ETSI TS 103 973 V1.2.2 clause D.0; ETSI TS 103 973 V1.2.2 clause D.2.1; ETSI TS 103 973 V1.2.2 clause D.3.1).
- Bitstream profiles: ETSI TS 103 973 V1.2.2, clause F.0 (ETSI TS 103 973 V1.2.2 clause F.0).