Candidates for constructing the list of timd and dimd merge modes

Abstract

Merge candidate lists for TIMD merge mode and / or DIMD merge mode can include history-based fusion candidates and / or temporal fusion candidates. Fusion weights for TIMD merge candidates can be recalculated. Non-angular modes and associated fusion weights can be inherited for candidates. The number of allowed merge candidates can be adapted according to coding information for a current block. A decoder can generate a first merge candidate list for a fusion intra prediction merge mode by adding neighboring spatial neighboring intra fusion candidates and / or non-neighboring spatial neighboring candidates to a history-based fusion (HFI) table and history-based fusion candidates associated with the current block. A device can generate a second merge candidate list by adding the history-based fusion candidates from the HFI table to the first merge candidate list. The device can decode the current block using intra prediction merge candidates from the second intra prediction merge candidate list.

Description

Cross-references to related applications

[0001] This application claims the benefit of European patent application 24305550.6, filed on 8 April 2024, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0002] Video coding systems can be used to compress digital video signals, for example, to reduce the storage space and / or transmission bandwidth required for such signals. Video coding systems can include, for example, block-based systems, wavelet-based systems, and / or object-based systems. Summary of the Invention

[0003] Systems, methods, and means for a device configured for one or more of video encoding / decoding (e.g., encoding and / or decoding), distribution, and consumption are disclosed. The merge candidate list for template-based intra-frame mode derivation (TIMD) merging modes and / or decoder-side intra-frame mode derivation (DIMD) merging modes may include history-based merging candidates and / or temporal merging candidates. The merging weights for each TIMD merging candidate can be recalculated. Non-angular mode and associated merging weights can be inherited for the TIMD merging candidates. The number of allowed merging candidates can be adapted based on the encoding information of the current block.

[0004] In the example, a device (e.g., a decoder for video decoding) can generate a first intra-prediction merging candidate list for fusing intra-prediction merging modes. For example, the first intra-prediction merging candidate list can be generated by adding at least one of adjacent spatial proximity intra-merging candidates and non-adjacent spatial proximity candidates. The device can add history-based merging candidates associated with the current block to a history-based merging (HFI) table. The device can generate a second intra-prediction merging candidate list. For example, the second intra-prediction merging candidate list can be generated by adding one of the history-based merging candidates from the HFI table to the first intra-prediction merging candidate list. The device can use the intra-prediction merging candidates from the second intra-prediction merging candidate list to decode the current block.

[0005] In the example, the device may include temporal fusion candidates to generate a third intra-frame prediction merging candidate list. The third intra-frame prediction merging candidate list is used for at least one of a TIMD merging mode and a decoder-side intra-frame mode derivation DIMD merging mode.

[0006] In the example, the device can adapt the number of allowed merge candidates for TIMD merge mode or DIMD merge mode based on the encoding information of the current block.

[0007] In the example, the device may be a TIMD merge candidate that inherits a non-angled pattern and a set of fusion weights associated with the non-angled pattern.

[0008] In the example, the fused intra-prediction merging mode may include at least one of the TIMD mode and the DIMD mode.

[0009] In the example, the device may prune the intra-prediction merging candidate list. For example, the intra-prediction merging candidate list may be pruned based on determining that a subset of intra-prediction modes in the intra-prediction merging candidate list or information associated with the intra-prediction modes is redundant.

[0010] In the example, the device can determine whether the history-based fusion candidate is the same as one in the HFI table. The device can, for example, remove the HFI candidate from the HFI table and shift all subsequent HFI candidates one position forward based on the determination that the history-based fusion candidate is the same as one in the HFI table. Alternatively, the device can, for example, remove the first history-based fusion candidate from the HFI table, shift each of the remaining history-based fusion candidates in the HFI table one position forward, and add the history-based fusion candidate to the end of the HFI table based on the determination that the history-based fusion candidate is not the same as one in the HFI table.

[0011] In the example, the HFI table can be generated based on a historical fusion candidate count. In the example, the HFI table can be reset when decoding of a new coding tree unit (CTU), region, tile, slice, sub-picture, or frame begins. In the example, the device can add multiple intra-prediction modes and information associated with those multiple intra-prediction modes as the last entry in the table. Attached Figure Description

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

[0013] Figure 1B This illustrates that, according to embodiments, it is possible to... Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0014] Figure 1C This illustrates that, according to embodiments, it is possible to... Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0015] Figure 1D This illustrates that, according to embodiments, it is possible to... Figure 1A The system diagram shows another exemplary RAN and another exemplary CN used within the communication system shown.

[0016] Figure 2 An example video encoder is shown.

[0017] Figure 3 An example video decoder is shown.

[0018] Figure 4 Examples of systems that can achieve various aspects and examples are shown.

[0019] Figure 5 An example is shown for inferring the intra-prediction mode index for blocks predicted via TIMD.

[0020] Figure 6 This shows an example of a non-adjacent spatial neighbor block that can be used in TIMD merge list generation.

[0021] Figure 7 An example of calculating the gradient histogram (HoG) based on an L-shaped template formed from reconstructed samples is shown.

[0022] Figure 8 An example of a spatial neighbor that can provide DIMD information for a DIMD merging pattern is shown.

[0023] Figure 9 A flowchart is shown as an example of the process of constructing a list of TIMD merge / DIMD merge candidates using HFI candidates.

[0024] Figure 10 A flowchart is shown, illustrating an example of the coding process associated with adding HFI candidates and related information to the HFI table.

[0025] Figure 11 This shows an example of applying FIFO rules to a full HFI table.

[0026] Figure 12 A flowchart is shown, illustrating an example of the process of constructing a list of TIMD merge / DIMD merge candidates using temporal intra-frame fusion candidates.

