Interactive signaling to cancel energy saving decoder operation reduction

Abstract

Systems, methods, and apparatus are disclosed for interactive signaling for canceling energy saving decoder operation reduction. An example device may send a first request to a video encoding device indicating a first power reduction type value associated with enabling a first energy saving feature and a second energy saving feature. The device may detect an event associated with cancelling the energy saving feature. In response to detecting the event, the device may send a second request to the video encoding device indicating a second power reduction type value associated with cancelling the second energy saving feature. The first power reduction type value and the second power reduction type value may be different. The device may decode a current block based on the first energy saving feature.

Description

Interactive signaling for canceling the reduced operation of the energy-saving decoder.

[0001] Cross-reference to related applications This application claims the benefit of European patent application 23306717.2 filed on 5 October 2023 and European patent application 23306757.8 filed on 10 October 2023, the disclosures 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 and / or transmission bandwidth required for such signals. Video coding systems can include, for example, block-based, wavelet-based, and / or object-based systems. Summary of the Invention

[0003] Systems, methods, and instruments for interactive signaling used to cancel energy-saving decoding operation reduction are disclosed. Example devices may have a processor configured to perform one or more actions.

[0004] A device (e.g., a video decoding device) may send a first request to a video encoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature. The device may detect an event associated with disabling an energy-saving feature. In response to detecting the event, the device may send a second request to the video encoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature. The first power reduction type value and the second power reduction type value may be different. The device may decode the current block based on the first energy-saving feature.

[0005] The device may send a third request indicating a third power reduction type value associated with enabling a third energy-saving feature. Decoding the current block may be further based on the third energy-saving feature. The device may detect a third event associated with enabling the energy-saving feature. Sending the first request may be in response to detecting the third event.

[0006] The current block may be a first current block. The event associated with canceling the energy-saving feature may be a first event associated with canceling the energy-saving feature. The device may send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling the first, second, and third energy-saving features. The device may detect a second event associated with canceling the energy-saving feature. In response to detecting the second event, the device may send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with canceling the first and third energy-saving features. The device may decode the second current block based on the second energy-saving feature.

[0007] The device may send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling multiple energy-saving features. The device may send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with disabling all enabled energy-saving features. The device may decode the second current block.

[0008] The device may send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature and the second energy-saving feature. The device may detect a second event associated with disabling the energy-saving feature. In response to detecting the second event, the device may send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature and the second energy-saving feature. The device may decode a second current block.

[0009] An event that could be associated with canceling energy-saving features is that the power level is above a threshold.

[0010] An example device (e.g., a video encoding device) can receive a first request from a video decoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature. Based on the first request, the device can enable the first energy-saving feature and the second energy-saving feature. The device can receive a second request from the video decoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature. The first power reduction type value and the second power reduction type value may be different. Based on the second request, the device can disable the second energy-saving feature. The device can encode the current block based on the first energy-saving feature.

[0011] The device may receive a third request indicating a third power reduction type value associated with enabling a third energy-saving feature. Encoding the current block may be further based on the third energy-saving feature.

[0012] The current block may be a first current block. The device may receive a third request from the video decoding device, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature. Based on the third request, the device may enable the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature. The device may encode a second current block based on the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature. The device may receive a fourth request from the video decoding device, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature and the third energy-saving feature. Based on the fourth request, the device may disable the first energy-saving feature and the third energy-saving feature. The device may encode the second current block based on the second energy-saving feature.

[0013] The device may receive a third request from the video decoding device, the third request indicating multiple energy-saving features. The device may enable the multiple energy-saving features. The device may encode a second current block based on the multiple energy-saving features. The device may receive a fourth request from the video decoding device, the fourth request indicating a fourth power reduction type value associated with canceling the multiple energy-saving features. The device may disable the multiple energy-saving features. The device may encode a third current block.

[0014] The device may receive a third request from the video decoding device, the third request indicating a third power reduction type value associated with enabling the second and third energy-saving features. The device may enable the second and third energy-saving features. The device may encode a second current block based on the first, second, and third energy-saving features. The device may receive a fourth request from the video decoding device, the fourth request indicating a fourth power reduction type value associated with disabling the first, second, and third energy-saving features. The device may disable the first, second, and third energy-saving features. The device may encode a third current block.

[0015] The first energy-saving feature may be: adjusting one or more parameters associated with encoder operation; disabling one or more encoding tools; or adjusting image resolution and video frame rate.

[0016] The device (e.g., a decoder, such as a video decoder) can detect a first event associated with a power level below a threshold. Based on detecting the first event, the device can send a first request to a video encoding device, the first request indicating a first power reduction type value associated with enabling an energy-saving feature. The device can detect a second event associated with a power level above the threshold. Based on detecting the second event, the device can send a second request to the video encoding device, the second request indicating a second power reduction type value associated with disabling at least a portion of the energy-saving feature. The device can decode the current block based on the remaining portion of the energy-saving feature, if any.

[0017] The threshold can be a first threshold that is less than the second threshold. Energy saving can be a first energy saving feature. Before detecting the first event, the device can: detect a third event associated with the power level being below the second threshold; and based on the detection of the third event, send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling the second energy saving feature. The second power reduction type value can, for the video encoding device, indicate disabling the first energy saving feature and continuing to use the second energy saving feature. Decoding the current block can be further based on the second energy saving feature.

[0018] An example device (e.g., an encoder, such as a video encoder) can receive a first request from a video decoding device, the first request indicating a first power reduction type value associated with enabling an energy-saving feature. The device can enable the energy-saving feature based on the first request. The device can receive a second request from the video decoding device, the second request indicating a second power reduction type value associated with disabling at least a portion of the energy-saving feature. The device can disable said at least a portion of the energy-saving feature based on the second request. The device can encode the current block based on the remaining portion of the energy-saving feature, if any.

[0019] The device may receive a third request from the video decoding device before receiving the first request. This third request indicates a third power reduction type value associated with enabling the second energy-saving feature. The second power reduction type value may, for the video encoding device, indicate disabling the first energy-saving feature and continuing to use the second energy-saving feature. Encoding of the current block may be further based on the second energy-saving feature.

[0020] The energy-saving feature may be associated with an identifier. The second request may further indicate the identifier. The second request may further include metadata indicating at least a portion of the energy-saving feature.

[0021] A second power reduction type value associated with disabling at least a portion of the energy-saving feature may include a request to cancel at least one of the following: all components of the energy-saving feature; multiple decoding operations associated with the energy-saving feature; disabling loop filter tools; disabling bidirectional prediction in one or more slices; disabling intra-frame prediction in one or more slices; disabling fractional pixel filtering in one or more slices; image resolution modification in luminance samples; or image frame rate modification.

