Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  18.8.0

Top   Top   Up   Prev   Next
0…   3…   4…   5…   6…   6.2.3…   6.2.5…   6.2.7…   6.2.10…   7…   7.5…   8…   9…   10…   10.2.1.6…   10.2.2…   10.3…   10.4…   11…   12…   12.3…   12.7…   13a…   16…   16.5…   17…   18…   19…   A…   A.3…   A.4…   A.5…   A.10…   A.14…   A.15…   B…   C…   C.1.3…   C.1.3.5   C.2…   D   E…   E.18…   E.31…   G…   K…   L…   M…   N…   O…   P…   P.3   Q…   R…   S…   T…   U…   V…   W…   X…   Y…   Y.6…   Y.6.4…   Y.6.5…   Y.7… 
A.4 SDP offers and answers for video sessions  A.4.2a H.264/AVC  A.4.2b High Granularity CVO example  A.4.2c RTP Retransmission  A.4.2d RTP Forward Error Correction (FEC)  A.4.2e SDP Examples with ROI  A.4.4a H.264/AVC with "imageattr" attribute  A.4.4a.1 H.264/AVC with "imageattr" attribute - different image sizes in SDP offer and answer  A.4.4a.2 H.264/AVC with "imageattr" attribute - different payload type numbers in offer and answer  A.4.4b H.264/AVC with "imageattr" attribute with multiple rtpmaps  A.4.5 H.264 with asymmetric video streams  A.4.6 H.264/AVC with "imageattr" attribute for non-CVO operation  A.4.7 H.264 (AVC) and H.265 (HEVC)  A.4.7.1 MTSI client with 848x480 resolution 5 inch display  A.4.7.2 MTSI client with 1280x720 resolution 5 inch display  A.4.7.3 MTSI client with 848x480 resolution 10 inch display  A.4.7.4 MTSI client with 1280x720 resolution 10 inch display  A.4.8 H.264 (AVC) and H.265 (HEVC) with asymmetric video streams 
...

 

A.4  SDP offers and answers for video sessions  p. 250

A.4.1  Void

A.4.2  Void

A.4.2a  H.264/AVC |R11|  p. 250

In this example the SDP offer includes H.264/AVC.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184). The profile-level-id parameter indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so-called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re-ordered frames to be zero so that latency can be minimized. The bandwidth (including IP, UDP and RTP overhead) for video is restricted to 315 kbps.
The negotiation of AVPF features is also shown. By setting 'trr-int' to 5000 the MTSI client indicates that the minimum interval between two regular RTCP packets needs to be 5 seconds, RFC 4585. The 'nack' and 'nack pli' parameters indicate that the MTSI client supports NACK (Generic NACK) and PLI (Picture Loss Indication) as defined by AVPF, RFC 4585. The 'ccm fir' and 'ccm tmmbr' parameters indicate that the MTSI client supports the FIR (Full Intra Request) and TMMBR (Temporary Maximum Media Stream Bit Rate Request), RFC 5104. The wildcard ('*') indicates that at it is possible to use these features for all RTP payload types for the video stream.
The negotiation of the video orientation header extension is made with the a=extmap attribute, RFC 5285. In this example, the local identifier (ID) is set to '4'. This number is only an example and other values may be used.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The responding MTSI client is capable of using H.264/AVC. As the offer already indicated the lowest level (level 1.2) of H.264/AVC as well as the minimum constraint set, there is no room for further negotiation of profiles and levels. However, the bandwidth could be constrained further by reducing the bandwidth in b=AS.
Up

A.4.2b  High Granularity CVO example |R12|  p. 252

This example is identical to A.4.2a with the exception of higher granularity CVO being offered.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 urn:3gpp:video-orientation:6
The offer for higher granularity is indicated in the last SDP line above.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:5 urn:3gpp:video-orientation:6
The answer indicates that higher granularity has been accepted as indicated by the last SDP line above.
Up

A.4.2c  RTP Retransmission |R13|  p. 252

This example is identical to A.4.2a with the exception of retransmission being offered.
SDP offer 
m=video 49154 RTP/AVP 99 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtpmap:100 rtx/90000
a=fmtp:100 apt=99;rtx-time=400
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 ccm tmmbr
The offer for retransmission and associated parameters are listed after the line describing the format properties of the H.264 video.
SDP answer 
m=video 49154 RTP/AVPF 99 100
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtpmap:100 rtx/90000
a=fmtp:100 apt=99;rtx-time=400
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 ccm tmmbr
The answer indicates that retransmission has been accepted as indicated.
Up