[0027] Figure 13 This example illustrates searching for multiple temporal fusion candidates at multiple locations.

[0028] Figure 14 This example illustrates searching for multiple offset temporal fusion candidates at multiple offset locations. Detailed Implementation

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

[0030] Figure 1A This is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless broadband). For example, 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 (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0031] like Figure 1A As shown, 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 can 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.

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

[0033] 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.

[0034] 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 radio access technology (RAT) can be used to establish air interface 116.

[0035] 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 Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish 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).

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

[0037] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0038] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple 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 multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0039] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), 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.

[0040] Figure 1A Base station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, 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 picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0041] 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 Figure 1AAs not shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may 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.

[0042] 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.

[0043] Some or all of the WTRUs 102a, 102b, 102c, and 102d in 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, Figure 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can use cellular-based radio technology and with a base station 114b that can use IEEE 802 radio technology.

[0044] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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.

[0045] 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. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable 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 While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0046] 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 another embodiment, 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.

[0047] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0048] 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).

[0049] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keyboard 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, keyboard 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 that is not physically located on WTRU 102 (such as on a server or home computer (not shown)).

[0050] 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.

[0051] 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.

[0052] The processor 118 may also be coupled 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.

[0053] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals 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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe of both UL (e.g., for transmission) and downlink (e.g., for reception)) are separate.

[0054] Figure 1C This 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.

[0055] 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.

[0056] 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. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0057] Figure 1C The CN 106 shown 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 CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0058] 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.

[0059] The SGW 164 can connect to each of the eNode Bs 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 eNode-B 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.

[0060] 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.

[0061] 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) that serves as an interface between CN 106 and PSTN 108, or can communicate with it. 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.

[0062] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0064] 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 access or interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send 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 peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), 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 the "ad-hoc" communication mode in this article.

[0065] 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 bandwidth of 20 MHz) 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 (CSMA / CA) with collision avoidance can be implemented, for example, in an 802.11 system. For CSMA / CA, the AP STA (e.g., each STA) 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.

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

[0067] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz 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 resolver 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 80 MHz 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 sent to the Media Access Control (MAC).

[0068] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, including, for example, limited capabilities to support (e.g., only support) 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).

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

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

[0071] Figure 1D This 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.

[0072] 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 an embodiment, 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 can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0073] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. 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 or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., including different numbers of OFDM symbols and / or absolute times of varying durations).

[0074] 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., eNodeBs 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.

[0075] 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 uplink (UL) and / or downlink (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. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0076] Figure 1DThe CN 115 shown 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 a CN operator.

[0077] 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 used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. 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).

[0078] 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 them to route traffic 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.

[0079] 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 multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0080] 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.

[0081] Given Figures 1A to 1D and Figures 1A to 1D The corresponding descriptions can be performed by one or more emulation devices (not shown) that perform one or more of the functions described herein with respect to: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more 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.

[0082] 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.

[0083] One or more simulation devices may perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used to test scenarios in a laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas).

[0084] 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.

[0085] The aspects described and envisioned in this application can be implemented in many different forms. Figures 5 to 14 Some examples can be provided, but other examples are envisioned. Figures 5 to 14 The discussion 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.

[0086] 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.

[0087] This document describes various methods, each of which includes one or more steps or actions to implement 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 be performed, for example, before, during, or in a time period overlapping with the second decoding.

[0088] The various methods and other aspects described in this application can be used to modify, for example... Figure 2 and Figure 3 The illustrated modules of the video encoder 200 and decoder 300 include, for example, a decoding module. 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.

[0089] Various numerical values ​​are used in the examples described in this application, such as chroma format (e.g., 4:2:0, 4:2:2, 4:4:4), block size or coding unit size (e.g., height, width), number of coding units, partition size, number of search regions, number of sub-regions or regions, search step size, number of reconstructed blocks, number of entries in the list, precision, number of directions, number of patterns, number of candidates, candidate order, number of samples, number of references, bit value, sub-block size, number of parameters, multiplier value, constant value, range value, minimum value, maximum value, threshold, index value, number of predicted patterns, number of reference rows, index value, flag value, number of weights, weight value, etc. These and other specific values ​​are for illustrative purposes, and the aspects described are not limited to these specific values.

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

[0091] Before being encoded, the video sequence may undergo pre-coding processing 201 (e.g., applying color transformations to the input color picture (e.g., converting from RGB 4:4:4 to YCbCr 4:2:0), or performing remapping of the input picture components) to obtain a signal distribution more suited to compression (e.g., using histogram equalization of one of the color components). Metadata may be associated with the pre-processing and appended to the bitstream.

[0092] In encoder 200, the frame is encoded by encoder elements as described below. The frame to be encoded is divided (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.

[0093] The prediction residual is then transformed (225) and quantized (230). The quantized transform coefficients, along with motion vectors and other syntax elements (e.g., screen division information), 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.

[0094] 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 Offset) / ALF (Adaptive Loop Filtering) filtering, thereby reducing coding artifacts. The filtered image is stored in a reference image buffer (280).

[0095] Figure 3 This is a diagram illustrating an exemplary video decoder. In the exemplary decoder 300, the bitstream is decoded by decoder elements, as described below. The video decoder 300 typically performs operations similar to... Figure 2 The encoding process described herein is the inverse of the decoding process. Encoder 200 typically also performs video decoding as part of the encoded video data.

[0096] 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, prediction modes, motion vectors, and other encoded information. Frame segmentation information indicates how the frame should be segmented. Therefore, the decoder can segment (335) the frame based on the decoded frame segmentation 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 frame buffer (380). In some examples (e.g., for a given frame), the contents of the reference frame buffer 380 on the decoder 300 side can be the same as the contents of the reference frame buffer 280 on the encoder 200 side (e.g., for the same frame).