[0022] A second request indicating a second power reduction type value associated with at least a portion of the energy-saving feature may be a request to cancel multiple previous requests for the second power reduction type. Attached Figure Description

[0023] Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

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

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

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

[0027] Figure 2 illustrates an example video encoder.

[0028] Figure 3 illustrates an example video decoder.

[0029] Figure 4 illustrates an example of a system that can implement various aspects and examples.

[0030] Figure 5 illustrates an example of the functional architecture for the transmitter and receiver.

[0031] Figure 6 illustrates an example of decoder operation reduction (e.g., using cancel interactive signaling).

[0032] Figure 7 illustrates an example of the encoder-side response to a global cancellation request.

[0033] Figure 8 illustrates an example of an encoder-side response to a partial cancellation request.

[0034] Figure 9 illustrates an example of decoder-side operation cancellation. Detailed Implementation

[0035] A more detailed understanding can be obtained from the following description, which is given in conjunction with the accompanying drawings as examples.

[0036] Figure 1A is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0037] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. Although it will be appreciated, 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. As an 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 industrial and / or automated processing chain scenarios), 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.

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

[0039] 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area for a radio service, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0040] 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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0041] More specifically, as noted above, 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, and 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).

[0042] In one 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 Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

[0044] In one embodiment, 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 jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized 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).

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

[0046] Base station 114b in Figure 1A can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial location, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, 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 one 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 a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not be required to access Internet 110 via CN 106 / 115.

[0047] 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, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting to RAN 104 / 113 which can utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technology.

[0048] CN 106 / 115 may also act 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.

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

[0050] Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments.

[0051] 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 depicts processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or on a chip.

[0052] 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 one 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 and optical signals. It will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

[0055] The processor 118 of WTRU 102 can be coupled to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132), and store data in that memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), 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, processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0056] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control the power going to other components in the WTRU 102. The power supply 134 can 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.

[0057] 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 the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0058] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripherals 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. Peripherals 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.

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

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

[0061] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although 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, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0062] 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, and user scheduling in the UL and / or DL. As shown in Figure 1C, the eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0064] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN104 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, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can provide control plane functions for handover between RAN104 and other RANs (not shown) employing other radio technologies, such as GSM and / or WCDMA.

[0065] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

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

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

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

[0070] In an Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic from a STA to 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 source and destination STAs (e.g., directly between them) using a direct link setup (DLS). 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 or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0071] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel, such as a 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 STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can back off. A STA (e.g., only one station) can transmit at any given time within a given BSS.

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

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

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

[0075] 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 STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation 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 1MHz operating mode) is transmitting to the AP, the entire available band may be considered busy, even if most of the band is still idle and could be available.

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

[0077] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As noted 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.

[0078] RAN 113 may include gNBs 180a, 180b, and 180c, although 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. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0080] 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 also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility 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 with / connect to gNBs 180a, 180b, and 180c, and simultaneously communicate with / connect to 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-B 160a, 160b, and 160c can act as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU 102a, 102b, and 102c.

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

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

[0083] 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 SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slices can be used by AMF182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be built for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely 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) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0085] UPF 184a and 184b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. These gNBs can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184a 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.

[0086] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 connect to local data networks (DNs) 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0087] Based on the descriptions in Figures 1A through 1D and their corresponding descriptions, one or more emulation devices (not shown) can perform one or more of the functions described herein with respect to one or more of the following: WTRU102a-d, base station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN185a-b, and / or one or more 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.

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

[0089] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing on one or more components. The one or more simulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the simulation devices to transmit and / or receive data.

[0090] This application describes various aspects, including tools, features, examples, models, schemes, etc. Many of these aspects are described in detail and are often described in a way that may sound restrictive, at least to illustrate individual characteristics. However, this is for clarity of purpose and does not limit the application or scope of those aspects. Indeed, all the different aspects can be combined and interchanged to provide further aspects. Furthermore, this aspect can also be combined and interchanged with aspects described in earlier filings.

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

[0092] In this application, the terms “reconstructed” and “decoded” may be used interchangeably, as may the terms “pixel” and “sample”, and may the terms “image”, “picture” and “frame” be used interchangeably.

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

[0094] The various methods and other aspects described in this application can be used to modify modules of the video encoder 200 and decoder 300 shown in Figures 2 and 3, such as the decoding module. Furthermore, the subject matter disclosed herein can be applied to, for example, any type, format, or version of video encoding, whether or not described in a standard or recommendation, whether pre-existing or future-developed, and any extensions to such standards and recommendations. Unless otherwise indicated or technically excluded, the aspects described in this application may be used individually or in combination.

[0095] Various numerical values, such as 1, 2, 4, 7, 8, 16, 32, 64, etc., are used in the examples described in this application. These and other specific values ​​are used for the purpose of describing the examples, and the aspects described are not limited to these specific values.

[0096] Figure 2 is a diagram illustrating an example video encoder 200. Variations of the example encoder 200 can be conceived, but for clarity, the encoder 200 will be described below without depicting all expected variations.

[0097] Before being encoded, the video sequence may undergo pre-encoding processing (201), such as applying color transformations to the input color image (e.g., a conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing remapping of the input image components to obtain a more resilient signal distribution for compression (e.g., using histogram equalization of one of the color components). Metadata (e.g., which may include film grain parameters determined through preprocessing, as described herein) may be associated with the preprocessing and attached to the bitstream.

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

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

[0100] The encoder decodes the encoded blocks to provide a reference for further prediction. The quantized transform coefficients are dequantized (240) and inverse transformed (250) to decode the prediction residuals. The decoded prediction residuals and the predicted blocks are combined (255) to reconstruct the image blocks. A loop filter (265) is applied to the reconstructed image to perform, for example, deblocking / SAO (sample adaptive offset) filtering to reduce coding artifacts. The filtered image is stored in a reference image buffer (280).

[0101] Figure 3 is a diagram illustrating an example video decoder. In the example decoder 300, the bitstream is decoded by decoder elements, as described below. The video decoder 300 generally performs decoding passes that correspond to the encoding passes described in Figure 2. The encoder 200 also generally performs video decoding as part of the encoding of the video data.

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

[0103] The decoded image can undergo further 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, performing the inverse operation of the remapping process performed in pre-encoding processing (201). Post-decoding processing can utilize metadata derived in pre-encoding processing and signaled in the bitstream. In one example, the decoded image (e.g., after the application of a loop filter (365) and / or after post-decoding processing (385) in the case of post-decoding processing) can be sent to a display device for presentation to a user.

[0104] Figure 4 is a diagram illustrating an example of a system in which the various aspects and examples described herein can be implemented. System 400 may be embodied as a device including the various components described below and configured to perform one or more of the 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. The elements of system 400 may be embodied individually or in combination in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one example, the processing 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 of the aspects described in this document.

[0105] System 400 includes: at least one processor 410 configured to execute instructions loaded therein for implementing various aspects, such as those described in this document. Processor 410 may include embedded memory, input / output interfaces, and various other circuitry as 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 which 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. Storage device 440 may include internal storage devices, attached storage devices (including removable and non-removable storage devices), and / or network-accessible storage devices, as non-limiting examples.

[0106] 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 one or more modules that may be included in a device to perform encoding and / or decoding functions. It is well known that a device may include one or both encoding and decoding modules. Furthermore, the encoder / decoder module 430 may be implemented as a separate element of system 400, or may be incorporated into processor 410 as a combination of hardware and software as known to those skilled in the art.

[0107] Program code to be loaded onto processor 410 or encoder / decoder 430 to execute the various aspects described herein may be stored in storage device 440 and subsequently loaded onto memory 420 for execution by processor 410. According to various examples, one or more of processor 410, memory 420, storage device 440, and encoder / decoder module 430 may store one or more items of various kinds during the execution of the processes described herein. 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 the processing of equations, formulas, operations, and operational logic.

[0108] 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., processor 410 or encoder / decoder module 430) is used for one or more of these functions. External memory may 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.

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

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

