Apparatus and method for quality metric reporting for point cloud content streaming

Abstract

The present disclosure provides apparatuses and methods for quality metric reporting for point cloud content streaming. An apparatus for a client includes a memory; and a processor circuit coupled with the memory, wherein the processor circuit is to: generate an immersive media metric ViewportDataType to identify a viewport in a 6DoF environment, wherein the immersive media metric ViewportDataType includes one or more keys to indicate x-y-z components of a rotation of the viewport; and provide the immersive media metric ViewportDataType to a server, and wherein the memory is to store the immersive media metric ViewportDataType. Other embodiments can also be disclosed and claimed.

Description

[0001] CLAIM

[0002] This application is based on and claims priority to U.S. Provisional Application Serial No. 62 / 948,115, filed December 13, 2019. The entire contents of this application are hereby incorporated by reference herein in their entirety. TECHNICAL FIELD

[0003] Embodiments of the present disclosure generally relate to the field of communications, and in particular, to apparatuses and methods for quality metric reporting for point cloud content streaming. BACKGROUND

[0004] Initial virtual reality (VR) 360 support was limited to three degrees of freedom (3DoF), which means that the viewing pose could only be changed by rotating on the x, y, and z axes (denoted as roll, pitch, and yaw, respectively), while purely translational motion did not result in rendering a different media. Thus, VR 360 provided an overall flat experience, as it positioned the viewer in a static position with limited freedom of movement and a low level of interactivity. In a sense, this was a limitation, as it was not possible to achieve a fully immersive experience, thereby compromising the user experience and the level of realism. Emerging VR standards and products will provide support for 3DoF+ and six degrees of freedom (6DoF) to improve the level of immersion and user experience. 3DoF+ restricts the modification of the viewing position by limiting the translational motion of the user’s head around the original viewpoint, while 6DoF supports both rotational and translational motion, thereby enabling the user to not only change the orientation but also the position of moving around in the observed scene. The Moving Picture Experts Group (MPEG) is currently developing codecs, storage and distribution formats, and rendering metadata to provide interoperable and standards-based immersive 3DoF+ and 6DoF experiences as part of its “Coding Representations of Immersive Media” (MPEG-I) project. SUMMARY

[0005] An aspect of the disclosure provides an apparatus for a client, the apparatus comprising: a memory; and a processor circuit coupled with the memory, wherein the processor circuit is to: generate a viewport data type for immersive media to identify a viewport in a six degrees of freedom (6DoF) environment, wherein the viewport data type for immersive media comprises one or more keys to indicate x-y-z components of a rotation of the viewport; and provide the viewport data type for immersive media to a server, and wherein the memory is to store the viewport data type for immersive media.

[0006] An aspect of the disclosure provides an apparatus for a client, the apparatus comprising: a first interface; and a processor circuit coupled with the first interface, wherein the processor circuit is to: obtain sensor data from a sensor via the first interface, wherein the sensor data comprises viewport and viewpoint related information about x-y-z translational motion of a user in a six degrees of freedom (6DoF) environment; and generate immersive media metrics based at least in part on the sensor data for transmission to a server.

[0007] An aspect of the disclosure provides an apparatus for a client, the apparatus comprising: a first interface; and a processor circuit coupled with the first interface, wherein the processor circuit is to: obtain, in a six degrees of freedom (6DoF) environment, immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata via the first interface, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volume annotation information or scene object information; and generate immersive media metrics based at least in part on the MIV metadata or the V-PCC metadata for transmission to a server.

[0008] An aspect of the disclosure provides a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to: generate a viewport data type for immersive media to identify a viewport in a six degrees of freedom (6DoF) environment for video-based visual volumetric coding (V3C) content, wherein the viewport data type for immersive media comprises one or more keys to indicate x-y-z components of a rotation of the viewport; and send the viewport data type for immersive media to a server. BRIEF DESCRIPTION OF DRAWINGS

[0009] Embodiments of the present disclosure will be illustrated by way of example in the accompanying drawings, in which like reference numerals indicate similar elements, and in which:

[0010] Figure 1 An example of a V-PCC architecture is shown in accordance with some embodiments of the present disclosure.

[0011] Figure 2 An example of a DASH-based streaming framework is shown in accordance with some embodiments of the present disclosure.

[0012] Figure 3 An example of content streaming in a DASH delivery function for point cloud content delivery is shown in accordance with some embodiments of the present disclosure.

[0013] Figure 4 An immersive media metrics client reference model is shown in accordance with some embodiments of the present disclosure.

[0014] Figure 5 A flowchart of a method for generating immersive media metrics is shown in accordance with some embodiments of the present disclosure.

[0015] Figure 6 A flowchart of a method for generating immersive media metrics is shown in accordance with some embodiments of the present disclosure.

[0016] Figure 7 A flowchart of a method for generating immersive media metrics is shown in accordance with some embodiments of the present disclosure.

[0017] Figure 8 An example set of components of a device is shown in accordance with some embodiments of the present disclosure.

[0018] Figure 9 An example of an infrastructure device is shown in accordance with some embodiments of the present disclosure.

[0019] Figure 10 is a block diagram showing components that can read instructions from a machine- or computer- readable medium and perform any one or more of the methods discussed herein in accordance with some example embodiments. DETAILED DESCRIPTION

[0020] Various aspects of the illustrative embodiments will be described using terminology commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that many alternative embodiments can be practiced in addition to the embodiments here described. For purposes of explanation and illustration, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments can be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

[0021] Furthermore, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

[0022] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly. This phrase does not necessarily refer to the same embodiment; however, it can. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise. The phrases “A or B” and “A / B” mean “(A), (B), or (A and B)”.

[0023] Figure 1 An example of a video-based point cloud coding (V-PCC) architecture is shown in accordance with some embodiments of the present disclosure. Such a V-PCC architecture can allow for reuse of legacy video codecs, such as H.264 / AVC and H.265 / HEVC. In particular, the 3D geometry and attribute data of a point cloud can be converted into a set of 2D patches. Such patches are then packed into an image, which can then be compressed with any existing or future image or video codec, such as MPEG-4 Advanced Video Coding (AVC), High Efficiency Video Coding (HEVC), AV1, etc.

[0024] V-PCC can utilize a patch-based approach to divide a point cloud into a set of clusters (or patches). These patches can be mapped to a predefined set of 2D planes through an orthogonal projection, which is limited in its deformation but free of self-occlusions. The goal is to find a time-coherent, low-distortion, injective mapping that would assign each point of the 3D point cloud to a cell of a 2D grid. The mapping between the point cloud and the regular 2D grid is then obtained by packing the projected patches in a patch packing process.

[0025] All patch information needed to reconstruct the 3D point cloud from the 2D geometry, attributes, and occupancy video also needs to be compressed. Such information is encoded in the V-PCC patch sequence sub-stream. V-PCC introduces a new codec specifically optimized to handle this sub-stream, which is relatively small (e.g., below 5%) in proportion to the entire bitstream. Other information needed to synchronize and link the video and patch sub-streams is also signaled in the bitstream. The V-PCC bitstream is then formed by concatenating the various encoded information (e.g., occupancy map, geometry, attributes, and patch sequence sub-streams) into a single stream. This is done by encapsulating these sub-streams into V-PCC data units, each of which contains a header and a payload.

[0026] The header of a V-PCC data unit can describe the type of V-PCC unit. Currently, five different unit types are supported. The sequence parameter set (SPS) unit type describes the entire V-PCC bitstream and its sub-components. The remaining unit types can include occupancy video, geometry video, attributes video, and patch sequence data units, which encapsulate the occupancy map, geometry, attributes, and patch sequence sub-streams, respectively.

[0027] The V-PCC decoding process can be divided into two phases: 1) the bitstream decoding process, and 2) the reconstruction process. The bitstream decoding process can take the compressed V-PCC bitstream as input and output the decoded occupancy, geometry, and attributes 2D video frames, as well as the patch information associated with each frame. The reconstruction process can use the patch information to convert the 2D video frames into a set of reconstructed 3D point cloud frames.

[0028] The reconstruction process needs to resample the occupancy, geometry, and attributes video sequences at the nominal 2D resolution specified in the SPS. The resampled videos are then used in the 3D reconstruction process, which can include two main steps: 1) geometry and attributes reconstruction, and 2) geometry and attributes smoothing.