[0097] The decoded image can also undergo post-decoding processing (385), such as inverse color transformation (e.g., conversion from YCbCr 4:2:0 to RGB 4: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 the in-loop filter (365) and / or, in the case of post-decoding processing, after post-decoding processing (385)) can be sent to a display device for presentation to the user.

[0098] Figure 4 This is a diagram illustrating examples of systems in which the various aspects and examples described herein can be implemented. System 400 can be implemented 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 can be implemented 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.

[0099] System 400 includes at least one processor 410 configured to execute instructions loaded thereon to implement various aspects described herein, such as those described. 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.

[0100] 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 can include one or both of the 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 into processor 410 as a combination of hardware and software known to those skilled in the art.

[0101] 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.

[0102] 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.

[0103] Inputs 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. Figure 4 Other examples not shown include composite video.

[0104] In various examples, the input device of block 445 has associated 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 functions among 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 above (and other) components, remove some of them, 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.

[0105] 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 encoder / decoder 430), which operate in conjunction with memory and storage elements to process the data stream as needed for presentation on the output device.

[0106] 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).

[0107] 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.

[0108] In various examples, wireless networks, such as Wi-Fi networks (e.g., IEEE 802.11, where IEEE refers to the 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.

[0109] 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, cellular phones (mobile phones), or other devices. Display 475 can also be integrated with other components (e.g., in a smartphone) or separate (e.g., an external monitor for a laptop computer). In various examples, other peripheral devices 495 include one or more of stand-alone 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.

[0110] In various examples, signaling (such as AV.Link, Consumer Electronics Control (CEC), or other communication protocols that enable 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 another component of system 400 in an electronic device, such as a television. In various examples, display interface 470 includes a display driver, such as a timing controller (TCon) chip.

[0111] 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.

[0112] The example can be executed 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.

[0113] 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 procedures typically performed by the decoder, such as generating a first intra-prediction merging candidate list for fusing intra-prediction merging modes (e.g., where the first intra-prediction merging candidate list can be generated by adding at least one of adjacent spatial neighbor intra-merging candidates and / or non-adjacent spatial neighbor candidates); adding history-based merging candidates associated with the current block to a history-based merging (HFI) table; generating a second intra-prediction merging candidate list (e.g., where the second intra-prediction merging candidate list can be generated by adding one of the history-based merging candidates from the HFI table to the first intra-prediction merging candidate list); decoding the current block using intra-prediction merging candidates from the second intra-prediction merging candidate list, etc.

[0114] As another example, 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 the broader decoding process, and it is believed that those skilled in the art will understand this well.

[0115] Various implementations involve encoding. Similar to the discussion of “decoding” above, “encoding” as used in this application can include, for example, all or part of a process 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 can also include, or alternatively can include, processes performed by an encoder of the various implementations described in this application, such as generating a first intra-prediction merging candidate list for fusing intra-prediction merging modes (e.g., where the first intra-prediction merging candidate list can be generated by adding at least one of adjacent spatial neighbor intra-fusion candidates and / or non-adjacent spatial neighbor candidates); adding history-based fusion candidates associated with the current block to a history-based fusion (HFI) table; generating a second intra-prediction merging candidate list (e.g., where the second intra-prediction merging candidate list can be generated by adding one of the history-based fusion candidates from the HFI table to the first intra-prediction merging candidate list); encoding the current block using intra-prediction merging candidates from the second intra-prediction merging candidate list, etc.

[0116] As another example, 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. It will be clear from the specific context of the description whether the phrase "encoding process" is intended to refer specifically to a subset of operations or to a broader encoding process, and it is believed that those skilled in the art will understand this well.

[0117] It should be noted that the names of syntactic elements used in this article (such as, timdIsBlend,ph_temporal_mvp_ enabled_flag, ph_collocated_ref_idx, ph_collocated_from_l0_flag, sh_collocated_ from_l0_flag, sh_collocated_ref_idx (etc.) are descriptive terms only. Therefore, the use of other syntactic element names is not excluded.

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

[0119] The implementations and aspects described herein can be implemented in, for example, methods or processes, apparatuses, software programs, data streams, or signals. Even if discussed only in the context of a single implementation (e.g., discussed only as a method), the implementation of the features in question can be implemented in other forms (e.g., apparatuses or programs). Apparatuses can be implemented, for example, with appropriate hardware, software, and firmware. Methods can be implemented in, for example, 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.

[0120] The reference to “an example” or “an example” or “an implementation” or “an implementation”, and their variations, means that the specific features, structures, characteristics, etc., described in connection with the example are included in at least one example. Therefore, the phrases “in an example” or “in the example” or “in an implementation” or “in the implementation”, and any other variations, appearing throughout this application, do not necessarily refer to the same example.

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

[0122] 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 information from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, and estimating information.

[0123] Additionally, this application may relate to "receiving" various types of information. Like "accessing," receiving is a broad term. Receiving information may include one or more of the following: for example, accessing information and retrieving information (e.g., retrieving information 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.

[0124] It should be understood that the use of any of the following “ / ”, “and / or”, and “…” (e.g., in the cases of “A / B”, “A and / or B”, and “at least one of A and B”) 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.

[0125] Furthermore, as used herein, the phrase "signaling" specifically refers to instructing the corresponding decoder to provide certain information. Encoder signals may include, for example, residual signals, metadata, encoding or motion representation modes and associated signals (e.g., DIMD merge mode, TIMD merge mode, ITMP, LIC flags), partitioning modes, reference frames, motion vector predictors (MVP), motion vector differences (MVD), indices, candidate lists, HFI table sizes, etc. In this way, in the examples, the same parameters are used on both the encoder and decoder sides. Therefore, for example, the encoder can send (explicit signaling) specific parameters to the decoder so that the decoder can use the same specific parameters. Conversely, if the decoder already has specific parameters as well as other parameters, signaling can be used without sending (implicit signaling) to simply allow the decoder to know and select specific parameters. Bit savings are achieved in various examples 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 syntax elements, flags, etc., are used to signal information to the corresponding decoder. Although the verb form of the word "signal" was mentioned earlier, the word "signal" can also be used as a noun in this article.

[0126] As will be apparent to those skilled in the art, implementations can generate various signals, which are formatted to carry, for example, information that can be stored or transmitted. The 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 the 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.

[0127] 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, and the encoder, bitstream, and / or decoder may be 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, cellular phone, tablet computer, or other electronic device performing decoding. The TV, set-top box, cellular phone, tablet computer, or other electronic device may (e.g., using a monitor, screen, or other type of display) display the resulting image (e.g., an image reconstructed from the residual of a video bitstream). The TV, set-top box, cellular phone, tablet computer, or other electronic device may receive a signal including the encoded image and perform decoding.

[0128] The lists of TIMD merge candidates and DIMD merge candidates can be improved, for example, by performing one or more of the following: 1) including history-based merge candidates and / or temporal merge candidates; 2) recalculating (e.g., each) the merge weights of TIMD merge candidates; 3) inheriting non-angular patterns and associated merge weights for TIMD merge candidates; and 4) adapting the number of allowed merge candidates for TIMD merge and / or DIMD merge modes according to the encoding information of the current block.

