Avatar specification pose in scene description

Abstract

Systems, methods, and tools associated with avatar grids and avatar construction and rendering are disclosed herein. In an example, a device associated with avatar construction and rendering may receive avatar data associated with an avatar. An avatar grid may be generated using the avatar data. The apparatus may determine that the avatar data includes a canonical pose attribute. In an example, normative pose attributes may include at least one of a definition of coordinates, an orientation, a direction of rotation, a front axis, a bottom-up axis, a right axis, a foot level, and an avatar status. An avatar pose associated with the avatar may be modified using the avatar mesh and the canonical pose attributes. In an example, the modification of the avatar pose may relate to at least one of placement of the avatar, orientation of the avatar, and gaze of the avatar.

Description

Cross-references to avatar pose specification applications in the scene description

[0001] This application claims the benefit of European patent application 23306725.5, filed on 6 October 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0002] Video coding systems can be used to compress digital video signals, for example, to reduce the storage and / or transmission bandwidth required for such signals. Video coding systems can include, for example, block-based, wavelet-based, and / or object-based systems. Current mechanisms for avatar coding for 3D scene representation may be inadequate. Summary of the Invention

[0003] This article discloses the systems, methods, and tools associated with avatar meshes, as well as avatar construction and rendering.

[0004] In the example, the apparatus associated with avatar construction and rendering can receive avatar data associated with the avatar. The avatar data can be used to generate an avatar mesh. The apparatus can determine that the avatar data includes canonical pose attributes. In the example, canonical pose attributes can include at least one of the following: coordinate definition, orientation, rotation direction, front axis, bottom-up axis, right axis, foot level, and avatar state.

[0005] In the example, the device can determine that the canonical pose attribute includes a transformation. Based on the canonical pose attribute including the transformation, the transformation can be used to transform the avatar mesh. The transformed avatar mesh can be returned for modifying the avatar pose. In the example, the transformation can include at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation. In the example, the device can determine that the canonical pose includes a type attribute. Based on the canonical pose attribute including the type attribute, the avatar mesh can be transformed according to the type attribute. The transformed avatar mesh can be returned for modifying the avatar pose.

[0006] The avatar pose associated with an avatar can be modified using avatar mesh and canonical pose attributes. In the example, modification of the avatar pose can be related to at least one of the following: avatar placement, avatar orientation, and avatar gaze. In the example, avatar data can be Graphics Library Transport Format (gIFT) data including MPEG Node Avatar Extensions. In the example, the apparatus can determine that an avatar flag associated with MPEG Node Avatar Extensions is enabled.

[0007] The apparatus for constructing and rendering avatar meshes and avatars can parse glTF data. The apparatus can determine that the glTF data includes nodes with MPEG node avatar extensions (e.g., MPEG_node_avatar extensions). The apparatus can determine that avatar attributes associated with the MPEG node avatar extensions (e.g., the "isAvatar" attribute) are enabled (e.g., set to true). The apparatus can then use the glTF data to generate an avatar mesh. The apparatus can also determine that the MPEG node avatar extensions include canonical pose attributes (e.g., "canonicalPose" attributes). The apparatus can use the avatar mesh and the settings provided by the canonical pose attributes to construct and / or render the avatar.

[0008] The apparatus can also determine whether the canonical pose attribute includes a transformation. A transformation can include at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation. Furthermore, if the apparatus determines that the canonical pose attribute includes a transformation, the apparatus can use that transformation to transform the avatar mesh and return the transformed avatar mesh for rendering.

[0009] The apparatus can determine that the canonical pose includes, for example, a type attribute associated with an application running on the apparatus. This type attribute may indicate at least one canonical pose Uniform Resource Name (URN). The apparatus can then transform the avatar mesh based on the canonical pose and return the transformed avatar mesh for rendering.

[0010] These examples can be executed by a device having a processor. This device can be an encoder or a decoder. These examples can be executed by a computer program product stored on a non-transitory computer-readable medium and including program code instructions. These examples can be executed by a computer program including program code instructions. These examples can be executed via a bitstream including information representing a template-matching prediction pattern.

[0011] The systems, methods, and tools described herein may relate to decoders. In some examples, the systems, methods, and tools described herein may relate to encoders. In some examples, the systems, methods, and tools described herein may relate to signals (e.g., from an encoder and / or received by a decoder). A computer-readable medium may include instructions for causing one or more processors to perform the methods described herein. A computer program product may include instructions that, when executed by one or more processors, cause one or more processors to perform the methods described herein. Attached Figure Description

[0012] Figure 1A is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments.

[0013] Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communication system shown in Figure 1A according to an embodiment.

[0014] Figure 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communication system shown in Figure 1A according to an embodiment.

[0015] Figure 1D is a system diagram illustrating yet another example RAN and yet another example CN that can be used within the communication system shown in Figure 1A according to an embodiment.

[0016] Figure 2 shows an example video encoder.

[0017] Figure 3 shows an example video decoder.

[0018] Figure 4 shows an example of a system in which various aspects and examples can be implemented.

[0019] Figure 5 shows an example of an avatar pose.

[0020] Figure 6 shows an example of an incarnation of a cube facing the Z-axis.

[0021] Figure 7 shows an example of an avatar head with a neutral expression.

[0022] Figure 8 illustrates the parsing of a node with support for the MPEG_node_avatar extension.

[0023] Figure 9 illustrates the parsing of the "canonicalPose" attribute.

[0024] Figure 10 shows an example of constructing an avatar mesh using a canonical pose.

[0025] Figure 11 shows a list of Uniform Resource Names and their definitions. Detailed Implementation

[0026] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings.

[0027] Figure 1A is a diagram illustrating an example communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. 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 Extended OFDM (ZTUWDTS-sOFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0028] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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 the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) 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, hotspots 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 the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0029] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0031] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable air interface access technology (RAT) can be used to establish air interface 116.

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

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

[0034] In the embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using New Radio (NR) to establish NR radio access for air interface 116.

[0035] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or by transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0036] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0037] Base station 114b in Figure 1A can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0038] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting to RAN 104 / 113, which can be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0039] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0041] Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B, WTRU 102 may include 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0042] 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. As suggested above, processor 118 may include multiple processors. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B depicts processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or on a chip.

[0043] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0044] Although the transmit / receive element 122 is depicted as a single element in FIG. 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, 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 via the air interface 116.

[0045] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

[0046] The processor 118 of WTRU 102 can be coupled to and 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) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information and store data from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not actually located on WTRU 102, such as on a server or home computer (not shown).

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

[0048] 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) about 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) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0049] The processor 118 can also be connected to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0050] WTRU 102 may include a full-duplex radio, wherein the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, wherein the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0051] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

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

[0053] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0054] The CN 106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is described 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.

[0055] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0056] The SGW 164 can connect to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during eNodeB handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0057] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0058] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional terrestrial line communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such an IP gateway as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0059] Although the WTRU is depicted as a wireless terminal in Figures 1A through 1D, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0060] In a representative embodiment, the other network 112 may be a WLAN.

[0061] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have an interface to a Distribution System (DS) or another type of wired / wireless network that loads traffic into and / or loads traffic out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to a destination outside the BSS can be transmitted to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., transmitted directly between them). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Independent BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0062] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (e.g., every STA), including the AP, can sense the primary channel. If a particular STA senses / detects that the primary signal is busy and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

