According to TS 26.501, Downlink Media Streaming provides the ability for content to be distributed using procedures and protocols defined by 5G Media Streaming as shown in Figure 3A.2.1-1. The detailed procedures for the interfaces and APIs for 5G Media Streaming are defined in TS 26.512.

The present document primarily deals with the segment formats delivered on M4d and the requirements applicable to the media playback platform and content decryption module. According to Figure 3A.2.1-1, the Access Client in the 5GMSd Client uses the manifest, typically the Media Presentation Description (MPD) for Dynamic Streaming over HTTP (DASH) as defined in ISO/IEC 23009-1 [20] and TS 26.247 or the Master Playlist for HTTP Live Streaming (HLS) as defined in IETF RFC 8216 to download Segments to initiate a media playback session. A 5GMSd Application Provider may publish these segments directly through M2d such that the 5GMSd AS acts as a hosting server but does not require the media to be either transcoded or repackaged. Using these unified formats maximizes cacheability and improves general Content Delivery Network (CDN) operations, including usage of secure transport protocols such as HTTPS on interface M4d. 5G Media Streaming segment formats are defined based on the Common Media Application Format (CMAF) as specified in ISO/IEC 23000-19 [7]. By using this format, 5G Media Streaming is compatible with a broad set of segment-based streaming protocols including Dynamic Streaming over HTTP (DASH) and HTTP Live Streaming (HLS). For example, ISO/IEC 23009-1 [20] defines a detailed DASH profile for delivering CMAF content within a DASH Media Presentation using a converged format for segmented media content. Readers of the present document are encouraged to familiarize themselves with terms defined in CMAF such as CMAF Headers, CMAF Fragments, CMAF Tracks and CMAF Switching Sets. CMAF defines a content model for adaptive playback of segmented media (enabling seamless switching across tracks encoded from the same media) and late binding of tracks from different media types, associated with the same presentation. CMAF also defines a content protection and encryption framework for multi-DRM support based on ISO/IEC 23001-7 [8]. Furthermore, CMAF defines media profiles, i.e. encoding constraints on a CMAF track and its contained media samples associated with a specific codec. This specification only uses the structural constraints of CMAF as defined in clause 7 of ISO/IEC 23000-19 [7] and in clause 8 of ISO/IEC 23000-19 [7] for encrypted content. Specific 5GMS media profiles for video, audio and subtitles based on the general constraints of ISO/IEC 23000-19 [7], clauses 9, 10 and 11, respectively, are defined in the present document. However, Downlink Media Streaming is not restricted to the media profiles defined in the present document: any codec that defines a CMAF media profile may be used and distributed with Downlink Media Streaming.

The media playback platform is initiated and used by the Access Client to create a streaming session and experience. The Access Client itself handles the download of segmented media content via interface M4d. This specification is based on a hypothetical playback model that permits an 5GMSd-Aware Application and/or a media Access Client to play back segmented media content streamed via 5G Media Streaming for downlink. Playback receiver requirements for CMAF content are defined in the CTA WAVE Device Playback Specification [9] documenting how an Access Client can use manifest information for establishing and performing playback of CMAF content based on a CMAF Reference Player model. Following the details in Figure 3A.2-1, playback functionalities include:

1. Querying the capabilities of the device to determine if it supports the playback of a specific media profile. Different means exist and are described in CTA-5003 [9], but minimally a well-defined MIME type and a well-defined codecs parameter following the requirements in RFC 6381 is needed.
2. Initializing the playback platform with the codec by providing appropriate initialization information. At minimum, a CMAF Header is needed for initializing the decoder. Initialization of content decryption, if needed, depends on the used DRM system.
3. Playback itself, by appending data to source and track buffers and providing additional instructions such as seek, accelerated playback, random access, etc
4. The ability to check the status of the playback platform, for example the size and duration of the media buffers, current playback time, etc. Relevant APIs exposed by the 5GMSd Client via M7d are defined in TS 26.512.
5. The ability to receive notifications and and error events from the playback platform, for example non-conforming content, buffer unde-runs, etc. Relevant APIs exposed by the 5GMSd Client via M7d are defined in TS 26.512.

In order to use a media codec or a specific media profile of the codec in the context of 5G Media Streaming, the following aspects need to be defined:

• A CMAF media profile definition with all the requirements according to ISO/IEC 23000-19 [7] for a media profile.
• A definition of how capability discovery can be done, at the minimum a suitable and well-defined MIME type following the requirements in RFC 6381, and in particular the definition of the codecs and profiles parameters.
• The mapping of media profile parameters to a DASH MPD. The mapping includes the static information (i.e. fixed parameters in the MPD) and dynamic information (e.g., depending on information in the CMAF Header).
• Potential requirements and restrictions for encrypted content.

This specification defines the above information for several media codecs in clause 4, and provides requirements and recommendations for the support of these media profiles in specific 5G Media Streaming profiles in clause 5.