[0029] The patch packing process can be constrained to ensure that there is no overlap between patches. In addition, the boundary blocks (expressed in T x T blocks, where T is the packing block size) of any patch are not allowed to overlap with any T x T block belonging to a previously encoded patch. Such a constraint makes it possible to determine, for each T x T block of the packing grid, the patch to which it belongs by analyzing the 2D boundary blocks of all patches.

[0030] The T x T blocks are then processed in parallel to generate the point cloud geometry and attributes. For each cell of a T x T block, the corresponding pixel in the occupancy map can be used to determine whether the cell is full or empty. If the cell is full, then 3D points can be generated according to the type of patch through two different processes.

[0031] V-PCC can support the concept of regular patches, which uses the patch projection method introduced earlier. For regular patches, the 3D point Cartesian coordinates can be computed by combining the depth information stored in the geometry image with the 2D position of the cell, the 3D offset of the patch, and the 2D projection plane. The attribute values associated with the reconstructed points can be obtained by sampling the 2D attribute frame at the same grid position.

[0032] The International Organization for Standardization (ISO) Base Media File Format (ISO / International Electrotechnical Commission (IEC) 14496-12 - MPEG-4 Part 12) defines a general structure for time-based multimedia files (e.g., video and audio). The same text is published as ISO / IEC 15444-12 (JPEG 2000, Part 12).

[0033] The file format can be designed as a flexible, extensible format to facilitate interchange, management, editing, and presentation of media. The presentation can be local or via a network or other streaming mechanism. The file format can be designed to be independent of any particular network protocol, while generally supporting them. It can be used as a basis for other media file formats (e.g., the container formats MP4 and 3GP). In the Third Generation Partnership Project (3GPP), a special instance of the ISO Base Media File Format is specified in 3GPP TS 26.244 V15.0.0 (2018-06) to be used as the 3GP file format for 3GPP systems.

[0034] Hypertext Transfer Protocol (HTTP) streaming is widely spreading as a multimedia delivery form of Internet video. Since HTTP and its underlying transport communication protocol (TCP) / Internet Protocol (IP) protocol are widely adopted, HTTP-based delivery can provide reliability and ease of deployment. Dynamic adaptive streaming over HTTP (DASH) is a new technology standardized in 3GPP TS 26.247 V16.1.0 (2018-12) (Transparent end-to-end packet-switched streaming service (PSS); Progressive download and dynamic adaptive streaming over HTTP (3GP-DASH)) and MPEG ISO / IEC DIS 23009-1 (Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats).

[0035] Figure 2 An example of a DASH-based streaming framework is shown in accordance with some embodiments of the present disclosure. From Figure 2 As can be seen, a client and a server (e.g., a web server) can communicate with each other to implement data streaming.

[0036] In DASH, the Media Presentation Description (MPD) metadata file provides information about the structure and different versions of the media content representation stored on the server (including different bitrates, frame rates, resolutions, codec types, etc.). Additionally, DASH specifies segmentation formats, including information about media engine initialization and media segmentation to ensure segments are mapped to the media presentation timeline for switching and synchronization with other representations. Based on the MPD metadata describing the relationships between segments and how they form the media presentation, clients can request segments using HTTP GET or partial GET methods. The client has complete control over the streaming session; for example, it manages timely requests and smooth playback of segment sequences, potentially adjusting bitrates or other attributes to react to changes in device state or user preferences.

[0037] like Figure 2 As shown, a client can send an HTTP GET request to the web server to request a segment. The server can respond to the client with an MPD (Multiple Access Request). When the client receives the MPD from the server, it can send an HTTP GET Uniform Resource Locator (URL) (frag 1 req) to the server to request segment 1. The server can then respond by sending segment 1 back to the client. Alternatively, the client can send an HTTP GET URL (frag i req) to the server to request segment i; the server can then respond by sending segment i back to the client.

[0038] Figure 3 An example of a content stream in a DASH delivery function for point cloud content delivery according to some embodiments of the present disclosure is shown.

[0039] like Figure 3 As shown, the DASH MPD generation module and server can be Figure 2 DASHMPD and the segmented receiving module can be part of the web server in the system. Figure 2 It is part of the client. Figure 3 Fs, F's, H, H', and G in the DASH protocol can represent the interface (or the information or data input or output) that is part of the DASH transmission.

[0040] Specifically, Fs / F's can represent initialization and media segmentation, as generally defined and specified for media profiles.

[0041] G can represent a DASH MPD or manifest file, including metadata specific to point cloud media. The MPD (G) can be generated based on segments (Fs) and other media files representing the same content. The DASH MPD generator can include descriptors specific to point cloud media. The descriptors can be generated based on equivalent information in the segments.

[0042] The server typically provides the segments (Fs) to the client. The server can also provide the MPD (in this case considered part of the interface H), or can deliver the MPD to the client by other means. The segments and MPD are delivered over the network, and the segments and MPD received from the server are labeled H' in Figure 3 The output (H) of the server can be the same as the input (H') of the DASH MPD and segment reception module. The DASH MPD and segment reception module outputs the received segments (F's) to the file / segment de-encapsulation module for further processing.

[0043] The DASH client can obtain the current viewing position and orientation, e.g. viewport, e.g. from a head-mounted display that detects the position of the user, and detects the orientation of the head, and possibly the eyes. By parsing the metadata from the MPD, the DASH client can conclude which adaptation set and representation can provide the highest quality and bitrate to cover the current viewing position and orientation with the current estimated network throughput. The DASH client can issue (sub-)segment requests accordingly.

[0044] Volumetric video has recently gained a lot of interest in providing 6DoF experiences. Volumetric video contains spatial data that enables the viewer to walk around and interact with people and objects. It is more immersive than a 360-degree video shot because it can capture real people in motion from three dimensions. Users can view these motions from any angle by using position tracking. A point cloud is a volumetric representation used to describe a 3D object or scene. A point cloud can include an unordered set of data points in 3D space, each of which can be specified by its spatial (x, y, z) position and possibly by other related attributes such as RGB color, surface normal, and reflectance. In essence, this is the 3D equivalent of the well-known representation of pixels for 2D video. Together, these data points describe the 3D geometry and texture of a scene or object. This volumetric representation makes it easy to interact and render immersively with 6DoF.

[0045] For example, a point cloud is a form of representing a 3D environment. A point cloud is a set of points {v} each with a spatial location (x, y, z) identifying the geometry and an attribute vector such as color (Y, U, V), normal, curvature, or other attributes. A point cloud can be voxelized by quantizing the point locations to lie on an integer grid within a bounding cube. This allows more efficient real-time processing. A cube of voxels in 3D is somewhat equivalent to a pixel in 2D. A voxel can be said to be occupied if it contains any point of the point cloud. Likewise, higher level representations mapped from color and depth apply.

[0046] As this point cloud representation requires a large amount of data, it is necessary to develop efficient compression techniques to enable consumers to use it through traditional broadband access systems.

[0047] As mentioned above, 6DoF can support both rotational and translational motion, allowing users to change not only orientation but also position moving around in the observed scene. As point cloud content has a 6DoF experience in it, it is necessary to reevaluate immersive media metrics and the metrics in ISO / IEC 23090-6 (ISO / IEC JTC 1 / SC 29 / WG 11 Moving Picture and Audio Coding Meeting: UNI (Italy), 2019-2-26) can not be directly applicable or can need to be refined to be applicable to 6DoF volumetric experiences. In this disclosure, the extension of the metrics in ISO / IEC 23090-6 to be applicable to 6DoF point cloud content distribution will be discussed. New immersive media metrics for 6DoF environments will be discussed in this disclosure, with a focus on point cloud (PC) content distribution.

[0048] Some technical aspects to be considered can include, but are not limited to: a) a higher degree of user interactivity due to translational (x-y-z) motion of 6DoF users, which is complementary to the rotational motion only allowed for 3DoF; b) the perceived quality of point cloud objects (e.g., based on the proximity of the user and the object motion), e.g., the quality of a volumetric tile can vary greatly inversely with the distance of the user to the tile; c) the impact of dynamic viewport and viewpoint changes and network bandwidth limitations, especially when delivering large point clouds with multiple objects; d) the impact of partial access to PC streaming with dynamic user motion and viewport / viewpoint changes, which can require continuous tracking and requesting of relevant parts of the point cloud to the network.