[0063] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0064] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be transmitted to the Media Access Control (MAC).

[0065] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0066] 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 the 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 limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and potentially available.

[0067] In the United States, the available frequency band for 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 bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0068] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

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

[0070] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be varied for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths, or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0071] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0072] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. As shown in Figure 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0073] The CN 115 shown in Figure 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. While each of the foregoing elements is described 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.

[0074] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services dependent on Ultra Reliable Low Latency (URLLC) access, services dependent on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between 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 (such as WiFi).

[0075] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0076] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0077] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0078] Based on the corresponding descriptions in Figures 1A-1D, one or more emulation devices (not shown) can perform one or more or all of the functions described herein with respect to one or more of the following: WTRU 102a-102d, base stations 114a-114b, eNode-B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0079] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when 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 simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0080] One or more simulation devices may perform one or more functions when implemented / deployed without being part of a wired and / or wireless communication network. For example, simulation devices may be used to test scenarios in a laboratory and / or undeployed (e.g., tested) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices may be test equipment. Simulation devices may transmit and / or receive data using direct RF connections and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0081] This application describes various aspects, including tools, features, examples, models, methods, etc. Many of these aspects are described in a specific manner, and are generally described in a way that may sound restrictive, at least to illustrate the individual features. However, this is for the purpose of clarity of description and does not limit the application or scope of these aspects. In fact, all the different aspects can be combined and interchanged to provide other aspects. Furthermore, these aspects can also be combined and interchanged with those described in previous documents.

[0082] The aspects described and contemplated in this application can be implemented in many different forms. Figures 5 through 11 described herein provide some examples, but other examples are contemplated. The discussion of Figures 5 through 11 does not limit the breadth of implementations. At least one aspect generally relates to video encoding and decoding, and at least one other aspect generally relates to transmitting the generated or encoded bitstream. These and other aspects can be implemented as methods, apparatus, computer-readable storage media having instructions thereon stored thereon for encoding or decoding video data according to any of the methods, and / or computer-readable storage media having bitstreams generated according to any of the methods stored thereon.

[0083] In this application, the terms “reconstruction” and “decoding” are used interchangeably, the terms “pixel” and “sample” are used interchangeably, and the terms “image”, “picture” and “frame” are used interchangeably.

[0084] This document describes various methods, each of which includes one or more steps or actions for implementing the described method. Unless the correct operation of the method requires a specific order of steps or actions, the order and / or use of specific steps and / or actions can be modified or combined. Additionally, in various examples, terms such as "first," "second," etc., may be used to modify elements, components, steps, operations, etc., such as, for example, "first decoding" and "second decoding." Unless specifically required, the use of such terms does not imply a sequence of operations. Therefore, in this example, the first decoding does not need to be performed before the second decoding, but can occur, for example, before, during, or in a time period overlapping with the second decoding.

[0085] The various methods and other aspects described in this application can be used to modify modules of the video encoder 200 and decoder 300 shown in Figures 2 and 3, such as decoding modules. Furthermore, the subject matter disclosed herein can be applied to, for example, any type, format, or version of video coding, whether described in standards or recommendations (whether pre-existing or future-developed) and any extensions to such standards and recommendations. Unless otherwise stated or technically excluded, these aspects described in this application may be used alone or in combination.

[0086] Various numerical values, such as reconstructed sample values, are used in the examples described in this application. These and other specific values ​​are for illustrative purposes, and the aspects described are not limited to these specific values.

[0087] Figure 2 is a diagram illustrating an example video encoder. Variations of the example encoder 200 are envisioned, but for clarity, encoder 200 is described below without describing all anticipated variations.

[0088] Before being encoded, the video sequence may undergo pre-coding (201), for example, applying a color transformation to the input color image (e.g., a conversion from RGB4:4:4 to YCbCr4:2:0), or performing a remapping of the input image components to obtain a signal distribution that is more resilient to compression (e.g., using histogram equalization with one of the color components). Metadata may be associated with the pre-processing and appended to the bitstream.

[0089] In encoder 200, the image is encoded by encoder elements as described below. The image to be encoded is partitioned (202) and processed in units such as coding units (CUs). Each unit is encoded using, for example, an intra-frame or inter-frame mode. When a unit is encoded in intra-frame mode, intra-frame prediction (260) is performed. In inter-frame mode, motion estimation (275) and compensation (270) are performed. The encoder determines (205) which mode, intra-frame or inter-frame, to use to encode the unit, and indicates the intra-frame / inter-frame decision by, for example, a prediction mode flag. For example, the prediction residual is calculated by subtracting (210) the prediction block from the original image block.

[0090] The predicted residual is then transformed (225) and quantized (230). The quantized transform coefficients, motion vectors, and other syntactic elements are entropy encoded (245) to output a bitstream. The encoder can skip the transform and apply quantization directly to the untransformed residual signal. The encoder can bypass both the transform and quantization, i.e., directly encode the residual without applying either the transform or quantization process.

[0091] The encoder decodes the coded block to provide a reference for further prediction. The quantized transform coefficients are dequantized (240) and inverse transformed (250) to decode the prediction residual. The decoded prediction residual and the prediction block are combined (255) to reconstruct the image block. An in-loop filter (265) is applied to the reconstructed image to perform, for example, deblocking / SAO (Sample Adaptive Shift) filtering, thereby reducing coding artifacts. The filtered image is stored in a reference image buffer (280).

[0092] Figure 3 is a diagram illustrating an example video decoder. In the example decoder 300, the bitstream is decoded by decoder elements, as described below. The video decoder 300 typically performs a decoding process that is the reverse of the encoding process shown in Figure 2. The encoder 200 typically also performs video decoding as part of the encoded video data.

[0093] Specifically, the decoder's input includes a video bitstream, which can be generated by the video encoder 200. First, entropy decoding (330) is performed on the bitstream to obtain transform coefficients, motion vectors, and other encoded information. Image partitioning information indicates how the image is partitioned. Therefore, the decoder can partition (335) the image based on the decoded image partitioning information. The transform coefficients are dequantized (340) and inverse transformed (350) to decode the prediction residuals. The decoded prediction residuals and prediction blocks are combined (355) to reconstruct the image blocks. Prediction blocks (370) can be obtained from intra-frame prediction (360) or motion-compensated prediction (i.e., inter-frame prediction) (375). An in-loop filter (365) is applied to the reconstructed image. The filtered image is stored in a reference image buffer (380).

[0094] The decoded image can also undergo post-decoding processing (385), such as inverse color transformation (e.g., conversion from YCbCr4:2:0 to RGB4:4:4) or inverse remapping, which is the inverse of the remapping process performed in the pre-encoding process (201). Post-decoding processing can use metadata derived in the pre-encoding process and signaled in the bitstream. In the example, the decoded image (e.g., after applying an in-loop filter (365) and / or, in the case of post-decoding processing, after post-decoding processing (385)) can be transmitted to a display device for presentation to the user.