A.4.2d  RTP Forward Error Correction (FEC) |R13|  p. 253

This example is identical to A.4.2a with the exception of FEC being offered.
SDP offer 
m=video 49154 RTP/AVP 99 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtpmap:100 flexfec/90000
a=rtpmap:100 repair-window:150000
a=ssrc:1234
a=ssrc:2345
a=ssrc-group:FEC-FR 1234 2345
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 ccm tmmbr
The offer for FEC and associated parameters are listed after the line describing the format properties of the H.264 video.
SDP answer 
m=video 49154 RTP/AVPF 99 100
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtpmap:100 flexfec/90000
a=rtpmap:100 repair-window:150000
a=ssrc:1234
a=ssrc:2345
a=ssrc-group:FEC-FR 1234 2345
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 ccm tmmbr
The answer indicates that FEC has been accepted as indicated.
Up

A.4.2e  SDP Examples with ROI |R13|  p. 254

This example is identical to A.4.2a with the exception of 'Arbitrary ROI' and 'Sent ROI' being offered.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-arbitrary
a=extmap:7 urn:3gpp:roi-sent
The offer for 'Arbitrary ROI' and 'Sent ROI' are indicated in the last two lines.
The use of RTCP feedback messages carrying 'Arbitrary ROI' is negotiated with the '3gpp-roi-arbitrary' parameter. The wildcard ('*') indicates that it is possible to use the ROI features for all RTP payload types including video.
The use of the 'Sent ROI' header extension carrying arbitrary ROI information is negotiated with the a=extmap attribute (RFC 5285) based on the URN 'urn:3gpp:roi-sent'. In this example, the local identifier (ID) is set to 7, which is only an example. Other values may be used as long as a distinct ID is assigned for each extmap attribute corresponding to different URNs.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-arbitrary
a=extmap:7 urn:3gpp:roi-sent
The answer indicates that both 'Arbitrary ROI' and 'Sent ROI' have been accepted.
The following example is identical to A.4.2a with the exception of 'Pre-defined ROI' and 'Sent ROI' being offered.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \
 Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \
 Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \
 Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \
 Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-predefined
a=extmap:7 urn:3gpp:predefined-roi-sent
The offer for 'Pre-defined ROI' and 'Sent ROI' are indicated in the last two lines.
The offered set of pre-defined ROIs is provided by the "a=predefined_ROI" attribute. The use of RTCP feedback messages carrying 'Pre-defined ROI' is negotiated with the '3gpp-roi-predefined' parameter. The wildcard ('*') indicates that it is possible to use the ROI features for all RTP payload types including video.
The use of the 'Sent ROI' header extension carrying pre-defined ROI information is negotiated with the a=extmap attribute (RFC 5285) based on the URN 'urn:3gpp:predefined-roi-sent'. In this example, the local identifier (ID) is set to 7, which is only an example. Other values may be used as long as a distinct ID is assigned for each extmap attribute corresponding to different URNs.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \                  
 Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \                  
 Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ 
 Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \
 Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-predefined
a=extmap:7 urn:3gpp:predefined-roi-sent
The answer indicates that both 'Pre-defined ROI' and 'Sent ROI' have been accepted.
The following example is identical to A.4.2a with the exception of FECC, 'Arbitrary ROI' and 'Sent ROI' being offered.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-arbitrary
a=extmap:7 urn:3gpp:roi-sent
m=application 50000 RTP/AVPF 99
a=rtpmap:99 h224/4800
a=sendonly
The offer for FECC is made according to the procedures specified in [139]. In this example, the MTSI client offers a sendonly channel since it is unwilling to adjust the video ROI during encoding based on PTZF commands received from the far end and it does not intend to use H.224 to learn the capabilities of the far end. At the same time, if the far end is capable of FECC, it indicates that it can take advantage of this capability and send PTZF commands to adjust video ROI for the video stream in the receive direction.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-arbitrary
a=extmap:7 urn:3gpp:roi-sent
m=application 50000 RTP/AVPF 99
a=rtpmap:99 h224/4800
a=recvonly
The answer indicates that FECC, 'Arbitrary ROI' and 'Sent ROI' are all accepted. On FECC, the MTSI client answers with a recvonly confirming that it supports the FECC protocol and would be willing to adjust the video ROI during encoding based on PTZF commands received from the far end. As such, FECC can only be used for video in one direction.
The following example is identical to A.4.2a with the exception of FECC, 'Pre-defined ROI' and 'Sent ROI' being offered.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \                  
 Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \
 Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \
 Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \
 Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-predefined