[0129] Template-based intra-mode derivation (TIMD) can rely on the following assumption: if an intra-prediction mode generates the highest quality prediction of a template of reconstructed pixels around a given block to be predicted, then that intra-prediction mode is most likely to produce the highest quality prediction of that block.

[0130] For a given block predicted via TIMD, inference of the intra-prediction mode index may include performing a multi-round (e.g., three (3) rounds) mode test on a template of reconstructed pixels around the block in terms of prediction. The test may use the sum of absolute transform differences (SATD).

[0131] Figure 5 This illustrates an example of intra-prediction mode index inference for blocks predicted via TIMD. For example... Figure 5 As shown, during the first round of testing, for a given Block (1000), for list The intra-prediction modes in the frame (e.g., each) are indexed (e.g., a list of most probable modes (MPMs) for block (1000), supplemented by a default index in (DC_IDX, HOR_IDX, VER_IDX) if the index is not already present in the MPM list). The mode calculates the prediction of template (1001, 1002) based on a reference sample set (1003) of templates (1001, 1002) surrounding the reconstructed pixels of block (1000), and the SATD between template (1001, 1002) and its prediction can be calculated. Two intra-prediction modes with the minimum template prediction SATD can be retained.

[0132] During the second round of testing, for example for several extended wide-angle intra-prediction modes, each mode computes a prediction of template (1001, 1002) based on a reference sample (1003), and the SATD between template (1001, 1002) and its prediction can be computed. Intra-prediction modes with the minimum template prediction SATD (e.g., two) can be updated.

[0133] During the third round of testing, for each of the (e.g., two) intra-prediction modes retained from the second round, if the mode is neither PLANA nor DC, the (e.g., also) closest directional intra-prediction modes can be tested on templates (1001, 1002), for example, in terms of predicting SATD. (e.g., if needed) the (e.g., two) intra-prediction modes with the smallest template prediction SATD can be updated.

[0134] Mixing conditions can be defined. If timdIsBlend represents a flag indicating whether TIMD mixing is applicable, and satd0 and satd1 represent the minimum prediction SATD and the second smallest prediction SATD, respectively, then the flag indicating whether TIMD mixing is applicable (e.g., timdIsBlend) can be determined, for example, as follows:

[0135] If timdIsBlend is false, the final prediction of the current block, based on its reference sample set, can be performed using the first reserved intra-prediction mode. Otherwise, the final prediction of the current block can be obtained by blending (e.g., two) predictions of the block via the first reserved intra-prediction mode and the second reserved intra-prediction mode, respectively. The blending weights may depend on the minimum prediction SATD and the second minimum prediction SATD (e.g., satd0 and satd1).

[0136] Additional non-angle and position-dependent TIMDs may exist. During the step of inferring the intra-prediction mode index, for example before the first round, PLANA and DC can be tested on a template of reconstructed pixels around a given block, such as in the prediction of SATD. A minimum prediction can be saved. Index of non-angular intra-frame prediction modes Then, after the third round, if Unlike (e.g., two) the indexes of the preserved intra-prediction modes, and if Then, during subsequent operations to generate the final prediction for a given block, the final prediction can be obtained from a mixture of: (e.g., two) predictions of the block via a first reserved intra-prediction mode and a second reserved intra-prediction mode, respectively, and via an indexed... The intra-frame prediction mode is used to mix the predictions for the block. The mixing weights may depend on, for example... , and .

[0137] TIMD merging patterns can be inherited from previously TIMD-encoded blocks. Neighboring and non-neighboring spatially adjacent blocks can be scanned, for example, to determine whether the scanned blocks are encoded using a TIMD merging pattern or a TIMD merging scheme. TIMD information (e.g., prediction mode, merging flag, merging weights, and / or wide-angle conditions of the TIMD pattern) of blocks encoded using a TIMD merging pattern or a TIMD merging scheme can be added to the TIMD merging list. One or more pairs (e.g., up to 10 TIMD pairs) can be added to the list, as shown in Table 1, for example. Figure 6 This shows an example of a non-adjacent spatial neighbor block that can be used in TIMD merge list generation.

[0138] Table 1 - Example of an initial TIMD merge list