[0095] Figure 4 is a diagram illustrating an example of a system in which the various aspects and examples described herein may be implemented. System 400 may be embodied as a device including the various components described below and configured to perform one or more aspects described in this document. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. Elements of system 400 may be embodied individually or in combination in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one example, the processing elements and encoder / decoder elements of system 400 are distributed across multiple ICs and / or discrete components. In various examples, system 400 is communicatively coupled to one or more other systems or other electronic devices via, for example, a communication bus or through dedicated input and / or output ports. In various examples, system 400 is configured to implement one or more aspects described in this document.

[0096] System 400 includes at least one processor 410 configured to execute instructions loaded thereon to implement various aspects, such as those described in this document. Processor 410 may include embedded memory, input / output interfaces, and various other circuitry known in the art. System 400 includes at least one memory 420 (e.g., a volatile memory device and / or a non-volatile memory device). System 400 includes a storage device 440 that may include non-volatile memory and / or volatile memory, including but not limited to electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), programmable read-only memory (PROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, disk drives, and / or optical disk drives. As a non-limiting example, storage device 440 may include internal storage devices, attached storage devices (including removable and non-removable storage devices), and / or network-accessible storage devices.

[0097] System 400 includes an encoder / decoder module 430 configured to, for example, process data to provide encoded or decoded video, and the encoder / decoder module 430 may include its own processor and memory. The encoder / decoder module 430 represents a module that can be included in a device to perform encoding and / or decoding functions. It is well known that a device may include one or both encoding and decoding modules. Alternatively, the encoder / decoder module 430 may be implemented as a separate element of system 400, or it may be incorporated within processor 410 as a combination of hardware and software known to those skilled in the art.

[0098] Program code to be loaded onto processor 410 or encoder / decoder 430 to execute the various aspects described in this document may be stored in storage device 440 and subsequently loaded onto memory 420 for execution by processor 410. Depending on various examples, one or more of processor 410, memory 420, storage device 440, and encoder / decoder module 430 may store one or more of various items during the execution of the processes described in this document. Such stored items may include, but are not limited to, input video, decoded video or portions of decoded video, bitstreams, matrices, variables, and intermediate or final results from equations, formulas, operations, and operational logic processing.

[0099] In some examples, the memory within processor 410 and / or encoder / decoder module 430 is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other examples, external memory (e.g., the processing device could be processor 410 or encoder / decoder module 430) is used for one or more of these functions. External memory could be memory 420 and / or storage device 440, such as volatile memory and / or non-volatile flash memory. In several examples, external non-volatile flash memory is used to store, for example, the operating system of a television. In at least one example, fast external volatile memory such as RAM is used as working memory for video encoding and decoding operations.

[0100] Input to the components of system 400 can be provided through various input devices, as indicated in box 445. Such input devices include, but are not limited to, (i) a radio frequency (RF) section that receives, for example, RF signals transmitted over the air by a broadcaster, (ii) a component (COMP) input terminal (or a set of COMP input terminals), (iii) a universal serial bus (USB) input terminal, and / or (iv) a high-definition multimedia interface (HDMI) input terminal. Other examples not shown in Figure 4 include composite video.

[0101] In various examples, the input device of block 445 has corresponding input processing elements known in the art. For example, the RF section may be associated with elements suitable for: (i) selecting a desired frequency (also known as selecting a signal, or limiting the signal band to a band), (ii) down-converting the selected signal, (iii) further band-limiting to a narrower band to select (e.g.,) a signal band that may be referred to as a channel in some examples), (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and / or (vi) demultiplexing to select the desired data packet stream. The RF section of various examples includes one or more elements performing these functions, such as frequency selectors, signal selectors, band limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF section may include tuners performing various of these functions, including, for example, down-converting a received signal to a lower frequency (e.g., intermediate frequency or near-baseband frequency) or baseband. In one set-top box example, the RF section and its associated input processing elements receive RF signals transmitted via a wired (e.g., cable) medium and perform frequency selection by filtering, down-converting, and filtering again to the desired frequency band. Various examples rearrange the order of the above (and other) components, remove some of these components, and / or add other components that perform similar or different functions. Adding components may include inserting components between existing components, such as inserting amplifiers and analog-to-digital converters. In various examples, the RF section includes an antenna.

[0102] USB and / or HDMI terminals may include corresponding interface processors for connecting system 400 to other electronic devices via USB and / or HDMI connections. It should be understood that aspects of input processing (e.g., Reed-Solomon error correction) may be implemented, for example, within a separate input processing IC or within processor 410, as needed. Similarly, aspects of USB or HDMI interface processing may be implemented, as needed, within a separate interface IC or within processor 410. The demodulated, error-corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 410 and an encoder / decoder 430 operating in conjunction with memory and storage elements, to process the data stream as needed for presentation on an output device.

[0103] Various components of system 400 can be housed within an integrated housing. Within the integrated housing, the various components can be interconnected and transmit data between them using suitable connection devices 425 (e.g., internal buses known in the art, including inter-IC (I2C) buses, wiring, and printed circuit boards).

[0104] System 400 includes a communication interface 450 that enables communication with other devices via a communication channel 460. The communication interface 450 may include, but is not limited to, a transceiver configured to send and receive data via the communication channel 460. The communication interface 450 may include, but is not limited to, a modem or network interface card (NIC), and the communication channel 460 may be implemented, for example, within a wired and / or wireless medium.

[0105] In various examples, wireless networks, such as Wi-Fi networks (e.g., IEEE 802.11, where IEEE stands for Institute of Electrical and Electronics Engineers), are used to stream or otherwise provide data to system 400. In these examples, the Wi-Fi signal is received via a communication channel 460 and a communication interface 450 adapted for Wi-Fi communication. The communication channel 460 in these examples is typically connected to an access point or router that provides access to external networks, including the Internet, to allow streaming applications and other over-the-top communications. Other examples use a set-top box to provide streaming data to system 400, delivering data via an HDMI connection to input block 445. Still other examples use an RF connection to input block 445 to provide streaming data to system 400. As indicated above, various examples provide data in non-streaming modes. Additionally, various examples use wireless networks other than Wi-Fi, such as cellular networks or Bluetooth® networks.

[0106] System 400 can provide output signals to various output devices, including display 475, speaker 485, and other peripheral devices 495. Various examples of display 475 include one or more of, for example, touchscreen displays, organic light-emitting diode (OLED) displays, curved displays, and / or foldable displays. Display 475 can be used in televisions, tablets, laptops, mobile phones, or other devices. Display 475 can also be integrated with other components (e.g., in a smartphone) or standalone (e.g., an external monitor for a laptop computer). In various examples, other peripheral devices 495 include one or more of standalone digital video discs (or digital multifunction discs) (DVDs, for both terms), disc players, stereo systems, and / or lighting systems. Various examples use one or more peripheral devices 495 that provide functionality based on the output of system 400. For example, a disc player performs the function of playing the output of system 400.

[0107] In various examples, signaling (such as AV.Link, Consumer Electronics Control (CEC), or other communication protocols that implement device-to-device control with or without user intervention) is used to transmit control signals between system 400 and display 475, speaker 485, or other peripheral devices 495. Output devices may be communicatively coupled to system 400 via dedicated connections through corresponding interfaces (470, 480, and 490). Alternatively, output devices may be connected to system 400 via communication interface 450 using communication channel 460. Display 475 and speaker 485 may be integrated into a single unit along with other components of system 400 in electronic devices such as televisions. In various examples, display interface 470 includes a display driver, such as a timing controller (TCon) chip.

[0108] For example, if the RF input section 445 is part of a separate set-top box, the display 475 and speaker 485 can alternatively be separate from one or more of the other components. In various examples where the display 475 and speaker 485 are external components, the output signal can be provided via a dedicated output connection, including, for example, an HDMI port, a USB port, or a COMP output.

[0109] The example can be implemented by processor 410 or by computer software implemented by hardware or a combination of hardware and software. As a non-limiting example, the example can be implemented by one or more integrated circuits. As a non-limiting example, memory 420 can be of any type suitable for the technical environment and can be implemented using any suitable data storage technology, such as optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and removable memory. As a non-limiting example, processor 410 can be of any type suitable for the technical environment and can encompass one or more microprocessors, general-purpose computers, special-purpose computers, and processors based on multi-core architectures.

[0110] Various implementations involve decoding. As used herein, “decoding” can encompass all or part of a process performed, for example, on a received encoded sequence to produce a final output suitable for display. In various examples, such a process includes one or more processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. In various examples, such a process also includes, or alternatively may include, a process performed by a decoder of the various implementations described herein, such as identifying a reference image (e.g., a reference frame) associated with a block (e.g., the current block).

[0111] As further examples, in one example, "decoding" refers only to entropy decoding; in another example, "decoding" refers only to differential decoding; and in yet another example, "decoding" refers to a combination of entropy decoding and differential decoding. Based on the specific context of the description, it will be clear whether the phrase "decoding process" is intended to specifically refer to a subset of operations or to refer to a broader decoding process, and it is believed that those skilled in the art will readily understand this.

[0112] Various implementations involve encoding. Similar to the discussion above regarding “decoding,” “encoding” as used herein can include, for example, all or part of the processing performed on an input video sequence to produce an encoded bitstream. In various examples, such processes include one or more processes typically performed by an encoder, such as partitioning, differential coding, transform, quantization, and entropy coding. In various examples, such processes also include, or alternatively may include, processes performed by an encoder of the various embodiments described herein.

[0113] As further examples, in one example, "encoding" refers only to entropy encoding; in another example, "encoding" refers only to differential encoding; and in yet another example, "encoding" refers to a combination of entropy encoding and differential encoding. Based on the specific context of the description, it will be clear whether the phrase "encoding process" is intended to specifically refer to a subset of operations or to refer to a broader encoding process, and it is believed that those skilled in the art will readily understand this.

[0114] It should be noted that the syntactic elements used in this article (e.g., the encoding syntax in template matching prediction, including but not limited to isAvatar, canonicalPose, mappings, type, animation, matrix, rotation, translation, scale, etc.) are descriptive terms. Therefore, they do not preclude the use of other syntactic element names.

[0115] When a diagram is presented as a flowchart, it should be understood that it also provides a block diagram of the corresponding device. Similarly, when a diagram is presented as a block diagram, it should be understood that it also provides a flowchart of the corresponding method / device.

[0116] The embodiments and aspects described herein may be implemented, for example, in methods or processes, apparatus, software programs, data streams, or signals. Even if discussed only in the context of a single embodiment (e.g., discussed only as a method), embodiments of the discussed features may be implemented in other forms (e.g., apparatus or program). Apparatus may be implemented, for example, with suitable hardware, software, and firmware. Methods may be implemented, for example, in a processor, which generally refers to a processing device, including, for example, a computer, microprocessor, integrated circuit, or programmable logic device. Processors also include communication devices, such as computers, cellular phones, portable / personal digital assistants (“PDAs”), and other devices that facilitate information communication between end users.

[0117] The references to “an example” or “example” or “an implementation” or “implementation”, and their variations, mean that a particular feature, structure, characteristic, etc., described in connection with the example is included in at least one example. Therefore, the phrases “in an example” or “in a sample” or “in an implementation” or “in an implementation”, and any other variations, appearing throughout this application, do not necessarily refer to the same example.

[0118] Additionally, this application may relate to "determining" various types of information. Determining information may include one or more of the following: for example, estimated information, calculated information, predicted information, or information retrieved from memory. Obtaining may include receiving, retrieving, constructing, generating, and / or determining.

[0119] Furthermore, this application may involve "accessing" various types of information. Accessing information may include one or more of the following: for example, receiving information, retrieving information (e.g., retrieving from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0120] Additionally, this application may relate to "receiving" various types of information. Like "access," the intent to receive is a broad term. Receiving information may include one or more of the following: for example, accessing information or retrieving information (e.g., retrieving from memory). Furthermore, "receiving" is generally referred to in one or more ways during operation, such as storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0121] It should be understood that, for example, in the cases of “A / B,” “A and / or B,” and “at least one of A and B,” the use of any of the following “ / ,” “and / or,” and “at least one” is intended to cover selecting only the first listed option (A), or only the second listed option (B), or selecting both options (A and B). As yet another example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” this wording is intended to include selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or selecting all three options (A, B, and C). As will be apparent to those skilled in the art and related fields, this can be extended to a large number of listed items.