a=extmap:7 urn:3gpp:predefined-roi-sent
m=application 50000 RTP/AVPF 99
a=rtpmap:99 h224/4800
a=sendrecv
In this example, the MTSI client offers a sendrecv channel for FECC since it is willing to adjust the video ROI during encoding based on PTZF commands received from the far end and it intends to use H.224 to learn the capabilities of the far end.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=predefined_ROI:99 [ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720, \                  
 Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360, \                  
 Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360, \ 
 Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360, \
 Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=rtcp-fb:* 3gpp-roi-predefined
a=extmap:7 urn:3gpp:predefined-roi-sent
m=application 50000 RTP/AVPF 99
a=rtpmap:99 h224/4800
a=sendonly
The answer indicates that FECC, 'Pre-defined ROI' and 'Sent ROI' are all accepted. For FECC, the MTSI client answers with a sendonly since it is unwilling to adjust the video ROI during encoding based on PTZF commands received from the far end and it does not intend to use H.224 to learn the capabilities of the far end. At the same time, since the far end is capable of FECC, it indicates that it can take advantage of this capability and send PTZF commands to adjust video ROI for the video stream in the receive direction. As such, FECC can only be used for video in one direction.
Up

A.4.3  Void

A.4.4  Void

A.4.4a  H.264/AVC with "imageattr" attribute |R11|  p. 260

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.
SDP offer 
a=tcap:1 RTP/AVPF
m=video 49154 RTP/AVP 99 
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:99 send [x=176,y=144] [x=224,y=176] \
     [x=272,y=224] [x=320,y=240] recv [x=176,y=144] \
     [x=224,y=176] [x=272,y=224,q=0.6] [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184). The profile-level-id parameter indicates Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so-called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 315 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re-ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320x240, which is the largest of all offered sizes for send direction. The offering MTSI client offers four image sizes for both send and receive directions but prefers 272x224 for receive direction, which might fit the available space on its display better than the other image sizes.
Since the support of a particular codec level does not imply that the video encoder has to produce a bitstream up to the maximum capability of the level, it may be useful for an MTSI client to indicate the image sizes it can encode video at for each codec it supports, using the "imageattr" SDP attribute RFC 6236. Then on the receiving side, the MTSI client can indicate which of these image sizes it prefers to receive. This reduces the loss of quality from rescaling the decoded image to fit the available space on the receiver's display.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Baseline profile at level 1.2. From the four image sizes offered, the responding MTSI client included 320x240 for both send and receive directions. Although the offering MTSI client preferred 272x224 for receive direction, the responding MTSI client might not be able to offer 272x224 or not allow encoding and decoding of video of different image sizes simultaneously. The responding MTSI client sent new sprop-parameter-sets for the video decoder of the offering MTSI client, which was constructed assuming the agreed conditions and image size of 320x240.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:107
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=272,y=224] recv [x=320,y=240,q=0.6] [x=272,y=224]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
In this alternative answer, the responding MTSI client has restricted the video bandwidth to 107 kbps and restricted the H.264/AVC level to 1.1 which supports bitrates up to 192 kbps. The restricted H.264/AVC level should be high enough to enable the image sizes for both send and receive directions. From the four image sizes offered, the responding MTSI client included 272x224 for send direction, which was preferred by the offering MTSI client. For the receive direction, the responding MTSI client included 320x240 as preferred and 272x224 as fallback because the responding MTSI client was unsure whether the offering MTSI client can encode and decode video of different image sizes simultaneously at the conditions. The responding MTSI client sent new sprop-parameter-sets for the video decoder of the offering MTSI client, which was constructed assuming the restricted conditions. Though not required in response to the SDP answer indicating more than one image size in the receive direction, the offering MTSI client may chose to send a second offer as shown in Table A.4.12 to confirm that it is able to encode and decode at different image sizes.
Second SDP offer 
m=video 49154 RTP/AVPF 99
b=AS:107
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=320,y=240] recv [x=272,y=224]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
Since now the offering MTSI client knows that the responding MTSI client supports and prefers to use AVPF, AVPF is offered without SDPCapNeg and AVP.
Up