[0049] Figure 4 An immersive media metrics client reference model is shown in accordance with some embodiments of the present disclosure.

[0050] The client model can include various functional modules, including but not limited to network access, media processing, sensors, media renderers, and immersive media applications. The VR client can be an all-inclusive Media Format (OMAF) player for file / segment reception or file access, file / segment de-encapsulation, audio, video or image bitstream decoding, audio and image rendering, and viewport selection. A Metrics Calculation and Reporting (MCR) module can query measurable data from the various functional modules and calculate specified metrics. The MCR module can reside inside or outside the VR client. The specified metrics can then be reported to an analytics server or other entity interested and authorized to access the metrics. The analytics server or other entity can use the metrics data to analyze end-user experience, evaluate client device capabilities, and evaluate immersive system performance to enhance overall immersive service experience across networks, platforms, devices, applications, and services.

[0051] The interfaces from the network access element, media processing element, sensor element, media renderer element, and immersive media application element to the MCR are referred to as Observation Points (OP) 1, OP2, OP3, OP4, and OP5, respectively, as shown in Figure 3 Figure 3 The Immersive Media Metrics Client Reference Model in ISO / IEC 23090-6. However, there is a need to update the collectable information from OP2 and / or OP3.

[0052] In some embodiments, OP2 can provide, among other information, immersive video metadata (MIV) metadata and / or V-PCC metadata. In other words, the media processing element can provide the MIV metadata and / or V-PCC metadata to the MCR to generate immersive media metrics. In some embodiments, the MIV metadata can include at least one of the following: viewport camera information, viewport position information, and viewing space information. In some embodiments, the V-PCC metadata can include at least one of the following: volumetric annotation information, and scene object information. In other embodiments, the MIV metadata and V-PCC metadata can alternatively or additionally include other information. The disclosure is not limited in this respect.

[0053] The updates to OP2 can also apply to the specifications of related codecs and formats, such as ISO / IEC 23090 Parts 5, 9, 10, and 12.

[0054] ​In some embodiments, OP3 can provide, among other information, viewport and / or viewpoint related information about the user's x-y-z translational motion in the 6DoF environment. In other words, the sensor can sense and provide to the MCR, among other information, viewport and / or viewpoint related information about the user's x-y-z translational motion in the 6DoF environment to generate immersive media metrics.

[0055] Figure 5 A flowchart of a method 500 for generating immersive media metrics is shown, in accordance with some embodiments of the present disclosure. In some embodiments, the method 500 can include steps 510 and 520, which can be performed by an apparatus for a client (e.g., a client in Figures 2-4 , for example, by an MCR of Figure 4 .

[0056] In 510, MIV metadata or V-PCC metadata can be obtained in the 6DoF environment. The MIV metadata can include viewport camera information, viewport position information, or viewing space information. The V-PCC metadata can include volumetric annotation information or scene object information.

[0057] In 520, immersive media metrics can be generated based at least in part on the MIV metadata or the V-PCC metadata for transmission to a server.

[0058] In some embodiments, alternatively or additionally, the method 500 can include obtaining sensor data from a sensor. The sensor data can include viewport and viewpoint related information about the user's x-y-z translational motion in the 6DoF environment. In these embodiments, immersive media metrics can be generated based on the sensor data.

[0059] Figure 6 A flowchart of a method 600 for generating immersive media metrics is shown, in accordance with some embodiments of the present disclosure. In some embodiments, the method 600 can include steps 610 and 620, which can be performed by an apparatus for a client (e.g., a client in Figures 2-4 , for example, by an MCR of Figure 4 .

[0060] In 610, sensor data can be obtained from a sensor. The sensor data can include viewport and viewpoint related information about the user's x-y-z translational motion in the 6DoF environment.

[0061] In 620, immersive media metrics can be generated based at least in part on the sensor data for transmission to a server.

[0062] The MCR can generate various immersive media metrics. Among these immersive media metrics, the metric ViewportDataType can be updated accordingly. The metric ViewportDataType can indicate information related to the data type of the viewport.

[0063] Generally, the metric ViewportDataType can include the following parameters: viewpoint id, centre azimuth, centre elevation, centre tilt, azimuth range, and elevation range, as shown in Table 1 below.

[0064] Table 1. Conventional ViewportDataType

[0065]

[0066] In some embodiments, the metric ViewportDataType can include, among other things, the parameters center x, center y, and center z to indicate the viewport and viewpoint related information about the x-y-z translational motion of the user in the 6DoF environment.

[0067] In some embodiments, each of the parameters center x, center y, and center z can be specified as an integer in a decimal representation. The parameters center x, center y, and center z can represent the x-coordinate, y-coordinate, and z-coordinate of the center point of the sphere or plane containing the viewport, respectively. Table 2 below shows an example of a refined ViewportDataType including these parameters, among others.

[0068] Table 2. Example of a refined ViewportDataType

[0069]

[0070]

[0071] In some embodiments, the ViewportDataType can include other different parameters or keys, such as based on the position and rotation of the virtual camera. In some embodiments, the terms “parameter” and “key” are interchangeable.

[0072] In some embodiments, the metric ViewportDataType can include one or more keys to indicate x-y-z components of a rotation of the viewport. In some embodiments, the one or more keys can include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z to indicate x, y, and z components of a rotation of the viewport, respectively, using a quaternion representation.

[0073] In some embodiments, the metric ViewportDataType can include additional one or more keys to indicate x-y-z coordinates of a position of the viewport. In some embodiments, the additional one or more keys include three floating-point keys vp_pos_x, vp_pos_y, and vp_pos_z to indicate x, y, and z coordinates of a position of the viewport in a global reference coordinate system, respectively.

[0074] In some embodiments, the metric ViewportDataType can include a string key viewport_id to indicate an identifier of a camera to which the viewport belongs.

[0075] In some embodiments, the metric ViewportDataType can include an integer key viewport_type to indicate a type of the viewport.

[0076] In some embodiments, the metric ViewportDataType can include two Boolean keys to indicate whether the viewport position information corresponds to a center of the viewport, a left stereo position of the viewport, or a right stereo position of the viewport. In some embodiments, the two Boolean keys include a key vp_center_view_flag to indicate whether the viewport position information corresponds to a center of the viewport or one of two stereo positions of the viewport, and a key vp_left_view_flag to indicate whether the viewport position information corresponds to a left stereo position of the viewport or a right stereo position of the viewport.

[0077] Table 3 below shows an example of a refined ViewportDataType. In addition to the keys listed in Table 3, the metric ViewportDataType can include those keys in the conventional ViewportDataType.

[0078] Table 3. Example of a refined ViewportDataType

[0079]

[0080]

[0081] The values or value ranges in Table 3 are examples, and other values or value ranges can also apply. The present disclosure is not limited in this regard.

[0082] In some embodiments, the metrics described in connection with Table 3 can be used for visual volumetric video-based coding (V3C) content. In other embodiments, the metrics described in connection with Table 3 can be used for other content. The present disclosure is not limited in this regard.

[0083] Figure 7 A flowchart of a method 700 for generating immersive media metrics is shown, in accordance with some embodiments of the present disclosure. In some embodiments, the method 700 can include steps 710 and 720, which can be performed by an apparatus for a client (e.g., a client in Figures 2-4 MCR) of the apparatus. Figure 4

[0084] In 710, an immersive media metric ViewportDataType is generated to identify a viewport in a 6DoF environment. The immersive media metric ViewportDataType can include one or more keys to indicate x-y-z components of a rotation of the viewport.

[0085] In 720, the immersive media metric ViewportDataType is provided to a server.

[0086] The immersive media metric ViewportDataType described in the method 700 can include other keys shown in Table 3, which will not be described in detail.

[0087] In the above examples of refinement of ViewportDataType, the rendered viewport metrics (e.g., RenderedViewports) defined in Section 5.4 of ISO / IEC 23090-6 can also be used to report a list of viewports within PCC content in a 6DoF environment.

[0088] In the case of refinement(s) of ViewportDataType as described above, the comparable quality viewport switching delay and viewpoint switching delay metrics defined in Sections 5.5 and 5.6 of ISO / IEC 23090-6 can also be reused.

[0089] A sample 6DoF metric report structure can be as follows:

[0090] • as a function of time (gauge by real time and / or media time)

[0091] ​• Report the user's position and viewport in the point cloud

[0092] • For each PC object:

[0093] • If (object is in the user's viewport)

[0094] • Measure the distance of the object to the user's viewport

[0095] • Report the perceived quality / bandwidth, possibly in a per-tile consumed way

[0096] • Report DASH level metrics in a per-tile consumed way, e.g. buffer level, rebuffering events, consumed representations, their bitrates, codec information, etc.

[0097] • Report information about any lost or late fragments or tiles, etc.

[0098] This sample 6DoF metrics reporting structure can be applicable to the metric ViewportDataType. In addition, this sample 6DoF metrics reporting structure can also be applicable to other metrics. The present disclosure is not limited in this regard.

[0099] With the refinement of the metric ViewportDataType, both rotational and translational motion in a 6DoF environment can be supported, thus potentially increasing the level of immersion and user experience.

[0100] Figure 8 Example components of the device 800 in accordance with some embodiments are shown. In some embodiments, the device 800 can include application circuitry 802, baseband circuitry 804, Radio Frequency (RF) circuitry 806, front-end module (FEM) circuitry 808, one or more antennas 810, and power management circuitry (PMC) 812, which can be coupled together as shown in the example of Figure 8. The components of the device 800 can be included in a client or a server (e.g., a client or server as described above). In some embodiments, the device 800 can include less functionality than shown in Figure 8 (e.g., a server can not use application circuitry 802, but rather can include a processor / controller to process data received from a client device). In some embodiments, the device 800 can include additional elements such as, for example, memory / storage, display, camera, sensor, or input / output (I / O) interface. In other embodiments, the components described below can be included in more than one device (e.g., in some implementations, the circuitry described below can be separately included in more than one device).

[0101] The application circuitry 802 can include one or more application processors. For example, the application circuitry 802 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications and / or operating systems to run on the device 800. In some embodiments, the processors of application circuitry 802 can process IP packets received from the EPC.

[0102] The baseband circuitry 804 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 804 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 806 and to generate baseband signals for a transmit signal path of the RF circuitry 806. The baseband processing circuitry 804 can interface with the application circuitry 802 for generation and processing of the baseband signals and for control of the RF circuitry 806. For example, in some embodiments, the baseband circuitry 804 can include third generation (3G) baseband processor 804A, fourth generation (4G) baseband processor 804B, fifth generation (5G) baseband processor 804C, or other baseband processor(s) 804D for other existing generations, generations in development or future generations (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 804 (e.g., one or more of baseband processors 804A-D) can handle various radio control functions

[0103] In some embodiments, the baseband circuitry 804 can include one or more audio digital signal processors (DSP) 804F. The audio DSP(s) 804F can be configured to process audio data in accordance with a defined audio protocol, such as 3rd Generation Partnership Project (3GPP) Audio Codec

[0104] In some embodiments, the baseband circuitry 804 can provide communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 804 can support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMANs), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 804 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0105] RF circuitry 806 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 806 can include switches, filters, amplifiers, etc. to facilitate the communication with wireless networks. RF circuitry 806 can include a receive signal path, which can include circuitry to down-convert and filter received RF signals and provide baseband signals to the baseband circuitry 804. RF circuitry 806 can also include a transmit signal path, which can include circuitry to up-convert and filter baseband signals provided by the baseband circuitry 804 and provide generated RF signals to the FEM circuitry 808 for transmission.

[0106] In some embodiments, the receive signal path of the RF circuitry 806 can include mixer circuitry 806a, amplifier circuitry 806b and filter circuitry 806c. In some embodiments, the transmit signal path of the RF circuitry 806 can include filter circuitry 806c and mixer circuitry 806a. RF circuitry 806 can also include synthesizer circuitry 806d for synthesizing a frequency for use by the mixer circuitry 806a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 806a of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 808 based on a frequency provided by synthesizer circuitry 806d. The amplifier circuitry 806b can be configured to amplify the down-converted signals, and the filter circuitry 806c can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 804 for further processing. In some embodiments, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In as some embodiments, mixer circuitry 806a of the receive signal path can comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0107] In some embodiments, the mixer circuitry 806a of the transmit signal path can be configured to up-convert input baseband signals based on a frequency provided by synthesizer circuitry 806d to generate RF output signals for the FEM circuitry 808. The baseband signals can be provided by the baseband circuitry 804 and can be filtered by filter circuitry 806c.

[0108] In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path can include two or more mixers and can be arranged for quadrature downconversion and / or upconversion, respectively. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path can be arranged for direct downconversion and / or direct upconversion, respectively. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path can be configured for superheterodyne operation.

[0109] In some embodiments, the output baseband signals and the input baseband signals can be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternative embodiments, the RF circuitry 806 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 804 can include a digital baseband interface to communicate with the RF circuitry 806.

[0110] In some dual-mode embodiments, separate radio ICs can be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0111] In some embodiments, the synthesizer circuitry 806d can be a fractional N synthesizer or a fractional N / N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 806d can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0112] The synthesizer circuitry 806d can be configured to synthesize an output frequency for use by the mixer circuitry 806a of the RF circuitry 806 based on a frequency input and a divider control input. In some embodiments, synthesizer circuitry 806d can be a fractional N / N+1 synthesizer.

