5 Media Codecs

26.2233GPPMedia handling and interactionRelease 18Telepresence using the IP Multimedia Subsystem (IMS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Speech

TP clients in terminals offering speech communication shall support super-wideband and full-band audio as per below.

TP clients in terminals offering speech communication shall support,

– super-wideband and full-band through EVS codec (3GPP TS 26.441 [27], 3GPP TS 26.442 [28], 3GPP TS 26.452 [49], 3GPP TS 26.445 [29] and 3GPP TS 26.443 [47]) including functions for discontinuous transmission (3GPP TS 26.450 [30]).

To support transcoder-free interworking with MTSI clients, a TP UE shall additionally offer lower bandwidth (e.g. NB, WB) speech communication as per below.

TP clients in terminals offering speech communication shall support,

– wideband through EVS AMR-WB IO mode (3GPP TS 26.446 [46]) or AMR-WB codec (3GPP TS 26.171 [31], 3GPP TS 26.190 [32], 3GPP TS 26.173 [33] and 3GPP TS 26.204 [34]) including all 9 modes and source controlled rate operation ‎3GPP TS 26.193 [45].

– narrowband through AMR speech codec (3GPP TS 26.071 [35], 3GPP TS 26.090 [36], 3GPP TS 26.073 [37] and 3GPP TS 26.104 [38]) including all 8 modes and source controlled rate operation ‎3GPP TS 26.093 [44].

5.2 Video

TP clients in terminals offering video communication shall support:

– H.264 (AVC) [16] Constrained High Profile (CHP), Level 3.1

To support transcoder-free interworking with MTSI clients, TP clients in terminals offering video communication shall also support:

– H.264 (AVC) [16] Constrained Baseline Profile (CBP), Level 1.2

In addition, TP UEs shall support:

– H.265 (HEVC) [17] Main Profile, Main Tier, Level 4.1

Furthermore, TP UEs should support:

– H.265 (HEVC) [17] Screen-Extended Main, Main Tier, Level 4.1

– H.265 (HEVC) [17] Screen-Extended Main 4:4:4, Main Tier, Level 4.1

H.264 (AVC) CHP shall be used, without requirements on output timing conformance (annex C of [16]). Each sequence parameter set of H.264 (AVC) shall contain the vui_parameters syntax structure including the num_reorder_frames syntax element set equal to 0.

H.265 (HEVC) Main, Screen-Extended Main, and Screen-Extended Main 4:4:4 profiles shall be used with general_progressive_source_flag equal to 1, general_interlaced_source_flag equal to 0, general_non_packed_constraint_flag equal to 1, general_frame_only_constraint_flag equal to 1, and sps_max_num_reorder_pics[ i ] equal to 0 for all i in the range of 0 to sps_max_sub_layers_minus1, inclusive, without requirements on output timing conformance (annex C of [17]).

For both H.264 (AVC) and H.265 (HEVC), the decoder needs to know the Sequence Parameter Set (SPS) and the Picture Parameter Set (PPS) to be able to decode the received video packets. A compliant H.265 (HEVC) bitstream includes a Video Parameter Set (VPS), although the VPS may be ignored by the decoder in the context of the present specification. When H.264 (AVC) or H.265 (HEVC) is used it is recommended to transmit the parameter sets within the SDP description of a stream, using the relevant MIME/SDP parameters as defined in RFC 6184 [18] for H.264 (AVC) and in [19] for H.265 (HEVC), respectively. Each media source (SSRC) shall transmit the currently used parameter sets at least once in the beginning of the RTP stream before being referenced by the encoded video data to ensure that the parameter sets are available when needed by the receiver. If the video encoding is changed during an ongoing session such that the previously used parameter set(s) are no longer sufficient then the new parameter sets shall be transmitted at least once in the RTP stream prior to being referenced by the encoded video data to ensure that the parameter sets are available when needed by the receiver. When a specific version of a parameter set is sent in the RTP stream for the first time, it should be repeated at least 3 times in separate RTP packets with a single copy per RTP packet and with an interval not exceeding 0,5 seconds to reduce the impact of packet loss. A single copy of the currently active parameter sets shall also be part of the data sent in the RTP stream as a response to FIR. Moreover, it is recommended to avoid using a sequence or picture parameter set identifier value during the same session to signal two or more parameter sets of the same type having different values, such that if a parameter set identifier for a certain type is used more than once in either SDP description or RTP stream, or both, the identifier always indicates the same set of parameter values of that type.

The video decoder in a multimedia TP client in terminal shall either start decoding immediately when it receives data, even if the stream does not start with an IDR/IRAP access unit (IDR access unit for H.264, IRAP access unit for H.265) or alternatively no later than it receives the next IDR/IRAP access unit or the next recovery point Supplemental Enhancement Information (SEI) message, whichever is earlier in decoding order. The decoding process for a stream not starting with an IDR/IRAP access unit shall be the same as for a valid video bit stream. However, the TP client in terminal shall be aware that such a stream may contain references to pictures not available in the decoded picture buffer. The display behaviour of the TP client in terminal is out of scope of the present document.

A TP client in terminal offering video support other than H.264 CHP Level 3.1 shall also offer H.264 CHP Level 3.1.

A TP UE client in terminal offering H.265 (HEVC) shall support negotiation to use a lower Level than the one in the offer, as described in [19] and [20].

To support interworking with MTSI clients, a TP UE shall offer both H.264 CBP Level 1.2 and H.264 CHP Level 3.1 (with preference for the latter) and should also offer H.264 CBP Level 3.1.

In case a codec profile is offered with a Level higher than the required Level, no separate offer for the required Level is needed.

A TP client in terminal offering H.264 (AVC) CHP support at a level higher than Level 3.1 shall support negotiation to use a lower Level as described in [18] and [20].

A TP client in terminal offering H.264 (AVC) CBP support at a level higher than Level 1.2 shall support negotiation to use a lower Level as described in [18] and [20].

A TP client in terminal offering H.264 (AVC) CBP support at a level higher than Level 3.1 shall support negotiation to use a lower Level as described in [18] and [20].

NOTE 1: All levels are minimum requirements. Higher levels may be supported and used for negotiation.

NOTE 2: TP clients in terminals may use full-frame freeze and full-frame freeze release SEI messages of H.264 (AVC) to control the display process. For H.265 (HEVC), MTSI clients may set the value of pic_output_flag in the slice segment headers to either 0 or 1 to control the display process.

NOTE 3: An H.264 (AVC) encoder should code redundant slices only if it knows that the far-end decoder makes use of this feature (which is signalled with the redundant-pic-cap MIME/SDP parameter as specified in RFC 6184 [18]). H.264 (AVC) encoders should also pay attention to the potential implications on end‑to‑end delay. The redundant slice header is not supported in H.265 (HEVC).

NOTE 4: If a codec is supported at a certain level, it implies that on the receiving side, the decoder is required to support the decoding of bitstreams up to the maximum capability of this level. On the sending side, the support of a particular level does not imply that the encoder will produce a bitstream up to the maximum capability of the level. This method can be used to set up an asymmetric video stream. For H.264 (AVC), another method is to use the SDP parameters ‘level-asymmetry-allowed’ and ‘max-recv-level’ that are defined in the H.264 payload format specification, [18]. For H.265 (HEVC) it is possible to use the SDP parameter ‘max-recv-level-id’ defined in the H.265 payload format specification, [19], to indicate a higher level in the receiving direction than in the sending direction.

NOTE 5: For H.264 (AVC) and H.265 (HEVC), respectively, multiple sequence and picture parameter sets can be defined, as long as they have unique parameter set identifiers, but only one sequence and picture parameter set can be active between two consecutive IDRs and IRAPs, respectively.

5.3 Real-time Text

The real-time text requirements for MTSI clients in terminals specified in TS 26.114 [2], clause 5.2.3, also apply for TP UEs.

5.4 Still Images

The still images requirements for MTSI clients in terminals specified in TS 26.114 [2], clause 5.2.4, also apply for TP UEs.