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.5.0

Top   Top   Up   Prev   None
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… 
Y.7 Media transport  Y.7.1 RTP  Y.7.2 RTCP  Y.8 SDP Examples (informative)  Y.9  Recommended audio mixing gains  Y.9.1 RTP header extension for audio mixing gain  $ Change history 

 

Y.7  Media transport  p. 485

Y.7.1  RTP  p. 485

RTP signaling impacts are FFS.

Y.7.2  RTCP  p. 485

When viewport-dependent processing (VDP) of 360-degree video is successfully negotiated between the ITT4RT-Tx client and ITT4RT-Rx client as per the SDP-based procedures described in clause Y.6.2, the RTCP feedback (FB) message type 'Viewport' shall carry requested viewport information during the RTP transmission of media signalled from the ITT4RT-Rx client to the ITT4RT-Tx client.
The signalling of 'Viewport' requests shall use RTCP feedback messages as specified in RFC 4585. The RTCP feedback message is identified by PT (payload type) = PSFB (206) which refers to payload-specific feedback message. FMT (feedback message type) shall be set to the value assigned by IANA for Viewport feedback messages. The IANA registration information for the FMT value for 'Viewport' is provided in Annex R.3 of TS 26.114. The RTCP feedback method may involve signalling of viewport information in both of the immediate feedback and early RTCP modes.
The FCI (feedback control information) format for Viewport shall be as follows. The FCI shall contain exactly one viewport. The signalled desired viewport information in the RTCP feedback message for 'Viewport' is composed of the following parameters (as defined as shape type value equal to 0 in clause 7.5.6 of ISO/IEC 23090-2 [179]):
  • Viewport_azimuth: Specifies the azimuth of the centre point of the sphere region corresponding to the requested viewport in units of 2−16 degrees relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −180 * 216 to 180 * 216 − 1, inclusive..
  • Viewport_elevation: Specifies the elevation of the centre point of the sphere region corresponding to the requested viewport in units of 2−16 degrees relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −90 * 216 to 90 * 216, inclusive.
  • Viewport_tilt: Specifies the tilt angle of the sphere region corresponding to the requested viewport, in units of 2−16 degrees, relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −180 * 216 to 180 * 216 − 1, inclusive.
  • Viewport_azimuth_range: Specifies the azimuth range of the sphere region corresponding to the requested viewport through the centre point of the sphere region in units of 2-16 degrees expressed in unsigned 32-bit integer format, in the range of 0 to 180 * 216, inclusive.
  • Viewport_elevation_range: Specifies the elevation range of the sphere region corresponding to the requested viewport through the centre point of the sphere region in units of 2−16 degrees expressed in unsigned 32-bit integer format, in the range of 0 to 180 * 216, inclusive.
The RTCP feedback message for 'Viewport' shall contain all of the parameters Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range. The values for the each of the parameters Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range shall each be indicated using four bytes.
The FCI for the RTCP feedback message for 'Viewport' shall follow the following format: 
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Viewport_azimuth                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Viewport_elevation                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Viewport_tilt                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Viewport_azimuth_range                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Viewport_elevation_range                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For each 4-byte indication of the Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range, the bytes will be ordered in the order of importance such that high bytes shall be followed by the low bytes, where the highest byte holds the most significant bits and lowest byte holds the least significant bits.
Up

Y.8  SDP Examples (informative)  p. 486

An example SDP offer for multiple 360-degree video is shown in Table Y.8.1.
SDP offer 
; 1st conference room @ conference location
;
m=video 49144 RTP/AVP 98 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ; indicates this m-line is from the main source from the conference location
a=rtpmap:98 H265/90000
 ; 360 video
a=3gpp_360video:98…
a=rtpmap:100 H265/90000
 ; 2D video
;
; 2nd conference room @ conference location
; 
m=video 49154 RTP/AVP 102 104
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap:102 H265/90000
 ; 360 video