[0122] Furthermore, as used herein, the word “signal” specifically refers to instructing the corresponding decoder to do something. Encoder signals may include, for example, an encoding function about the block's input using a precision factor. In this way, in the example, both the encoder and decoder use the same parameters. Thus, for example, the encoder may send (explicitly signal) a specific parameter to the decoder so that the decoder can use the same specific parameter. Conversely, if the decoder already has the specific parameter as well as other parameters, signaling can be used without sending (implicitly signal) to simply allow the decoder to know and select the specific parameter. Bit savings are implemented in various embodiments by avoiding the transmission of any actual functionality. It should be understood that signaling can be implemented in various ways. For example, in various examples, one or more syntactic elements, flags, etc., are used to send information to the corresponding decoder. Although the verb form of the word “signal” was mentioned above, the word “signal” can (e.g., it can also) be used as a noun herein.

[0123] As will be apparent to those skilled in the art, implementations can produce a variety of signals formatted to carry, for example, signals that can be stored or transmitted. Information may include, for example, instructions for performing a method, or data generated by one of the described implementations. For example, a signal may be formatted to carry a bitstream of the described example. Such a signal may be formatted as, for example, electromagnetic waves (e.g., using the radio frequency portion of a spectrum) or baseband signals. Formatting may include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information carried by the signal may be, for example, analog or digital information. It is well known that signals can be transmitted via a variety of different wired or wireless links. Signals may be stored on, or accessed or received from, a processor-readable medium.

[0124] This document describes numerous examples. Features of the examples may be provided individually or in any combination across various claim classes and types. Furthermore, examples may include one or more of the features, devices, or aspects described herein, individually or in any combination across various claim classes and types. For example, the features described herein may be implemented in a bitstream or signal that includes information generated as described herein. This information may allow a decoder to decode the bitstream, the encoder, bitstream, and / or decoder being any of the embodiments described. For example, the features described herein may be implemented by creating and / or transmitting and / or receiving and / or decoding a bitstream or signal. For example, the features described herein may be implemented by a method, process, apparatus, medium storing instructions, medium storing data, or signal. For example, the features described herein may be implemented by a TV, set-top box, mobile phone, tablet computer, or other electronic device performing decoding. The TV, set-top box, mobile phone, tablet computer, or other electronic device may display (e.g., using a monitor, screen, or other type of display) a resulting image (e.g., an image reconstructed from the residual of a video bitstream). The TV, set-top box, mobile phone, tablet computer, or other electronic device may receive a signal including an encoded image and perform decoding.