[0111] USB and / or HDMI endpoints may include corresponding interface processors for connecting system 400 to other electronic devices across USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or, if necessary, within processor 410. Similarly, aspects of USB or HDMI interface processing may be implemented, either within a separate interface IC or, if necessary, 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 an output device.

[0112] Various components of the system 400 can be provided within an integrated housing, in which the various components can be interconnected and data can be transmitted therebetween using a suitable connection arrangement 425, such as an internal bus as known in the art, including inter-IC (I2C) bus, wiring and printed circuit board.

[0113] 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 transmit and receive data on 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 over, for example, wired and / or wireless media.

[0114] In various examples, data is streamed or otherwise provided to system 400 using a wireless network such as WiFi (e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers)). In these examples, the Wi-Fi signal is received on 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 that delivers data over an HDMI connection in input box 445 to provide streaming data to system 400. Still other examples use an RF connection in input box 445 to provide streaming data to system 400. As indicated above, various examples provide data in a non-streaming manner. Additionally, various examples use wireless networks other than Wi-Fi, such as cellular networks or Bluetooth® networks.

[0115] System 400 can provide output signals to various output devices, including a display 475, a speaker 485, and other peripheral devices 495. Various examples of the display 475 include one or more of the following: for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. The display 475 can be used in a television, tablet, laptop, cellular phone, or another device. The display 475 can also be integrated with other components (e.g., as in a smartphone) or separate (e.g., an external monitor for a laptop). In various examples, other peripheral devices 495 include one or more of a standalone digital video disc (or digital multifunction disc) (DVD, for both terms), a disc player, a stereo system, and / or a lighting system. Various examples utilize 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.

[0116] In various examples, signaling such as AV is used to transmit control signals between system 400 and display 475, speaker 485, or other peripheral devices 495. Device-to-device control links, consumer electronics control (CEC), or other communication protocols are implemented with or without user intervention. Output devices can be communicatively coupled to system 400 via dedicated connections through corresponding interfaces 470, 480, and 490. Alternatively, output devices can be connected to system 400 via communication interface 450 using communication channel 460. Display 475 and speaker 485 can be integrated into a single unit with other components of system 400 in electronic devices such as, for example, televisions. In various examples, display interface 470 includes display drivers, such as, for example, timing controller (TCon) chips.

[0117] Display 475 and speaker 485 can alternatively be separated from one or more other components, for example, if the RF section of input 445 is part of a separate set-top box. In various examples where display 475 and speaker 485 are external components, output signals can be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.

[0118] The example can be implemented by computer software, hardware, or a combination of hardware and software, as implemented by processor 410. 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 of microprocessors, general-purpose computers, special-purpose computers, and processors based on multi-core architectures.

[0119] Various implementations involve decoding. As used in this application, "decoding" can encompass all or part of a process performed, for example, on a received encoded sequence to produce a final output suitable for display. In various examples, such a process includes one or more processes typically performed by a decoder, such as entropy decoding, dequantization, inverse transform, and differential decoding. In various examples, such a process may also or alternatively include a process performed by a decoder of various implementations described in this application, such as: sending a first request to a video encoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature; detecting an event associated with disabling an energy-saving feature; in response to detecting the event, sending a second request to the video encoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature, wherein the first power reduction type value and the second power reduction type value are different; and decoding the current block based on the first energy-saving feature.

[0120] As further examples, in one example, "decoding" refers only to entropy decoding; in another example, "decoding" refers only to differential decoding; and in yet another example, "decoding" refers to a combination of entropy decoding and differential decoding. Whether the phrase "decoding process" is intended to specifically refer to a subset of operations or generally to a broader decoding process will be clear based on the specific context of the description and is considered to be well understood by those skilled in the art.

[0121] Various implementations involve encoding. In a manner similar to the above discussion of “decoding,” the term “encoding,” as used herein, can encompass all or part of a process performed, for example, on an input video sequence to produce an encoded bitstream. In various examples, such a process includes one or more processes typically performed by an encoder, such as partitioning, differential coding, transform, quantization, and entropy coding. In various examples, such a process also, or alternatively, includes a process performed by an encoder of various implementations described herein, such as: receiving a first request from a video decoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature; enabling the first energy-saving feature and the second energy-saving feature based on the first request; receiving a second request from the video decoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature, wherein the first power reduction type value and the second power reduction type value are different; disabling the second energy-saving feature based on the second request; and encoding the current block based on the first energy-saving feature.

[0122] As further examples, in one example, "encoding" refers only to entropy encoding; in another example, "encoding" refers only to differential encoding; and in yet another example, "encoding" refers to a combination of differential and entropy encoding. Whether the phrase "encoding process" is intended to specifically refer to a subset of operations or generally to a broader encoding process will be clear based on the specific context of the description and is considered well understood by those skilled in the art.

[0123] Note that the syntax elements used in this article (e.g., coding syntax on intensity intervals, granular parameters, block offsets, expansion factors, etc.) are descriptive terms. Therefore, they do not preclude the use of other syntax element names.

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