[0113] In some embodiments, the frequency input can be provided by a voltage controlled oscillator (VCO), although this is not a requirement. Divider control input can be provided by the baseband circuitry 804 or the application processor 802 based on a desired output frequency. In some embodiments, the divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the application processor 802.

[0114] Synthesizer circuitry 806d of the RF circuitry 806 can include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA). In some embodiments, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements can be configured to break a VCO period up into Nd equal phase components, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help assure that the total delay in the delay line is one VCO cycle.

[0115] In some embodiments, synthesizer circuitry 806d can be configured to generate a carrier frequency as an output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency can be a LO frequency (fLO). In some embodiments, the RF circuitry 806 can include an IQ / polar converter.

[0116] FEM circuitry 808 can include a receive signal path, which can include circuitry configured to operate on RF signals received from one or more antennas 810, amplify the received signals, and provide the amplified versions of the received signals to the RF circuitry 806 for further processing. FEM circuitry 808 can also include a transmit signal path, which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 806 as well as to filter out images and harmonics of the amplified signals. In various embodiments, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 806, solely in the FEM 808, or in both the RF circuitry 806 and the FEM 808.

[0117] In some embodiments, FEM circuitry 808 can include a TX / RX switch, to switch between transmit mode and receive mode operation. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include a low-noise amplifier (LNA) to amplify received RF signals, and provide the amplified received RF signals as an output (e.g., to the RF circuitry 806). The transmit signal path of the FEM circuitry 808 can include a power amplifier (PA) to amplify signals for transmission provided by the RF circuitry 806, and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 810).

[0118] In some embodiments, the PMC 812 can manage power provided to the baseband circuitry 804. In particular, the PMC 812 can control power source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 812 can typically be included on the device 800 when the device is capable of being powered by a battery, for example when the device is included in a client. The PMC 812 can increase the power conversion efficiency to provide a desirable implementation size and heat dissipation characteristics.

[0119] While Figure 8The PMC 812 is shown to be coupled to only the baseband circuitry 804. However, in other embodiments, the PMC 812 can be additionally or alternatively coupled to, and perform similar power management operations for, other components such as, but not limited to, the application circuitry 802, RF circuitry 806, or FEM 808.

[0120] In some embodiments, the PMC 812 can control, or otherwise be part of, various power-saving mechanisms of the device 800. For example, if the device 800 is in an RRC_Connected state, in which it is still connected to the server as it expects more traffic, it then can enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this time, the device 800 can power down for short periods of time, thus saving power.

[0121] If there is no data traffic for an extended period of time, then the device 800 can transition off to an RRC Idle state where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 800 in this state goes into a very low power state and

[0122] An additional power saving mode can allow a device to be unavailable to the network for a period of time (ranging from seconds to hours) during which time it does not perform operations such as channel quality feedback, handover, etc. It may