[0125] These examples can be executed by a device having at least one processor. The device can be an encoder or a decoder. These examples can be executed by a computer program product stored on a non-transitory computer-readable medium and including program code instructions. These examples can be executed by a computer program including program code instructions. These examples can be executed via a bitstream including information representing a template-matching prediction pattern.

[0126] This article discloses the systems, methods, and tools associated with avatar meshes, as well as avatar construction and rendering.

[0127] In the example, the apparatus associated with avatar construction and rendering can receive avatar data associated with the avatar. The avatar data can be used to generate an avatar mesh. The apparatus can determine that the avatar data includes canonical pose attributes. In the example, canonical pose attributes can include at least one of the following: coordinate definition, orientation, rotation direction, front axis, bottom-up axis, right axis, foot level, and avatar state.

[0128] In the example, the apparatus may determine that the canonical pose attribute includes a transformation. Based on the canonical pose attribute including the transformation, the avatar mesh can be transformed using this transformation. The transformed avatar mesh can be returned for modifying the avatar pose. In the example, the transformation may include at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation. In the example, the apparatus may determine that the canonical pose includes a type attribute. Based on the canonical pose attribute including the type attribute, the avatar mesh can be transformed based on this type attribute. The transformed avatar mesh can be returned for modifying the avatar pose.

[0129] The avatar pose associated with an avatar can be modified using avatar mesh and canonical pose attributes. In the example, modification of the avatar pose can be related to at least one of the following: avatar placement, avatar orientation, and avatar gaze. In the example, avatar data can be Graphics Library Transport Format (gIFT) data including MPEG Node Avatar Extensions. In the example, the apparatus can determine that an avatar flag associated with MPEG Node Avatar Extensions is enabled.

[0130] The apparatus for constructing and rendering avatar meshes and avatars can parse glTF data. The apparatus can determine that the glTF data includes nodes with MPEG node avatar extensions (e.g., MPEG_node_avatar extensions). The apparatus can determine that avatar attributes associated with the MPEG node avatar extensions (e.g., the "isAvatar" attribute) are enabled (e.g., set to true). The apparatus can then use the glTF data to generate an avatar mesh. The apparatus can also determine that the MPEG node avatar extensions include canonical pose attributes (e.g., "canonicalPose" attributes). The apparatus can use the avatar mesh and the settings provided by the canonical pose attributes to construct and / or render the avatar.

[0131] The device can also determine whether the canonical pose attribute includes a transformation. Transformations can include at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation. Furthermore, if the device determines that the canonical pose attribute includes a transformation, it can use that transformation to transform the avatar mesh and return the transformed avatar mesh for rendering.

[0132] The apparatus can determine that the canonical pose includes, for example, a type attribute associated with an application running on the apparatus. The type attribute may indicate at least one canonical pose Uniform Resource Name (URN). The apparatus can then transform the avatar mesh based on the canonical pose and return the transformed avatar mesh for rendering.

[0133] An avatar can be described using a canonical pose (e.g., in a scene description). In some examples, a device (e.g., a video rendering device, a head-mounted display device, etc.) can perform one or more of the features described herein. Embodiments can provide avatar encoding for 3D scene representation. The canonical pose of an avatar model can be defined, for example, as described herein. A canonical pose can include, for example, one or more of the following: coordinates, orientation, rotation direction, front axis, bottom-up axis, right axis, feet horizontal, avatar state, etc.

[0134] The MPEG-I Scene Description (SD) format can use extensions (e.g., the MPEG_node_avatar extension) to allow the definition of avatar models. Applications can determine which mesh is the avatar and / or can therefore use that avatar (e.g., if the avatar is a regular human mesh). Applications can place the avatar within the scene and / or allow users to move the avatar within an environment (e.g., a virtual world).

[0135] The orientation and / or pose of the avatar can be indeterminate. For example, the application may not know the orientation and / or pose of the avatar. The orientation and / or pose of the avatar can come from the modeler's artistic choices or preferences, the digital authoring software (DCC) used (e.g., Maya, Blender, MeshLab, etc.), or other suitable sources. The orientation and / or pose of the avatar can be aligned with axes (e.g., X, Y, and / or Z), with preferred directions (e.g., forward, front, bottom-up, and / or left / right orientation), with scaling / linear distance, with rotational orientation, and / or with attachment points (e.g., feet horizontal).

[0136] Orientation can be specified in glTF format. Orientation can be selected as the default orientation for the glTF file; for example, Z for forward / positive, Y for bottom-up, and -X for right orientation. Distance units can be meters, and rotation can be counter-clockwise. The mesh in the glTF file (e.g., all meshes) can follow one or more properties without any supplementary information. Meshes that do not follow these properties may not be used correctly, or the application may know (e.g., in advance) how to correct these meshes.

[0137] Default glTF coordinates may not include avatar-specific properties. For example, if default coordinates are used to place an avatar in a virtual world, information about the position of the avatar's feet or anything related to the avatar's positioning in the virtual world can be determined. For the human body, for example, the lowest bottom-up coordinates may be obvious. For other avatars, the coordinates may not be (e.g., immediately) obvious. For example, the coordinates of a boat can be determined so that the boat can be placed on water (e.g., if the boat is in the water). In this case, the coordinates of the waterline may be necessary. Like parameters of deformable target weights or skinning weights, (e.g., canonicalizing) the avatar pose may require a specific state, such as raising both arms like in Leonardo da Vinci's Vitruvian Man.

[0138] Asset creation and exchange can involve a variety of requirements (e.g., specific requirements) that may or may not be met. For example, when an avatar is added to a public 3D database or online store, it may or may not be possible to ensure that the avatar pose specification will be the one expected by the application. In some examples, glTF files can be corrected to conform to specifications. However, if the avatar is more complex (e.g., compared to simpler avatars), only an expert can solve this problem (e.g., requiring a significant amount of time). In some examples, using extensions as described herein, a “canonical pose” (e.g., the pose found when opening a file in any 3D software) can be provided. This pose can be useful (e.g., useful for situations where it is needed). “Transformations” that can correct the pose can also be provided. In examples, small plugins (e.g., dedicated plugins) can be used for such transformation tasks.

[0139] For example, the format described herein can conform to the glTF format. This format is compatible with MPEG-ISD extensions. For example, a right-handed axis can be used in a glTF file. This format can be used regardless of the axis orientation, for example, as in a glTF file. This format can be implemented using other formats (e.g., XML, USD, etc.).

[0140] An avatar's canonical pose can be defined, for example, using a Uniform Resource Name (URN). An avatar's canonical pose can be unique and can be defined using a specific set of specifications. Avatar canonical pose specifications can include one or more of the following: coordinate system orientation, positioning rotation direction, units of all linear distances, front axis, bottom-up axis, right axis, foot level, avatar animation state, etc. The coordinate system orientation can indicate, for example, the direction displayed by the image based on a coordinate system (e.g., left-handed coordinate system versus right-handed coordinate system). The positioning rotation direction can be clockwise or counterclockwise. Units of linear distances can include, for example, units such as meters, miles, etc. Foot level can be based on the following plane equations: .

