MBMS OV - (11 - TBC) Transmission in MBMS and E-MBMS

To be completed later

MBMS OV - (10) Data formats, Media Types and Codec in MBMS

1.1. Data formats and Media Types in MBMS

Media types shall be supported independent of specific data types and formats behind. As a minimum MBMS User Services shall support the following media types:

- Text

It shall be possible to embed hyperlinks and to decorate text within content provided by MBMS User Services.

- Still Images

- Video

- Speech

- Mono/Stereo Audio

- Data format and data types as being used by other multimedia services shall be supported for interoperability reasons.

- MBMS User Services shall ensure service interoperability with respect to media formats and codecs, at the same time being able to re-use existing multimedia capabilities in the UE as far as possible.

- Therefore MBMS User Services shall support a minimum set of media formats and codecs. This minimum set should be aligned with the set of media formats and codecs required for MMS and PSS.

1.2. Media Codecs and Formats

- The set of media decoders that are supported by the MBMS Client to support a particular media type are defined below.

- Speech, Audio, Video, Timed Text and Scene description media decoders are relevant for both MBMS Download and Streaming delivery.

- Other media decoders are only relevant for MBMS Download delivery.

1. Speech

- If speech is supported, the AMR decoder shall be supported for narrow-band speech 3GPP TS 26.071, 3GPP TS 26.090, 3GPP TS 26.073 and 3GPP TS 26.107.

- The AMR wideband speech decoder, 3GPP TS 26.171, 3GPP TS 26.190, 3GPP TS 26.173 and 3GPP TS 26.204, shall be supported when wideband speech working at 16 kHz sampling frequency is supported.

2. Audio

- If audio is supported, then the following two audio decoders should be supported:

- Enhanced aacPlus 3GPP TS 26.401, 3GPP TS 26.410 and 3GPP TS 26.411.

- Extended AMR-WB 3GPP TS 26.290, 3GPP TS 26.304 and 3GPP TS 26.273.

3. Synthetic audio

- If synthetic audio is supported, the Scalable Polyphony MIDI (SP-MIDI) content format defined in Scalable Polyphony MIDI Specification and the device requirements defined in Scalable Polyphony MIDI Device 5-to-24 Note Profile for 3GPP should be supported.

- SP-MIDI content is delivered in the structure specified in Standard MIDI Files 1.0, either in format 0 or format 1.

- In addition the Mobile DLS instrument format and the Mobile XMF content format defined in should be supported.

- Content that pairs Mobile DLS and SP-MIDI resources is delivered in the structure specified in Mobile XMF. A Mobile XMF file shall contain one SP-MIDI SMF file and no more than one Mobile DLS file. Media handling behaviours for the SP-MIDI SMF and Mobile DLS resources contained within Mobile XMF.

4. Video

H.264 (AVC)

- The H.264 (AVC) decoder in an MBMS client should infer missing macro blocks in a coded picture.

- The H.264 (AVC) decoder in an MBMS client should infer an unintentional reference picture loss.

- The H.264 (AVC) decoder in an MBMS client should infer a syntax violation, when decoding causes any syntax or semantics violation other than specified above.

- When the H.264 (AVC) decoder in an MBMS client infers missing macro blocks in a non-reference picture, it should continue decoding no later than from the next access unit in decoding order.

- When the H.264 (AVC) decoder in an MBMS client infers an unintentional reference picture loss or missing macroblocks in a reference picture, it may or may not continue decoding "immediately", i.e. from the NAL unit in which the loss is inferred.

- If the H.264 (AVC) decoder in an MBMS client continues decoding "immediately", it should be aware that such a stream may contain references to macroblocks or pictures that are not available in the decoded picture buffer.

- The H.264 (AVC) decoder in an MBMS client should continue decoding after an unintentional reference picture loss, missing macroblocks in a reference picture or a syntax violation no later than it receives the next IDR access unit or the next recovery point SEI message, whichever is earlier in decoding order.

Encoding and Packetization Recommendations

- The following recommendations are given to MBMS encoders and packetizers to optimize the tradeoff between loss rates and throughput for MBMS video services:

* The encoder/packetizer should choose a suitable IP packet size for the loss regime and other network characteristics

* When H.264/AVC is in use and FEC is in use, the encoder may produce NAL units larger than the suitable IP/RTP packet size.

* When H.264/AVC is in use and in any case when larger NAL units are produced by the encoder, the packetizer should use NAL Unit fragmentation as specified in RFC 3984, to adapt the RTP packet size to the network, and not produce large RTP packets

- If video is supported, H.264 (AVC) Baseline Profile Level 1.2 decoder (ITU-T Recommendation H.264 and ISO/IEC 14496-10/FDAM1: "AVC Fidelity Range Extensions") with constraint_set1_flag=1 and without requirements on output timing conformance (annex C of ITU-T Recommendation H.264) should be supported.

- When H.264 (AVC) is in use in the MBMS streaming delivery method, it is recommended to transmit H.264 (AVC) parameter sets within the SDP description of a stream (using sprop-parameter-sets MIME/SDP parameter - RFC3984), and it is not recommended to transmit parameter sets within the RTP stream.

- The H.264 (AVC) decoder in an MBMS client shall start decoding immediately when it receives data (even if the stream does not start with an IDR access unit) or alternatively no later than it receives the next IDR access unit or the next recovery point SEI message, whichever is earlier in decoding order.

5. Still images

If still images are supported, ISO/IEC JPEG together with JFIF decoders shall be supported. The support for ISO/IEC JPEG only applies to the following two modes:

- baseline DCT, non-differential, Huffman coding, as defined in table B.1, symbol 'SOF0' in 3GPP TS 26.273

- progressive DCT, non-differential, Huffman coding, as defined in table B.1, symbol 'SOF2' 3GPP TS 26.273

6. Bitmap graphics

If bitmap graphics is supported, the following bitmap graphics decoders should be supported:

- GIF87a

- GIF89a

- PNG

7. Vector graphics

If vector graphics is supported, SVG Tiny 1.2 and ECMAScript shall be supported.

8. Text

The text decoder is intended to enable formatted text in a SMIL presentation. If text is supported, a MBMS client shall support

- text formatted according to XHTML Mobile Profile

- rendering a SMIL presentation where text is referenced with the SMIL 2.0 "text" element together with the SMIL 2.0 "src" attribute.

If text is supported, the following character coding formats shall be supported:

- UTF-8

- UCS-2.

NOTE: Since both SMIL and XHTML are XML based languages it would be possible to define a SMIL plus XHTML profile. In contrast to the presently defined SMIL Language Profile that only contain SMIL modules, such a profile would also contain XHTML modules. No combined SMIL and XHTML profile is specified for MBMS.

9. Timed text

- If timed text is supported, MBMS clients shall support 3GPP TS 26.245. Timed text may be transported over RTP or downloaded contained in 3GP files using Basic profile.

NOTE: When a MBMS client supports timed text it needs to be able to receive and parse 3GP files containing the text streams. This does not imply a requirement on MBMS clients to be able to render other continuous media types contained in 3GP files, e.g. AMR, if such media types are included in a presentation together with timed text. Audio and video are instead streamed to the client using RTP.

10. 3GPP file format

- An MBMS client shall support the Basic profile and the Extended presentation profile of the 3GPP file format 3GPP TS 26.244 (3GP).

11. Scene Description

- If scene description is supported, MBMS clients shall support 3GPP DIMS TS 26.142 (Dynamic and Interactive Multimedia Scenes)