a=3gpp_360video:102…
a=rtpmap:104 H265/90000
 ; 2D video
;
; Capture of a remote participant
;
m=video 49164 RTP/AVP 106 108
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:106 H265/90000
 ; 2D video
a=rtpmap:108 H265/90000
 ; 360 video
a=3gpp_360video:108…
An example SDP offer for multiple 360-degree video with group restrictions is shown in Table Y.8.2.
SDP offer 
a=itt4rt_group: D G H / E F H / H G I
 ; create multiple groups at MRF,
 ; each group between a different 360 video from a certain source,
 ; and 2D videos from other sources/
;
; 360 video of 1st conference room @ conference location
;
m=video 49144 RTP/AVP 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ; indicates this m-line is from the main source from the conference location
a=rtpmap:98 H265/90000 /*360 video*/
a=3gpp_360video:98…
a=mid=D
;
; 2D video of 1st conference room @ conference location
;
m=video 49154 RTP/AVP 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ;indicates this m-line is from the main source from the conference location
a=rtpmap:100 H265/90000 ; 2D video
a=3gpp_overlay:100… ; optional attribute
a=mid=E
;
; 360 video of 2nd conference room @ conference location
;
m=video 49164 RTP/AVP 102
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap: 102 H265/90000 ;360 video
a=3gpp_360video:98…
a=mid=F
;
; 2D video of 2nd conference room @ conference location
;
m=video 49174 RTP/AVP 104
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap:100 H265/90000 ; 2D video
a=3gpp_overlay:104… ; optional attribute
a=mid=G
;
; 2D video capture of a remote participant
;
m=video 49164 RTP/AVP 106
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:106 H265/90000 ; 2D video
a=3gpp_overlay:100… : optional attribute
a=mid=H
;
; 3D capture of a remote participant
;
m=video 49164 RTP/AVP 108
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:108 H265/90000 ; 360 video
a=3gpp_360video:108…
a=mid=I
Up

Y.9  Recommended audio mixing gains  p. 487

An ITT4RT-Tx client may specify recommended gains for mixing of its transmitted audio streams and update these recommended gains during a session. An ITT4RT-Rx client may or may not use such recommended mixing gains to scale the audio streams prior to mixing.
An ITT4RT-Tx client may for example send the recommended mixing gains r0, r1, .., rN for the audio sources a0 (360 video) and a1, a2, .., aN (overlay videos) of that sender to recommend a mix at the receivers to be r0*a0+r1*a1+……+rN*aN.
If an ITT4RT-Rx client negotiated to receive recommended audio mixing gains and the ITT4RT-Tx client chooses to send these mixing gains, the ITT4RT-Tx client shall indicate each audio mixing gain value to the ITT4RT-Rx client using RTP header-extensions (see clause Y.9.1).
Up

Y.9.1  RTP header extension for audio mixing gain  p. 488

The format for sending a recommended audio mixing gain using the RTP header extension shall be as follows: 
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |  ID   | len=0 |audio-mixing-gain| 
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Audio mixing gain using One-Byte Header Format
The 4-bit ID is the local identifier of this element. The 4-bit length is the number, minus one, of data bytes of this header extension element following the one-byte header. The URI for declaring the audio mixing gain header extension in a Session Description Protocol (SDP) extmap attribute (RFC 5285) and mapping it to a local identifier is: 
urn:3gpp:audio-mixing-gain
The audio mixing gain is expressed in dB as a signed integer in the range "-127" to "0" (hence the numerical values directly represent the gain in dB). A value of "-128" indicates muting the channel. The meaning of positive values other than 0 is undefined and shall be ignored if received.
An ITT4RT-Tx client may repeat the header extension over multiple RTP packets to improve the likelihood of successful transmission as described in (RFC 8285). The number of header extension transmissions (for the same recommended mixing gain) should therefore depend on the probability of delivery.
Up

$  Change history  p. 489

Up   Top