[0139] For example, the merge candidates in the TIMD merge list can be sorted based on the SATD cost on the template of the current block. For cost calculation, the SATD cost of a pair of TIMD modes can be normalized, for example, using their fusion weights. For example, if a merge candidate has two intra-prediction modes (IPM1, IPM2) and fusion weights (W1, W2), the candidate's cost can be calculated, for example, as follows:

[0140] Template size and template cost calculations can be performed similarly to those in the TIMD pattern, for example. After sorting the TIMD merged candidates, the best candidates (e.g., two) can be selected from the sorted list for encoder rate-distortion optimization (RDO). On the encoder side, the best candidates (e.g., two) can be passed to a SATD-based sort. The best-performing candidate (e.g., one of the two) can be selected and used for full RD.

[0141] For example, a PU-level flag encoded with context-adaptive binary arithmetic (CABAC) can be used to signal the use of the TIMD merge mode. The TIMD merge mode can be used as a sub-mode of the TIMD tool. In the example, if / when the TIMD merge mode is enabled, the CABAC-encoded index can be signaled (e.g., also) to indicate whether the first or second candidate (e.g., from the TIMD merge list) has been used.

[0142] Decoder-side intra-mode derivation (DIMD) can rely on the assumption that the reconstructed pixels around a given block to be predicted carry information for inferring the texture orientation in the block (e.g., the intra-prediction mode that is most likely to generate the highest quality prediction).

[0143] Gradients can be extracted from the context of the reconstructed pixels surrounding the block. These gradients can be used to fill the Histogram of Gradients (HoG). The intra-frame prediction mode most likely to give the highest quality prediction can be derived from the HoG. Intra-frame modes (e.g., up to five intra-frame modes) can be derived from reconstructed neighboring samples. (e.g., five) predictors can be combined with planar mode predictors (e.g., combined with combination weights derived from the HoG).

[0144] HoG can be calculated, for example, on an L-shaped template with three sample widths / heights formed by reconstructed samples. For example... Figure 7 As shown, HoG can be constructed, for example, by accumulating the magnitude of the gradients of all samples within the upper left region (e.g., light gray region), the upper region (e.g., dark gray region), and the left left region (e.g., black region). Figure 7 An example of calculating HoG based on an L-shaped template formed from reconstructed samples is shown.

[0145] DIMD merging modes may include merging HoGs of neighboring blocks to derive DIMD information. Non-adjacent surrounding areas (e.g., such as...) Figure 6The DIMD information of the CUs (e.g., up to 31 CUs) shown can be used to derive the merged HoG (MHoG). The MHoG can be used to derive intra-prediction modes and weights, as can be done in conventional DIMD. Directional modes and corresponding weights corresponding to the five highest amplitudes in the MHoG can be selected. The corresponding predictors can be mixed, as can be done in conventional DIMD. A low-storage version of DIMD merging can be achieved, for example, by storing and averaging the five highest amplitudes of the histogram.

[0146] Figure 8 This example illustrates spatial neighbors that can provide DIMD information for DIMD merge patterns. The list of DIMD merge patterns can include DIMD information from neighboring blocks, which may include one or more of the following: DIMD information from spatial neighbors (e.g., such as...). Figure 8 As shown); DIMD information from non-adjacent neighbors (e.g., as shown) Figure 6 (as shown); and / or DIMD information derived from MHoG.

[0147] Redundancy checks can be applied, for example, during the pruning phase (e.g., two redundancy checks). For instance, one redundancy check can be compared with DIMD merge candidates, and another redundancy check can be compared with DIMD information derived from the current block. For example, if / when the associated DIMD information differs from the information already existing in the list from DIMD merge candidates and the current block's DIMD information, a DIMD merge candidate can be added to the DIMD merge list.

[0148] Flags (e.g., two flags) may depend on DIMD flags. A DIMD merge pattern can be considered a sub-pattern of a DIMD. (e.g., two) conditional flags may include one or more of the following, such as: a DIMD merge pattern flag; and / or a DIMD merge pattern index representing a DIMD merge candidate.

[0149] For example, if the current block has at least one neighbor encoded in DIMD or DIMD merge mode, DIMD merge mode may be available as an option. Neighborhood regions may be expanded, for example, to include portions of non-adjacent candidates.

[0150] In the example, if / when the DIMD merging mode is available, a list of DIMD merging candidates can be derived on both the encoder and decoder sides. On the encoder side, each candidate can be evaluated, for example, using a Hadamard traversal and an RDO loop, to determine whether the associated Hadamard-based cost is competitive.

[0151] For example, if the associated costs are not competitive compared to other models, the DIMD merger candidate can be discarded.

[0152] (For example, in addition to TIMD and DIMD information from spatial neighbors) TIMD and DIMD information from (e.g., selected) historical and / or temporal candidates can be considered for constructing lists of TIMD merging and DIMD merging candidates, for example, to further improve (e.g., accuracy and / or compression) performance.

[0153] One or more improvements can be implemented to further enhance the performance of TIMD and DIMD merge modes. TIMD merge candidates and DIMD merge candidates can be improved, for example, as described herein. In some examples, history-based fusion candidates can be included to construct a list of merge candidates for TIMD and / or DIMD merge modes. In some examples, temporal fusion candidates can be included to construct a list of merge candidates for TIMD and / or DIMD merge modes. In some examples, the fusion weights for each TIMD merge candidate can be recalculated. In some examples, non-angular modes and their associated fusion weights can be inherited for TIMD merge candidates (e.g., if this information is available). In some examples, for example, the number of allowed merge candidates for TIMD and / or DIMD merge modes can be adapted based on the encoding information of the current block.