[0125] The implementations and aspects described herein can be implemented, for example, in methods or processes, apparatus, software programs, data streams, or signals. Even if discussed only in the context of a single form of implementation (e.g., discussed only as a method), the features in question can be implemented in other forms (e.g., apparatus or program). Apparatus can be implemented, for example, in appropriate hardware, software, and firmware. Methods can be implemented, for example, in a processor, where processor 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, for example, computers, cellular phones, portable / personal digital assistants (“PDAs”), and other devices that facilitate communication of information between end users.

[0126] References to “an example” or “an instance” or “an implementation” or “an implementation” and their variations mean that the specific feature, structure, characteristic, etc., described in connection with the example is included in at least one example. Therefore, the appearance of the phrase “in an example” or “in an instance” or “in an implementation” or “in an implementation” and any variations appearing throughout this application do not necessarily all refer to the same example.

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

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

[0129] Additionally, this application may refer to "receiving" various pieces of information. As with "access," "receiving" is intended to be a broad term. Receiving information may include one or more of, for example, accessing information or retrieving information (e.g., from memory). Further, "receiving" typically refers to actions performed during operation, such as, for example, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0130] It should be understood that the use of any of the following “ / ”, “and / or”, and “…at least one of” (e.g., in the cases of “A / B”, “A and / or B”, and “at least one of A and B”) is intended to cover the selection of only the first listed option (A), or only the second listed option (B), or the selection of both options (A and B). As a further example, in the cases of “A, B, and / or C” and “at least one of A, B, and C”, this phrase is intended to cover the selection of 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 the selection of all three options (A, B, and C). This can be extended to as many items as are listed, as will be clear to those skilled in the art and related fields.

[0131] Moreover, as used herein, the term "signaling" refers, among other things, to instructing the corresponding decoder to do something. Encoder signals may include, for example, the number of intensity intervals, the number of model values, particle parameters, particle identifiers, scaling factors, and so on. In this way, in one example, the same parameters are used on both the encoder and decoder sides. Thus, for example, the encoder can transmit specific parameters (explicit signaling) 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, then signaling can be used without transmission (implicit signaling) to simply allow the decoder to know and select specific parameters. Bit saving is achieved in various examples by avoiding the transmission of any actual functionality. It should be understood that signaling can be done in a variety of ways. For example, in various examples, one or more syntax elements, tags, etc., are used to signal information to the corresponding decoder. Although the foregoing refers to the verb form of the term "signaling," the term "signaling" may also be used as a noun in this text.

[0132] As will be apparent to those skilled in the art, implementations can generate various signals 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, the signal may be formatted to carry a bit stream of the described example. Such a signal may be formatted as, for example, an electromagnetic wave (e.g., using the radio frequency portion of a spectrum) or a baseband signal. Formatting may include, for example, encoding the data stream and modulating a carrier wave using the encoded data stream. The information carried by the signal may be, for example, analog or digital information. The signal may be transmitted over a variety of different wired or wireless links, as is well known. The signal may be stored on or accessed from a processor-readable medium.

[0133] This document describes numerous examples. Features of the examples may be provided individually or in any combination across various claim classes and types. Further, examples may include one or more of the features, devices, or aspects described 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, encoder, bitstream, and / or decoder according to any of the described embodiments. For example, the features described herein may be implemented by creating and / or transmitting and / or receiving and / or decoding the bitstream or signal. For example, the features described herein may be implemented using methods, processes, apparatus, media storing instructions, media storing data, or signals. For example, the features described herein may be implemented by a TV, set-top box, cellular phone, tablet, or other electronic device performing decoding. The TV, set-top box, cellular phone, tablet, or other electronic device may display (e.g., using a monitor, screen, or other type of display) the obtained image (e.g., a signal reconstructed from the residual of a video bitstream). The TV, set-top box, cellular phone, tablet, or other electronic device may receive a signal including an encoded image and perform decoding.

[0134] Interactive signaling for reducing the response of decoding operations for energy conservation can provide a signaling mechanism that enables the decoder to control its energy usage.

[0135] Reducing the energy consumption of electronic devices can decrease their environmental impact and / or contribute to the emergence of a sustainable display industry.

[0136] Video represents more than 80% of the data consumed by the end user. The decoder in the end-user device can process the received video, which may be transmitted over a network. The energy consumed when decoding video can be reduced.

[0137] Figure 5 illustrates the following example: using interactive signaling between a decoder (e.g., in a receiver) and a transmitter (e.g., including an encoder) to exchange metadata related to how to reduce energy consumption at the decoder side by adapting the encoding process at the encoder side.

[0138] The decoder can send a request for reduction of the decoding operation to the transmitter. The transmitter can then send a response to the reduction of the decoding operation, for example, to acknowledge receipt of the request message and / or to notify the decoder what changes the encoder can accept as part of its encoding process.

[0139] Metadata (e.g., green metadata) can facilitate a reduction in energy usage at the decoder, for example, through a Decoding Operation Reduction Request (DOR-Req) sent by the decoder to the transmitter to request changes in the encoding process (e.g., the definition of ). One or more (e.g., three) types of requests can be defined. For example, a remote encoder (e.g., in a first mode where dec_pow_reduction_type can be equal to 0) can be requested to adjust its encoding parameters such that (e.g., when the local decoder decodes the bitstream) power savings of the local decoder can be increased due to the reduction in decoder operations (e.g., which can be implied by the DOR-Req message). A remote encoder (e.g., in a second mode where dec_pow_reduction_type can be equal to 1) can be requested to disable (e.g., cancel) the encoding tools such that (e.g., when the local decoder decodes the bitstream) power consumption of the local decoder can be reduced. A remote encoder can be requested (e.g., in the third mode, where dec_pow_reduction_type can be equal to 2) to adjust the image resolution and / or video frame rate, so that (e.g., when the local decoder is decoding the bitstream) the power consumption of the local decoder can be reduced.

[0140] You can send metadata (e.g., additional metadata) to request one or more (e.g., specific) encoded parameters, such as those dependent on the pattern.

[0141] On the transmitter side, a response message may exist, for example, to acknowledge that it has received a request from the decoder and / or to indicate (e.g., to provide information about) what the transmitter accepts (e.g., determines) to change during its encoding process based on the received request. For example, the response message may indicate whether changes during the encoding process match the received request.

[0142] The encoder (e.g., the transmitter) can respond to the decoder, for example, if / when a request for reduction of decoding operations is received. This response can allow the encoder to acknowledge receipt of the request and / or indicate how the encoder can modify its encoding process in response to the requested changes from the decoder. The decoding operation reduction mechanism can support an interactive signaling framework in response to the response message.

[0143] The decoder can send a cancellation request for one or more previous (e.g., all previous) decode operation reduction requests. Decode operation reduction requests (e.g., existing decode operation reduction requests) can be interpreted in one or more ways.