A.4.4a.1  H.264/AVC with "imageattr" attribute - different image sizes in SDP offer and answer |R13|  p. 262

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.
SDP offer 
a=tcap:1 RTP/AVPF
m=video 49154 RTP/AVP 99 
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offer in Table A.4.12ad is identical to that in Table A.4.10a except that the MTSI client offers an image size of 320x240 for both directions.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:107
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00b; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=272,y=224] recv [x=272,y=224]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
In this case, the offering MTSI client should proceed with the session setup without issuing another SDP offer to perform image size negotiation.
Up

A.4.4a.2  H.264/AVC with "imageattr" attribute - different payload type numbers in offer and answer |R13|  p. 263

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute.
SDP offer 
a=tcap:1 RTP/AVPF
m=video 49154 RTP/AVP 99 
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=272,y=224]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offer in Table A.4.12af is identical to that in Table A.4.10a except that the MTSI client offers image sizes of 320x240 for the send direction and 272x224 for the receive direction.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 101
a=acfg:1 t=1
b=AS:107
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=0;profile-level-id=42e00b; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:101 send [x=272,y=224] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
In this case, the responding MTSI client's answer matches the image sizes in the offer. However, payload type number 99 is not available (e.g., already used for other media) and payload type number 101 is included instead for video media. After the session is established, the offering MTSI client sends the video with payload type number 101 with image size 320x240 towards the responding MTSI client. Similarly, the answering MTSI client sends the video with payload type number 99 with image size 272x224 towards the offering MTSI client.
Up

A.4.4b  H.264/AVC with "imageattr" attribute with multiple rtpmaps |R13|  p. 264

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute with multiple rtpmaps for different image sizes.
SDP offer 
a=tcap:1 RTP/AVPF
m=video 49154 RTP/AVP 99 100
a=pcfg:1 t=1
b=AS:900
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA==
a=imageattr:99 send [x=640,y=480] recv [x=640,y=480]
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:100 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. Two image sizes for send and receive directions are offered. The profile-level-id parameter of the first rtpmap indicates Constrained Baseline profile at level 2.2, which supports bitrates up to 4000 kbps. It also indicates, by using so-called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 900 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re-ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 640x480. The profile-level-id parameter of the second rtpmap indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384kbps. It also indicates, by using so-called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re-ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320x240.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Constrained Baseline profile at level 1.2. The responding MTSI client included 320x240 for both send and receive directions. Therefore, the final negotiated level is 1.2. The offering MTSI is expecting receiving H.264 RTP packets of resolution 320x240 with payload type number either 99 or 100, while the answering MTSI is expecting receving H.264 RTP packets of resolution 320x240 with payload type number 99.
Up

A.4.5  H.264 with asymmetric video streams |R11|  p. 266

As described in clause 5.2.2 (Note 5), when a certain level of H.264 (AVC) is offered using the 'profile-level-id' parameter then the video codec is capable of receiving a bitstream up to the offered level and the bandwidth offered with b=AS. This however does not necessarily mean that the H.264 video codec will produce a bitstream up to the offere level when sending video. An MTSI client in terminal can use this method to set up asymmetric video streams. One drawback with using this method is that there is no information in the SDP that resource reservation functions in the network, e.g. RAN bearer allocation, could use to allocate transmission resources asymmetrically for the different directions.
A better method to allocate asymmetric video for H.264 (AVC) is to use the 'level-asymmetry-allowed' and the 'max-recv-level' parameters defined in the H.264 payload format, RFC 6184. The 'profile-level-id' parameter then defines the default level while the 'max-recv-level' parameter defines the maximum level for the receiving direction. With this method, there is codec-specific information in the SDP that could be used by resource reservation functions to allocate for example radio bearers in a more optimal way.
The SDP example below shows how a session with asymmetric video can be setup using these SDP parameters. The SDP offer sets the default level to 1.2 (max 384 kbps). The maximum receive level is set to 3.1 (max 14 Mbps) but is limited to 2 Mbps using the b=AS bandwidth modifier. The answerer also declares asymmetric video but using lower levels and bitrates. The default level is set to 1.1 (max 192 kbps) and receiving direction is limited to level 1.2 (max 384 kbps)
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:2000
b=RS:0
b=RR:5000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00d; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; level-asymmetry-allowed=1; \
     max-recv-level=e01f
a=imageattr:99 send [x=320,y=240] [x=640,y=480] recv [x=320,y=240] [x=640,y=480] [x=1280,y=720]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP answer 
m=video 49156 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:416
b=RS:0
b=RR:5000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00b; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; level-asymmetry-allowed=1; \
     max-recv-level=e00c