[0154] History-based fusion intra-cancellation candidates may be included to construct a list of fusion candidates for fusing intra-prediction fusion modes (e.g., TIMD and / or DIMD fusion modes). In some examples, the intra-prediction modes and / or association information of previously fused intra-coded blocks (e.g., TIMD and / or DIMD intra-coded blocks that are distant from the current block) may be considered as history-based fusion candidates. Multiple history-based fusion candidates may be stored in a table (e.g., with a finite number of candidates). This table may be referred to as a history-based fusion (HFI) table. The table may be maintained during the encoding / decoding process (e.g., in real time).

[0155] Figure 9 A flowchart is shown as an example of the process of constructing a list of TIMD merge / DIMD merge candidates using HFI candidates. Figure 9 As shown, at S101, spatially adjacent intra-frame fusion candidates can be added to the merging list. At S102, non-adjacent spatially adjacent intra-frame fusion candidates can be added to the merging list. At S103, (e.g., then) history-based fusion candidates from the HFI table can be added to the merging list (e.g., if it is not full). For example, a pruning operation can be applied to avoid including redundant fusion intra-frame prediction modes and / or association information in the list.

[0156] Figure 10A flowchart is shown, illustrating an example of an encoding process associated with adding HFI candidates and associated information to the HFI table. For example, if / when encoding / decoding a new CTU begins, the HFI table may be reset (e.g., cleared). For example, if / when fused intra-coded blocks (e.g., TIMD and / or DIMD intra-coded blocks) exist, new HFI candidates may be added to the HFI table. For example, intra-prediction mode pairs / sets of the fused intra-coded blocks and other associated information may be added as (e.g., last) entries to the table as new HFI candidates. An example of the overall encoding process is shown in... Figure 10 It is described in the text.

[0157] The HFI table size can be set to a predefined value, for example. (For example, ), which can indicate the most Several HFI candidates can be added to the table. For example, if there are more than... If there are HFI candidates from previously encoded blocks, then FIFO rules can be applied. For example, FIFO rules can be applied such that the table (e.g., always) includes the latest... A previously encoded intra-prediction mode candidate. If / when an HFI candidate is added to the HFI table, a redundancy check is performed, for example, to determine if an identical HFI candidate exists in the table. Identical HFI candidates found in the HFI table can be removed or repositioned. In some examples, HFI candidates following the removed identical candidates can be moved forward, with the index decremented by one (1). Identical HFIs can be inserted as the last entry in the table. If in a size of If no redundancy is found in the full HFI table, the first HFI candidate can be removed, all other HFI candidates can be moved forward in the HFI table, and the new HFI candidate can be appended to the end of the table.

[0158] Figure 11 This illustrates an example of applying FIFO rules to a full HFI table (e.g., to remove HFI candidates from the HFI table, thereby adding new HFI candidates to the HFI table). Figure 11 As shown in the example, suppose the table has There are HFI candidates, denoted as ,in Can represent HFI candidate indices, and where Can be within range Inside. When adding, it is represented as When creating new HFI candidates, the new HFI candidates can be compared with (for example, all) existing HFI candidates. If For example with If they are the same, then the indexes of more than two (2) (e.g., all) HFI candidates can be moved forward to the head of the HFI table (e.g., removed from the HFI table). ), and new HFI candidates It can be appended to the end of the HFI table.

[0159] In some examples, an HFI table can be constructed or generated based on the occurrence counts of HFI candidates in the HFI table. When a new HFI is appended to the table, a redundancy check can be performed, for example, to determine if identical HFI candidates exist in the table. If redundant candidate entries are found in the HFI table, the counts of identical HFI candidates in the HFI table can be accumulated (e.g., to maintain the popularity of identical candidates), and the current HFI table can be rearranged. For example, if the occurrence count of a new HFI candidate is higher than the occurrence count of the last entry in the current HFI table, the new HFI candidate can be moved to the last entry of the HFI table. Based on the occurrence count indicating that it appears more often in the HFI table than other HFI candidates in the HFI table, the HFI candidate in the last entry of the table can be considered "most popular". If no redundancy is found and the size is... If the HFI table is full, the first HFI candidate can be removed, and all other HFI candidates with the same occurrence count as the new HFI can be moved forward. The new HFI candidate can be added (e.g., inserted or appended) to the HFI table, placing it before other candidates with higher occurrence counts in the table (e.g., so that the "lowest-hot" HFI candidate may be at the top of the HFI table).

[0160] In some examples, more than one HFI table can be built for the fused intra-prediction merging mode. For example, separate HFI tables can be generated for TIMD merging mode and DIMD merging mode.

[0161] TIMD merging modes can inherit associated information from previously encoded TIMDs or TIMD-merged encoded blocks (e.g., merging flags, intra-modes, merging weights, and / or wide-angle conditions of the TIMD mode). For example, each TIMD merging candidate can store a pair of intra-modes and a pair of merging weights (e.g., in an HFI table), as shown in the example in Table 2. The same TIMD information (e.g., a pair of intra-modes and a pair of merging weights) can be stored for each history-based merging candidate used for TIMD merging.

[0162] DIMD merging patterns can inherit associated information from previously encoded DIMDs or blocks encoded via DIMD merging (e.g., merging flags, intra-modes, merging weights, gradient histograms (HoGs), and / or location-related conditions of the DIMD patterns). For example, (e.g., each) DIMD merging candidate can (e.g., in an HFI table) store a set of intra-modes (e.g., five (5) intra-modes), a set of merging weights (e.g., five (5) weights, one of which may be associated with an intra-mode), and a set of HoGs (e.g., five (5) HoGs, one of which may be associated with an intra-mode), as illustrated in the example in Table 2. In the example, the same DIMD information (e.g., a set of intra-modes, a set of merging weights, and a set of HoGs) can be stored for (e.g., each) history-based merging candidate used for DIMD merging.

[0163] Table 2 - Example of an initial DIMD merge list