[0141] For example, if a combination of specifications is attached to a unique URN, the application can propose additional specifications. Figure 11 shows a list of URNs and their definitions. For example, an avatar canonical pose may not include components from the scene, such as cameras, materials, or light. For example, an avatar canonical pose can be independent of any scene. An avatar canonical pose can be defined using one or more URNs listed in Figure 11.

[0142] Figure 5 shows an example of an avatar pose, where the positive / front axis is -Y, the bottom-up axis is Z, and the right axis is X. Figure 5 shows an example of an avatar with a pose (e.g., "mpeg:sd:avatar:pose:iyzix"). The camera may not be defined by this pose. Figure 5 shows an avatar from its right side. Figure 5 shows an avatar, for example, whose pose is not affected by Y being the front axis, Z being the bottom-up axis, and / or X being the right axis.

[0143] The MPEG_node_avatar extension can be extended with, for example, attributes and / or parameters that can define the canonical pose of the avatar mesh, and / or can transform the avatar mesh (e.g., from the source camera to which the node belongs) to put the avatar in this pose (if the avatar is not already in this pose).

[0144] Scenes can be defined in a glTF file. This extension may not change the scene defined in the glTF file. For example, the default renderer may ignore the scene in the glTF file (e.g., not parse all the content of the scene), and / or the canonical pose may be used by applications that load assets from glTF and / or dynamically place these assets into an existing scene or transform these assets. For example, a virtual world may place an avatar mesh in the world. The avatar mesh pose may be determined (required) to determine the placement of the avatar's feet (e.g., in the virtual world). The application may need this pose to place accessories on the avatar (e.g., otherwise the application may not be able to place the avatar's feet on the ground in the virtual world).

[0145] For example, the attribute "canonicalPose" can be added to the MPEG_node_avatar extension, as shown in Table 1.

[0146] Table 1

[0147] For example, the "canonicalPose" attribute can be provided, as shown in Table 2.

[0148] Table 2

[0149] The "type" attribute defines the canonical pose of the avatar. The value of the "type" attribute can be a Uniform Resource Name (URN). A URN can be part of the URNs in Table 3 or can be defined by the application. Other transformation attributes (such as "animation", "matrix", "translation", "rotation", and "scale") can be used to transform the mesh. For example, these attributes can be used when the avatar is not in a canonical pose. In some examples, these attributes may not be used to change the avatar in the scene (e.g., they can provide useful information). These attributes can be used in processes that may require canonical poses, such as to place accessories on the avatar. If used in such processes, these transformations can be applied before node transformations. Node transformations can be used to place the avatar in the scene, for example, in a scene where the mesh is in a default pose (e.g., and not necessarily a canonical pose). One or more of "animation" and "matrix" and combinations of the "translation", "rotation", and "scale" attributes can be mutually exclusive. If the "animation" attribute is present, the "matrix", "translation", "rotation", and / or "scale" attributes may not be specified. The "animation" property can reference animations in glTF's animation assets. At frame t=0, animations can be used to bring the avatar into a canonical pose. If the "matrix" property is present, the "animation," "translation," "rotation," and / or "scale" properties can be omitted. The "matrix" property can include a floating-point 4×4 transformation matrix stored in column-major order. Matrices can be used to bring the avatar into a canonical pose.

[0150] If one or more of the "translation", "rotation", and "scale" properties are present, the "animation" and "matrix" properties can be omitted. The "translation" property can include translations along the x, y, and z axes. The "rotation" property can include unit quaternion rotations in the order (x, y, z, w), where w is a scalar. The "scale" property can include, for example, non-uniform scaling as a scaling factor along the x, y, and z axes. These transformations can be used to bring the avatar into a canonical pose.

[0151] The "node" property can involve the canonicalPose transformation. If the mesh is not yet in a normalized pose, the canonicalPose transformation can be used to bring it to a normalized pose. The canonicalPose transformation can be applied before the node transformation. Node transformations can be used to set the avatar's position in the world. Node transformations do not necessarily have to be related to the normalized pose.

[0152] The canonicalPose transformation described in this article can act as (e.g., equivalent to) the "node" attribute described in this article, except that the purpose of the canonicalPose transformation can be different. CanonicalPose transformation and node transformation can be complementary. CanonicalPose transformation can be applied before node transformation. If the mesh is not yet in a normal pose, canonicalPose transformation can be used to put the mesh in a normal pose. CanonicalPose transformation can be used (e.g., previously used) to set the correct gaze direction of an avatar in cases of incorrect left-right orientation, or to properly bind accessories to an avatar by fixing orientation or scaling issues. Node transformation can set the avatar's position in the scene's world coordinate system, regardless of the normal pose.

[0153] Various examples of glTF diagrams can be provided. Such examples can illustrate the portions of a glTF file related to the avatar canonical pose. A scene with sufficient data to construct an avatar mesh can be used as an example. Examples can include loading nodes with avatar components. In the example, the avatar could consist of multiple (e.g., seven) cubes.

[0154] Figure 6 illustrates an avatar with a cube facing the Z-axis. As shown in Figure 6, the cube can be part of the avatar. For example, cube 0 can indicate the avatar's head, with the id definition "full_body / upper_body / head". Cube 1 can indicate the avatar's chest, with the id definition "full_body / upper_body / thorax". Cube 3 can indicate the avatar's right arm, with the id definition "full_body / upper_body / arm_right". Cube 4 can indicate the avatar's left arm, with the id definition "full_body / upper_body / arm_left". Cube 5 can indicate the avatar's pelvis, with the id definition "full_body / upper_body / pelvis". Cube 6 can indicate the avatar's right leg, with the id definition "full_body / upper_body / leg_right". Cube 6 can indicate the avatar's left leg, with the id definition "full_body / upper_body / leg_left".

