Video-based point cloud stream

Abstract

To provide a system, device and method for processing video-based point cloud streams in an ISO Base Media File Format (ISOBMFF) container files associated with a three-dimensional (3D) space.SOLUTION: 3D space 602 (e.g., a bounding box corresponding to the 3D space) for a point cloud may be divided into a 3D cube grid (e.g., cuboids 602a, 602b, 602c, etc.) representing a plurality of regions and / or objects in the 3D space. The points belonging to each of the regions and / or objects within the 3D space may be clustered and a bounding box may be used to represent that region or object. Points belonging to different parts of the same object may be grouped together and may be represented by a respective bounding box for that part.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 852,046, filed May 23, 2019, and U.S. Provisional Patent Application No. 62 / 907,249, filed September 27, 2019, the disclosures of which are incorporated herein by reference in their entireties. [Background technology]

[0002] background

[0002] Video coding systems can be used to compress and / or decompress digital video signals (e.g., to reduce the storage and / or transmission bandwidth required for such signals). Three-dimensional (3D) point clouds have emerged as an advanced representation of immersive media. These point clouds can be captured in many ways, for example, using multiple cameras, depth sensors, and / or light detection and ranging (LiDAR) laser scanners. The number of points required to realistically reconstruct objects and / or scenes in 3D space can be on the order of millions or billions. Therefore, efficient representation, compression, and / or delivery techniques for storing and / or transmitting point cloud data are desirable. Summary of the Invention

[0003] overview

[0003] Systems, methods, and means for processing video data associated with a three-dimensional (3D) space are disclosed. A video decoding device described herein may include a processor configured to receive a media container file (e.g., an International Organization for Standardization (ISO) Base Media File Format (ISOBMFF) container file) including a video-based point cloud compression (V-PCC) bitstream. The processor may analyze the media container file and / or the V-PCC bitstream included therein to determine region identifiers (IDs) of 3D regions within the 3D space and track group IDs for each of one or more track groups associated with the 3D space. The processor may determine that one or more track groups are associated with the 3D region based on determining that the track group IDs for each of the one or more track groups are linked to the region IDs of the 3D region. The processor may decode video tracks (e.g., corresponding to one or more tiles in a 2D frame) belonging to the one or more track groups to render a visual representation of the 3D region in the 3D space. One or more track groups described herein may share a common track group type, and the one or more track groups may be determined to be associated with a 3D region further based on the track group type. The medial container file may include one or more structures defining the number of regions associated with the 3D space and the number of track groups associated with each of these regions, and the processor may be configured to determine, based on information included in the structures, that a track group ID of each of the one or more track groups is linked to a region ID of the 3D region.

[0004]

[0004] The medial container file may include timed metadata that includes information associated with a subset of updated regions, and the timed metadata may indicate updates to this subset of regions (e.g., position, dimensions, etc.). Furthermore, the video track may include one or more sample entries, each of which may include an indication of a length of a data field indicating a network abstraction layer (NAL) unit size. The sample entry may further include an indication of the number of V-PCC parameter sets associated with the sample entry or the number of arrays of atlas NAL units associated with the sample entry. [Brief explanation of the drawings]

[0005] BRIEF DESCRIPTION OF THE DRAWINGS [Figure 1A] FIG. 5 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]

[0006] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 1C]

[0007] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 1D]

[0008] FIG. 1B is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 2]

[0009] 1 illustrates an exemplary video-based point cloud compression (V-PCC) bitstream structure including multiple V-PCC units. [Figure 3]

[0010] 1 illustrates an exemplary media container structure. [Figure 4]

[0011] 1 illustrates exemplary constraints under which intra-random access point (IRAP) samples of a component are aligned. [Figure 5]

[0012] An example of using the least common multiple of IRAP periods to indicate a V-PCC IRAP is shown. [Figure 6]

[0013] 1 illustrates an exemplary media container structure that may be used to enable spatial access to specific regions in 3D space. DETAILED DESCRIPTION OF THE INVENTION

[0006] Detailed Description

[0014] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which:

[0007]

[0015] 1A is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including radio spectrum). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filter OFDM, filter bank multicarrier (FBMC), etc.

[0008]

[0016] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d, RANs 104 / 113, CNs 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (all of which may also be referred to as “stations” and / or “STAs”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

[0009]

[0017] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks (e.g., the CN 106 / 115, the Internet 110, and / or other networks 112). By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. It will be understood that while each of the base stations 114a, 114b is depicted as a single element, it may include any number of interconnected base stations and / or network elements.

[0010]

[0018] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (e.g., base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc.) (not shown). The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, sometimes referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers (i.e., one for each sector of the cell). In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0011]

[0019] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0012]

[0020] Specifically, as noted above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology (such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA)) that may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Enhanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0013]

[0020] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology (such as Evolved UMTS Terrestrial Radio Access (E-UTRA)) that may establish the air interface 116 by using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0014]

[0022] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR Radio Access), which may establish the air interface 116 by using NR.

[0015]

[0023] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, for example, by using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNB and gNB).

[0016]

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0017]

[0025] 1A may be a wireless router, Home Node B, Home eNode B, or access point and may utilize any suitable RAT for facilitating wireless connectivity within a local area, such as a business, home, vehicle, lot, industrial facility, air corridor (e.g., for use by drones), roadway, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114b may not be required to access the Internet 110 via CN 106 / 115.

[0018]

[0026] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as various throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019]

[0027] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0020]

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ cellular-based wireless technology, and a base station 114b, which may employ IEEE 802 wireless technology.

[0021]

[0029] 1B is a system diagram illustrating an exemplary WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while being consistent with an embodiment.

[0022]

[0030] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0023]

[0031] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0024]

[0032] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. In particular, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0025]

[0033] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0026]

[0034] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102 (such as on a server or home computer (not shown)).

[0027]

[0035] The processor 118 may be configured to receive power from the power source 134 and distribute and / or control this power to other components within the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0028]

[0036] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location determination method while conforming to an embodiment.

[0029]

[0037] The processor 118 is further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographic location sensor, an altimeter, a light sensor, a contact sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0030]

