Content for  TS 26.114  Word version:  18.5.0

a=3gpp_fisheye: <fisheye> <fisheye-img> <maxpack>

att-field = "3gpp_fisheye" 
att-value = [SP fisheye] SP fisheye-img SP maxpack
fisheye = pos-integer
fisheye-img = 1*fisheye-img-X
fisheye-img-X = "[" "id=" idvalue "," "azi=" azivalue "," "ele=" elevalue "," "til=" tilvalue
"," "fov=" fovvalue "]"
;sub-rules for fisheye-img-X
idvalue = byte-string ; byte-string defined by RFC 4566
azivalue = degminus180to180
elevalue = degminus90to90
tilvalue = degminus180to180
fovvalue = deg0to360
maxpack = pos-integer
;pos-integer, degminus180to180, degminus90to90 and deg0to360 are from Annex Y.6.2.1

m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:10000
b=RS:0
b=RR:2500
a=rtpmap:99 H265/90000
a=fmtp:99 profile-id=1; level-id=93;
a=3gpp_fisheye: 2 [id=1,azi=0,ele=0,til=0,fov=11796480] [id=2,azi=11796479,ele=0,til=0,fov=11796480] 2
a=sendonly

Network-based stitching in the context of ITT4RT refers to generation of 360-degree videos in the ITT4RT MRF based on 2D video captures received from MTSI clients. This clause describes SDP-based signalling of camera calibration parameters for this purpose using the "a=3gpp-camera-calibration" attribute and SDP-based grouping of the corresponding 2D video captures using the "a=stitch_group" attribute. The SDP syntax for "a=3gpp-camera-calibration" is defined with the following semantics (detailed ABNF presented at the end of the clause): If the ITT4RT-Tx client in the ITT4RT MRF intends to perform network-based stitching to generate 360-degree video from a particular set of 2D video captures received from an MTSI sender, it shall use the SDP session-level attribute "a=stitch_group" before any media lines that correspond to the particular 2D video captures during the SDP negotiation of the corresponding media. Likewise, an MTSI sender capable of capturing 2D videos for 360-degree video generation shall use the session-level "a=stitch_group" attribute in the SDP before any media lines that correspond to the particular 2D video captures. The "a=stitch_group" attribute is used to group the corresponding to-be-stitched 2D video captures using the mid attribute as defined according to the ABNF below: The mid attribute with the appropriate value as defined in the other parts of the SDP shall be included in the media description for the relevant 2D video captures when the "a=stitch_group" attribute is used. Furthermore, for each of these 2D video captures, the MTSI sender shall also include the SDP attribute 3gpp-camera-calibration in the SDP under the relevant m= line for that particular video to signal the relevant camera calibration information. The order of the media included in the "a=stitch_group" indicates the synchronization source with the first media always being the synchronization anchor when synchronization is required. More specifically, detailed camera calibration parameters based on ISO/IEC 23008-2 [3] are provided as follows, considering the multi-view acquisition information SEI message for HEVC. With these specifications, a 3-dimensional world point, wP = [ x y z ] is mapped to a 2-dimensional camera point, cP[ i ] = [ u v 1 ], for the i-th camera according to: Equation Y.6.6.1 can be extended to incorporate the entrance pupil variation to correct the incidence ray of cP[ i ] = [ u v 1 ] such that it always passes through the camera optical center, thereby removing distortion. The resulting entrance pupil coefficients E[i] may be incorporated into Equation Y.6.6.1 as Accordingly, the following intrinsic camera parameters can be signalled in the SDP for each 2D video capture using the "a=3gpp-camera-calibration" attribute: focalLengthX[ i ] specifies the focal length of the i-th camera in the horizontal direction as a signed floating-point number. focalLengthY[ i ] specifies the focal length of the i-th camera in the vertical direction as a signed floating-point number. principalPointX[ i ] specifies the principal point of the i-th camera in the horizontal direction as a signed floating-point number. principalPointY[ i ] specifies the principal point of the i-th camera in the vertical direction as a signed floating-point number. skewFactor[ i ] specifies the skew factor of the i-th camera as a signed floating-point number. The intrinsic matrix A[ i ] for i-th camera is represented by: It is possible that the intrinsic camera parameters are equal for all of the cameras. In that case, only one set of values based on the above parameters would need to be signalled, e.g., via SDP signalling at the session level. Furthermore, the following extrinsic camera parameters can be signalled in the SDP for each camera as per ISO/IEC 23008-2 [3]: The rotation matrix R[ i ] for i-th camera is represented as follows: The translation vector T[ i ] for the i-th camera is represented by: For the i-th camera, E[ i ][ j ] specifies the j-th component of the entrance pupil coefficient [e1, e2, e3, e4] where j=1,…4. The parameters are represented as a signed floating-point number, as per eqn (2) above. The syntax for the "a=3gpp-camera-calibration" attribute shall conform to the following ABNF:

An ITT4RT-Tx client shall use the a=rtcp-fb ccm pause attribute and parameter values as specified in RFC 5104 and RFC 7728 to indicate the capability to support receiving and acting on PAUSE and RESUME requests targeted for RTP streams it sends. The optional parameter setting of a=rtcp-fb ccm pause config=3 could be used by the ITT4RT-Tx client to indicate that it will only receive and react to PAUSE and RESUME requests but will not send them. An ITRT4RT-Rx client shall use the a=rtcp-fb ccm pause attribute and parameter values as specified in RFC 5104 and RFC 7728 to indicate the capability to support sending PAUSE and RESUME requests targeted for RTP streams it receives. The optional parameter setting of a=rtcp-fb ccm pause config=2 could be used by the ITT4RT-Rx client to indicate that it will only send PAUSE and RESUME requests but does not support receiving these requests.

An ITT4RT conference may contain multiple 360-degree videos which originate from multiple conference rooms at the conference location, or from remote participants. When multiple 360-degree videos are present in an ITT4RT conference, an ITT4RT MRF shall negotiate an SDP session with every remote participant. In the SDP offer from the ITT4RT MRF, 360-degree video is identified by either the a=3gpp_360video or a=3gpp_fisheye media line attributes. When multiple 360-degree videos are present in the SDP offer, the ITT4RT MRF shall include the a=content attribute under the media lines for 2D or 360-degree video originating from the conference location. For media streams originating from the main default conference room, the content attribute is set to a=content:main. For media streams originating from other conference rooms, the content attribute is set to a=content:alt. 2D and 360-degree video from remote participants shall not include the a=content attribute under their corresponding media lines. When there are multiple 360-degree videos from multiple sources available to the ITT4RT MRF, the ITT4RT MRF may include the 'itt4rt_group' attribute (as defined in clause Y.6.2.6) to define one or more restricting groups, each group containing at least one mid associated with a 360-degree video media line, and at least one mid associated with an overlay. On receipt of an SDP offer containing multiple 360-degree videos from the ITT4RT MRF, an ITT4RT-Rx client shall select to receive only one 360-degree video media together with possible 2D video media from other sources, rejecting the other 360-degree video media. Example SDP offers for multiple 360-degree video with and without group restrictions are shown in clause Y.8.

att-field	= "no_other_overlays"