[0144] Metadata can be used to signal information about reductions in decoding operations. This can reduce power consumption on the decoder side.

[0145] The mechanism used for interactive signaling allows the decoder to request (e.g., specifically) a reduction in decoding operations. The syntax in Table 1 includes examples of metadata. Table 1 – Syntax for interactive signaling to reduce power for remote decoders.

[0146] A transmitter in a device (e.g., each device) can send a Decoding Operation Reduction Request (DOR-Req) message to a remote encoder. In a first mode (e.g., dec_pow_reduction_type equals 0), the DOR-Reduction Request message can instruct the remote encoder to adjust its encoding parameters (e.g., such that if the local decoder decodes the bitstream, the power savings of the local decoder match the power savings implied by the DOR-Reduction Request message). In a second mode (e.g., dec_pow_reduction_type equals 1), the DOR-Reduction Request message can instruct the remote encoder to disable one or more encoding tools (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In a third mode (e.g., dec_pow_reduction_type equals 2), the DOR-Reduction Request message can instruct the remote encoder to adjust the image resolution and / or video frame rate (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced).

[0147] For a given pattern (e.g., each dec_pow_reduction_type), supplementary metadata can be sent to the request. The metadata may include information related to executing the request based on the pattern (e.g., how to execute a request of type dec_pow_reduction_type).

[0148] If the decoder determines that a previous request for the type of reduction for the decoding operation has been cancelled, the decoder may send a request of the same type for dec_pow_reduction_type (e.g., another request). The request may include the value of the relevant metadata (e.g., a new value).

[0149] For example, the decoder can send a request with dec_pow_reduction_type == 1 and a value (e.g., a new value) for the metadata (e.g., each metadata disable_loop_filters, disable_bi_prediction, disable_intra_in_B, disable_fracpel_filtering, user_defined_req).

[0150] In one example, the decoder may send a request with `dec_pow_reduction_type == 0`. The request may include a value of `dec_ops_reduction_req` equal to the requested variant of the local decoding operation (e.g., the inverse of the total number of decoding operations since the start of the video session), for example, if the decoder wants to cancel previous requests of type `dec_pow_reduction_type == 0` (e.g., all previous requests). If the decoder wants to cancel the last request of type `dec_pow_reduction_type == 0` (e.g., only cancel the previous request of type `dec_pow_reduction_type == 0`), the decoder may send another request of type `dec_pow_reduction_type == 0` with a value of `dec_ops_reduction_req` equal to the requested variant of the local decoding operation, the inverse of the variant of the last request. In these cases, the decoder may maintain (e.g., in memory) a list (e.g., updated) of the current local variants(one or more) of the decoding operations relative to the original number of decoding operations at the start of the video session.

[0151] This document provides one or more features associated with the cancellation mechanism of `dec_pow_reduction_type`. For example, a decoder power reduction type can be identified as a cancellation request. In this case, a corresponding decoding operation reduction response can be added. The type can be identified as a cancellation request based on the definition of the syntax and / or semantics of the response message used by the transmitter.

[0152] The features described herein relate to the decoder's ability to request a cancellation of one or more previous decoding operation reduction requests corresponding to a decoding operation reduction type (e.g., in point-to-point communication). This cancellation request can be sent (e.g., at any time) to the encoder. If the encoder receives the cancellation request, it can stop (or partially stop) the encoding process that enables power savings at the decoder side. One or more (e.g., all or some) of the encoding tools and parameters can be set to a predetermined (predetermined) mode (e.g., original or default mode). The image resolution and frame rate in the bitstream can be set back to their original values ​​(e.g., if the cancellation request involves these parameters).

[0153] A cancellation request can correspond to a specific type of decoding operation reduction. A cancellation request can correspond to the last request that only reduced the decoding operation. A cancellation request can correspond to one or more decoding operation reduction requests of one or more types and / or related metadata. A cancellation request can correspond to a decoding operation reduction request identifier. A cancellation request can correspond to a type of decoding operation reduction request with associated (e.g., specific) information metadata.

[0154] This article provides examples of the syntax and signaling for canceling requests.

[0155] One or more of the features described herein can be implemented at the encoder and / or decoder. One or more of the features described herein can be implemented at the power optimization module on the transmitter and / or receiver side of the video streaming end-to-end chain.

[0156] The receiver and / or decoder may request the cancellation of one or more previous decoding operations reduction requests. The request may require the transmitter and / or encoder to modify its encoded bitstream. The transmitter and / or encoder may send a response acknowledging the request. The response may instruct the transmitter and / or encoder to accept the operation cancelled during encoding.

[0157] Decoding operations can reduce the scope of requests that involve messages carried at the transport level. This article describes example syntax and semantics.

[0158] Decoding operation reduction requests can be extended. For example, signaling in point-to-point communication between a receiver and a transmitter can include requests for global or partial cancellation of previous decoding operation reduction requests.

[0159] This article provides examples of signaling and semantics.

[0160] The example signaling can use multiple modes (e.g., three different modes) corresponding to different (e.g., three different) request types. The transmitter of a device (e.g., in each device) can send a Decode Operation Reduction Request (DOR-Req) message to the remote encoder's attention. In the first mode (e.g., dec_pow_reduction_type equals 0), the DOR-Reduction Request message can instruct the remote encoder to adjust its encoding parameters (e.g., such that if the local decoder decodes the bitstream, the power saving of the local decoder matches the power saving implied by the DOR-Reduction Request message). In the second mode (e.g., dec_pow_reduction_type equals 1), the DOR-Reduction Request message can instruct the remote encoder to disable (one or more) encoding tools (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In the third mode (e.g., dec_pow_reduction_type equals 2), the DOR-Reduction Request message can instruct the remote encoder to adjust the image resolution and / or video frame rate (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced).

[0161] The metadata dec_pow_reduction_type can have a value (e.g., additional value) 3. A value of 3 can correspond to an undefined mode, as shown in Table 2. Table 2 – Example definition of dec_pow_reduction_type.

[0162] The features(one or more) described herein can be used to extend this signaling (e.g., based on another interpretation of dec_pow_reduction_type equal to 3). As described herein, dec_pow_reduction_type equal to 3 can correspond to (e.g., a specified type) a global or partial cancellation of one or more previous decoding operation reduction requests, as shown in Table 3. Table 3 – Example definitions of dec_pow_reduction_type.

[0163] Signaling may involve a transmitter (e.g., in each device) sending a Decode Operation Reduction Request (DOR-Req) message to the remote encoder's attention. In a first mode (e.g., dec_pow_reduction_type equals 0), the DOR-Reduction message may instruct the remote encoder to adjust its encoding parameters (e.g., such that if the local decoder decodes the bitstream, the power savings of the local decoder match the power savings implied by the DOR-Reduction message). In a second mode (e.g., dec_pow_reduction_type equals 1), the DOR-Reduction message may instruct the remote encoder to disable one or more encoding tools (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In a third mode (e.g., dec_pow_reduction_type equals 2), the DOR-Reduction message may instruct the remote encoder to adjust the image resolution and / or video frame rate (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In the third mode (dec_pow_reduction_type equals 3), a message can request a global or partial cancellation of a specific type of decoding operation reduction request at the transmitter side. In this case, the encoder can stop the corresponding changes previously enabled during encoding. If a global cancellation is requested, the transmitter can revert to a (pre)defined mode (e.g., normal mode).

[0164] In some examples, signaling can be extended, as shown in Table 4.

[0165] A transmitter in a device (e.g., each device) can send a decoding operation reduction request (e.g., DOR-Req) message to the encoder (e.g., a remote encoder) for attention. In a first mode (e.g., dec_pow_reduction_type equals 0), the message can request the remote encoder to adjust its encoding parameters (e.g., such that if the local decoder decodes the bitstream, the power saving of the local decoder matches the power saving implied by the DOR-Req message). In a second mode (e.g., dec_pow_reduction_type equals 1), the message can request the remote encoder to disable one or more encoding tools (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In a third mode (e.g., dec_pow_reduction_type equals 2), the message can request the remote encoder to adjust the image resolution and / or video frame rate (e.g., such that if the local decoder decodes the bitstream, the power consumption of the local decoder is reduced). In the fourth mode (e.g., dec_pow_reduction_type equals 3), the message may indicate that the decoding operation reduction type (e.g., some other extended decoding operation reduction type) was requested by the remote encoder.

[0166] In an example extension of the decode operation reduction type, the message may request a global or partial cancellation of the last decode operation reduction request (e.g., one or more specific types) at the transmitter side. In this case, the encoder can stop the corresponding changes previously enabled during its encoding process. If a global cancellation is requested, the transmitter can revert to the default mode (e.g., nominal mode). The default mode may be a mode that has not changed in the local decode operation compared to the start of the video session. Table 4 – Example definition of dec_pow_reduction_type.

[0167] Figure 6 illustrates an example of decoder operation reduction request / response cancellation interactive signaling. The interactive signaling in Figure 6 can be transmitted between the transmitter and receiver (e.g., in the context of decoder operation reduction cancellation).

[0168] In Figure 6, at point 1, the transmitter can advertise Service #1 as a green profile service. At point 2, the user can select Service #1 from the service list. For example, the user can send an energy-aware application request for the service. At point 3, the receiver (e.g., an energy-aware receiver) can receive video data.

[0169] At point 4, the first energy event can occur (e.g., a low battery level is boosted). The receiver can then initiate a decoding reduction to decrease its power consumption.

[0170] At point 5, the receiver can send a decoding operation reduction request to the transmitter. The decoding operation reduction request may include a resolution value (e.g., a new resolution value). The decoding operation reduction request may also request that one or more encoding parameters (e.g., encoding filters) be disabled.

[0171] At point 6, a second energy event may occur (e.g., an event where the battery level is raised to high). At point 7, the decoder may determine to stop the decoding operation reduction. The decoder may send a decoding operation reduction request indicating the requested cancellation.

[0172] Decoding power reduction types (e.g., a new type where dec_pow_reduction_type equals 3) can allow the decoder to send (e.g., easily and efficiently) requests for cancellation (e.g., global cancellation) of one or more (e.g., all) previously requested power reductions for decoding operations. Global cancellation requests can be signaled by dec_pow_reduction_type=3. In this case, the field nb_dec_pow_reduction_type_req can be set to 0, and / or other fields can be omitted from the message. Global cancellation requests can also allow all cancellation requests to be sent with (e.g., a single) message (e.g., instead of sending several request messages, e.g., one request message per dec_pow_reduction_type value with a new value for the relevant metadata).

[0173] In some examples, dec_pow_reduction_type equal to 3 can correspond to the cancellation of requests (e.g., all requests) that correspond to a list of dec_pow_reduction_types (e.g., only the specified dec_pow_reduction_type).

[0174] In some examples, dec_pow_reduction_type equal to 3 can correspond to the cancellation of the last decoding operation reduction request of a specified type.

[0175] In some examples, dec_pow_reduction_type equal to 3 can correspond to the cancellation of one or more last requests that correspond to a list of specified dec_pow_reduction_types (e.g., only to a list of specified dec_pow_reduction_types).

[0176] In some examples, `dec_pow_reduction_type` equal to 3 can correspond to the cancellation of a decode operation reduction request associated with a requested identifier signaled in the message. In this case, the identifier can be created and added within the decode operation reduction request message. The identifier can be sent along with the corresponding request (e.g., together with the corresponding request). The transmitter and receiver can maintain a list of requested identifiers.

[0177] In some examples, `dec_pow_reduction_type` equal to 3 can correspond to the cancellation of one or more types of reduction operations with some (e.g., additional) metadata. Bit fields can be inserted into the message, which can allow metadata to be included. Metadata can allow cancellation requests to be more precise. For example, a receiver can request cancellation of a request with `dec_pow_reduction_type=2` using a resolution-specific (e.g., resolution-only) cancellation. In this case, the receiver can request the transmitter to return to the original resolution of the video.

[0178] Setting dec_pow_reduction_type=3 for cancellation requests allows the decoder / receiver to send cancellation requests for one or more requests (e.g., last requests). The signaling can be simplified so that the decoder / receiver does not have to send a dec_pow_reduction_type corresponding to the type of the last decoding operation reduction request and metadata (e.g., additional metadata) with the corresponding value.

[0179] In some examples, to cancel a reduction request for a decoding operation of type 1, the decoder / receiver can send (e.g., it can send first) a dec_pow_reduction_type with a value of 1, and send flags with updated values ​​(e.g., all flags) disable_loop_filters, disable_bi_prediction, disable_intra_in_B, disable_fracpel_filtering, and user_defined_req.

[0180] In some examples, dec_pow_reduction_type equal to 3 can correspond to the definition of an extension (e.g., some extension) of the decoding operation reduction type. In some examples, dec_pow_reduction_extension_type can indicate one or more other types of requests for decoding operation reduction(s) from a remote decoder.

[0181] For example, if `dec_pow_reduction_extension_type` equals 0, this can indicate a global or partial cancellation of the last decoding operation reduction request for one or more specific types at the transmitter side. In this case, the encoder can stop the corresponding changes previously enabled during its encoding process. If a global cancellation is requested, the transmitter can revert to the default mode (e.g., nominal mode). The default mode can be a mode that has not changed during local decoding operations compared to the start of the video session.

[0182] This article provides example syntax. The basic example syntax is shown in Table 5. Table 5 – Example syntax for interactive signaling for power reduction of remote decoders.

[0183] To cancel a decoding operation reduction request that was previously performed by the receiver using only one message (e.g., all decoding operation reduction requests), example syntax can be shown in Table 6. Table 6 – Example syntax for interactive signaling for power reduction of remote decoders.

[0184] In this case, if dec_pow_reduction_type=3, nb_dec_pow_reduction_type_req can be set to 0 to indicate that the reduction type will be active if no decoding operation is requested (e.g., all requests are cancelled on the transmitter side).

[0185] If the nb_dec_pow_reduction_type_req field is not inserted into the message, this can indicate that global cancellation was requested.

[0186] In some examples, the syntax can be modified as shown in Table 7. In this case, the list of request types corresponding to requests for cancellation can be provided to the encoder by the decoder. Table 7 – Example syntax for interactive signaling for power reduction of remote decoders.

[0187] In this case, `nb_dec_pow_reduction_type_req` can indicate the number of requested types for which the decoder requests cancellation. `dec_pow_reduction_type_req_id[i]` can indicate the last request for the corresponding type that the decoder requests cancellation.

[0188] In some examples, the syntax can be modified as shown in Table 8. In this case, the last decode operation reduction request can be cancelled (e.g., only the last decode operation reduction request can be cancelled). The type of the last decode operation reduction request can be provided in the cancellation message. Table 8 – Example syntax for interactive signaling for power reduction of remote decoders.

[0189] For example, dec_pow_reduction_type_req_id can indicate the type of the last decoder power reduction request to be canceled.

[0190] In some examples, the syntax may resemble the syntax described with respect to Table 7. In these examples, `nb_dec_pow_reduction_type_req` may indicate the number of requested types that the decoder requests to cancel. `dec_pow_reduction_type_req_id[i]` may indicate that the decoder requests to cancel previous requests for the corresponding type (e.g., all previous requests). In this case, the requested percentage change of the local decoding operation in the encoder may be set to 0. If the decoder retains a record of the percentage change (e.g., in memory), that percentage change may be set to 0.

[0191] In some examples, the syntax can be modified as shown in Table 9. In this case, the list of requested types can be replaced by a list of decoder power-reducing request identifiers. This implies to the receiver that identifiers are created and added to each request. Both the transmitter and receiver maintain a list of request identifiers. Table 9 – Example syntax for interactive signaling for power reduction of remote decoders.

[0192] In this case, nb_dec_pow_reduction_id_req can indicate the number of requests the decoder requests to cancel. dec_pow_reduction_req_id[i] can indicate the identifier of the request to be canceled.

[0193] In some examples, bit fields can be used to indicate the decoder power reduction method for which the decoder / receiver request has been cancelled. In this case, the syntax can be modified as shown in Table 10. Table 10 – Example syntax for interactive signaling for power reduction of remote decoders.

[0194] In this case, `dorm_flags` can be a bit field indicating the reduction method of the decoding operation to be canceled. Table 11 shows examples of `dorm_flags` bit fields. Table 11 – Description of dorm_flags.

[0195] For example, bit 0 can indicate that the request to reduce global decoder power is cancelled; bit 1 can indicate that the decoder will cancel the reduction of the number of decoding operations; bit 2 can indicate the cancellation of the request to disable the loop filter tool; bit 3 can indicate the cancellation of the request to disable bidirectional prediction in one or more slices (e.g., B slices); bit 4 can indicate the cancellation of the request to disable intra-frame prediction in one or more slices (e.g., B slices); bit 5 can indicate the cancellation of the request to disable fractional pixel filtering in one or more slices (e.g., P slices or B slices); bit 6 can indicate the cancellation of the request to change the image resolution in the luminance sample; bit 7 can indicate the cancellation of the request to change the image frame rate; and / or bits 8-10 can be reserved for future use.

[0196] Example syntax can be used, such as the syntax shown in Table 12. Table 12 – Example syntax for interactive signaling for power reduction of remote decoders.

[0197] In this example, dec_pow_reduction_extension_type can indicate one or more types (e.g., other types) of the request for reduction of decoding operations from a remote decoder.

[0198] For example, if `dec_pow_reduction_extension_type` equals 0, this can indicate a global or partial cancellation of the last decoding operation reduction request for one or more specific types at the transmitter side. In this case, the encoder can stop the corresponding changes previously enabled during its encoding process. If a global cancellation is requested, the transmitter can revert to the default mode (e.g., nominal mode). The default mode can be a mode that has not changed during local decoding operations compared to the start of the video session.

[0199] Decoding operation reduction cancellation requests can be handled by the encoder / transmitter.

[0200] Figure 7 illustrates an example of encoder-side operation in response to receiving a global cancellation request. Figure 7 illustrates an example of the encoder modifying encoding parameters in response to a DOR-Req for global cancellation from the decoder.

[0201] At position 1001, a cancellation request can be received from the decoder. Encoding parameters can be reset (e.g., returning to normal mode). Normal mode can correspond to a state without energy saving (e.g., a state where no energy saving request is sent from the decoder). At position 1002, the encoder can encode the image in normal mode using the encoding parameters.

[0202] Figure 8 illustrates an example of encoder-side operation in response to a partial cancellation request. Figure 8 also illustrates an example modification of the encoding parameters based on the DOR-Req from the decoder for partial cancellation.

[0203] At 1101, the encoder can receive a request for cancellation from the decoder. The encoder can partially reset one or more encoding parameters (e.g., partially set the encoding parameters back to normal mode). Normal mode can correspond to a state without energy saving (e.g., a state in which no energy saving request is sent from the decoder). At 1102, the encoder can encode the image using the encoding parameters set at 1101.

[0204] The decoder can generate a decoder power reduction cancellation request.

[0205] Figure 9 illustrates an example decoder-side operation for canceling an operation reduction request. If the decoder detects an event (e.g., a high-level battery event), it can generate (e.g., partially or globally) a decode operation reduction cancellation request (DOR-req) at 1201. At 1202, the decoder can send the request to the transmitter / encoder. At 1203, the decoder can receive the image (e.g., a currently normal image). At 1204, the decoder can decode the image.

[0206] The operations described herein can be performed in any combination and / or order.

[0207] The features described herein provide a signaling mechanism that enables the receiver to easily and efficiently request the global or partial cancellation of a decoding power reduction request.

[0208] Although features and elements have been described above in specific combinations, those skilled in the art will appreciate that each feature or element may be used individually or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated 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 memory devices, magnetic media (such as internal hard disks and removable disks), magnetic-optical media, and optical media (such as CD-ROMs and digital multifunction discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A video decoding device, comprising: The processor is configured to: send a first request to a video encoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature; detect an event associated with disabling an energy-saving feature; in response to detecting the event, send a second request to the video encoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature, wherein the first power reduction type value and the second power reduction type value are different; and decode the current block based on the first energy-saving feature.

2. The video decoding apparatus of claim 1, wherein the processor is further configured to send a third request indicating a third power reduction type value associated with enabling a third energy-saving feature, and wherein decoding of the current block is further based on the third energy-saving feature.

3. The video decoding device of claim 1, wherein the processor is further configured to detect a third event associated with enabling an energy-saving feature, wherein the processor is configured to send the first request including being configured to send the first request in response to detecting the third event.

4. The video decoding apparatus of claim 1, wherein the current block is a first current block, the event associated with canceling the energy-saving feature is a first event associated with canceling the energy-saving feature, and the processor is further configured to: send a third request to the video encoding apparatus, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; detect a second event associated with canceling the energy-saving feature; in response to detecting the second event, send a fourth request to the video encoding apparatus, the fourth request indicating a fourth power reduction type value associated with canceling the first energy-saving feature and the third energy-saving feature; and decode the second current block based on the second energy-saving feature.

5. The video decoding apparatus of claim 1, wherein the current block is a first current block, and the processor is further configured to: send a third request to the video encoding apparatus, the third request indicating a third power reduction type value associated with enabling a plurality of energy-saving features; send a fourth request to the video encoding apparatus, the fourth request indicating a fourth power reduction type value associated with disabling all enabled energy-saving features; and decode the second current block.

6. The video decoding apparatus of claim 1, wherein the current block is a first current block, the event associated with canceling the energy-saving feature is a first event associated with canceling the energy-saving feature, and the processor is further configured to: send a third request to the video encoding apparatus, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature and the second energy-saving feature; detect a second event associated with canceling the energy-saving feature; in response to detecting the second event, send a fourth request to the video encoding apparatus, the fourth request indicating a fourth power reduction type value associated with canceling the first energy-saving feature and the second energy-saving feature; and decode the second current block.

7. The video decoding device of claim 1, wherein the event associated with canceling the energy-saving feature includes: The power level is above the threshold.

8. A video encoding device, comprising: The processor is configured to: receive a first request from a video decoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature; enable the first energy-saving feature and the second energy-saving feature based on the first request; receive a second request from the video decoding device, the second request indicating a second power reduction type value associated with disabling the second energy-saving feature, wherein the first power reduction type value and the second power reduction type value are different; disable the second energy-saving feature based on the second request; and encode the current block based on the first energy-saving feature.

9. The video encoding apparatus of claim 8, wherein the processor is further configured to receive a third request indicating a third power reduction type value associated with enabling a third energy-saving feature, and wherein encoding of the current block is further based on the third energy-saving feature.

10. The video encoding apparatus of claim 8, wherein the current block is a first current block, and the processor is further configured to: receive a third request from the video decoding apparatus, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; enable the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature based on the third request; encode a second current block based on the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; receive a fourth request from the video decoding apparatus, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature and the third energy-saving feature; disable the first energy-saving feature and the third energy-saving feature based on the fourth request; and encode the second current block based on the second energy-saving feature.

11. The video encoding apparatus of claim 8, wherein the current block is a first current block, and the processor is further configured to: receive a third request from the video decoding apparatus, the third request indicating a plurality of energy-saving features; Enable the aforementioned multiple energy-saving features; Encode the second current block based on the plurality of energy-saving features; receive a fourth request from the video decoding device, the fourth request indicating a fourth power reduction type value associated with canceling the plurality of energy-saving features; disable the plurality of energy-saving features; and encode the third current block.

12. The video encoding apparatus of claim 8, wherein the current block is a first current block, and the processor is further configured to: receive a third request from the video decoding apparatus, the third request indicating a third power reduction type value associated with enabling the second energy-saving feature and the third energy-saving feature; enable the second energy-saving feature and the third energy-saving feature; encode a second current block based on the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; receive a fourth request from the video decoding apparatus, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; disable the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; and encode a third current block.

13. The video encoding device of claim 8, wherein the first energy-saving feature includes: Adjust one or more parameters associated with encoder operation; Disable one or more encoding tools; Alternatively, adjust the image resolution and video frame rate.

14. A method performed by a video decoding device, the method comprising: Send a first request to the video encoding device, the first request indicating a first power reduction type value associated with enabling a first energy-saving feature and a second energy-saving feature; Detect an event associated with canceling the energy-saving feature; in response to detecting the event, send a second request to the video encoding device, the second request indicating a second power reduction type value associated with canceling the second energy-saving feature, wherein the first power reduction type value and the second power reduction type value are different; and decode the current block based on the first energy-saving feature.

15. The method of claim 14, wherein the method further comprises sending a third request indicating a third power reduction type value associated with enabling a third energy-saving feature, and wherein decoding of the current block is further based on the third energy-saving feature.

16. The method of claim 14, wherein the method further comprises detecting a third event associated with enabling the energy-saving feature, and sending the first request comprises sending the first request in response to detecting the third event.

17. The method of claim 14, wherein the current block is a first current block, the event associated with canceling the energy-saving feature is a first event associated with canceling the energy-saving feature, and the method further comprises: Send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature, the second energy-saving feature, and the third energy-saving feature; detect a second event associated with disabling the energy-saving feature; in response to detecting the second event, send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature and the third energy-saving feature; and decode the second current block based on the second energy-saving feature.

18. The method of claim 14, wherein the current block is a first current block, and the method further comprises: A third request is sent to the video encoding device, the third request indicating a third power reduction type value associated with enabling multiple energy-saving features; Send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with canceling all enabled energy-saving features; and decode the second current block.

19. The method of claim 14, wherein the current block is a first current block, the event associated with canceling the energy-saving feature is a first event associated with canceling the energy-saving feature, and the method further comprises: Send a third request to the video encoding device, the third request indicating a third power reduction type value associated with enabling the first energy-saving feature and the second energy-saving feature; detect a second event associated with disabling the energy-saving feature; in response to detecting the second event, send a fourth request to the video encoding device, the fourth request indicating a fourth power reduction type value associated with disabling the first energy-saving feature and the second energy-saving feature; and decode the second current block.

20. The method of claim 14, wherein the events associated with canceling the energy-saving feature include: The power level is above the threshold.

Images