[0038] The WTRU 102 may include a full-duplex radio for simultaneous transmission and reception of some or all of the signals (e.g., associated with particular subframes of both the UL (e.g., for transmission) and downlink (e.g., for reception) links). The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference either through hardware (e.g., a choke) or through signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with particular subframes of the UL (e.g., for transmission) and downlink (e.g., for reception) links).

[0031]

[0039] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0032]

[0040] The RAN 104 may include eNode-Bs 160a, 160b, and 160c. However, it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit and / or receive wireless signals to the WTRU 102a.

[0033]

[0041] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with each other over an X2 interface.

[0034]

[0042] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0035]

[0043] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during initial task creation for the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0036]

[0044] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may typically route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions (such as anchoring the user plane during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.).

[0037]

[0045] The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0038]

[0046] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0039]

[0047] Although the WTRU is illustrated in FIGS. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0040]

[0048] In an exemplary embodiment, the other network 112 may be a WLAN.

[0041]

[0049] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to a STA originating from outside the BSS may reach the STA through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be sent, for example, through the AP, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between source and destination STAs via a direct link setup (DLS). In some exemplary embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may have no APs, and the STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad hoc" mode of communication.

[0042]

[0050] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically configurable width via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish association with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may withdraw. One STA (e.g., only one station) may transmit in a given BSS at a given time.

[0043]

[0051] A High Throughput (HT) STA may use a 40 MHz wideband channel for communication, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wideband channel.

[0044]

[0052] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wideband channels. 40 MHz and / or 80 MHz channels may be formed by combining adjacent 20 MHz channels. A 160 MHz channel, sometimes referred to as an 80+80 configuration, may be formed by combining eight adjacent 20 MHz channels or two non-contiguous 80 MHz channels. For the 80+80 configuration, the channel-encoded data may be passed through a segment analyzer that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiving STA, the above operations for the 80+80 configuration may be reversed, and the combined data may be transmitted to the Medium Access Control (MAC).

[0045]

[0503] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths by using non-TVWS spectrum. According to exemplary embodiments, 802.11ah may support Meter Type Control / Machine-Type communications, such as MTC devices within a macro coverage area. MTC devices may have some capabilities (e.g., limited capabilities including some bandwidths and / or limited bandwidth support (e.g., support only)). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0046]

[0054] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by a STA that supports the lowest bandwidth operating mode among all STAs when operating within the BSS. In an 802.11ah example, the primary channel can be 1 MHz wide for a STA (e.g., an MTC-type device) that supports 1 MHz mode (e.g., only supports 1 MHz mode), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting can depend on the condition of the primary channel. If the primary channel is busy transmitting to the AP, for example due to a STA (that only supports 1 MHz mode of operation), then the entire available frequency band may be considered busy even though the majority of the frequency band may remain idle and available.

[0047]

[0055] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total available band for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0048]

[0056] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to one embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0049]

[0057] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while conforming to an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit and / or receive signals to and / or from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit and / or receive wireless signals to and / or from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0050]

[0058] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c by using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c by using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., by including different numbers of OFDM symbols and / or lasting for different lengths of absolute time).

[0051]

[0509] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without access to another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c by using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0052]

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other over an Xn interface.

[0053]

[0061] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054]

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling various PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services with machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (e.g., WiFi).

[0055]

[0063] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0056]

[0064] The UPFs 184a, 184b may be connected via an N3 interface to one or more of the gNBs 180a, 180b, 180c in the RAN 113 (which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0057]

[0065] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0058]

[0606] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0059]

[0067] The emulation device may be designed to perform one or more tests of other devices within a laboratory environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices may perform one or more or all of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform testing by using wireless communication.

[0060]

[0068] One or more emulation devices may perform one or more functions (including all functions) while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in a non-deployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling via RF circuitry and / or wireless communication (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061]

[0069] 3D point clouds (e.g., high-quality 3D point clouds) can be used to represent immersive media. A point cloud can include one or more (e.g., a set of) points that can be represented in 3D space using coordinates that indicate the location and / or one or more attributes of each point. For example, the attributes can include one or more of color, transparency, time of acquisition, laser reflectivity, or material properties associated with each point. Point clouds can be captured in many ways. For example, multiple cameras and depth sensors can be used to capture the point cloud. A light detection and ranging (LiDAR) laser scanner can be used to capture the point cloud. The number of points included in a point cloud for realistically reconstructing objects and / or scenes in 3D space can be on the order of millions or billions. Efficient representation and compression can facilitate storing and / or transmitting point cloud data.

[0062]

[0070] 2 shows an example structure 200 of a bitstream for video-based point cloud compression (V-PCC) that may be transmitted (e.g., signaled) by an encoding device and parsed and decoded by a decoding device. The V-PCC bitstream 200 may include a set of one or more V-PCC units 202, and Table 1 includes an example syntax for signaling V-PCC units. Each V-PCC unit 202 may include a V-PCC unit header 204 and a V-PCC unit payload 206, which may include one or more sequence parameter sets 208, occupation video data 210, various types of patch data groups 212, geometry video data 214, or attribute video data 216. The V-PCC unit header 204 may define the V-PCC unit type (e.g., as indicated by the vpcc_unit_type field in Table 2) of the V-PCC unit, which may be one of several values ​​including VPCC_OVD, VPCC_GVD, and VPCC_AVD, VPCC_PDG, VPCC_SPS, which may correspond to, for example, occupancy, geometry, attribute, patch data group, and sequence parameter set data units, respectively. V-PCC units of some or all of these unit types may be used to reconstruct a point cloud. The V-PCC attribute unit header may specify the attribute type and its index. The V-PCC attribute unit header may allow multiple instances of the same attribute type to be supported.As shown, vpcc_unit_type may indicate the type of V-PCC unit, vpcc_sequence_parameter_set_id may indicate an identifier of the V-PCC sequence parameter set, vpcc_attribute_index may indicate an index of the V-PCC attribute, vpcc_attribute_dimension_index may indicate an index of the dimension partition of the V-PCC attribute, sps_multiple_layer_streams_present_flag may indicate whether the sequence parameter set (SPS) is associated with multiple layers or views, vpcc_layer_index may indicate an index of one of multiple layers, pcm_separate_video_data may indicate pulse code modulation (PCM) video data (e.g., in a separate video stream) and / or parameters associated with coding of the PCM data, and vpcc_reserved_zero_23bits or vpcc_reserved_zero_27bits may indicate the number of reserved zero bits.