[0164] For example, if / when starting on a new tile / slice / sub-picture / frame or (e.g., a) predefined region (e.g., , When encoding / decoding, the HFI table can be reset (e.g., cleared).

[0165] In the example, the HFI table size The values ​​can be (predefined) and fixed for (e.g., all) sequences, or the HFI table size can be signaled, for example, by a View Parameter Set (VPS), Sequence Parameter Set (SPS), Picture Parameter Set (PPS), Adaptive Parameter Set (APS), and / or Picture Header (PH). The value of .

[0166] In non-I slices (e.g., B and / or P slices), temporal fusion intra-slice candidates can be used to construct a list of fusion candidates for fusing intra-prediction fusion modes (e.g., TIMD and / or DIMD fusion modes).

[0167] If / when the juxtaposed block of the current block in the juxtaposed frame is DIMD intra-coded, the association information of the juxtaposed block can be added as a temporary fusion candidate to the merge candidate list. For example, if the association information does not yet exist in the merge list, the temporary fusion candidate can be tested for the current block.

[0168] Figure 12 A flowchart is shown, illustrating an example of the process of constructing a list of TIMD merge / DIMD merge candidates using temporal intra-frame fusion candidates. For example... Figure 12As shown, at S201, spatially adjacent intra-frame fusion candidates can be added to the merging list. At S202, non-adjacent spatially adjacent intra-frame fusion candidates can be added to the merging list. At S203, temporal intra-frame fusion candidates can be added to the merging list (e.g., if the merging list is not full after including spatially adjacent and spatially non-adjacent candidates at S201 and S202, respectively). One or more pruning operations can be applied to the merging list, for example, to avoid including redundant fused intra-frame prediction modes and / or association information in the list.

[0169] For example (e.g., only if / when Temporal Motion Vector Prediction (TMVP) is enabled), juxtaposed frames can be defined. In some examples, if / when ph_temporal_mvp_enabled_flag When equal to 1 (1), TMVP can be enabled. A juxtaposed screen can be specified, for example, as follows: at the start of decoding (e.g., each) P or B slice (e.g., after decoding the slice header, e.g., after calculating the reference screen list for the current slice), the juxtaposed screen can be determined to have a screen header syntax element that may be equal to the parsed screen header. ph_collocated_ref_idx The reference screen for the index (e.g., in the screen header syntax element) ph_ collocated_from_I0_flag (In the reference screen list L0 or L1). Slice header syntax elements. sh_ collocated_from_I0_flag and sh_collocated_ref_idx It can be used to identify the juxtaposed frames of the current frame, for example, if two syntax elements (e.g., ph_collocated_from_I0_flag and ph_collocated_ref_idx It does not exist in the image header.

[0170] In some examples, one or more temporal fusion candidates may be searched at one or more locations (e.g., in addition to the location of the juxtaposition block) and may be included in a fusion candidate list for fusing intra-frame prediction fusion modes. Figure 13 This illustrates an example of searching for multiple temporal fusion candidates at multiple locations. For example, ... Figure 13 As shown in the example, for example in the following order: C01 C02 … C010 can search multiple locations from juxtaposed screens (e.g., ... Figure 13 Of the 10 locations depicted, C1i can be used to replace C0i if C01 is unavailable (e.g., if C0i's location is outside the frame / slice boundary or outside the current CTU line) and C1i is available. If neither C0i nor C1i is available, then check the next included location, and so on.

[0171] In some examples, one or more offset temporal fusion candidates can be searched and included in a fusion candidate list for fusing intra-frame prediction fusion modes. Figure 14 This illustrates an example of searching for multiple offset temporal fusion candidates at multiple offset locations. For example, such as... Figure 14 As shown in the example, the position of the juxtaposed block can be offset by a selected neighboring motion vector, such that the positions of C0i and C1i can therefore be offset by the same neighboring motion vector. The inclusion order of the offset temporal candidates can, for example, be the same as the inclusion order of the temporal candidates. A neighboring motion vector can be selected, for example, from the motion vectors of neighboring blocks, such as... Figure 14 The described order of checks can be as follows: L0B1 L1B1 L0A1 L1A1 L0B0 L1B0 L0A0 L1A0 L0B2 L1B2. Optionally, a motion vector can be used as the reference frame (e.g., the first one). For example, if no such motion vector is found using the juxtaposed frame as the reference frame, then no temporal fusion candidate may be added.

[0172] The prediction quality of TIMD and DIMD merge patterns can be improved, for example, by modifying inherited association information, to better fit the current block. For example, the fusion weights of each TIMD merge candidate can be recalculated. Fusion weights from previously encoded TIMDs or blocks encoded with TIMD merges may not be stored as part of the TIMD information used to construct the TIMD merge list. In some examples (e.g., after forming the TIMD merge list), fusion weights can be calculated based on the SATD cost on the current block template. Template size and template cost calculations can be, for example, the same as in the TIMD pattern. For example, after regenerating the fusion weights of each TIMD merge candidate, one or more pruning operations can be applied, for example, to avoid including redundant association information in the include list. Candidates (e.g., two candidates) can be fed into a sort (e.g., SATD-based sorting) (e.g., after regenerating the fusion weights). The best-performing candidate among the two can be selected at the encoder and used for the full RD.

[0173] Non-angular mode and associated fusion weights can be inherited for TIMD merge candidates (e.g., if this information is available). TIMD information (e.g., plus non-angular intra-frame mode and associated fusion weights) can be stored and adapted for one or more candidate TIMD merges, as shown in the examples in Table 3.

[0174] Table 3 - Example of a TIMD merge list

[0175] In some examples, such as based on the coding information of the current block, the number of allowed merging candidates for the fused intra-prediction merging mode (e.g., TIMD and / or DIMD merging mode) that can be used for the current block can be adapted. For example, the coding information may be size information (e.g., height, width, height-to-width ratio, block surface area), color components, intra-coding mode (e.g., multiple reference lines (MRL), intra-sub-block prediction (ISP)), quantization parameters, transform mode (e.g., transform skip mode, non-transform skip mode, explicit multiple transform set (MTS) mode, implicit MTS mode, different MTS types, low-frequency inseparable transform (LFNST), inseparable master transform (NSPT)), sequence type, configuration set of the current block, etc.

[0176] Although the features and elements are described in the specific combinations above, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage 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 discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A video decoding device, comprising: The processor is configured as follows: A first intra-prediction merging candidate list is generated for fusing intra-prediction merging modes, wherein the first intra-prediction merging candidate list is generated by adding at least one of adjacent spatial neighbor intra-fusion candidates and non-adjacent spatial neighbor candidates. Add multiple history-based fusion candidates associated with the current block to the history-based fusion HFI table; A second intra-frame prediction merging candidate list is generated, wherein the second intra-frame prediction merging candidate list is generated by adding one of the plurality of history-based fusion candidates from the HFI table to the first intra-frame prediction merging candidate list. as well as The current block is decoded using intra-prediction merge candidates from the second intra-prediction merge candidate list.

2. The video decoding device according to claim 1, wherein the processor is configured to: Determine whether the history-based fusion candidate is the same as one of the plurality of history-based fusion candidates in the HFI table; Based on the determination that the history-based fusion candidate is the same as one of the plurality of history-based fusion candidates in the HFI table, the HFI candidate is removed from the HFI table and all HFI candidates after the removed HFI candidate are shifted one position. as well as Based on the determination that the history-based fusion candidate is different from one of the plurality of history-based fusion candidates in the HFI table, the first history-based fusion candidate in the HFI table is removed, each of the remaining history-based fusion candidates in the HFI table is shifted forward one position, and the history-based fusion candidate is added to the last position of the HFI table.

3. The video decoding device of claim 1, wherein the processor is configured to add a plurality of intra-frame prediction modes and information associated with the plurality of intra-frame prediction modes as the last entry in the HFI table.

4. The video decoding device of claim 1, wherein the processor is further configured to: include temporal fusion candidates to generate a third intra-frame prediction merging candidate list, wherein the third intra-frame prediction merging candidate list is used for at least one of template-based intra-frame mode derivation TIMD merging mode and decoder-side intra-frame mode derivation DIMD merging mode.

5. The video decoding device according to claim 1, wherein the processor is further configured to: adapt the number of allowed merge candidates for template-based intra-frame mode derivation TIMD merge mode or decoder-side intra-frame mode derivation DIMD merge mode based on the encoding information of the current block.

6. The video decoding apparatus of claim 1, wherein the processor is configured to: derive TIMD merging candidate inherited non-angle modes and a set of fusion weights associated with the non-angle modes for template-based intra-frame modes.

7. A video decoding method, comprising: A first intra-prediction merging candidate list is generated for fusing intra-prediction merging modes, wherein the first intra-prediction merging candidate list is generated by adding at least one of adjacent spatial neighbor intra-fusion candidates and non-adjacent spatial neighbor candidates. Add multiple history-based fusion candidates associated with the current block to the history-based fusion HFI table; A second intra-frame prediction merging candidate list is generated, wherein the second intra-frame prediction merging candidate list is generated by adding one of the plurality of history-based fusion candidates from the HFI table to the first intra-frame prediction merging candidate list. as well as The current block is decoded using intra-prediction merge candidates from the second intra-prediction merge candidate list.

8. The method according to claim 7, further comprising: Determine whether the history-based fusion candidate is the same as one of the plurality of history-based fusion candidates in the HFI table; Based on the determination that the history-based fusion candidate is the same as one of the plurality of history-based fusion candidates in the HFI table, the HFI candidate is removed from the HFI table and all HFI candidates after the removed HFI candidate are shifted one position. as well as Based on the determination that the history-based fusion candidate is different from one of the plurality of history-based fusion candidates in the HFI table, the first history-based fusion candidate in the HFI table is removed, each of the remaining history-based fusion candidates in the HFI table is shifted forward one position, and the history-based fusion candidate is added to the last position of the HFI table.

9. The method according to claim 7, further comprising: Multiple intra-prediction modes and the information associated with the multiple intra-prediction modes are added as the last entry in the HFI table.

10. The method of claim 7, further comprising: The method includes temporal fusion candidates to generate a third intra-frame prediction merging candidate list, wherein the third intra-frame prediction merging candidate list is used for at least one of template-based intra-frame mode derivation TIMD merging mode and decoder-side intra-frame mode derivation DIMD merging mode.

11. The method of claim 7, further comprising: The number of allowed merge candidates is adapted based on the encoding information of the current block for template-based intra-mode derivation of TIMD merge mode or decoder-side intra-mode derivation of DIMD merge mode.

12. The video decoding device according to claim 1, further comprising: The template-based intra-frame mode is used to derive TIMD merging candidate inherited non-angle modes and a set of fusion weights associated with the non-angle modes.

13. The video decoding device according to claim 1 or the video decoding method according to claim 7, wherein the HFI table is generated based on the historical fusion candidate count in the HFI table.

14. The video decoding device according to claim 1 or the video decoding method according to claim 7, wherein the HFI table is reset when decoding of a new coding tree unit (CTU), region, tile, slice, sub-picture, or frame begins.

15. The video decoding device according to claim 1 or the video decoding method according to claim 7, wherein the fused intra-prediction merging mode includes at least one of template-based intra-mode derivation (TIMD) mode and decoder-side intra-mode derivation (DIMD) mode.

Images