[0123] The processors of the application circuitry 802 and the processors of the baseband circuitry 804 can be used to execute instructions stored in memory (for example, non-transitory computer-readable storage medium) to perform various operations. For example, the processors of the baseband circuitry 804 (alone or in combination), can be used to execute layers 3, 2, or 1 functionality, while the processors of the application circuitry 804 can utilize data received by these layers (for example, packet data) and further execute layer 4 functionality. As referred to herein, layer 3 can include a radio resource control (RRC) layer. As referred to herein, layer 2 can include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer. As referred to herein, layer 1 can include a physical (PHY) layer that is client / server-based.

[0124] Figure 9An example of an infrastructure device 900 is shown, in accordance with various embodiments. The infrastructure device 900 (or“system 900”) can be implemented as a client, a server, and the like, such as the clients and servers shown and described previously. In other examples, the system 900 can be implemented in or by a client, the application server(s) 130, and / or any of the other elements / devices discussed herein. The system 900 can include one or more of: application circuitry 905, baseband circuitry 910, one or more radio front end modules (RFEMs) 915, memory 920, power management integrated circuitry (PMIC) 925, power tee circuitry 930, network controller 935, network interface connector 940, satellite positioning circuitry 945, and user interface 950. In some embodiments, the device 900 can include additional elements such as storage, a display, a camera, a sensor, or an input / output (I / O) interface element. In other embodiments, the components described below can be included in more than one device (for example, the circuitries can be divided between multiple devices for some implementations).

[0125] As used herein, the term“circuitry” can refer to, be part of, or include an integrated circuit (IC), an Application-Specific Integrated Circuit (ASIC), a system-on-chip (SoC), a processor, a microprocessor, a programmable logic device (PLD), a programmable logic array (PLA), a field-programmable gate array (FPGA), a memory unit, a storage unit, a memory device, a storage device, a storage medium, a processor, a controller, a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), a video processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a programmable logic array (PLA), a field-programmable gate array (FPGA), a digital circuit, an analog circuit, a combination thereof, or any other processing unit.

[0126] The terms “application circuit” and / or “baseband circuit” may be considered synonymous with “processor circuit” and may be referred to as “processor circuit”. For the purposes of this document, the term “processor circuit” may refer to, be part of, or include circuits capable of sequentially and automatically performing a sequence of arithmetic or logical operations; and recording, storing, and / or transmitting digital data. The term “processor circuit” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes.

[0127] Application circuitry 905 may include one or more central processing unit (CPU) cores and one or more of the following: cache memory, low dropout (LDO) regulator, interrupt controller, serial interface such as SPI, I2C, or a universal programmable serial interface module, real time clock (RTC), timer-counter including interval and watchdog timers, general purpose input / output (I / O), memory card controller such as Secure Digital (SD) / MultiMediaCard (MMC), Universal Serial Bus (USB) interface, Mobile Industry Processor Interface (MIPI) interface, and Joint Test Access Group (JTAG) test access port. As an example, application circuitry 905 may include one or more Intel... or Processor; Advanced Micro Devices (AMD) Processor, Accelerated Processing Unit (APU) or Processor; etc. In some embodiments, system 900 may not utilize application circuitry 905, but may instead include, for example, a dedicated processor / controller to process IP data received from EPC or 5GC.

[0128] Additionally or alternatively, application circuitry 905 can include circuitry such as, but not limited to, one or more a field-programmable device(s) (FPD) such as field-programmable gate arrays (FPGA), programmable logic devices (PLD), complex programmable logic device (CPLD), high- capacity PLD (HCPLD), programmable SoC (PSoC), etc. In this embodiment, the circuitry of application circuitry 905 can include logic blocks or logic fabric, including other interconnected resources that can be programmed to perform various functions, such as the processes, methods, functions and procedures discussed herein. In this embodiment, the circuitry of application circuitry 905 can include a storage unit (e.g., non- volatile memory or storage such as EPROM, EEPROM, flash memory, static

[0129] Baseband circuitry 910 can be implemented, for example, as a solder-down application specific integrated circuit (ASIC) that includes one or more integrated circuits or chips (not shown) depending on implementation requirements. Baseband circuitry 910 can include one or more processors 910A, one or more memories 910B, one or more digital baseband processors 910C, one or more digital baseband interfaces 910D, one or more mixed signal interfaces 910E, one or more power management interfaces 910F, one or more power control interfaces 910G, one or more static random access memory (SRAM) units 910H, and one or more processing blocks 910I. In an example embodiment, one or more of the components of baseband circuitry 910 can be integrated with one or more components of application circuitry 905. In another embodiment, one or more of the components of baseband circuitry 910 can be implemented as a separate element that is coupled to (e.g., via a bus, a point to point interface, a network, etc.) application circuitry 905. In some embodiments, one or more of the components of baseband circuitry 910 can be used by both application circuitry 905 and radio front end circuitry 915. In other embodiments, one or more of the components of baseband circuitry 910 can be used by only one of application circuitry 905 or radio front end circuitry 915.

[0130] User interface circuitry 950 can include one or more user interfaces designed to enable interaction with a user of system 900 or peripheral component interfaces designed to enable interaction with peripheral components of system 900. User interfaces can include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, etc. Peripheral component interfaces can include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, etc.

[0131] Radio front end modules (RFEMs) 915 can include millimeter wave RFEMs and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs can be physically separate from the millimeter wave RFEMs. The RFICs can include connections to one or more antennas or antenna arrays, and the RFEMs can be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions can be implemented in the same physical radio front end module 915. RFEMs 915 can contain both millimeter wave antennas and sub-millimeter wave antennas.

[0132] Memory circuitry 920 can include one or more of volatile memory, including dynamic random access memory (DRAM), and / or non-volatile memory (NVM), including flash memory, phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and can include any of the 3D Cross Point (XPOINT) memory from Intel® and Micron®. Memory circuitry 920 can be implemented as one or more of solder-down packaged integrated circuits, socketed memory modules, and plug-in memory cards. and Memory circuitry 920 can be implemented as one or more of solder-down packaged integrated circuits, socketed memory modules, and plug-in memory cards.

[0133] The PMIC 925 can include voltage regulators, surge protectors, power alarm detection circuitry, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuitry can detect one or more of brownouts (under-voltage) and power surges (over-voltage). The power tee circuitry 930 can provide power drawn from a network cable to provision both power supply and data connectivity to the infrastructure equipment 900 using a single cable.

[0134] The network controller circuitry 935 can provide connectivity to a network using a standard network interface protocol such as Ethernet, GRE-tunnelled Ethernet, Multiprotocol Label Switching (MPLS)-based Ethernet, or some other appropriate protocol. Network connectivity to / from the infrastructure equipment 900 can be provided via the network interface connector 940 using a physical connection, which can be electrical (commonly referred to as a “copper interconnect”), optical, or wireless. The network controller circuitry 935 can include one or more dedicated processors and / or FPGAs to communicate using one or more of the above-mentioned protocols. In some implementations, the network controller circuitry 935 can include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0135] The positioning circuitry 945 can include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) can include the United States’ Global Positioning System (GPS), the Russian GLObal NAvigation System (GLONASS), the European Union’s Galileo system, China’s BeiDou Navigation Satellite System, a regional navigation system or GNSS augmentation system (such as Navigation with Indian Constellation (NAVIC), Japan’s Quasi-Zenith Satellite System (QZSS), France’s Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), etc.), or the like. The positioning circuitry 945 can include various hardware elements (including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate communication over-the-air (OTA) communications) to communicate with components of a positioning network (such as navigation satellite constellation nodes).

[0136] A node or satellite of a navigation satellite constellation(s) (“GNSS node”) can provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight that can be used by a GNSS receiver (e.g., positioning circuitry 945 and / or positioning circuitry implemented by a client, etc.) to determine its GNSS position. A GNSS signal can include a pseudo-random code known to the GNSS receiver (e.g., a sequence of ones and zeros) and a message including a time of transmission (ToT) of the code epoch (e.g., a defined point in the pseudo-random code sequence) and a GNSS node position at the ToT. The GNSS receiver can monitor / measure GNSS signals transmitted / broadcast by multiple GNSS nodes (e.g., four or more satellites) and solve various equations to determine a corresponding GNSS position (e.g., spatial coordinates). GNSS receivers also implement clocks that are typically not as stable and accurate as the atomic clocks of the GNSS nodes, and the GNSS receiver can use the measured GNSS signals to determine a bias of the GNSS receiver relative to true time (e.g., a deviation of the GNSS receiver clock relative to GNSS node time). In some embodiments, positioning circuitry 945 can include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a primary timing clock to perform position tracking / estimation without GNSS assistance.