[0063]

[0071] The occupancy payload, geometry, and / or attribute V-PCC units may correspond to video data units (e.g., HEVC network abstraction layer (NAL) units) that may be decoded by a video decoder (e.g., as defined by corresponding occupancy, geometry, and attribute parameter set V-PCC units). Table 3 shows an example V-PCC unit payload syntax.

[0064] [Table 1]

[0065] [Table 2]

[0066] [Table 3]

[0067]

[0072] In some examples (e.g., when lossless coding is used in V-PCC), the encoder may generate missing point patches containing information about points that may be missing after reconstruction from the compressed V-PCC bitstream. The missing points are sometimes referred to as missing pulse code modulation (PCM) points. The PCM points may be coded directly, for example, without using a patch projection process. The missing point patches may enable the decoder to reconstruct (e.g., fully reconstruct) the original point cloud, which may be provided as input to the V-PCC encoder. The patches containing information related to the missing points may be packed into the same video (e.g., the same video stream as the stream carrying the other points) or into a separate video (e.g., a separate video stream from the stream carrying the other points).

[0068]

[0073] The patch data group (PDG) may be replaced by a patch NAL (PNAL) unit (e.g., or atlas NAL unit). The PNAL unit may be equivalent to a network abstraction layer (NAL) unit used in a video stream. Each PNAL unit may include a header containing a unit type and / or additional information (e.g., layer identification). The PNAL unit may be defined in one or more formats. The one or more formats may include a simple PNAL unit stream format and / or a sample stream format. In the sample stream format, an additional header may precede the PNAL unit. The additional header may indicate the size (e.g., exact size) of the PNAL unit.

[0069]

[0074] The International Organization for Standardization (ISO) Base Media File Format (ISOBMFF) may define a structured, media-independent file format. An ISOBMFF (e.g., an ISOBMFF container file) may contain structural and / or media data information (e.g., for timed presentation of media content such as audio and video). An ISOBMFF container file may include support for untimed data (e.g., metadata at various levels within the file structure). The logical structure of the file may be that of a movie (e.g., mimic a movie), which may contain a set of time-parallel tracks. The temporal structure of the file is such that a track may contain a sequence of samples in time. This sequence of samples may be mapped to the overall movie timeline. ISOBMFF may be based on the concept of a box-structured file. A box-structured file may contain a series of boxes (e.g., atoms) that may have respective sizes and / or types (e.g., each box may be associated with a size and type). The type may be a 32-bit value and represented by four printable characters (also known as a four-character code (4CC)). The non-timed data may be included in a metadata box, for example at the file level, and / or may be added to a movie box within a movie or to one of the streams (eg, tracks) of timed data.

[0070]

[0075] An ISOBMFF container (e.g., an ISOBMFF container file) may contain a MovieBox ("moov"). A MovieBox may contain metadata for media streams (e.g., continuous media streams) present in the file. Metadata may be signaled within a hierarchy of boxes within the MovieBox (e.g., within a TrackBox ("trak")). A track may represent a media stream (e.g., continuous media stream) present in the file. A media stream may contain a sequence of samples (e.g., sample entries), such as audio or video access units of an elementary media stream, and may be encapsulated within a MediaDataBox ("mdat") (e.g., at the top level of the container). The metadata for each track may include a list of sample description entries, each of which provides the encoding or encapsulation format used in the track and initialization data for processing this format. Each sample may be associated with one of the track's sample description entries. Tools may be used to define an explicit timeline map for each track. For example, an edit list may define an explicit timeline map for each track. An edit list may be signaled by using an EditListBox (or similar entity) with the exemplary syntax shown in Table 4, where each entry defines a portion of the track timeline, for example by mapping a composition timeline or by indicating an "empty" time or "empty" edit (e.g., some portion of the presentation timeline that does not map any media).

[0071] [Table 4]

[0072]

[0076] ISOBMFF can be used to handle situations where a file author (e.g., an encoding device) can indicate to a player or renderer specific actions to perform. In the case of a video stream, the file author can indicate such actions through the use of a restricted video format track. If a video track is a restricted video format track (e.g., as defined in subsection 8.15 of the ISO / IEC 14496-12 standard), post-decoder requirements can be signaled on the track. A track can be converted to a restricted video format track by setting its sample entry code to the four-character code (4CC) "resv" and adding a RestrictedSchemeInfoBox (or similar entity) to its sample description. One or more boxes (e.g., all other boxes) can be left unmodified. The original sample entry type (based on the video codec used to encode the stream) can be stored in an OriginalFormatBox (or similar entity) within the RestrictedSchemeInfoBox. A RestrictedSchemeInfoBox may contain three boxes: OriginalFormatBox, SchemeTypeBox, and SchemeInformationBox. The OriginalFormatBox may store the original sample entry type based on the video codec used to encode the component stream. The nature of the restriction (e.g., characteristics) may be defined within the SchemeTypeBox.

[0073]

[0077] 3 shows an example structure of an ISOBMFF V-PCC container 300. Based on this example structure, the V-PCC ISOBMFF container may include one or more of the following: The V-PCC ISOBMFF container may include a V-PCC track 302. The V-PCC track 302 may include samples carrying one or more sequence parameter sets and / or one or more non-video coding information V-PCC unit payloads (e.g., V-PCC unit types VPCC_SPS and / or VPCC_PDG). The V-PCC track 302 may provide track references to other tracks containing samples carrying one or more video compressed V-PCC unit payloads (e.g., V-PCC unit types VPCC_GVD, VPCC_AVD, and / or VPCC_OVD). A V-PCC ISOBMFF container may contain one or more restricted video format tracks 304 (e.g., payloads of V-PCC units of type VPCC_GVD) whose samples may contain NAL units of a video coded elementary stream of geometry data. A V-PCC ISOBMFF container may contain one or more restricted video format tracks 306 (e.g., payloads of V-PCC units of type VPCC_AVD) whose samples may contain NAL units of a video coded elementary stream of attribute data. A V-PCC ISOBMFF container may contain one or more restricted video format tracks 308 (e.g., payloads of V-PCC units of type VPCC_OVD) whose samples may contain NAL units of a video coded elementary stream of occupancy map data.

[0074]