a=imageattr:99 send [x=640,y=480] recv [x=640,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
A resource reservation function that only uses the bandwidth information in the b=AS bandwidth modifiers will probably allocate 416 kbps in both directions. This means that an overallocation will occur but this does not present any other problems. The offering MTSI client offers two and three image sizes for both send and receive directions. A larger size, 1280x720, is offered only for the receive direction, which has a higher level.
With the 'provile-level-id', 'level-asymmetry-allowed' and the 'max-recv-level' in the SDP, a codec-aware resource allocation function can take advantage of this information and allocate transmission resources more efficiently, e.g. to allocate 192 kbps from the answerer to the offerer and 384 kbps from the offerer to the answerer. From the image sizes offered, the responding MTSI client included 640x480 for both send and receive directions.
Up

A.4.6  H.264/AVC with "imageattr" attribute for non-CVO operation |R12|  p. 267

In this example the SDP offer includes H.264/AVC with negotiation of the image size using the "imageattr" attribute allowing for orientation compensation in case of non-CVO operation (see clause 6.2.3.3 and clause 7.4.5).
SDP offer 
a=tcap:1 RTP/AVPF
m=video 49154 RTP/AVP 99 
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==,Z0LADEVoPCmgH9Q=,aEjjqA==
a=imageattr:99 send [x=320,y=240] [x=240,y=320] recv [x=320,y=240] [x=240,y=320]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The offered codec is H.264/AVC. The packetization-mode parameter indicates single NAL unit mode. This is the default mode and it is therefore not necessary to include this parameter (see RFC 6184). The profile-level-id parameter indicates Constrained Baseline profile at level 1.2, which supports bitrates up to 384 kbps. It also indicates, by using so-called constraint-set flags, that the bit stream can be decoded by any Baseline, Main or Extended profile decoder. The bandwidth (including IP, UDP and RTP overhead) for video is 315 kbps. The third parameter, sprop-parameter-sets, includes base-64 encoded sequence and picture parameter set NAL units that are referred by the video bit stream. The sequence parameter set used here includes syntax that specifies the number of re-ordered frames to be zero so that latency can be minimized. sprop-parameter-sets is constructed assuming the offered conditions and image size of 320x240 and 240x320, and contains separate sequence and picture parameter sets with separate ID for both of the supported image resolutions in the send direction. In this example there are two Sequence Parameter Sets (SPS), numbered 0 and 1. SPS 0 has resolution 320x240. SPS 1 has resolution 240x320. There are two Picture Parameter Sets (PPS), numbered 0 and 1. PPS 0 refers to SPS 0. PPS 1 refers to SPS 1. There are four comma-separated and Base64 encoded NAL units as value for sprop-parameter-sets. The order in the example is SPS0,PPS0,SPS1,PPS1.
While the offering MTSI client indicates support for CVO operation, it also offers a couple of image sizes following the format [x,y] and [y,x] for both send and receive directions which allows for signalling of image rotation by a change of resolution in the bitstream in case the receiving MTSI client does not support CVO operation.
An example SDP answer to the offer is given below.
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==,Z0LADEVoPCmgH9Q=,aEjjqA==
a=imageattr:99 send [x=320,y=240] [x=240,y=320] recv [x=320,y=240] [x=240,y=320]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
The responding MTSI client is capable of using H.264/AVC. The responding MTSI client agreed to use a bandwidth of 315 kbps and to use the Constrained Baseline profile at level 1.2. The responding MTSI client did not agree CVO operation (removed the extmap attribute) but agreed both offered images sizes 320x240 for both send and receive directions allowing for image rotation compensation in non-CVO operation. The responding MTSI client sent new sprop-parameter-sets for the video encoder of the offering MTSI client, which was constructed assuming the agreed conditions and image sizes.
Up

A.4.7  H.264 (AVC) and H.265 (HEVC) |R12|  p. 269

A.4.7.1  MTSI client with 848x480 resolution 5 inch display  p. 269

This example SDP offer is for an MTSI client with a 5 inch display that supports 848x480 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1. The MTSI client also supports H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 690 kbps, including 36 kbps IPv6/UDP/RTP overhead (3 RTP packets per frame), but when H.265 (HEVC) is used, the required bandwidth is only 540 kbps, including 36 kbps overhead (3 RTP packets per frame).
Since the SDP offer includes both codecs, then the b=AS bandwidth must be set to the higher of the bandwidths for those codecs.
SDP offer 
m=video 49154 RTP/AVP 98 97 100 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:690
b=RS:0
b=RR:5000
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgNQ9oB/U=,aM46gA==
a=imageattr:100 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:97 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer includes the image sizes that are supported in sending and receiving directions. It is recommended to provide codec parameter sets for each image size in the SDP offer.
Table A.4.17 shows an example SDP answer where the answerer receives the SDP offer described in Table A.4.16 and accepts using the H.265 (HEVC) codec. The answerer chooses to use the H.265 (HEVC) codec for increased quality and therefore sets the bandwidth to the same value as in the SDP offer.
SDP answer 
m=video 49156 RTP/AVPF 98
a=acfg:1 t=1
b=AS:690
b=RS:0
b=RR:5000
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer in Table A.4.16 and the SDP answer in Table A.4.17 mean that symmetric bandwidths are requested with 690 kbps in both directions.
Table A.4.18 shows another example SDP answer where the answerer receives the SDP offer described in Table A.4.16 and accepts using the H.265 (HEVC) codec. In this case, the answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 540 kbps.
SDP answer 
m=video 49156 RTP/AVPF 98
a=acfg:1 t=1
b=AS:540
b=RS:0
b=RR:5000
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer in Table A.4.16 and the SDP answer in Table A.4.18 mean that asymmetric bandwidths are requested. The offerer requested to receive 690 kbps while the answerer requested to receive 540 kbps. This discrepency however can be solved by sending a new SDP offer with only the selected codec.
Up

A.4.7.2  MTSI client with 1280x720 resolution 5 inch display  p. 270

This example SDP offer is for an MTSI client with a 5 inch display that supports 1280x720 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 950 kbps, including 48 kbps IPv6/UDP/RTP overhead (4 RTP packets per frame), but when H.265 (HEVC) is used, the encoder uses only 640 kbps, including 36 kbps overhead (3 RTP packets per frame).
The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer.
SDP offer 
m=video 49154 RTP/AVP 98 97 100 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAH5WgFAFugH9Q,aM46gA==
a=imageattr:100 send [x=1280,y=720] recv [x=1280,y=720]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA==
a=imageattr:99 send [x=640,y=480] recv [x=640,y=480]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAUCAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:97 send [x=640,y=480] recv [x=640,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP answer 
m=video 49156 RTP/AVPF 98
a=acfg:1 t=1
b=AS:500
b=RS:0
b=RR:5000
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer includes the image sizes that are supported in sending and receiving directions.
The answerer could also have chosen to use H.265 (HEVC) to improve the quality, similar to what is discussed for Table A.4.17. In this case, the answerer would set the bandwidth to the same value as in the SDP offer.
Another possibility is that the answerer wants to use H.265 (HEVC) partly to increase the quality and partly to reduce the bit-rate. In this case the answerer would select a bit-rate that is in-between the bit-rate in the SDP offer and the bit-rate in the SDP answer as shown in Table A.4.19.
Up

A.4.7.3  MTSI client with 848x480 resolution 10 inch display  p. 271

This example SDP offer is for an MTSI client with 10 inch display that supports 848x480 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 900 kbps, including 48 kbps IPv6/UDP/RTP overhead (4 RTP packets per frame), but when H.265 (HEVC) is used, the encoder uses only 690 kbps, including 36 kbps of overhead (3 RTP packets per frame).
The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer. The answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 690 kbps.
SDP offer 
m=video 49154 RTP/AVP 98 97 100 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:900
b=RS:0
b=RR:5000
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgNQ9oB/U=,aM46gA==
a=imageattr:100 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:97 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP answer 
m=video 49156 RTP/AVPF 98
a=acfg:1 t=1
b=AS:690
b=RS:0
b=RR:5000
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:100 send [x=848,y=480] recv [x=848,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer includes the image sizes that are supported in sending and receiving directions.
Similar to the previous examples, the answerer could also have chosen to use H.265 (HEVC) to improve the quality or to use the codec partly to improve the quality and partly to reduce the bit-rate.
Up

A.4.7.4  MTSI client with 1280x720 resolution 10 inch display  p. 272

This example SDP offer is for an MTSI client with a 10 inch display that supports 1280x720 video and a frame rate of 25 fps. The MTSI client supports H.264 (AVC) Constrained Baseline Profile (CBP) level 3.1 and H.265 (HEVC) Main Profile, Main tier level 3.1. When encoding video with H.264 (AVC), the required bandwidth is 1060 kbps, including 60 kbps IPv6/UDP/RTP overhead (5 RTP packets per frame), but when H.265 (HEVC) is used, the required bandwidth is only 800 kbps, including 48 kbps overhead (4 RTP packets per frame).
The answerer is also an MTSI client that supports H.264 (AVC) and H.265 (HEVC) in the same way as the offerer. The answerer chooses to use the H.265 (HEVC) codec to save bandwidth and therefore sets the bit-rate to 800 kbps.
SDP offer 
m=video 49154 RTP/AVP 98 97 100 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:1060
b=RS:0
b=RR:5000
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAH5WgFAFugH9Q,aM46gA==
a=imageattr:100 send [x=1280,y=720] recv [x=1280,y=720]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgKA9oB/U=,aM46gA==
a=imageattr:99 send [x=640,y=480] recv [x=640,y=480]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAUCAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:97 send [x=640,y=480] recv [x=640,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP answer 
m=video 49156 RTP/AVPF 100
a=acfg:1 t=1
b=AS:800
b=RS:0
b=RR:5000
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=1280,y=720] recv [x=1280,y=720]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer includes the image sizes that are supported in sending and receiving directions.
Similar to the previous examples, the answerer could also have chosen to use H.265 (HEVC) to improve the quality or to use the codec partly to improve the quality and partly to reduce the bit-rate.
Up

A.4.8  H.264 (AVC) and H.265 (HEVC) with asymmetric video streams |R12|  p. 273

This example SDP offer shows how an asymmetric video session can be set up. The SDP offer is based on the example SDP offer shown in Annex A.4.7.4 (10 inch display, 1280x720 resolution) with modifications to allow for setting up an asymmetric session where the receive level is higher than the default level. The following video encoding and decoding capabilities apply:
  • For H.264 (AVC):
    • The Constrained Baseline Profile (CBP) is used.
    • The default level is 1.2, max 384 kbps, as shown with 'profile-level-id=42e00c'. This is then used for the maximum level in the sending direction if H.264 (AVC) is accepted by the answerer.
    • The maximum level in the receiving direction is 3.1, as shown with'max-recv-level=e01f'.
    • Asymmetric session is allowed as shown with 'level-asymmetry-allowed=1'.
    • The maximum bitrate in the receiving direction is limited to 1060 kbps with 'b=AS:1060'.
  • For H.265 (HEVC):
    • The Main Profile is used.
    • The default level is 1.0, max128 kbps, as shown with 'level-id=30'. This is then used for the maximum level in the sending direction if H.265 (HEVC) is accepted by the answerer.
    • The maximum level in the receiving direction is 3.1, as shown with 'max-recv-level-id=93'.
    • Asymmetric session is allowed as shown by including the 'max-recv-level-id' parameter.
    • The offerer would like to receive max 800 kbps if H.265 (HEVC) is accepted but there is no possibility to indicate this in the SDP offer.
SDP offer 
m=video 49154 RTP/AVP 98 97 100 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:1060
b=RS:0
b=RR:5000
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; \
     level-asymmetry-allowed=1; max-recv-level=e01f
a=imageattr:100 send [x=320,y=240] recv [x=1280,y=720] [x=320,y=240]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==; \
     level-asymmetry-allowed=1; max-recv-level=e01f
a=imageattr:99 send [x=320,y=240] recv [x=640,y=480] [x=320,y=240]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=30; \
     sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
     sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
     sprop-pps=RAHAcYDZIA==; \
     max-recv-level-id=93
a=imageattr:98 send [x=320,y=240] recv [x=1280,y=720] [x=320,y=240]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=30; \
     sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
     sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
     sprop-pps=RAHAcYDZIA==; \
     max-recv-level-id=90
a=imageattr:97 send [x=320,y=240] recv [x=640,y=480] [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
The SDP offer includes the image sizes that are supported in sending and receiving directions. Different resolutions are offered by including two RTP payload types for H.264 (AVC) and H.265 (HEVC), respectively.
For PT=98, the MTSI client in terminal specifies max-recv-level-id=93 since this is needed for 1280x720 resolution. But for PT=97, it specifies max-recv-level-id=90 since this is sufficient for 640x480 resolution.
Up

Up   Top   ToC