[0155] The z-coordinate of multiple (e.g., all) cubes can be zero. The left portion can have a positive x-coordinate, and the right portion can have a negative x-coordinate. Parts (e.g., all parts) can have positive y-coordinates (the avatar's feet can touch the ground). Higher parts can have higher y-coordinates (e.g., the higher part could be the head).

[0156] This avatar can be in its canonical pose, where Z is the front axis, Y is the bottom-up axis, and -X is the right axis. The feet can touch the plane y=0, which indicates that the canonical pose "mpeg:sd:avatar:pose:zyix" corresponds to the identified avatar.

[0157] Figure 6 shows the rendering of the avatar facing the camera (e.g., the camera position is (0,0,z), where z>0 and the direction is (0,0,-1)). As shown in Figure 6, the avatar's right arm and right leg are therefore on the left side, and the avatar's left arm and left leg are on the right side.

[0158] An avatar can be encoded as follows.

[0159]

[0160] The glTF loader can decode (e.g., all) regular content (e.g., buffers, meshes, nodes, etc.), except for the MPEG_node_avatar attribute. Multiple nodes (e.g., nodes 0-6) can be created using meshes that use the same cube but different materials (e.g., different colors). The glTF loader can use the "translation" attribute in the node to place each mesh / cube in the scene. The last node (e.g., id 7) can be the parent of other nodes.

[0161] The loader can decode MPEG_node_avatar extensions (e.g., in the last node with id 7). The "isAvatar" attribute indicates that this is an avatar mesh, the "type" attribute defines the avatar part name (e.g., "full_body / upper_body"), and the "mappings" attribute defines the avatar part. For example, node 0 is the avatar head.

[0162] The loader can find the “canonicalPose” attribute in the MPEG_node_avatar extension of the last node, and / or can decode the URN “mpeg:sd:avatar:pose:zyix”, which may mean that Z is the front axis, Y is the bottom-up axis, and -X is the right axis.

[0163] In some examples, the avatar may have been translated by (x,y,z) = (0, 2.5, 2) This translation may be performed, for example, to correctly construct the scene, or because it may be necessary for creating software within a workflow. In some cases, the reason could be that correcting the transformation is too complex. For example, each mesh in the mesh used to create the scene (e.g., an avatar mesh) may include a large number of mesh parts. Changing either a mesh or an avatar mesh part and updating all components of the scene can be complex. Furthermore, working with glTF files and modifying many of their numerous entities individually can be inconvenient for other users of the system.

[0164] Regarding the canonical pose used, such as "mpeg:sd:avatar:pose:zyix", where translation is along the Y-axis: the feet may no longer be located at y=0, and if we place such an avatar in a virtual world, the avatar or part of it may appear to be buried underground. This issue can be addressed, for example, by adding the "translation" attribute to the "canonicalPose" attribute of the MPEG_node_avatar extension.

[0165]

[0166] It's worth noting that the transformation in the "canonicalPose" of the MPEG_node_avatar extension may not transform the scene. If glTF is loaded in the viewer, the avatar can be positioned (e.g., as defined by other glTF parts). Therefore, the plane y=0 can split the avatar in two.

[0167] Applications can be configured to use or not use the transformations in the "canonicalPose" of the MPEG_node_avatar extension. If the application's goal is to place the avatar in a virtual world, the application can use the feature in one or more of the following ways.

[0168] The glTF loader can decode information in a file (e.g., each item). Information (e.g., data including MPEG_node_avatar extensions) can be stored as additional data. Applications can scan nodes to find avatar nodes (e.g., nodes with MPEG_node_avatar where "isAvatar" is true). Applications can construct associated meshes and their properties (e.g., if a node includes an avatar node, the application can construct a mesh of seven cubes). If a transformation exists in a node, the application can ignore that transformation.

[0169] After constructing the avatar mesh, the application can check if the canonical pose is "mpeg:sd:avatar:pose:zyix", i.e., a pose supported by the application. Therefore, no further action is required. If the application determines that the canonical pose is not "mpeg:sd:avatar:pose:zyix", it can either convert the avatar mesh to a supported pose or reject it due to incompatibility. The application can verify the presence of a transformation in the canonical pose, which can consist of a single translation. Transformations (e.g., shown only as translations) can be applied to the avatar mesh, which can then be prepared for placement in the virtual world.

[0170] In the example, the avatar can be a human head with deformable targets for constructing various facial expressions. The default expression can be (e.g., all) deformable target weights set to zero. This expression can be a neutral expression. Figure 7 shows an example of an avatar head with a neutral expression (e.g., all deformable target weights are zero). In this example, it can be assumed that the application can utilize an avatar with an open mouth to provide features such as adding accessories (e.g., when the mouth is closed, if the lip vertices do not coincide, it can be assumed that the lip vertices are closed, which could cause problems for algorithms used for detection and / or splicing). For example, the application might need this expression as the avatar's canonical pose. Simultaneously, the application might need a neutral pose to place the avatar in the virtual world. It would be too strange if all avatars in the world walked with their mouths open.

[0171] In some examples, the "animation" attribute can be added to the "canonicalPose" attribute of the MPEG_node_avatar extension.

[0172]

[0173] The glTF loader can decode MPEG_node_avatar data and store it in a dedicated structure. MPEG_node_avatar data can be semantic data that does not change the scene. Applications may or may not use this information (e.g., data in MPEG_node_avatar). In this example, the application determines that the type of the canonical pose is "mpeg:sd:avatar:pos:iyzix". This determination can be made for the pose for which the application created it. For example, the application can (e.g., if necessary) convert the avatar mesh to an application-supported pose or reject the avatar mesh due to incompatibility. The application can (e.g., after converting the avatar mesh to an application-supported pose or rejecting the avatar mesh) find a transformation in the canonical pose, which can consist of animation. The animation can modify the deformable target weights, for example, where the weights can be [0,1,0,…,0,0], where non-zero weights can be weights corresponding to deformable targets with open mouths.

[0174] In some examples, nodes can be parsed, for instance, based on support for the MPEG_node_avatar extension. Figure 8 illustrates the parsing of a node with support for the MPEG_node_avatar extension. This process can be performed (e.g., each time) as nodes are processed in the glTF file. As shown in Figure 8, at 501, the node can be parsed. At 502, standard attributes and possible extensions can be parsed and / or decoded by the glTF loader. At 503, if the MPEG_node_avatar exists, the loader can parse the MPEG_node_avatar. Otherwise, the loader can end the parsing at 509.

[0175] At 504, the "isAvatar" attribute can be parsed (e.g., required and / or an error if it does not exist). At 505, the "type" attribute can be parsed (e.g., required and / or an error if it does not exist). At 506, the "mappings" attribute can be parsed (e.g., required and / or an error if it does not exist). At 507, if present, the (508) "canonicalPose" attribute can be parsed. At 509, the result of the data found in the MPEG_node_avatar extension (e.g., if any) can be stored in a dedicated structure and can be fixed. Standard node attributes and / or other data in other extensions can modify the scene.

[0176] Figure 9 illustrates the resolution of the "canonicalPose" attribute. As shown in Figure 9, at 601, this process can be performed when the glTF loader finds the "canonicalPose" attribute in the MPEG_node_avatar extension. At 602, the "type" attribute can be resolved (e.g., required and / or throws an error if it does not exist). At 603, tests can be performed to determine if the "animation" attribute exists. For example, if the "animation" attribute exists, the attributes "matrix", "translation", "rotation", and / or "scale" may not exist. At 604, the "animation" attribute can be resolved. The resulting value can point to an animation in the glTF animation asset (e.g., an existing one). At 606, the "matrix" attribute can be tested. For example, if the "matrix" attribute exists, the attributes "animation", "translation", "rotation", and "scale" may not exist. At 606, the "matrix" attribute can be resolved. At points 607, 609, and 611, tests can determine whether "translation," "rotation," and "scale" exist. In the example, zero, one, two, or three of these attributes may exist. For example, if at least one of the attributes "translation," "rotation," and "scale" exists, some attributes, including "matrix" and "animation," may not exist. At point 608, the "translation" attribute can be resolved. At point 610, the "rotation" attribute can be resolved. At point 612, the "scale" attribute can be resolved. At point 613, data found during the resolution of the "canonicalPose" attribute can be stored in a dedicated structure and / or may not change the scene.

[0177] In the examples, as described herein, glTF files with the MPEG_node_avatar extension can be parsed. In some examples, the data in the MPEG_node_avatar extension may (e.g., only) be stored in a dedicated structure. Applications may or may not utilize the parsed data. Data associated with the avatar can be used to create an avatar mesh in a canonical pose. These and other uses are described herein.

[0178] Figure 10 illustrates an example of constructing an avatar mesh in a canonical pose. As shown in Figure 10, at 701, the process of constructing an avatar mesh in a canonical pose can begin. At 702, the glTF parsed data associated with nodes can be searched (e.g., by the application) for MPEG_node_avatar extensions. At 703, a determination can be made (e.g., by the application) whether an MPEG_node_avatar extension has been found and whether the "isAvatar" attribute associated with the MPEG_node_avatar extension is true. At 710, if the application fails to find a node with an MPEG_node_avatar extension and / or the "isAvatar" indicator is not true, the application can determine that an avatar mesh cannot be constructed.

[0179] At 704, an avatar mesh can be constructed using data grids or subdata. A grid can point to grid data, and subdata can point to other nodes that may include grid attributes or subattributes. Other node attributes, such as transformation-related attributes, including "matrix" or "translation" attributes, can be ignored. At 705, a test can be performed to determine whether the MPEG_node_avatar extension has the "canonicalPose" attribute. If the extension does not have the "canonicalPose" attribute, it can be assumed that the avatar mesh is already in a canonical pose supported by the application.

[0180] At 706, it can be determined whether the "canonicalPose" property has a transformation (such as one of "matrix", "animation", "translation", "rotation", and / or "scale" transformations). At 707, the avatar mesh can be transformed using the transformations found in the "canonicalPose" property.

[0181] At 708, it is possible to determine whether the canonical pose URN in the "type" attribute is supported. Support may depend on the possibility of rejecting applications of all poses other than those it supports. At 709, the avatar mesh can be transformed to match the applied canonical pose. At 711, the created avatar mesh can be returned.

[0182] For example, in the case of avatars in a virtual world, an application can place (e.g., correctly place) an avatar in the virtual world without needing to supplement data. Canonical poses allow the application to understand how to correctly place and orient the avatar, for example, ensuring the feet are in contact with the ground and the avatar is looking in the correct direction (e.g., the direction the avatar is walking). Avatar assets collected outside the application's scope can be safely used.

[0183] In examples, such as video conferencing, avatar detection can be provided. Avatar pose detection and adjustment (e.g., automatic detection and adjustment) can reduce the need for external data and / or prior information about the avatar. For example, an application can use a pose provided in glTF format to determine and verify that the avatar is facing the camera. Any avatar assets collected outside the application's scope can be safely executed.

[0184] In the example, avatar accessories and clothing can be placed on and displayed on the avatar. The application can place (e.g., correctly place) the accessories on the avatar. For example, to place the accessories, the application can determine the avatar's orientation or scaling. For instance, if the application has attachment points for placing glasses on the avatar, it might need to know which directions can be considered upwards and which can be considered downwards.

[0185] In some examples, the transformations in the "canonicalPose" attribute of the MPEG_node_avatar extension can be used to transform the avatar, place accessories, and / or invert the transformations and the entire mesh.

[0186] In the example, avatar gaze can be determined. Avatar gaze can be used to determine the direction the avatar is looking in. For example, avatar gaze is useful for determining what the avatar can or cannot see.

[0187] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) 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, and optical media such as CD-ROM discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. An apparatus associated with avatar construction and rendering, comprising: A processor configured to receive avatar data associated with an avatar; Use the avatar data to generate the avatar mesh; The avatar data is determined to include canonical pose attributes; and the avatar mesh and the canonical pose attributes are used to modify the avatar pose associated with the avatar.