[0078] A container format for point cloud data may be provided. Transmission of missing PCM point information may be supported by the container format for point cloud data. Signaling of V-PCC tile groups and / or spatial access may be provided. The sample format of a V-PCC track may support PNAL units. Many file format structures that allow flexible access to various components, layers, and / or spatial regions within a V-PCC bitstream may be provided to support PCM information and / or provide signaling. A track (e.g., only a single track) may be used to store information for layers (e.g., all layers) of a V-PCC component, for example, if the layers of the V-PCC component constitute a single video stream. A sample grouping mechanism may be used to group samples belonging to each layer.

[0075]

[0079] When layers are stored in separate tracks, a track grouping tool can be used to signal that the separate tracks are for layers belonging to the same V-PCC component. For example, a track group type (e.g., VPCCComponentGroupBox or a similar entity) can be defined by extending TrackGroupTypeBox. TrackGroupTypeBox can include a track_group_id field, which is an identifier for the group, and a track_group_type field, which stores a four-character code identifying the group type. The track_group_id and track_group_type pair can identify a track group within a container file. VPCCComponentGroupBox can be defined as follows: VPCCComponentGroupBox can be of box type "vplg" and can be placed within a TrackGroupBox container. In some examples, VPCCComponentGroupBox can be optional (e.g., not mandatory). In some examples, multiple VPCCComponentGroupBox boxes can exist within a TrackGroupBox.

[0076]

[0080] Table 5 shows an example VPCCComponentGroupBox syntax.

[0077] [Table 5]

[0078]

[0081] Tracks that belong to the same component layer (e.g., all tracks) may have a VPCCComponentGroupBox within the TrackGroupBox. In each VPCCComponentGroupBox, the value of track_group_id may be the same. A V-PCC media player may identify tracks that belong to the same V-PCC component by parsing each track in the container and / or by identifying those that have VPCCComponentGroupBoxes with the same track_group_id value.

[0079]

[0082] To collectively reference reference tracks (e.g., all tracks) that belong to the same component, track references corresponding to V-PCC components in the main V-PCC track may use the track_group_id of the component's track group (e.g., to identify one or more track groups associated with the component). For example, a TrackReferenceTypeBox corresponding to a component may have an entry in its track_IDs array that uses the track_group_id to identify the component's track group.

[0080]

[0083] In some examples, the TrackGroupTypeBox may include a flags field, and a bit (e.g., bit 0 of the field: bit 0 is the least significant bit) may be used to indicate the uniqueness of the track_group_id. Tracks carrying geometry and / or attribute information of the same layer may be grouped. Grouping tracks carrying geometry and / or attribute information may enable a media player to have scalable access to V-PCC content. A VPCCLayerGroupBox or similar entity may be defined and given a box type "vplg". A VPCCLayerGroupBox may be placed within a TrackGroupBox container. In some examples, a VPCCLayerGroupBox may be optional (e.g., not mandatory). In some examples, there may be multiple VPCCLayerGroupBox boxes within a TrackGroupBox.

[0081]

[0084] Table 6 shows an example VPCCLayerGroupBox syntax.

[0082] [Table 6]

[0083]

[0085] As shown in the example syntax, the VPCCLayerGroupBox field may include one or more of the following fields: The layer_index field may indicate the index of the layer to which one or more tracks in the group belong. The absolute_coding_flag field may indicate whether the geometry tracks in this track group depend on geometry tracks in another layer. If absolute_coding_flag is set to 1, the tracks may not depend on another layer. If absolute_coding_flag is set to 0, the tracks may depend on another layer. The predictor_layer_index field may indicate the index of the layer on which the geometry tracks in this group depend.

[0084]

[0086] A V-PCC component track may be provided. In some instances (e.g., when one or more V-PCC stream components, such as occupancy, geometry, and / or attribute components, are video coded), one or more tracks carrying information related to the V-PCC stream components (e.g., any of the occupancy, geometry, and / or attribute components) may be signaled as a limited video scheme track. A limited video scheme track may not be for direct rendering. The scheme_type field in a SchemeTypeBox may be set to 4CC for components of V-PCC content (e.g., "pccv"). Data associated with a V-PCC scheme may be stored in a SchemeInformationBox. For example, data associated with a V-PCC scheme may be signaled in a VPCCComponentInfoBox (or similar entity), which may be carried in a SchemeInformationBox and defined as follows:

[0085]

[0087] Table 7 shows an example VPCCComponentInfoBox syntax.

[0086] [Table 7]

[0087]

[0088] As shown in the example semantics, a VPCCComponentInfoBox may include one or more of the following fields: The component_type field may indicate the type of component. For example, a value of 0 for component_type may be reserved. A value of 1 for component_type may indicate an occupancy map component. A value of 2 for component_type may indicate a geometry component. A value of 3 for component_type may indicate an attribute component. It should be noted that these numbers are provided herein as an example and other numbers may be used to indicate various component types. The is_pcm_flag field may indicate whether the information carried in the track is of a PCM point. If is_pcm_flag is set (e.g., to a value of 1), the track may carry PCM information for the component indicated by component_type. The all_layers_present_flag field may indicate whether the track carries information for all layers of the component. Coding data for a layer (e.g., all layers) of a component may be present in the track, for example, if all_layers_present_flag is set (e.g., to a value of 1). Otherwise (e.g., if all_layers_present_flag is not set or is set to a value of 0), the track may carry coded data for a single layer of the component. The layer_index field may indicate the index of the component layer to which the data carried by the track belongs.

[0088]

[0089] The SchemeInformationBox may contain an additional VPCCAttributeInfoBox (or similar entity) that may provide additional description of the attribute component, for example if the component track is carrying attribute information (e.g., if component_type is set to 3). The VPCCAttributeInfoBox may be defined as shown in Table 8.

[0089] [Table 8]

[0090] As shown in the example semantics of Table 8, the VPCCAttributeInfoBox may include one or more of the following fields: The attr_index field may indicate the index of the attribute in a list of attributes. The attr_type field may indicate the attribute type. The attr_dimensions field may indicate the number of dimensions of the attribute (e.g., total number). The attr_first_dim_index field may indicate the index of the first attribute dimension carried by the track (e.g., a zero-based index).

[0091]