[0137] A GNSS receiver can measure a time of arrival (ToA) of GNSS signals from multiple GNSS nodes according to its own clock. The GNSS receiver can determine a time of flight (ToF) value for each received GNSS signal according to the ToA and the ToT, and can then determine a three-dimensional (3D) position and clock bias according to the ToF. The 3D position can then be converted to latitude, longitude, and altitude. Positioning circuitry 945 can provide data to application circuitry 905, which can include one or more of position data or time data. Application circuitry 905 can use time data to operate synchronously with other devices.

[0138] Figure 9The illustrated components can communicate with one another using interface circuits. As used herein, the term "interface circuit" can refer to, be part of, or include, circuitry that supports the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as a bus, an input / output (I / O) interface, a peripheral component interface, a network interface card, etc. Any suitable bus technology can be used in various implementations, which can include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The bus can be a proprietary bus used in SoC-based systems, for example. Other bus systems can be included, such as I2C interfaces, SPI interfaces, point-to-point interfaces, and power buses, among others.

[0139] Figure 10 is a block diagram illustrating a component that can read instructions from a machine- or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein, according to some example embodiments. Specifically, the Figure 10 A diagrammatic representation of the hardware resources 1000 is shown, including one or more processors (or processor cores) 1010, one or more memory / storage devices 1020, and one or more communication resources 1030, each of which can be communicatively coupled via a bus 1040. For embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1002 can be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1000.

[0140] The processors 1010 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) can include, for example, a processor 1012 and a processor 1014.

[0141] The memory / storage 1020 can include main memory, disk storage, or any suitable combination thereof. The memory / storage 1020 can include, but is not limited to, any type of volatile or nonvolatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0142] The communication resources 1030 can include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1004 or one or more databases 1006 via a network 1008. For example, the communication resources 1030 can include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Bluetooth components (e.g., Bluetooth Low Energy), Wi-Fi components, and other communication components.

[0143] The instructions 1050 can include software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1010 to perform any one or more of the methodologies discussed herein. The instructions 1050 can reside completely, though portions of the instructions 1050 can reside completely, within at least one of the processors 1010 (e.g., within the cache memory of the processors), the memory / storage 1020, or any suitable combination thereof. Furthermore, any portion of the instructions 1050 can be transferred between any combination of the hardware resources 1000, the peripheral devices 1004, and the databases 1006. Accordingly, the memory of the processors 1010, the memory / storage 1020, the peripheral devices 1004, and the databases 1006 are all examples of computer- and machine-readable media.

[0144] The following paragraphs describe examples of various embodiments.

[0145] Example 1 includes an apparatus for a client, the apparatus comprising: a memory; and a processor circuit coupled with the memory, wherein the processor circuit is to: generate a viewport data type, ViewportDataType, to identify a viewport in a six degrees of freedom (6DoF) environment, wherein the viewport data type, ViewportDataType, includes one or more keys to indicate x-y-z components of a rotation of the viewport; and provide the viewport data type, ViewportDataType, to a server, and wherein the memory is to store the viewport data type, ViewportDataType.

[0146] Example 2 includes the apparatus of Example 1, wherein the immersive media metric ViewportDataType is generated for Video-based Visual Volume Coding (V3C) content.

[0147] Example 3 includes the apparatus of Example 1, wherein the one or more keys include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z to indicate x, y, and z components, respectively, of the rotation of the viewport using a quaternion representation.

[0148] Example 4 includes the apparatus of Example 1, wherein the immersive media metric ViewportDataType includes additional one or more keys to indicate x-y-z coordinates of a position of the viewport.

[0149] Example 5 includes the apparatus of Example 4, wherein the additional one or more keys include three floating-point keys vp_pos_x, vp_pos_y, and vp_pos_z to indicate x, y, and z coordinates, respectively, of the position of the viewport in a global reference coordinate system.

[0150] Example 6 includes the apparatus of Example 1, wherein the immersive media metric ViewportDataType further includes a string key viewport_id to indicate an identifier of a camera to which the viewport belongs.

[0151] Example 7 includes the apparatus of Example 1, wherein the immersive media metric ViewportDataType further includes an integer key viewport_type to indicate a type of the viewport.

[0152] Example 8 includes the apparatus of Example 1, wherein the immersive media metric ViewportDataType further includes two Boolean keys to indicate whether the viewport position information corresponds to a center of the viewport, a left stereo position of the viewport, or a right stereo position of the viewport.

[0153] Example 9 includes the apparatus of Example 8, wherein the two Boolean keys include a key vp_center_view_flag to indicate whether the viewport position information corresponds to the center of the viewport or one of the two stereo positions of the viewport, and a key vp_left_view_flag to indicate whether the viewport position information corresponds to the left stereo position of the viewport or the right stereo position of the viewport.

[0154] Example 10 includes an apparatus for a client, the apparatus comprising: a first interface; and a processor circuit coupled with the first interface, wherein the processor circuit is to: obtain sensor data from a sensor via the first interface, wherein the sensor data comprises viewport and viewpoint related information about x-y-z translational motion of a user in a six degrees of freedom (6DoF) environment; and generate an immersive media metric based at least in part on the sensor data for transmission to a server.

[0155] Example 11 includes the apparatus of Example 10, wherein the immersive media metric comprises a metric ViewportDataType to indicate information related to a data type of a viewport; and wherein the metric ViewportDataType comprises parameters center_x, center_y, and center_z to indicate the viewport and viewpoint related information about x-y-z translational motion of the user in the 6DoF environment.

[0156] Example 12 includes the apparatus of Example 11, wherein each of the parameters center_x, center_y, and center_z specifies an integer in a decimal notation, and wherein the parameters center_x, center_y, and center_z represent x, y, and z coordinates, respectively, of a center point of a sphere or a plane containing the viewport.

[0157] Example 13 includes the apparatus of Example 10, wherein the processor circuit is to: obtain media immersive video (MIV) metadata or volumetric point cloud coding (V-PCC) metadata via a second interface; and generate the immersive media metric further based on the MIV metadata or the V-PCC metadata.

[0158] Example 14 includes the apparatus of Example 13, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volume annotation information or scene object information.

[0159] Example 15 includes an apparatus for a client, the apparatus comprising: a first interface; and a processor circuit coupled with the first interface, wherein the processor circuit is to: obtain, via the first interface, immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata in a six degrees of freedom (6DoF) environment, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volume annotation information or scene object information; and generate immersive media metrics based at least in part on the MIV metadata or the V-PCC metadata for transmission to a server.

[0160] Example 16 includes the apparatus of Example 15, wherein the processor circuit is to: obtain, via a second interface, sensor data from a sensor, wherein the sensor data comprises viewport and viewpoint related information about x-y-z translational motion of a user in the 6DoF environment; and generate the immersive media metrics further based on the sensor data.

[0161] Example 17 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to: generate an immersive media metric ViewportDataType to identify a viewport in a six degrees of freedom (6DoF) environment for video-based visual volumetric coding (V3C) content, wherein the immersive media metric ViewportDataType comprises one or more keys to indicate x-y-z components of a rotation of the viewport; and send the immersive media metric ViewportDataType to a server.

[0162] Example 18 includes the computer-readable medium of Example 17, wherein the one or more keys comprise three integer keys vp_quat_x, vp_quat_y, and vp_quat_z to indicate x, y, and z components of the rotation of the viewport, respectively, using a quaternion representation.

[0163] Example 19 includes the computer-readable medium of Example 17, wherein the immersive media metric ViewportDataType comprises additional one or more keys to indicate x-y-z coordinates of a position of the viewport.

[0164] Example 20 includes the computer-readable medium of Example 19, wherein the additional one or more keys comprise three floating keys vp_pos_x, vp_pos_y, and vp_pos_z to indicate x, y, and z coordinates, respectively, of the position of the viewport in a global reference coordinate system.

[0165] Example 21 includes the computer-readable medium of Example 17, wherein the immersive media metric ViewportDataType further includes a string key viewport id to indicate an identifier of a camera to which the viewport belongs.

[0166] Example 22 includes the computer-readable medium of Example 17, wherein the immersive media metric ViewportDataType further includes an integer key viewport type to indicate a type of the viewport.