2. The apparatus of claim 1, wherein the modification of the avatar pose is related to at least one of the following: the placement of the avatar, the orientation of the avatar, and the gaze of the avatar.

3. The apparatus of claim 1, wherein the normative pose attributes include at least one of the following: coordinate definition, orientation, rotation direction, front axis, bottom-up axis, right axis, foot level, and avatar state.

4. The apparatus of claim 1, wherein the processor is further configured to: determine that the canonical pose attribute includes a transformation; and, based on the canonical pose attribute including the transformation, use the transformation to transform the avatar mesh.

5. The apparatus of claim 4, wherein the processor is further configured to: return the transformed avatar mesh for the modification of the avatar pose.

6. The apparatus of claim 4, wherein the transformation includes at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation.

7. The apparatus of claim 1, wherein the processor is further configured to: determine that the canonical pose includes a type attribute; and transform the avatar mesh according to the type attribute based on the canonical pose attribute including the type attribute.

8. The apparatus of claim 7, wherein the processor is further configured to: return the transformed avatar mesh for the modification of the avatar pose.

9. The apparatus of claim 1, wherein the avatar data is gIFT data including MPEG node avatar extensions.

10. The apparatus of claim 9, wherein the processor is further configured to: determine that an avatar flag associated with the MPEG node avatar extension is enabled.

11. A method associated with avatar construction and rendering, the method comprising: Receive avatar data associated with the avatar; Use the avatar data to generate the avatar mesh; The avatar data is determined to include canonical pose attributes; And use the avatar mesh and the canonical pose attributes to modify the avatar pose associated with the avatar.

12. The method of claim 11, wherein the modification of the avatar pose is related to at least one of: the placement of the avatar, the orientation of the avatar, and the gaze of the avatar.

13. The method of claim 11, wherein the normed pose attributes include at least one of the following: coordinate definition, orientation, rotation direction, front axis, bottom-up axis, right axis, foot level, and avatar state.

14. The method of claim 11, further comprising: Determining the canonical pose attributes includes transformations; and based on the canonical pose attributes including the transformations, using the transformations to transform the avatar mesh.

15. The method of claim 14, further comprising: Return the transformed avatar mesh for the modification of the avatar pose.

16. The method of claim 14, wherein the transformation comprises at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation.

17. The method of claim 11, further comprising: The canonical pose is determined to include a type attribute; and based on the canonical pose attribute including the type attribute, the avatar mesh is transformed according to the type attribute.

18. The method of claim 17, further comprising: Return the transformed avatar mesh for the modification of the avatar pose.

19. The method of claim 11, wherein the avatar data is gIFT data including MPEG node avatar extensions.

20. The method of claim 19, further comprising: It is determined that the avatar flag associated with the MPEG node avatar extension is enabled.

21. An apparatus associated with avatar construction and rendering, comprising: A processor configured to receive avatar data associated with an avatar; Use the avatar data to generate the avatar mesh; The avatar data is determined to include canonical pose attributes, wherein the canonical pose attributes include at least one of the following: coordinate definition, orientation, rotation direction, front axis, bottom-up axis, right axis, foot level, and avatar state; the avatar mesh is transformed using the canonical pose attributes, including transformations, wherein the transformations include at least one of the following: matrix transformation, animation transformation, translation transformation, rotation transformation, and scaling transformation; the avatar mesh is transformed based on the canonical pose attributes, including type attributes; and the avatar mesh and the canonical pose attributes are used to modify the avatar pose associated with the avatar, wherein the modification of the avatar pose is related to at least one of the following: the avatar's placement, the avatar's orientation, and the avatar's gaze.

Images