[0091] The VPCCAttributeInfoBox may include a split indicator. Table 9 shows another example VPCCAttributeInfoBox syntax.

[0092] [Table 9]

[0093] As shown in the exemplary syntax of Table 9, the VPCCAttributeInfoBox may include one or more of the following fields: The attr_index field may indicate the index of the attribute in a list of attributes. The attr_type field may indicate the type of the attribute. The attr_dimensions field may indicate the number of dimensions of the attribute (e.g., total number). The attr_dim_partition_index field may represent the index (e.g., zero-based) of the dimension partition carried by the track.

[0094] In some examples, the VPCCComponentBox may carry (e.g., directly carry) a vpcc_unit_header() HLS struct of vpcc_unit_type corresponding to the component information carried by the track. If the vpcc_unit_type is VPCC_AVD, the presence of a VPCCAttributeInfoBox in the SchemeInformationBox may be optional.

[0095]

[0094] Information about missing PCM points may include geometry data and / or attribute data. PCM point information may be packed into the video stream of the associated component and / or available as a separate video stream (e.g., one video stream per component). PCM point information may be carried in a separate track (e.g., one track for information related to a component), for example if the PCM point information is available separately. A separate track may be signaled as a limited video format track with the is_pcm_flag field in the VPCCComponentBox set to 1 (e.g., as described herein). Each track carrying PCM point information may be included in a track group of the associated component. Track references from the main track to the track_group_id of the V-PCC component may refer to tracks of PCM and / or non-PCM points (e.g., collectively).

[0096] Geometry and attribute information associated with PCMs may be grouped, for example, to allow easy identification and access to missing points. Track groupings may be defined, for example, using a VPCCPCMTrackGroupBox (or similar entity) as shown in Table 10 to identify tracks that have PCM point information.

[0097] [Table 10]

[0098]

[0096] A track carrying information related to a PCM point of a certain V-PCC content may contain a VPCCPCMTrackGroupBox (or a similar entity) within a TrackGroupBox. In each VPCCPCMTrackGroupBox, the value of track_group_id may be the same.

[0099]

[0097] 4CC values ​​(e.g., "pccp") of the reference_type field of the TrackReferenceTypeBox may be defined that may be used to signal track references that carry PCM point data (e.g., including geometry and / or attribute data).

[0100]

[0098] In some examples, there may not be any constraints on the prediction structure used to encode various components of a V-PCC bitstream. Thus, it may be possible to encode various components and / or various layers of the same component (e.g., if the components are not in the same video stream) with a coding configuration that would result in non-aligned intra-refresh periods across various component substreams. Such non-aligned intra-refresh periods across various component substreams may make random access difficult, as an intra-coded sample in a patch stream within a primary V-PCC track at a given decode time may not have a corresponding intra-coded sample in another component track at the same decode time. Without additional information indicating where a synchronization sample in a component track is located relative to the primary track, a media player may rely on scanning the component track for the nearest synchronization sample.

[0101]

[0099] The synchronization samples in one V-PCC component may not be correctly aligned with the synchronization samples in other components. The synchronization samples in the main track may have corresponding synchronization samples in other (e.g., all other) component tracks. For example, if the intra-refresh period of the patch sequence stream is once every 30 frames, the geometry component may have an intra-refresh period once every 60 frames and / or the texture attributes may have an intra-refresh period once every 30 frames. For example, an intra-refresh frame may occur every 30 seconds in the main track and in other (e.g., all other) components. The intra-refresh frames may have the same decoding time.

[0102]

[0100] A constraint on coded intra-random access point (IRAP) duration across components may be defined such that IRAP samples are aligned across tracks (e.g., to support random access). For example, an encoder may be constrained to generate substreams with aligned synchronization samples at regular intervals. This constraint allows a decoder and / or client to assume the following: an IRAP sample is available in one or more other (e.g., all other) components at the same time that it is found in one (e.g., any) component track. The IRAP of each component may represent the IRAP of the VPCC bitstream. Figure 4 shows an example of a constraint by which component IRAP samples are aligned.

[0103] The constraints described herein may eliminate the need for additional information to signal the agreement of synchronization samples across tracks: when a synchronization sample arrives in the main track, a corresponding synchronization sample with the same decoding time can be found in the other (e.g., all other) component tracks.

[0104]

[0102] In some examples, the IRAP periods of various components and the main patch sequence track may be selected so that time-aligned (e.g., synchronized) intra samples occur at regular intervals. When time-aligned (e.g., synchronized) intra samples occur at regular intervals, a V-PCC media player accessing a synchronization sample in the main V-PCC track may find a corresponding synchronization sample at the same decoding time in the other component tracks. Each component may have a different IRAP period. The IRAP period of the main V-PCC track may be the least common multiple of the IRAP periods of the other (e.g., all) component tracks. The IRAP of the main V-PCC track may represent the IRAP of the V-PCC bitstream. Figure 5 shows an example of using the least common multiple of IRAP periods to indicate a V-PCC IRAP.

[0105] In some examples, there may not be any constraints on the IRAP duration of a V-PCC component. The IRAP of the primary V-PCC track may represent the IRAP of the V-PCC bitstream. For other components, the closest IRAP may be located given the decoding and / or presentation time of the IRAP in the primary V-PCC.

[0106]

[0104] The V-PCC high-level syntax (HLS) may support tile groups. In video coding standards (e.g., HEVC), a 2D frame may be divided into a grid of tiles. One or more tile groups may correspond to a rectangular region within a 2D frame containing many tiles. Motion constrained tile sets (MCTS) may be decoded (e.g., independently decoded) and may enable extraction of specific regions within a frame. In V-PCC, patches corresponding to points belonging to a region of space (e.g., a 3D region or a cube) may be packed into one or more MCTS. Tile group and MCTS may be used interchangeably herein.

[0107]

[0105] Figure 6 shows an example of a V-PCC container structure 600 that may be used to enable spatial access to specific regions within 3D space. As shown, the 3D space 602 of a point cloud (e.g., a bounding box corresponding to the 3D space) may be divided into a 3D cubic grid (e.g., cubes 602a, 602b, 602c, etc.) that represent multiple regions and / or objects within the 3D space. Points belonging to each of the regions and / or objects within the 3D space may be clustered, and a bounding box may be used to represent that region or object. Points belonging to different portions of the same object may be grouped together and represented by the respective bounding boxes of those portions.