[0167] Example 23 includes the computer-readable medium of Example 17, wherein the immersive media metric ViewportDataType further includes two Boolean keys to indicate whether the viewport position information corresponds to a center of the viewport, a left stereo position of the viewport, or a right stereo position of the viewport.

[0168] Example 24 includes the computer-readable medium of Example 23, wherein the two Boolean keys include a key vp_center_view_flag to indicate whether the viewport position information corresponds to a center of the viewport or one of two stereo positions of the viewport, and a key vp_left_view_flag to indicate whether the viewport position information corresponds to a left stereo position of the viewport or a right stereo position of the viewport.

[0169] Example 25 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to: obtain sensor data from a sensor, wherein the sensor data includes viewport and viewpoint related information about x-y-z translational motion of a user in a six degrees of freedom (6DoF) environment; and generate, based at least in part on the sensor data, an immersive media metric for transmission to a server.

[0170] Example 26 includes the computer-readable medium of Example 25, wherein the immersive media metric includes a metric ViewportDataType to indicate information about a data type of a viewport; and wherein the metric ViewportDataType includes parameters center x, center y, and center z to indicate the viewport and viewpoint related information about x-y-z translational motion of the user in the 6DoF environment.

[0171] Example 27 includes the computer-readable medium of Example 26, wherein each of the parameters center_x, center_y, and center_z specifies an integer in a decimal notation, and wherein the parameters center_x, center_y, and center_z represent x, y, and z coordinates, respectively, of a center point of a sphere or a plane that contains the viewport.

[0172] Example 28 includes the computer-readable medium of Example 25, wherein the instructions, when executed by the processor circuit, further cause the processor circuit to: obtain immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata; and generate the immersive media metrics based further on the MIV metadata or the V-PCC metadata.

[0173] Example 29 includes the computer-readable medium of Example 28, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volume annotation information or scene object information.

[0174] Example 30 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to: obtain immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata in a six degrees of freedom (6DoF) environment, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volume annotation information or scene object information; and generate immersive media metrics based at least in part on the MIV metadata or the V-PCC metadata for transmission to a server.

[0175] Example 31 includes the computer-readable medium of Example 30, wherein the instructions, when executed by the processor circuit, further cause the processor circuit to: obtain sensor data from a sensor, wherein the sensor data comprises viewport and viewpoint related information about x-y-z translational motion of a user in the 6DoF environment; and generate the immersive media metrics based further on the sensor data.

[0176] Example 32 includes a method comprising: generating, for a video-based visual volume coding (V3C) content, an immersive media metric ViewportDataType to identify a viewport in a six degrees of freedom (6DoF) environment, wherein the immersive media metric ViewportDataType includes one or more keys to indicate x-y-z components of a rotation of the viewport; and sending the immersive media metric ViewportDataType to a server.

[0177] Example 33 includes the method of Example 32, wherein the one or more keys include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z to indicate x, y, and z components, respectively, of the rotation of the viewport using a quaternion representation.

[0178] Example 34 includes the method of Example 32, wherein the immersive media metric ViewportDataType includes additional one or more keys to indicate x-y-z coordinates of a position of the viewport.

[0179] Example 35 includes the method of Example 34, wherein the additional one or more keys include three floating-point keys vp_pos_x, vp_pos_y, and vp_pos_z to indicate x, y, and z coordinates, respectively, of the position of the viewport in a global reference coordinate system.

[0180] Example 36 includes the method of Example 32, wherein the immersive media metric ViewportDataType further includes a string key viewport_id to indicate an identifier of a camera to which the viewport belongs.

[0181] Example 37 includes the method of Example 32, wherein the immersive media metric ViewportDataType further includes an integer key viewport_type to indicate a type of the viewport.

[0182] Example 38 includes the method of Example 32, wherein the immersive media metric ViewportDataType further includes two Boolean keys to indicate whether a viewport position information corresponds to a center of the viewport, a left stereo position of the viewport, or a right stereo position of the viewport.

[0183] Example 39 includes the method of example 38, wherein the two Boolean keys include: a key vp_center_view_flag to indicate whether the viewport position information corresponds to a center of the viewport or one of two stereoscopic positions of the viewport; and a key vp_left_view_flag to indicate whether the viewport position information corresponds to a left stereoscopic position of the viewport or a right stereoscopic position of the viewport.

[0184] Example 40 includes a method comprising: obtaining sensor data from a sensor, wherein the sensor data includes viewport and viewpoint related information about x-y-z translational motion of a user in a six degrees of freedom (6DoF) environment; and generating, based at least in part on the sensor data, an immersive media metric for transmission to a server.

[0185] Example 41 includes the method of example 40, wherein the immersive media metric includes a metric ViewportDataType to indicate information related to a data type of a viewport; and wherein the metric ViewportDataType includes parameters center_x, center_y, and center_z to indicate the viewport and viewpoint related information about x-y-z translational motion of the user in the 6DoF environment.

[0186] Example 42 includes the method of example 41, wherein each of the parameters center_x, center_y, and center_z specifies an integer in a decimal representation, and wherein the parameters center_x, center_y, and center_z represent x, y, and z coordinates of a center point of a sphere or a plane containing the viewport, respectively.

[0187] Example 43 includes the method of example 40, further comprising: obtaining immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata; and generating the immersive media metric further based on the MIV metadata or the V-PCC metadata.

[0188] Example 44 includes the method of example 43, wherein the MIV metadata includes viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata includes volume annotation information or scene object information.

[0189] Example 45 includes a method comprising: in a six-degrees-of-freedom (6DoF) environment, obtaining immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata, wherein the MIV metadata includes viewport camera information, viewport location information, or viewing space information, and wherein the V-PCC metadata includes volumetric annotation information or scene object information; and generating immersive media metrics, at least in part, based on the MIV metadata or the V-PCC metadata, for transmission to a server.

[0190] Example 46 includes the method of Example 45, further comprising: obtaining sensor data from a sensor, wherein the sensor data includes viewport and viewpoint related information about the user's xyz translational motion in the 6DoF environment; and also generating the immersive media metric based on the sensor data.

[0191] Example 47 includes an apparatus comprising: means for generating an immersive media metric ViewportDataType for video-based visual volumetric coding (V3C) content to identify a viewport in a six-degrees-of-freedom (6DoF) environment, wherein the immersive media metric ViewportDataType includes one or more keys to indicate xyz components of rotation of the viewport; and means for sending the immersive media metric ViewportDataType to a server.

[0192] Example 48 includes the device described in Example 47, wherein the one or more keys include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z to indicate the x, y, and z components of the rotation of the viewport, respectively, using quaternion representation.

[0193] Example 49 includes the device described in Example 47, wherein the immersive media metric ViewportDataType includes one or more additional keys to indicate the xyz coordinates of the viewport's location.

[0194] Example 50 includes the device described in Example 49, wherein the additional one or more keys include three floating keys vp_pos_x, vp_pos_y, and vp_pos_z to indicate the position of the viewport in the global reference coordinate system, respectively, the x-coordinate, y-coordinate, and z-coordinate.

[0195] Example 51 includes the device described in Example 47, wherein the immersive media metric ViewportDataType further includes a string key viewport_id to indicate an identifier of the camera to which the viewport belongs.

[0196] Example 52 includes the device of Example 47, wherein the immersive media metric ViewportDataType further includes an integer key viewport_type to indicate a type of the viewport.

[0197] Example 53 includes the device of Example 47, wherein the immersive media metric ViewportDataType further includes two Boolean keys to indicate whether the viewport position information corresponds to a center of the viewport, a left stereoscopic position of the viewport, or a right stereoscopic position of the viewport.

[0198] Example 54 includes the device of Example 53, wherein the two Boolean keys include a key vp_center_view_flag to indicate whether the viewport position information corresponds to a center of the viewport or one of two stereoscopic positions of the viewport, and a key vp_left_view_flag to indicate whether the viewport position information corresponds to a left stereoscopic position of the viewport or a right stereoscopic position of the viewport.

[0199] Example 55 includes a device comprising: means for obtaining sensor data from a sensor, wherein the sensor data includes viewport and viewpoint related information about x-y-z translational motion of a user in a six degrees of freedom (6DoF) environment; and means for generating, based at least in part on the sensor data, an immersive media metric for transmission to a server.

[0200] Example 56 includes the device of Example 55, wherein the immersive media metric includes a metric ViewportDataType to indicate information about a data type of a viewport; and wherein the metric ViewportDataType includes parameters center_x, center_y, and center_z to indicate the viewport and viewpoint related information about x-y-z translational motion of the user in the 6DoF environment.

[0201] Example 57 includes the device of Example 56, wherein each of the parameters center_x, center_y, and center_z specifies an integer in a decimal notation, and wherein the parameters center_x, center_y, and center_z represent an x-coordinate, a y-coordinate, and a z-coordinate, respectively, of a center point of a sphere or a plane that contains the viewport.

[0202] Example 58 includes the device of Example 55, further comprising: means for obtaining immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata; and means for generating the immersive media metrics further based on the MIV metadata or the V-PCC metadata.

[0203] Example 59 includes the device of Example 58, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volumetric annotation information or scene object information.

[0204] Example 60 includes a device comprising: means for obtaining immersive video metadata (MIV) metadata or video-based point cloud coding (V-PCC) metadata in a six degrees of freedom (6DoF) environment, wherein the MIV metadata comprises viewport camera information, viewport position information, or viewing space information, and wherein the V-PCC metadata comprises volumetric annotation information or scene object information; and means for generating immersive media metrics based at least in part on the MIV metadata or the V-PCC metadata for transmission to a server.

[0205] Example 61 includes the device of Example 60, further comprising: means for obtaining sensor data from a sensor, wherein the sensor data comprises viewport and viewpoint related information about x-y-z translational motion of a user in the 6DoF environment; and means for generating the immersive media metrics further based on the sensor data.

[0206] Example 62 includes a client as described and illustrated in the specification.

[0207] Example 63 includes a method performed at a client as described and illustrated in the specification.

[0208] While certain embodiments have been illustrated and described herein, various substitutions and / or modifications can be made to the embodiments or implementations contemplated herein without departing from the scope of the disclosure. The present application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is readily apparent that the embodiments described herein are only by way of example.

Claims

1. An apparatus for a client, the apparatus comprising: Memory; and Processor circuitry, wherein the processor circuitry is coupled to the memory. The processor circuit is used for: Generate an immersive media metric ViewportDataType to identify a viewport in a six-degrees-of-freedom (6DoF) environment, wherein the immersive media metric ViewportDataType includes one or more keys to indicate the xyz components of the viewport's rotation; and Provide the immersive media metric ViewportDataType to the server, and The memory is used to store the immersive media metric ViewportDataType.

2. The apparatus according to claim 1, wherein, The immersive media metric ViewportDataType is generated for video-based visual volumetric coding (V3C) content.

3. The apparatus according to claim 1, wherein, The one or more keys include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z, which are used to indicate the x, y, and z components of the rotation of the viewport, respectively, using quaternion representation.

4. The apparatus according to claim 1, wherein, The immersive media metric ViewportDataType includes one or more additional keys to indicate the xyz coordinates of the viewport's location.

5. The apparatus according to claim 4, wherein, The additional one or more keys include three floating keys vp_pos_x, vp_pos_y, and vp_pos_z, which respectively indicate the x, y, and z coordinates of the viewport's position in the global reference coordinate system.

6. The apparatus according to claim 1, wherein, The immersive media metric ViewportDataType also includes a string key viewport_id to indicate the identifier of the camera to which the viewport belongs.

7. The apparatus according to claim 1, wherein, The immersive media metric ViewportDataType also includes an integer key viewport_type to indicate the type of the viewport.

8. The apparatus according to claim 1, wherein, The immersive media metric ViewportDataType also includes two Boolean keys to indicate whether the viewport position information corresponds to the center of the viewport, the left stereo position of the viewport, or the right stereo position of the viewport.

9. The apparatus according to claim 8, wherein, The two Boolean keys include: The key `vp_center_view_flag` is used to indicate whether the viewport position information corresponds to the center of the viewport or one of two stereoscopic positions of the viewport; and The key vp_left_view_flag is used to indicate whether the viewport position information corresponds to the left stereo position or the right stereo position of the viewport.

10. An apparatus for a client, the apparatus comprising: First interface; and The processor circuit is coupled to the first interface. The processor circuit is used for: Sensor data is obtained from the sensor via the first interface, wherein the sensor data includes viewport and viewpoint related information regarding the user's xyz translational motion in a six-degrees-of-freedom (6DoF) environment; and Immersive media metrics are generated, at least in part, based on the sensor data, and then transmitted to the server.

11. The apparatus according to claim 10, wherein, The immersive media metric includes a metric ViewportDataType to indicate information related to the data type of the viewport; and wherein the metric ViewportDataType includes parameters center_x, center_y, and center_z to indicate viewport and viewpoint related information regarding the user's xyz translational motion in the 6DoF environment.

12. The apparatus according to claim 11, wherein, Each of the parameters center_x, center_y, and center_z is specified as an integer in decimal representation, and the parameters center_x, center_y, and center_z respectively represent the x-coordinate, y-coordinate, and z-coordinate of the center point of the sphere or plane containing the viewport.

13. The apparatus according to claim 10, wherein, The processor circuit is used for: Obtain immersive video metadata (MIV) or video-based point cloud coding (V-PCC) metadata via the second interface; and The immersive media metric is also generated based on the MIV or the V-PCC metadata.

14. The apparatus according to claim 13, wherein, The MIV includes viewport camera information, viewport position information, or viewing space information, and the V-PCC metadata includes volume annotation information or scene object information.

15. An apparatus for a client, the apparatus comprising: First interface; and The processor circuit is coupled to the first interface. The processor circuit is used for: In a six-degrees-of-freedom (6DoF) environment, immersive video metadata (MIV) or video-based point cloud coding (V-PCC) metadata is obtained via the first interface. The MIV includes viewport camera information, viewport position information, or viewing space information, and the V-PCC metadata includes volumetric annotation information or scene object information. Immersive media metrics are generated at least in part based on the MIV or the V-PCC metadata for transmission to the server.

16. The apparatus according to claim 15, wherein, The processor circuit is used for: Sensor data is acquired from the sensor via a second interface, wherein the sensor data includes viewport and viewpoint information related to the user's xyz translational motion in the 6DoF environment; and The immersive media metric is also generated based on the sensor data.

17. A computer-readable medium having instructions stored thereon, wherein the instructions, when executed by processor circuitry, cause the processor circuitry to: For video-based visual volumetric coding (V3C) content, an immersive media metric ViewportDataType is generated to identify a viewport in a six-degrees-of-freedom (6DoF) environment, wherein the immersive media metric ViewportDataType includes one or more keys to indicate the xyz components of the viewport's rotation; and Send the immersive media metric ViewportDataType to the server.

18. The computer-readable medium of claim 17, wherein, The one or more keys include three integer keys vp_quat_x, vp_quat_y, and vp_quat_z, which are used to indicate the x, y, and z components of the rotation of the viewport, respectively, using quaternion representation.

19. The computer-readable medium of claim 17, wherein, The immersive media metric ViewportDataType includes one or more additional keys to indicate the xyz coordinates of the viewport's location.

20. The computer-readable medium of claim 19, wherein, The additional one or more keys include three floating keys vp_pos_x, vp_pos_y, and vp_pos_z, which respectively indicate the x, y, and z coordinates of the viewport's position in the global reference coordinate system.

21. The computer-readable medium of claim 17, wherein, The immersive media metric ViewportDataType also includes a string key viewport_id to indicate the identifier of the camera to which the viewport belongs.

22. The computer-readable medium of claim 17, wherein, The immersive media metric ViewportDataType also includes an integer key viewport_type to indicate the type of the viewport.

23. The computer-readable medium of claim 17, wherein, The immersive media metric ViewportDataType also includes two Boolean keys to indicate whether the viewport position information corresponds to the center of the viewport, the left stereo position of the viewport, or the right stereo position of the viewport.

24. The computer-readable medium of claim 23, wherein, The two Boolean keys include: The key `vp_center_view_flag` is used to indicate whether the viewport position information corresponds to the center of the viewport or one of two stereoscopic positions of the viewport; and The key vp_left_view_flag is used to indicate whether the viewport position information corresponds to the left stereo position or the right stereo position of the viewport.

Images