[0108]

[0106] Patches resulting from the projection of points within each bounding box of the resulting bounding boxes may be packed together into one or more tile groups within a 2D frame in multiple V-PCC component streams or tracks (e.g., occupancy, geometry, and / or attribute streams or tracks). The patches may be encoded using a coding scheme that generates tile groups (e.g., independently decodable tile groups). These tile groups may be carried in separate tracks within an ISOBMFF container; thus, the term "tile group" may be used interchangeably with "track group" herein (e.g., a tile group may be an instance of a track group). Carrying tile groups in separate tracks may enable a decoding device (e.g., a media player) to access and / or download tracks that carry information related to a particular region or object in 3D space. For example, if tile groups are carried in separate tracks in a V-PCC bitstream, a media player may access and / or download only tracks associated with a particular region of 3D space when decoding the particular region (e.g., when rendering a visual representation of the region).

[0109] Tracks with corresponding tile groups (e.g., carrying information about points within a bounding box representing a region or object) across a V-PCC component can be grouped together by using the track grouping tool. A TrackGroupBox ("trgr") or similar entity can be added to the TrackBox of each of these tracks, and the track grouping type of the V-PCC tile group can be defined by extending the TrackGroupTypeBox (e.g., by utilizing the track_group_id or tile_group_id fields) as shown below.

[0110] Table 11 shows an example VPCCTileGroupBox syntax.

[0111] [Table 11]

[0112] As shown in the example semantics of Table 11, a VPCCTileGroupBox may include a tile_group_id field (or a similar field) that identifies a V-PCC tile group (e.g., as an identifier of a V-PCC tile group). In some examples, the tile_group_id may correspond to (e.g., be identical to) a tile group address (e.g., a field such as ptgh_address that may be included in a tile group header of a V-PCC bitstream). Tracks belonging to the same point cloud tile group may have the same value of track_group_id with track_group_type "vptg". The track_group_id of a track from one point cloud tile group may differ from the track_group_id of a track from another point cloud tile group. For example, as shown in FIG. 6, a first tile group corresponding to 3D region 602a may have a track group ID of 1, and a second tile group corresponding to 3D region 602b may have a track group ID of 2. Therefore, a track_group_id in a TrackGroupTypeBox with track_group_type equal to 'vptg' (or similar 4CC value) can be used as an identifier for a point cloud tile group in an ISOBMFF container file.

[0113] For example, sample grouping may be used to signal which samples belong to which V-PCC tile group. For example, sample grouping may be used when information related to two or more V-PCC tile groups for one V-PCC component is carried in a track (e.g., for a set of V-PCC tile groups, there is a set of sample groups in the track, and each group of samples is associated with a respective V-PCC tile group). A sample group entry may be defined (e.g., as shown in Table 12 below), where the semantics (e.g., definition) of tile_group_id may be identical to that of tile_group_id defined in VPCCTileGroupBox as described herein. The group type may be "vpge" or a similar 4CC value. The container may be a SampleGroupDescriptionBox ("sgpd") or a similar entity. The VPCCTileGroupBox may not be mandatory (e.g., may be optional), and each track may have (e.g., be associated with) multiple VPCCTileGroupBoxes. Table 12 shows an example syntax for a VPCCTileGroupEntry.

[0114] [Table 12]

[0115] In some examples, sub-tracks carrying one or more V-PCC tile groups may be defined within a component track. One or more V-PCC tile groups may be defined using a SubTrackSampleGroupBox (or similar entity) and by enumerating the VPCCTileGroupEntry instances (or similar entities) corresponding to the V-PCC tile groups carried in each sub-track within the corresponding SubTrackSampleGroupBox (e.g., by referencing their group_description_index). One or more V-PCC tile groups may be defined by defining a V-PCC-specific VPCCTileGroupSubTrackBox (e.g., as shown in Table 13). The box type may be set to "vpst" or a similar 4CC value. The container may be a SubTrackDefinitionBox ("strd") or similar entity. The VPCCTileGroupSubTrackBox may not be mandatory (e.g., it may be optional), and each track may have multiple VPCCTileGroupSubTrackBoxes.

[0116] [Table 13]

[0117]

[0112] The union (e.g., set) of the tile_group_ids in a VPCCTileGroupSubTrackBox may describe (e.g., collectively describe) the sub-track defined by the box. The semantics of a VPCCTileGroupSubTrackBox may include one or more of the following fields: The item_count field may represent a count of the number of tile groups listed in the VPCCTileGroupSubTrackBox. The tile_group_id field may represent an identifier of the V-PCC tile group contained in this sub-track. The tile_group_id field in a VPCCTileGroupSubTrackBox may match (e.g., correspond to) the tile_group_id defined in the VPCCTileGroupEntry.

[0118]

[0113] A mapping may be provided between regions or objects in 3D space (e.g., each of the 3D bounding boxes) and respective tile groups, for example to enable a client (e.g., a media playing or decoding device) to identify which tracks to access / download to render a region in 3D space (e.g., as represented by a bounding box). It should be noted that while the position of a tile group within a 2D frame may not change, the position and potentially the size (e.g., dimensions) of a bounding box (e.g., region) in 3D space may change over time, for example due to movement of the object represented by the points within the bounding box. 3D regions within a point cloud are defined using the exemplary 3D region structure shown in Table 14.

[0119] [Table 14]

[0120] As shown in the example semantics of Table 14, a 3DRegionStuct may include one or more of the following fields: The region_id field may represent a unique identifier for the 3D region. The region_x field may represent the x-coordinate of a reference point associated with the 3D region (e.g., a bounding box associated with the region). The region_y field may represent the y-coordinate of the reference point. The region_z field may represent the z-coordinate of the reference point. The region_width field may indicate the length of the 3D region (e.g., a bounding box associated with the region) along the x-axis. The region_height field may indicate the length of the 3D region (e.g., a bounding box associated with the region) along the y-axis. The region_depth field may indicate the length of the 3D region (e.g., a bounding box associated with the region) along the z-axis. The dimensions_included_flag field may indicate whether dimensions of the 3D region (e.g., a bounding box associated with the region) are signaled in the same instance of the struct. For example, if dimensions_included_flag has a value of 0, this may indicate that the dimensions are not signaled and that the dimensions for the same region may have already been signaled (e.g., a previous instance of VPCC3DRegionStruct with the same region_id signaled the dimensions). If dimensions_included_flag has a value of 1, this may indicate that the dimensions are signaled.

[0121]

[0115] 3D regions or objects within a point cloud can be associated with one or more point cloud tile groups (e.g., instances of track groups) by using a VPCCRegionToTileGroupBox or similar entity. Table 15 shows an example VPCCRegionToTileGroupBox syntax.

[0122] [Table 15]

[0123] As shown in the example semantics of Table 15, a VPCCRegionToTileGroupBox may indicate a mapping relationship between a region (or object) in 3D space and one or more tile groups (e.g., track groups). A VPCCRegionToTileGroupBox may include one or more of the following fields: The num_regions field may indicate the number of 3D regions in the point cloud associated with the 3D space. The region_id field may identify (e.g., may include an identifier for) the 3D region. The num_tile_groups field may indicate the number of V-PCC tile groups associated with the 3D region. The tile_group_id field may identify a V-PCC tile group. Thus, a VPCCRegionToTileGroupBox may link one or more tiles to a 3D region via at least the tile_group_id and region_id fields.

[0124] 6, or in a sample entry of a separate timed metadata track 606 associated with the primary V-PCC track. The timed metadata track 606 (which may be separate from the primary V-PCC track, for example) may be included within an ISOBMFF container and may be used to update one or more properties (e.g., position and / or dimensions) of a defined 3D region of the point cloud, for example, over time. This timed metadata track 606 may include a defined sample entry (e.g., VPCC3DRegionSampleEntry) with a 4CC of "vp3r" (or a similar 4CC value), and the defined sample entry may extend MetadataSampleEntry or a similar entity as shown by the example syntax in Table 16 (e.g., of a VPCC3DRegionInfoBox or a similar entity).

[0125] [Table 16]

[0126] As shown in the example semantics of Table 16, the VPCC3DRegionInfoBox may include a num_regions field that indicates the total number of 3D regions in 3D space. The timed metadata track 606 may be linked to the main V-PCC track 604, for example, by using the 4CC of "cdsc" (or a similar 4CC value) as a track reference. Each (e.g., each) sample in this timed metadata track may define a 3D region, for example, by using the example syntax shown in Table 17 below. The VPCC3DRegionSample structure (e.g., or similar entity) may be extended with derived track formats.

[0127] [Table 17]

[0128] As shown in the example semantics of Table 17, a VPCC3DRegionSample may include a num_regions field, which may indicate the number of 3D regions being signaled in the sample. The number of 3D regions signaled in the sample may or may not be equal to the total number of available regions. For example, the number of 3D regions signaled in a sample may indicate the 3D regions whose characteristics (e.g., position and / or dimensions) are to be updated in the sample.

[0129]

[0120] Patch information may be carried in a V-PCC track. The VPCCDecoderConfigurationRecord (or similar entity) and sample format syntax of the V-PCC track may be formatted to support the transmission of patch information substreams structured, for example, as a series of patch network abstraction layer (PNAL) units. The VPCCDecoderConfigurationRecord may provide configuration information to the decoder (e.g., at the beginning of the decoding process). The VPCCDecoderConfigurationRecord may include one or more parameter sets and / or one or more supplemental enhancement information (SEI) messages. The VPCCDecoderConfigurationRecord may include a lengthSizeMinusOne field. An example VPCCDecoderConfigurationRecord syntax may be shown in Table 18 below.

[0130] [Table 18]

[0131] As shown in the example semantics of Table 18, the VPCCDecoderConfigurationRecord may include a configurationVersion field that indicates the current version of the configuration record. In some examples, non-compliant changes to a decoder configuration record may be indicated by a change in the configuration version number. A decoder device may be configured not to attempt to decode an applied configuration record or stream if the configuration version number is not recognized. The VPCCDecoderConfigurationRecord may include a lengthSizeMinusOne field, and the value of lengthSizeMinusOne plus 1 may indicate the length (e.g., in bytes) of the PNALUnitLength field in the V-PCC sample (e.g., in the stream to which this configuration record applies). For example, a PNALUnitLength field length of 1 byte may be indicated by a lengthSizeMinusOne value of 0. The value of the lengthSizeMinusOne field may be 0, 1, or 3, which may correspond to a length (e.g., PNALUnitLength) encoded by 1, 2, or 4 bytes, respectively.

[0132] In some examples, the decoder configuration record may include one or more setup unit arrays, such as a first setup unit array of V-PCC parameter sets (e.g., a Vsequence parameter set and a second setup unit array of other setup units of the patch information substream). Table 19 below shows an example illustrating one or more setup unit arrays.

[0133] [Table 19]

[0134] As shown in the semantic example of Table 19, a VPCCDecoderConfigurationRecord (or similar entity) may include one or more of the following fields: The configurationVersion field (or a similarly named field) may indicate the current version of the configuration record. In some examples, non-compliant changes to a decoder configuration record may be indicated by a change in the configuration version number. A decoding device may be configured not to attempt to decode the applied configuration record or stream if the configuration version number is not recognized. The numOfSequenceParameterSets field (or a similarly named field) may indicate the number of signed (e.g., defined) V-PCC parameter sets (e.g., arrays) in the decoder configuration record (e.g., of the stream to which the decoder configuration record applies). The numOfSetupUnitArrays field may indicate the number of signed (e.g., defined) arrays of PNAL units of the indicated type (e.g., indicated by PNAL_unit_type) in the decoder configuration record (e.g., of the stream to which the decoder configuration record applies). The array_completeness field may indicate whether all PNAL units are included in the array. For example, if the array_completeness field is equal to 1, this may indicate that PNAL units of a given type (e.g., all PNAL units) are included in the subsequent array (e.g., there are none in the stream). If the array_completeness field is equal to 0, this may indicate that additional PNAL units of the indicated type may be present in the stream. The default and / or allowed values ​​of array_completeness may be constrained by the sample entry name or sample entry type of the corresponding sample entry. For example, a VPCCDecoderConfigurationRecord may be used in various sample entries.The container of a VPCCDecoderConfigurationRecord may be a VPCCDecoderConfigurationBox (or similar entity), which may be a box contained within a VPCCSampleEntry. VPCCSampleEntry may be of different types, and the type of sample entry may set constraints on the allowed and / or default values ​​of the array_completeness field in the enclosed VPCCDecoderConfigurationRecord.

[0135]

[0124] A VPCCDecoderConfigurationRecord (or similar entity) may include a PNAL_unit_type field indicating the type of PNAL units in the following array (e.g., all of the PNAL units in the array may be of the indicated type). The PNAL_unit_type field may have (e.g., be restricted to take on) one of the following values ​​indicating PUP_PSPS, PUP_PREFIX_SEI, or PUP_SUFFIX_SEI PNAL units: A VPCCDecoderConfigurationRecord (or similar entity) may include a numPNALUnits field indicating the number of PNAL units of the indicated type contained in the configuration record (e.g., for the stream to which this configuration record applies). A supplemental enhancement information (SEI) array may include (e.g., only include) declarative SEI messages. Declarative SEI messages may include SEI messages indicating information about the stream in general. For example, a user data SEI may be a declarative SEI message.

[0136]

[0125] The VPCCDecoderConfigurationRecord (or similar entity) may include a pnalUnitLength field that indicates the length of the PNAL unit (e.g., in bytes). The VPCCDecoderConfigurationRecord (or similar entity) may include a pnalUnit field that may be used to hold a PUP_PSPS or declared SEI PNAL unit.

[0137]

[0126] Based on the exemplary VPCCDecoderConfigurationRecord syntax shown herein, the sample format of a sample (eg, represented as a VPCC Sample) in a V-PCC track is shown in Table 20 below.

[0138] [Table 20]

[0139] As shown in the example semantics of Table 20, the VPCCDecoderConfigurationRecord field may indicate a decoder configuration record in the corresponding V-PCC sample entry. The PNALUnitLength field may indicate the size of the PNAL unit (e.g., measured in bytes). In some examples, the PNALUnitLength field may include the size of both the PNAL unit header and the PNAL unit payload. In some examples, the PNALUnitLength field may not include the size of the PNALUnitLength field itself. Furthermore, the PNALUnit field may be included to represent a PNAL unit (e.g., a single atlas NAL unit).

[0140] In some examples, patch information within samples of a V-PCC track may be formatted based on a patch information sample stream (e.g., an atlas sample stream). A VPCCDecoderConfigurationRecord (or similar entity) may include a lengthSizeMinusOne field. Table 21 shows another example VPCCDecoderConfigurationRecord syntax.

[0141] [Table 21]

[0142]

[0129] The fields (e.g., variables) in the example syntax of Table 21 may be defined similarly to those in Table 19. For example, a value of lengthSizeMinusOne plus 1 may indicate the length (e.g., in bytes) of the PNALUnitLength field (e.g., in V-PCC samples in the stream to which this configuration record applies). Thus, the size of one byte of the PNALUnitLength field may be indicated by a lengthSizeMinusOne field having a value of 0. In the example syntax of Table 21, the lengthSizeMinusOne field may be defined as an unsigned int(3), and therefore the value of the lengthSizeMinusOne field may range from 0 to 7.

[0143]

[0130] Although features and elements have been described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in conjunction with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A video decoding device configured to process video data associated with a three-dimensional (3D) space, comprising: Receive a media container file, analyzing the media container file to determine a 3D region and one or more tiles within the 3D space; determining that the one or more tiles are associated with the 3D region based on a mapping indicated by the media container file, the mapping linking the one or more tiles to the 3D region; 11. A video decoding apparatus comprising: a processor configured to decode a plurality of video tracks associated with the one or more tiles to derive a visual representation of the 3D region.

2. The video decoding apparatus of claim 1 , wherein the media container file further indicates that the one or more tiles are associated with a track group.

3. The video decoding apparatus of claim 2 , wherein the processor is further configured to identify the plurality of video tracks based on an association of the one or more tiles with the track group.

4. 2. The video decoding device of claim 1, wherein the plurality of video tracks include a first video track carrying attribute information of the one or more tiles, a second video track carrying occupancy information of the one or more tiles, and a video track carrying geometry information of the one or more tiles.

5. The video decoding device of claim 1 , wherein the media container file includes a structure defining a plurality of 3D regions within the 3D space.

6. The video decoding device of claim 1 , wherein the media container file includes timed metadata indicating updates to at least one characteristic of the 3D region.

7. The video decoding device of claim 1 , wherein the processor is further configured to determine, based on the media container file, reference points associated with the 3D region and dimensions of the 3D region.

8. 2. The video decoding device of claim 1, wherein the video track includes one or more sample entries, each of which includes an indication of the length of a data field that defines a network abstraction layer (NAL) unit size.

9. 9. The video decoding apparatus of claim 8, wherein each of the one or more sample entries further includes an indication of the number of V-PCC parameter sets associated with the sample entry or the number of arrays of atlas NAL units associated with the sample entry.

10. 1. A method for decoding video data associated with a three-dimensional (3D) space, comprising: receiving a media container file; parsing the media container file to determine a 3D region and one or more tiles within the 3D space; determining that the one or more tiles are associated with the 3D region based on a mapping indicated by the media container file, the mapping linking the one or more tiles to the 3D region; and decoding a plurality of video tracks associated with the one or more tiles to derive a visual representation of the 3D region; A method comprising:

11. The method of claim 10 , wherein the media container file further indicates that the one or more tiles are associated with a track group.

12. The method of claim 11 , further comprising identifying the video track based on an association of the one or more tiles with the track group.

13. 11. The method of claim 10, wherein the plurality of video tracks include a first video track carrying attribute information of the one or more tiles, a second video track carrying occupancy information of the one or more tiles, and a video track carrying geometry information of the one or more tiles.

14. 11. The method of claim 10, wherein the video track includes one or more sample entries, each of the one or more sample entries including an indication of a length of a data field that defines a network abstraction layer (NAL) unit size.

15. 1. A video encoding device configured to encode video data associated with a three-dimensional (3D) space, comprising: Dividing the 3D space into at least one 3D region; further dividing the at least one 3D region into one or more tiles; indicating in a media container file that the one or more tiles are associated with the at least one 3D region; A video encoding device comprising a processor configured to send the media container file to a video decoding device.

Images