ISOBMFF carrying of attenuation map information for energy-aware images in DASH context

Abstract

Some embodiments of a method may include obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; and information related to a set of attenuation map representations of the visual content; obtaining segments of the video representation; obtaining a section of an attenuation map representation selected from the set of attenuation map representations based on the selected energy reduction rate; decoding a picture from a segment of the obtained video representation; decoding the attenuation map representation from the segments of the obtained attenuation map representation; and applying the decoded attenuation map representation to the decoded picture to produce an attenuated picture for display.

Description

[0001] Cross-reference to related applications This application claims the benefits of the following patent applications: European Patent Application No. EP23306784, entitled "ISOBMFF CARRIAGE OF ATTENUATIONMAP INFORMATION FOR ENERGY-AWARE IMAGES IN A DASH CONTEXT", filed on October 13, 2023; and European Patent Application No. EP23306227, entitled "ISOBMFF CARRIAGE OF ATTENUATIONMAP INFORMATION FOR ENERGY-AWARE IMAGES IN A DASH CONTEXT", filed on July 17, 2023, the entire contents of which are incorporated herein by reference.

[0002] By reference This application incorporates, by reference, the entire contents of, and relates to, the following applications: European patent application No. 22306227.2, filed on July 17, 2023 (“'227 application”); European patent application No. 22306719.0, filed on November 22, 2022 (“'719 application”); European provisional patent application No. 23305185.3, filed on February 10, 2023 (“'185 application”); European patent application No. 23305479.0, filed on April 3, 2023 (“'479 application”); European provisional patent application No. 23305958.3, filed on June 16, 2023 (“'958 application”); and European patent application No. 22306908.9. And the following European patent applications filed on December 10, 2022 (“'908 application”); European provisional patent application with serial number 23305521.9 filed on April 7, 2023 (“'521 application”); European patent application with serial number 23306066.4 filed on June 29, 2023 (“'066 application”); European provisional patent application with serial number 23305566.4 filed on April 14, 2023 (“'566 application”); and European provisional patent application with serial number 23306068.0 filed on June 29, 2023 (“'068 application”). Background Technology

[0003] Reducing the energy consumption of electronic devices has become not only a requirement for electronics manufacturers, but also a necessity to minimize environmental impact and contribute to the emergence of a sustainable display industry. The increase in display resolution, from SD to HD to 4K and soon to 8K and even higher, along with the introduction of high dynamic range imaging, has led to a corresponding increase in the energy requirements of display devices. Conversely, there is a global need to reduce energy consumption. In fact, displays are a source of energy consumption, whether for battery-powered devices (e.g., smartphones) or in the global video distribution chain. Summary of the Invention

[0004] The embodiments described herein include methods for video encoding and decoding (collectively, “decoding”).

[0005] A first exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; and information related to a set of attenuation map representations of the visual content; obtaining segments of the video representation; obtaining segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate; decoding an image from the obtained segments of the video representation; decoding the attenuation map representations from the obtained segments of the attenuation map representations; and applying the decoded attenuation map representations to the decoded image to produce an attenuated image for display.

[0006] In some embodiments of the first exemplary method, the manifest file includes an adaptive set having an identifier field corresponding to attenuation map information (AMI).

[0007] In some embodiments of the first exemplary method, the manifest file includes an adaptive set having an identifier field corresponding to the green video and a codec attribute having a value corresponding to the Attenuation Map Information Indication (AMII).

[0008] In some embodiments of the first exemplary method, the identifier field is accessible using an external class.

[0009] Some embodiments of the first exemplary method may further include: in response to finding an adaptive set having an identifier field corresponding to attenuation map information (AMI) in the manifest file, obtaining a list of one or more available pixel-wise attenuation maps; and selecting an attenuation map from the list, wherein the selected attenuation map corresponds to a selected attenuation map representation.

[0010] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the quality of the image, and the attenuation map is selected from the list based on the information corresponding to the quality of the image.

[0011] Some embodiments of the first exemplary method may further include: rendering the attenuation image.

[0012] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information representing the type of interpolation.

[0013] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the scaling of the pixels of the image.

[0014] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the backlight of the image.

[0015] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the quality of the image.

[0016] In some embodiments of the first exemplary method, the manifest file and the segment are based on MPEG-DASH.

[0017] In some embodiments of the first exemplary method, an adaptive set having an identifier field corresponding to the green video type is used to obtain the segment represented by the attenuation map.

[0018] A first exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0019] A second exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; and information related to a set of attenuation map representations of the visual content; in response to finding an adaptive set having an identifier field corresponding to attenuation map information (AMI) in the manifest file, obtaining a list of one or more available pixel-wise attenuation maps; and selecting an attenuation map from the list, wherein the selected attenuation map corresponds to an attenuation map representation selected from the set of attenuation map representations; obtaining a segment of the video representation; obtaining a segment of the selected attenuation map representation; decoding an image from the obtained segment of the video representation; decoding the selected attenuation map representation from the obtained segment of the selected attenuation map representation; and applying the decoded attenuation map representation to the decoded image to produce an attenuated image.

[0020] A second exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0021] A third exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; information related to a set of attenuation map representations of the visual content; and an adaptive set having an identifier field corresponding to a green video and a codec attribute having a value corresponding to an attenuation map information indication (AMII); obtaining segments of the video representation; obtaining segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate; decoding an image from the obtained segments of the video representation; decoding the attenuation map representations from the obtained segments of the attenuation map representations; and applying the decoded attenuation map representations to the decoded image to produce an attenuated image for display.

[0022] A third exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0023] A fourth exemplary method according to some embodiments may include: creating a manifest file corresponding to visual content, wherein the manifest file includes: information related to video representation; and information related to a set of attenuation map representations of the visual content; and sending the manifest file corresponding to the visual content to a client.

[0024] Some embodiments of the fourth exemplary method may further include: receiving a request for a segment of the video representation; receiving a request for a segment of attenuation map representation selected from the set of attenuation map representations based on a selected energy reduction rate; sending the segment of the video representation to the client; and sending the segment of attenuation map representation selected from the set of attenuation map representations based on a selected energy reduction rate to the client.

[0025] Some embodiments of the fourth exemplary method may further include: encoding an image as a segment of the video representation; and encoding a selected attenuation map representation as a segment of the selected attenuation map representation.

[0026] A fourth exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0027] An exemplary server device according to some embodiments may include: one or more processors configured to generate a manifest file including information configured and usable by a client to reduce the power consumption of a video representation on a pixel-by-pixel basis on a client display, wherein the one or more processors are further configured to generate the manifest file in part by obtaining the information from attenuation map information obtained from the server.

[0028] In some embodiments of the exemplary server device, the server is a DASH server.

[0029] For some embodiments of the exemplary server device, the manifest file is a DASH MPD file.

[0030] An exemplary client device according to some embodiments may include one or more processors and communicate with a display, the one or more processors being configured to obtain a manifest file including information configured and usable by the client to reduce the power consumption of a video representation on a pixel-by-pixel basis on the display, wherein the information is obtained from attenuation map information, and wherein the one or more processors are further configured to update the display according to the manifest file.

[0031] In some embodiments of the exemplary client device, the client includes the display.

[0032] In some embodiments of the exemplary client device, the client is a DASH client.

[0033] For some embodiments of exemplary client devices, the manifest file is a DASH MPD file.

[0034] In some embodiments of the exemplary client device, the client selects information obtained from the attenuation map information from the server.

[0035] In some embodiments of the exemplary client device, the server is a DASH server.

[0036] A fifth exemplary device according to some embodiments may include: at least one processor configured to perform any of the methods listed above.

[0037] A sixth exemplary device according to some embodiments may include: a computer-readable medium storing instructions for causing one or more processors to perform any of the methods listed above.

[0038] A seventh exemplary device according to some embodiments may include: at least one processor; and at least one non-transitory computer-readable medium storing instructions for causing the at least one processor to perform any of the methods listed above.

[0039] A computer-readable medium according to some embodiments may include: a computer-readable medium storing a bit stream generated according to any of the methods listed above.

[0040] The signal according to some embodiments may include: a bit stream generated according to any of the methods listed above.

[0041] In another embodiment, an encoder and decoder device is provided to perform the methods described herein. The encoder or decoder device may include a processor configured to perform the methods described herein. The device may include a computer-readable medium (e.g., a non-transitory medium) storing instructions for performing the methods described herein. In some embodiments, the computer-readable medium (e.g., a non-transitory medium) stores video encoded using any of the methods described herein.

[0042] One or more embodiments in this embodiment also provide a computer-readable storage medium having instructions stored thereon for performing bidirectional optical flow, encoding or decoding video data according to any of the methods described above. This embodiment also provides a computer-readable storage medium having a bitstream generated according to the methods described above stored thereon. This embodiment also provides a method and apparatus for transmitting a bitstream generated according to the methods described above. This embodiment also provides a computer program product including instructions for performing any of the methods described. Attached Figure Description

[0043] Figure 1A This is a system diagram illustrating an exemplary communication system according to some embodiments.

[0044] Figure 1B The illustration is based on some embodiments and is available Figure 1A The diagram shows a system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system.

[0045] Figure 1C This is a system diagram illustrating a set of exemplary interfaces of a system according to some embodiments.

[0046] Figure 2 This is a schematic diagram illustrating an exemplary DASH system architecture according to some embodiments.

[0047] Figure 3This is a schematic diagram illustrating an exemplary hierarchical system for MPD XML manifest files according to some embodiments.

[0048] Figure 4 This is a list of codes for an exemplary green video information structure according to some embodiments.

[0049] Figure 5 This is a schematic illustration showing the preparation of an exemplary video and attenuation map representation on the Dash server side according to some embodiments.

[0050] Figure 6 This is a schematic illustration showing an exemplary DASH client interface according to some embodiments.

[0051] Figures 7A-7B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0052] Figures 8A-8B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0053] Figures 9A-9B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0054] Figures 10A-10B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0055] Figure 11A-11B A list of codes that forms an exemplary MPD manifest file according to some embodiments.

[0056] Figure 12A-11B A list of codes that forms an exemplary MPD manifest file according to some embodiments.

[0057] Figure 13A This is a flowchart illustrating an exemplary DASH server-side application process according to some embodiments.

[0058] Figure 13B This is a flowchart illustrating an exemplary DASH server-side application process according to some embodiments.

[0059] Figure 14 This is a flowchart illustrating an exemplary DASH client-side process according to some embodiments.

[0060] Figure 15 This is a schematic illustration of an exemplary DASH client-side process according to some embodiments.

[0061] Figure 16This is a flowchart illustrating an exemplary process for generating an attenuated image for display, according to some embodiments.

[0062] Figure 17 This is a flowchart illustrating an exemplary process for generating an attenuated image for display, according to some embodiments.

[0063] Figures 18A-18B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0064] Figures 19A-19B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0065] Figures 20A-20B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments.

[0066] As examples, not limitations, entities, connections, arrangements, etc., depicted in and described in conjunction with the various figures are presented. Thus, any and all statements or other indications concerning what a particular figure “depicts,” what a particular element or entity in a particular figure “is” or “has,” and any and all similar statements may be interpreted in isolation and out of context as absolute and therefore limiting, and may only be appropriately interpreted as constructively preceded by a clause, such as “In at least one embodiment, …”. For the sake of brevity and clarity, such implicit introductory clauses are not repeated in the detailed description. Detailed Implementation

[0067] Figure 1A This is a diagram illustrating an exemplary communication system 100 that can implement one or more of the disclosed embodiments. 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 this content through the sharing of 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 Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Library Set Multicarrier (FBMC), etc.

[0068] like Figure 1AAs shown, the communication system 100 may include Wireless Transmit / Receive Units (WTRUs) 102a, 102b, 102c, 102d, RAN 104, CN 106, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. 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 WTRU in WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0069] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceivers (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, field controllers, access points (APs), wireless routers, 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.

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

[0071] Through air interface 116, base stations 114a and 114b can communicate with one or more WTRUs among WTRUs 102a, 102b, 102c, and 102d. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

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

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

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

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

[0078] RAN 104 can communicate with CN 106, 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 WTRUs among WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, mobile location-based services, prepaid telephony, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but will be understood, RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may use NR radio technology, CN 106 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0079] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 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 globally interconnected computer network and apparatus system 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 or a different RAT.

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

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

[0082] 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 decoding, 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, and transceiver 120 may be coupled to transmitting / receiving element 122. Although... Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0083] Transmitting / receiving element 122 may 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 may be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0085] 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 described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate over various RATs (such as, for example, NR and IEEE 802.11).

[0086] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128. 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 said memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a 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 the data in said memory.

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

[0088] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of WTRU 102. In addition to or alternative to information from GPS chipset 136, WTRU 102 may receive location information via air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0089] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, such as 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.

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

[0091] Although WTRU is Figure 1A-1B While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0093] Considering Figure 1A-1B As described herein, one or more of the functions described herein may be performed by one or more simulation devices (not shown). A simulation device may be one or more devices configured to simulate one or more of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0094] The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or in a carrier network environment. For example, while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions to test other devices within the communication network. While being temporarily implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions. The simulation device may be directly coupled to another device for testing purposes, and / or may use over-the-air wireless communication to perform the tests.

[0095] While not implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform the one or more functions (including all functions). For example, the simulation devices may be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., the RF circuit system may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0096] The embodiments described herein are not limited to implementation on WTRU. Other systems, such as... Figure 1C Such an embodiment can be implemented in a system. Figure 1C This is a system diagram illustrating a set of exemplary interfaces of a system according to some embodiments. Using, for example... Figure 1C The extended reality display device, together with its control electronics, can be implemented as a system. System 150 can be embodied as an apparatus including the various components described below and configured to perform one or more aspects of the aspects described in this document. Examples of such apparatus 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. Individually or in combination, the elements of system 150 can be embodied in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 150 are distributed across multiple ICs and / or discrete components. In various embodiments, system 150 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 embodiments, system 1000 is configured to implement one or more aspects of the aspects described in this document.

[0097] System 150 includes at least one processor 152 configured to execute instructions loaded therein to implement various aspects, such as those described in this document. Processor 152 may include embedded memory, input / output interfaces, and various other circuit systems as known in the art. System 150 includes at least one memory 154 (e.g., a volatile memory device and / or a non-volatile memory device). System 150 may include a storage device 158, 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. As a non-limiting example, storage device 158 may include internal storage devices, attached storage devices (including removable and non-removable storage devices), and / or network-accessible storage devices.

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

[0099] Program code to be loaded onto processor 152 or encoder / decoder 156 to execute the various aspects described herein can be stored in storage device 158 and subsequently loaded onto memory 154 for execution by processor 152. According to various embodiments, during the execution of the processes described herein, one or more of processor 152, memory 154, storage device 158, and encoder / decoder module 156 can store one or more items from various categories. Such stored items can include, but are not limited to, input video, decoded video or a portion of decoded video, bitstreams, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.

[0100] In some embodiments, memory within processor 152 and / or encoder / decoder module 156 is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other embodiments, memory located external to the processing device (e.g., processor 152 or encoder / decoder module 152) is used for one or more of these functions. External memory can be memory 154 and / or storage device 158, such as volatile memory and / or non-volatile flash memory. In several embodiments, external non-volatile flash memory is used to store, for example, the operating system of a television. In at least one embodiment, a fast external dynamic volatile memory (such as RAM) is used as working memory for video decoding and decoding operations, such as for MPEG-2 (MPEG stands for Moving Picture Experts Group; MPEG-2 is also known as ISO / IEC 13818, and 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC stands for High Efficiency Video Decoding, also known as H.265 and MPEG-H Part 2), or VVC (Universal Video Decoding, a new standard developed by JVET (Joint Video Experts Team)).

[0101] Inputs to the components of system 150 can be provided via various input devices as indicated in box 172. Such input devices include, but are not limited to: (i) a radio frequency (RF) section for receiving, for example, RF signals transmitted over the air by a broadcasting company; (ii) component (COMP) input terminals (or a set of COMP input terminals); (iii) a universal serial bus (USB) input terminal; and / or (iv) a high-definition multimedia interface (HDMI) input terminal. Figure 1C Other examples not shown include composite video.

[0102] In various embodiments, the input device of block 172 has associated corresponding input processing elements, as known in the art. For example, the RF section can be associated with various elements suitable for: (i) selecting a desired frequency (also referred to as selecting a signal or band-limiting a signal to a certain frequency band), (ii) down-converting the selected signal, (iii) band-limiting it again to a narrower frequency band to select, for example, a signal band that may be referred to as a channel in some embodiments, (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. The RF section in various embodiments 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 can 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 down-converting it to baseband. In one set-top box embodiment, the RF section and its associated input processing elements receive RF signals transmitted via a wired (e.g., cable) medium and perform frequency selection by filtering, down-converting, and filtering again to a desired frequency band. Various embodiments rearrange the order of the aforementioned (and other) components, remove some of these components, and / or add other components that perform similar or different functions. Adding components can include inserting components between existing components, such as, for example, inserting amplifiers and analog-to-digital converters. In various embodiments, the RF section includes an antenna.

[0103] Additionally, the USB and / or HDMI terminals can include corresponding interface processors for connecting system 150 to other electronic devices across USB and / or HDMI connections. It should be understood that, as needed, various aspects of input processing (e.g., Reed-Solomon error correction) can be implemented, for example, within a separate input processing IC or within processor 152. Similarly, as needed, various aspects of USB or HDMI interface processing can be implemented within a separate interface IC or within processor 152. Demodulated, error-corrected, and demultiplexed streams are provided to various processing elements, including, for example, processor 152 and encoder / decoder 156, which operate in conjunction with memory and storage elements to process the data stream as needed for presentation on the output device.

[0104] Various components of system 150 can be provided within an integrated housing, within which, using a suitable connection arrangement 174, such as internal buses (including inter-IC (I2C) buses), wiring, and printed circuit boards as known in the art, various components can be interconnected and data can be transferred between them.

[0105] System 150 includes a communication interface 160, which enables communication with other devices via a communication channel 162. The communication interface 160 may include, but is not limited to, a transceiver configured to transmit and receive data via the communication channel 162. The communication interface 160 may include, but is not limited to, a modem or network interface card (NIC), and the communication channel 162 may be implemented, for example, in a wired and / or wireless medium.

[0106] In various embodiments, using wireless networks, such as Wi-Fi networks, such as IEEE 802.11 (IEEE stands for Institute of Electrical and Electronics Engineers), data is streamed or otherwise provided to system 150. Wi-Fi signals in these embodiments are received via a communication channel 162 and communication interface 160 adapted for Wi-Fi communication. The communication channel 162 in these embodiments 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 embodiments use a set-top box to provide streaming data to system 150, with the set-top box delivering data via an HDMI connection in input block 172. Other embodiments use an RF connection in input block 172 to provide streaming data to system 150. As indicated above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, such as cellular networks or Bluetooth networks.

[0107] System 150 is capable of providing output signals to various output devices, including display 176, speaker 178, and other peripheral devices 180. Display 176 in various embodiments includes one or more of, for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. Display 176 can be used in televisions, tablet computers, laptop computers, cellular phones, or other devices. Display 176 can also be integrated with other components (e.g., as in a smartphone) or separate (e.g., as an external monitor for a laptop computer). In various examples of embodiments, other peripheral devices 180 include one or more of a standalone digital video disc (or digital universal disc) (DVR, used for both terms), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 180 that provide functionality based on the output of system 150. For example, a disc player performs the function of playing the output of system 150.

[0108] In various embodiments, control signals are transmitted between system 150 and display 176, speaker 178, or other peripheral devices 180 using signaling (such as AV.Link, Consumer Electronics Control (CEC)) or other communication protocols that enable device-to-device control with or without user intervention. Output devices can be communicatively coupled to system 1000 via dedicated connections through corresponding interfaces 164, 166, and 168. Alternatively, output devices can be connected to system 150 via communication interface 160 using communication channel 162. In electronic devices (such as, for example, televisions), display 176 and speaker 178 can be integrated with other components of system 150 into a single unit. In various embodiments, display interface 164 includes a display driver, such as, for example, a timing controller (TCon) chip.

[0109] For example, if the RF section of input 172 is part of a separate set-top box, then display 176 and speaker 178 can alternatively be separate from one or more other components. In various embodiments where display 176 and speaker 178 are external components, output signals can be provided via dedicated output connections (including, for example, HDMI ports, USB ports, or COMP outputs).

[0110] System 150 may include one or more sensor devices 168. Examples of usable sensor devices include one or more GPS sensors, gyroscope sensors, accelerometers, light sensors, cameras, depth cameras, microphones, and / or magnetometers. Such sensors can be used to determine various information, such as the user's position and orientation. Where system 150 is used as a control module (such as control modules 124, 132) for an extended reality display, the user's position and orientation can be used to determine how to render image data so that the user perceives the correct portion of a virtual object or scene from the correct viewpoint. In the case of a head-mounted display device, the device's own position and orientation can be used to determine the user's position and orientation for rendering virtual content. In the case of other display devices (such as telephones, tablets, computer monitors, or televisions), other inputs can be used to determine the user's position and orientation for rendering content. For example, using a touchscreen, keypad or keyboard, trackball, joystick, or other inputs, the user can select and / or adjust the desired viewpoint and / or direction of observation. When the display device has sensors (such as accelerometers and / or gyroscopes), the viewpoint and orientation used to render content can be selected and / or adjusted based on the movement of the display device.

[0111] The embodiments can be implemented through computer software implemented by processor 152, or through hardware, or through a combination of hardware and software. As a non-limiting example, the embodiments can be implemented using one or more integrated circuits. Memory 154 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 non-limiting examples. Processor 152 can be of any type suitable for the technical environment and, as a non-limiting example, can include one or more of microprocessors, general-purpose computers, special-purpose computers, and processors based on multi-core architectures.

[0112] This application relates to the field of communication systems for video streaming, and aims to provide a signaling mechanism that enables a display to control its power usage and the quality of rendered video on the screen of a desktop or laptop computer, smartphone, tablet computer, set-top box, or internet-connected television in the context of DASH delivery, DASH delivery being specified in ISO / IEC 23001-10; ISO / IEC 23009-1, Dynamic Adaptive Streaming over HTTP (DASH) — Part 1: Media Presentation Description and Segment Formats (“ISO / IEC 23009-1”); and ISO / IEC 23009-3, Dynamic Adaptive Streaming over HTTP (DASH) — Part 3: Implementation Guidelines (“ISO / IEC 23009-3”).

[0113] Reducing the energy consumption of electronic devices has become not only a requirement for electronics manufacturers, but also a necessity to minimize environmental impact and contribute to the emergence of a sustainable display industry. The increase in display resolution, from SD to HD to 4K and soon to 8K and even higher, along with the introduction of high dynamic range imaging, has led to a corresponding increase in the energy requirements of display devices. Conversely, there is a global need to reduce energy consumption. In fact, displays are a source of energy consumption, whether for battery-powered devices (e.g., smartphones) or in the global video distribution chain.

[0114] Organic light-emitting diode (OLED) displays are becoming increasingly popular compared to non-emissive displays (such as thin-film transistor liquid crystal displays (TFT-LCDs)) due to their many advantages. Instead of using uniform backlighting, OLED displays use LEDs as image pixels. OLED power consumption is therefore highly dependent on the image content and can be easily estimated by taking into account the brightness levels of the displayed image pixels. Although OLED displays consume energy in a more controlled and efficient manner, they remain the most significant energy source in the video delivery chain.

[0115] Therefore, the following is interesting: carefully studied energy-sensing images, i.e., those that require less energy when displayed on CE displays (especially OLED displays). An example of such careful study is discussed in '518 application, which discusses a technique for building energy-sensing images based on learning from dimming maps with favorable properties such as smoothness and scalability.

[0116] When in a video decoding chain, the question arises as to where this process of creating an energy-aware image should be applied, and several stages may be envisioned: at the encoder, at the decoder, or at the display side.

[0117] Applications '518 and '066 discuss a method for signaling a dimming map and making it available on the display side of a video decoding chain. In this solution, a new SEI message is created, and the dimming map is transmitted as supplementary data to the receiver side.

[0118] '958 application discusses a method for signaling a dimming map to be transmitted via an interactive streaming application and made available on the display side of a video decoding chain. In this application, a new track is created for the dimming map and associated with a rendered video for which the receiver expects reduced power consumption. The application also discusses new attributes for the @AdaptationSet and Representation elements in the DASH MPD manifest file.

[0119] This application aims to propose alternatives to the new @AdaptationSet and @Representation attributes by using at least one metadata track carrying attenuation map information that follows the storage format of timing metadata within the ISO basic media file formats (ISO / IEC 14496-12 and ISO / IEC 15444-12).

[0120] Figure 2This is a schematic illustration of an exemplary DASH system architecture according to some embodiments. In the MPD manifest file specified for HTTP Dynamic Adaptive Streaming (i.e., DASH), this new timing metadata track carrying attenuation map information is signaled, enabling continuous delivery of media content from a standard HTTP server to an HTTP client and enabling content caching via a standard HTTP cache.

[0121] Figure 2 The illustration shows an example of a DASH-based adaptive streaming system 200. System 200 includes a DASH server 206 and a DASH client 210. The server 206 is implemented, for example, via a content provider server, and the DASH client is implemented, for example, using a display device. When the DASH client 210 wants to play multimedia content in adaptive streaming, it first obtains a Media Presentation Description (MPD), also known as a manifest, which describes how such multimedia content can be obtained. Typically, this is achieved, for example, via the HTTP protocol represented by HTTP caching 208 or via other means (e.g., broadcast, broadband service description, etc.), by obtaining the manifest from a URL (Uniform Resource Locator). The manifest is pre-generated via DASH Media Presentation Preparation / Description 202. The manifest can be static or dynamically updated. The manifest lists available representations of the multimedia content, also known as instances or versions, which vary in terms of decoding bitrate, image resolution, and other properties. A representation can be associated with a given quality level expressed as a bitrate. Each representation of the data stream is provided by DASH segment delivery function 204 and is divided into segments (also referred to as chunks) of equal duration (e.g., a few seconds) accessible by separate URLs. These segments are prepared by DASH media rendering preparation. Different versions of each segment are prepared and ready to be provided to the client. When playing multimedia content, the DASH client can smoothly switch from one quality level to another between two segments to dynamically adapt to network conditions. When low bandwidth is available, the client requests low bitrate chunks, and when higher bandwidth becomes available, they can request higher bitrate chunks. As a result, video quality may vary during playback, but interruptions (also referred to as stuttering) are rare.

[0122] On the client side, segments can be selected based on measurements of the available bandwidth of the transmission path. DASH clients typically request representations of segments corresponding to bitrate encoding, and therefore, request quality consistent with the measured bandwidth.

[0123] Figure 3 This is a schematic diagram illustrating an exemplary hierarchical system for MPD XML manifest files according to some embodiments. Figure 3The illustration shows an exemplary structure 300 of a DASH-based media presentation description 302. The media presentation description 302 includes time period elements 304, 312 of equal length (60 seconds in this example) (regular time periods, advance available time periods, etc.). Each time period is identified by a time period ID, a start value, and a duration, where the start value represents the start time of the first frame of the multimedia content for that time period. Each time period includes one or more adaptive sets 306, 314, which contain alternative representations 308, 316 of multimedia components considered perceptually equivalent. The adaptive sets and their contained representations are prepared and contain sufficient information to enable seamless switching between different representations across an adaptive set. Multimedia content components include video, audio, teletext, captions, etc. Each representation 308, 316 includes segment information 310, 318, which itself includes different sub-segments 320, each sub-segment having a relative start time for the current segment. The adaptive sets and their contained representations may differ from one time period to another.

[0124] In some embodiments, a mechanism for transmitting pixel-by-pixel attenuation maps in an adaptive video streaming environment enables a receiver device to control its power reduction rate when displaying video. Some embodiments of adaptive sets for DASH may have an identifier (@id) attribute that includes the string "ami," representing, for example, "attenuation map information," or the attribute may include another string representing a concept of attenuation map signaling (e.g., "dm" for dimming maps, "dpr" for display power reduction). The DASH server and DASH client are aware of this string. This identifier indicates that the adaptive set includes attenuation map information. This adaptive set allows the DASH MPD to list pixel-by-pixel attenuation map representations available on the DASH server as different representations. This adaptive set also allows the DASH client to select one of the representations to control its power reduction rate when displaying video. Instead of using the identifier @id="ami" to identify new types of adaptive set elements, the adaptive set attribute @contentType may be set to, for example, "Attenuation Map" or "am" or other strings to indicate that the adaptive set element signals the attenuation map representation. For simplicity, the term @id="ami" will be used in the remainder of this application.

[0125] The DASH client can also select, for example, multiple "ami" adaptive sets identified by @id="amiX" (where X is in the range 0..n) in the MPD manifest file, and thus allows selection of a suitable attenuation map corresponding to the selected energy reduction, where the adaptive sets have different values ​​for the energy reduction. The same principle applies to other parameters of the adaptive sets. Depending on its energy consumption strategy, the DASH client may ignore the "ami" adaptive sets. In this case, the DASH client does not request a pixel-by-pixel attenuation map representation, and the video is displayed without any modification. As a result, the DASH client may not benefit from the energy reduction.

[0126] For some embodiments, the "ami" adaptive set provides information about the following: how to use the pixel-wise attenuation map representation, the type of display to which the attenuation map representation is applied, the type of post-processing used for further use of the attenuation map representation, the type of downsampling used as preprocessing before using the attenuation map representation on the image and its subsequent upsampling (if any downsampling and subsequent upsampling exist), and some indicative measures of the expected energy reduction and expected quality effect of using such attenuation map representation.

[0127] In some embodiments, within the DASH MPD, the "ami" adaptive set is dynamically updated according to time periods, and the granularity of the update can be based on time (according to the time period / duration of the video content), time layer (according to time layer), slice type (according to intra-frame and inter-frame slices), or parts of the image (slices, tiles, sub-images). MPDs including adaptive sets with @id="ami" are hereby named AMI-MPD. On the DASH server, this MPD is generated based on information provided by a processing block, which handles the generation and encoding of attenuation maps from the input image. The AMI-MPD is parsed by the DASH client. In response, a pixel-wise attenuation map representation, for example, corresponding to a target attenuation rate, is selected and requested by the DASH server. When the information from the adaptive set and the representation are received, they are provided to the media engine and, as needed, to the post-processing module to apply the selected attenuation map representation to the video component representation. This operation results in reduced power consumption for the DASH client, as the displayed image uses less energy compared to the original image.

[0128] In some embodiments, multiple attenuation map representations are requested and combined together. This operation allows the generation of new attenuation maps with intermediate reduction rates, which are not directly present in the list of attenuation map representations. New attenuations can be generated by interpolating two attenuation map representations according to a weighted average corresponding to the respective attenuation rate. In this enhanced ecosystem, DASH servers and clients are energy-sensing devices in the following sense: energy-sensing DASH servers prepare the necessary data to allow energy-sensing DASH clients to control their energy consumption by selecting, receiving, and applying pixel-by-pixel dimming maps.

[0129] Additional signaling enables the dash player to select a video media representation, one or more complementary attenuation maps (or dimming maps), and one or more timing metadata representations to modify the video and reduce power consumption while displaying it on the receiver device's screen or a screen connected to the receiver. A timing metadata representation may be associated with one or more attenuation map representations.

[0130] Currently, as is generally understood, control over the energy impact of displayed video is quite limited and is not linked to pixel-by-pixel information declared as a batch of resource identifiers within the DASH Media Rendering Description (MPD) manifest file. The standard ISO / IEC 23001-11, Energy-Efficient Media Consumption (Green Metadata), specifies metadata (green metadata) that promotes reduction in energy use during media consumption (decoding and display operations), and specifically, for reducing display power consumption.

[0131] Metadata used for display adaptation is defined in the chapter "Displaypower reduction using display adaptation" of the standard ISO / IEC 23001-11. They are particularly well-suited for non-emissive pixel display technologies with embedded backlighting, such as LCDs. They are designed to achieve display power reduction through the use of display adaptation techniques, which dynamically generate RGB component statistics and quality indicator metrics on the emitter side regarding the consumed video content. They can be used to perform RGB image component rescaling to set the best compromise between backlight / voltage reduction and image quality, reducing voltage and thus allowing for reduced power consumption. However, this metadata conveys global information and should never be interpreted as not conveying any information that would help with the use of per-pixel attenuation maps, as such maps are useless for non-emissive pixel type displays.

[0132] The document ISO / IEC 23001-11 (Annex B.3) specifies how to convey these display green metadata in adaptive streaming as a DASH timing metadata representation with the @codecs attribute="dipi", which can be obtained by the decoder and used to perform post-processing on all available media representations and reduce power consumption.

[0133] Although applications '566 and '068 describe user data SEI messages registered by ITU-T Recommendation T.35, the generality of such messages makes their use inefficient for some current use cases. Application '908 describes a new SEI message that is communicated within the codec signaling and is designed to guide the use of pixel-by-pixel attenuation maps.

[0134] The challenge is how to provide information within the DASH MPD inventory derived from and related to dimming or attenuation maps for further use in the careful study of energy-sensing images at the receiver side (e.g., the OTT ecosystem). The information carried by the green video timing metadata representation is related to the attenuation map representation associated with the video representation.

[0135] This information enhances the ability of service providers to use the methods described herein, rather than using SEI messages and auxiliary data within the codec bitstream as described in applications '719 and '185. As is generally understood, there is no mechanism or signaling for providing information within the DASHMPD designed to reduce power consumption in the video representation on a pixel-by-pixel basis.

[0136] Figure 4 This is a list of codes for an exemplary green video information structure according to some embodiments. Figure 4 Example code list 400 is shown. The standard ISO / IEC 23001-11 specifies metadata intended to signal information for display adaptation. This metadata may include RGB component statistics and quality indicators for the video content. The statistics are used to set display controls in the presentation subsystem to achieve the desired quality level and corresponding display power reduction. In dynamic adaptive streaming, the metadata (see the section "Display power reduction using display adaptation" in the ISO / IEC 23001-11 document) is sent in a dedicated "green video" adaptation set, which has multiple representations associated with different representations of the "video" adaptation set: An adaptive set with id="green_video" conveys metadata about the reduction in energy consumption by the display, and each association conveys global information (such as v0, v1, v2, ...) about statistics obtained from the input content of each representation. This adaptive set does not allow the DASH client to be notified of the availability of one (or more) per-pixel attenuation maps on the content DASH server, but once used on the DASH client, this adaptive set allows for more precise control over both energy reduction and experience quality, and allows for reduced bitrate overhead because only the attenuation map selected by the DASH client is transmitted from the DASH server. Figure 4 An example of such an adaptive set with id="green_video" is shown. Different @codecs values ​​allow selection of either "display information" or "attenuation map information," already specified in ISO / IEC 23001-11. This allows data that will not be used by the receiver to be excluded from download.

[0137] This application uses an adaptive set with id="ami" (attenuation map information) in DASH MPD to list the available pixel-by-pixel attenuation maps on the DASH server, and allows DASH clients to select one or more pixel-by-pixel attenuation maps or not select any pixel-by-pixel attenuation maps, and control the energy reduction rate when displaying video on their monitor.

[0138] The selection and use of attenuation maps(s) by the receiver is performed by parsing an adaptive set with id="green video" and the @codecs attribute value "amii" (attenuation map information indicator). This adaptive set element contains a list of timing metadata representations associated with the attenuation maps(s) using the attribute @associationType="cdsc".

[0139] In the ISO Basic Media File Format (ISOBMFF) (ISO / IEC 14496-12 and ISO / IEC 15444-12), timing metadata represents the track-carried attenuation map information indication (AMII) metadata type (this metadata type is "amii"). The corresponding storage format of the attenuation map information metadata in ISOBMFF is identified by a unique sample entry code.

[0140] For some embodiments, Attenuation Map Information (AMI) metadata is provided as follows: • How to use pixel-by-pixel attenuation maps • The type of display to which the attenuation map is applied. • Types of processing used for further use of attenuation maps, • The type of downsampling used for preprocessing before applying the attenuation map to the image, and its subsequent upsampling (if any downsampling and subsequent upsampling exist). • Some indicative measures of the expected energy reduction and expected mass effect using this decay map. A DASH client can decide whether to use an adaptive set with id="ami" and / or an adaptive set with id="green video" and @codecs="amii" based on its power consumption strategy. In some embodiments, if the client decides "not to use," the DASH client does not request the green video metadata with @codecs="amii" and the pixel-by-pixel attenuation map representation, and the video is displayed without any modification. In some embodiments, if the client decides "to use," the green video metadata with @codecs="amii" and the associated pixel-by-pixel attenuation map are requested, obtained, and, based on the information in the green video metadata, the DASH client applies the attenuation map to the video to reduce power consumption on the display side.

[0141] Within DASH MPD, adaptive sets with id="ami" and id="green_video" with @codecs="amii" are dynamically updated according to time periods, and the granularity of the update can be based on: • Time: According to the time period / duration of the video content.

[0142] • Time layer: According to time layer • Slice type: Sliced ​​by intra-frame and inter-frame • Parts of the image: slices, tiles, sub-images In some embodiments, information provided by a carefully studied processing block responsible for attenuation maps is used to generate an MPD, an adaptive set with id="ami", and an adaptive set with id="green video" and @codecs="amii" on the DASH server.

[0143] In some embodiments, the operation may occur as described herein. The DASH client parses an adaptive set with id="ami" and an adaptive set with id="green video" and @codecs="amii" from the MPD. One or more pixel-wise attenuation maps are requested from the DASH server, and the pixel-wise attenuation maps are received. Information and representations within the adaptive sets are sent to the decoder and post-processing block to apply the attenuation maps to the video components.

[0144] In some embodiments, a system may include an encoder, a starter server wrapper, and a decoder. The encoder is required to create signal energy-related metadata into a bitstream. The decoder is required to decode this metadata.

[0145] In the ISO Basic Media File Format (ISOBMFF) (ISO / IEC 14496-12 and ISO / IEC 15444-12), metadata syntax and semantics are provided in the form of attenuation map information metadata type (“amii”). The affected codec blocks are not depicted in the accompanying figures because they involve the high-level syntax carried in the SEI message.

[0146] This application describes a novel adaptive set id for DASH MPD to signal one or more attenuation maps, thereby reducing the power consumption of a display, which may be located on or associated with a client. In some embodiments, this adaptive set in DASH MPD has id="ami". In addition to various representations of video media components, this adaptive set also relates to one or more attenuation map representations (which may exist on the DASH server side). Information associated with these attenuation maps can be carried in a timing metadata representation having id="green video" and attribute value @codecs="amii". This application can be implemented on both the DASH server and client sides for media delivery.

[0147] DASH server Figure 5 This is a schematic illustration showing the preparation of exemplary video and attenuation map representations on the Dash server side according to some embodiments. Figure 5 In this process, the input video 502 is supplied to the dash system 500 on the server side. This entity can handle the presentation preparation startup and manage the following items: • Different video component representations are encoded using 504 without any modification to existing technologies. As is generally understood, other systems can provide functionality to encode different video representations and signal different video representations.

[0148] • In the graph calculation and encoding of entity 506, attenuation graphs 514, 516, 518, 520, 522, and 524 with different energy reduction rates are calculated and encoded.

[0149] • Create attenuation map information timing metadata of type "amii" and store it in accordance with the ISO basic media file format (i.e., ISOBMFF) (ISO / IEC 14496-12 and ISO / IEC 15444-12).

[0150] • Insert a new adaptive set with id="ami" and a decay map representation associated with the video representation into the MPD manifest file.

[0151] • Insert an adaptive set with id="green video" and a timing metadata representation of the attenuation map information associated with the attenuation map representation into the MPD manifest file.

[0152] The outputs of one or more encoding and attenuation map calculation blocks 514, 516, 518, 520, 522, and 524 are transmitted to DASH delivery block 508, which can create segments of the following media components: • Segments representing different video representations (different bitrates, spatial resolutions, frame rates, etc.). • The segment represented by the attenuation map, • Attenuation map information, timed metadata representation of the segment The MPD manifest file is transmitted to the MPD delivery function 526 in response to any requests from the DASH client 512.

[0153] The segment format can be based on ISOBMFF, which utilizes segmented movie files. As defined in ISO / IEC 14496-12, (sub)segments are encoded as movie clips, which contain track clips and have independently decodeable constraints.

[0154] For performance reasons, segments may be cached in the HTTP cache 510. In some embodiments, for segments with multiple video representations, only the requested attenuation map representation and the associated attenuation map information timing metadata representation exist in this cache. The dash client requests the attenuation map representation from the information in the MPD manifest file (attenuation map information timing metadata representation) according to its energy reduction strategy.

[0155] Figure 5 The illustration shows an example of an architecture for an energy-aware DASH server according to an embodiment. This architecture is implemented, for example, by a content provider server. The raw input video is supplied to the dash system, supplied to encoded blocks, and the encoded blocks are combined... Figure 2 and 3The preparation and encoding of the input video involves segmenting the video into sections and encoding these sections for different video representations, such as different bitrates, different spatial resolutions, and / or different frame rates. From the decoded images of these different video representations, the graph generation module determines a set of corresponding attenuation maps, one for each decoded image. Using the same principles as with the video segments, these maps are then encoded in a conventional manner into so-called attenuation map representations. Multiple attenuation map representations can be used, for example, with different energy reduction rates, as shown in the figure (one representation has a 10% reduction, and a second representation has a 20% reduction). By driving the encoding module and the graph generation module, the DASH media presentation preparation module handles the preparation of data used within the system, such as establishing a set of different bitrates, different spatial resolutions, and / or different frame rates for different video representations and listing the reduction rates for which attenuation maps should be generated. Based on the metadata obtained from the encoding module and the graph generation module, the DASH media presentation preparation module 528 then generates an MPD manifest file, which includes an "ami" adaptive set and attenuation map representations. This metadata provides information on the element attributes of the adaptive set and representation (e.g., energy reduction rate, use of attenuation maps). The MPD manifest file is provided to the MPD delivery function in response to requests from the DASH client. Data generated by the encoding module and the graph generation module is combined by the DASH segment delivery function to create segments with different video representations and attenuation map representations. These segments (including video-related segments and corresponding attenuation map representations (i.e., 10% or 20% in the example in the attached figure)) will then be retrieved by the DASH client based on the information in the MPD manifest file and the selected energy reduction strategy. As follows... Figure 6 The DASH client will then apply attenuation to the video to produce an energy-sensing image 480, which will require less energy when displayed on the screen compared to the original image.

[0156] For performance reasons, segments are cached in the HTTP cache. This caching is handled so that only the relevant segments of the selected video representation among the various video representations and only the segments of the selected attenuation map representation exist in the cache, thus ensuring minimal load on the network. The segment format is based on ISOBMFF using segmented movie files, as defined in ISO / IEC 14496-12, where (sub)segments are encoded as movie clips, which contain track clips with independently decodeable constraints.

[0157] DASH Clients Figure 6 This is a schematic illustration showing an exemplary DASH client interface according to some embodiments. Figure 6An exemplary DASH client architecture 600 is shown, which has the ability to generate an adaptive set of attenuation maps. In some embodiments, video media and timing AMI metadata, as well as AM HTTP requests / segments, may be exchanged between the DASH server 602 and the DASH access engine 606 via an HTTP cache 604.

[0158] Figure 6 The illustration shows an example of an architecture 600 for an energy-sensing DASH client according to an embodiment. This architecture is implemented, for example, by a display device. Figure 6 The diagram illustrates the logical components of a DASH client 608 and their relationship to other components in a media streaming application. The DASH client 608 operates under the control of a media streaming application 610. A DASH access engine 606 requests and receives a Media Presentation Description (MPD) from a server. The MPD contains information related to both the video media component representation and an "ami" adaptive set, which has a list of attenuation map representations associated with the video media component representation. In some embodiments, the DASH access engine 606 may also request attenuation map information timing metadata representations using an adaptive set with id="greenvideo" and @codecs="amii". Energy reduction metadata is provided to a selection logic module. This energy reduction metadata includes information about the attenuation map representation, how the attenuation map representation is used to reduce energy consumption when the video components are presented on the display, the desired rate of reduction, and associated quality or experience metrics. Through interaction with an energy consumption module, the selection logic module 612 can use the energy reduction metadata to select the media components for the service requested by the media streaming application. This module receives a power profile from the media streaming application 610, determined by the device itself or the end user's power reduction strategy, and provides the requested reduction rate to the selection logic module 612. When the representation is selected, the media streaming application 610 configures the decoding module 614 (e.g., codec, number of attenuation map representations, etc.), attenuation map post-processing 616, video and attenuation map application module 618, and rendering module 620. Therefore, the DASH access engine requests and receives the video media segment and attenuation map representation segment corresponding to the selected representation. The attenuation map and video component representations are decoded by the decoding module. The attenuation map representation may be post-processed (e.g., up-scaling) as needed. The attenuation map representation is combined with the video by the application module, and the resulting video is rendered on the display by the video rendering module.

[0159] Figure 6The diagram illustrates the logical components of a conceptual DASH client model and their relationship to other components in a media streaming application. In this diagram, the DASH access engine requests and receives a Media Presentation Description (MPD), constructs and issues a request based on its energy reduction strategy, and receives segments or portions of segments. The MPD includes: video media component representations; a new attenuation map adaptive set with id="ami", containing a list of attenuation map representations associated with the video component representations (@associationType="amit"); and a green video adaptive set with @codecs="amii", containing a list of attenuation map information timing metadata representations associated with the attenuation map representations (@associationType="cdsc").

[0160] DASH clients can use attenuation map information timing metadata obtained from one or more representations of a green video adaptive set associated with one or more attenuation maps (@associationType="cdsc") with @codecs="amii" to select an attenuation map through communication with the media streaming application and understanding of the energy reduction strategies of the device itself or the end user. New information related to this application may be provided and may include information about attenuation maps and how attenuation maps are used to reduce energy consumption when video components are presented on a display.

[0161] In some implementations, the DASH access engine performs the following actions: • Request attenuation map information periodic metadata representation segment, • Obtain information related to one or more attenuation maps. • Determine whether the relevant attenuation map(s) matches the energy reduction strategy of the device or end user. • Select one or more attenuation maps and one or more video components • Output media and attenuation maps and timing information according to the MPEG container format or a portion thereof. The timing information maps the internal timing of the continuous media to the timeline of the media presentation.

[0162] The attenuation map and video component representation are decoded, the attenuation map is applied, and the resulting video is rendered on the display.

[0163] Attenuation map information timing metadata Obtain the timing metadata of the attenuation map information from the timing metadata representation of the green video adaptive set that has @codecs="amii" and is associated with one or more attenuation maps (@associationType="cdsc").

[0164] This information can be carried as a sample entry in the ISOBMFF file, where the unique value of @codecs is "amii". This sample entry is standardized in the ISO / IEC 23001-10 specification.

[0165] Attenuation map information sample entry definition Sample entry type: "amii" Container: Sample descriptor box (“stsd”) Mandatory: No Quantity: 0 or n Sample entries are stored in a sample description box (“stsd”).

[0166] Attenuation map information sample entry syntax The metadata for the sample decay map is as follows: class AttenuationMapInformationIndicationMetaDataSampleEntry() extends MetaDataSampleEntry('amii') { } Figure 7A-9B The example shown is based on this Sample Attenuation Map Information Indication (AMII) class structure.

[0167] Figures 7A-7B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Figure 7A and 7B Exemplary code lists 700 and 750 are shown. Each representation of the green video adaptive set with @codecs="amii" carries information from only one attenuation map.

[0168] Figures 8A-8B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Figure 8A and 8B Exemplary code lists 800 and 850 are shown. Each representation of the green video adaptive set with @codecs="amii" carries information about several attenuation maps in separate sample entries. An amID data field is added to identify the attenuation map (e.g., the amID variable could be the track ID of the attenuation map associated with the information) and to obtain the relevant attenuation map information.

[0169] Figures 9A-9B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Figure 9A and 9BExemplary code lists 900 and 950 are shown. Each representation of the green video adaptive set with @codecs="amii" carries information about several attenuation maps in a unique sample entry. Figure 7B In comparison, the amID data field is... Figure 9B An index is added to identify the attenuation map and retrieve related attenuation map information. The amiAmNumber field stores the amount of the attenuation map with associated attenuation map information. The index value i from 0 to (amiAmNumber-1) is used in conjunction with the attenuation map information array and function calls in the class AttenuationMapInformationIndicationMetaDataSample.

[0170] Figures 10A-10B A list of codes for forming an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Figure 10A and 10B Exemplary code lists 1000 and 1050 are shown. Each representation of the green video adaptive set with @codecs="amii" carries information about several attenuation maps in a unique sample entry. For some embodiments, such as Figure 10B As shown in the example, with Figure 9B In comparison, the amID data field has been removed.

[0171] The amiAmNumber field stores the amount of the attenuation map with associated attenuation map information. This associated attenuation map information is referenced by a separate box class, TrackReferenceBox, within the track box that carries the attenuation map information. This TrackReferenceBox class uses an array of TrackReferenceTypeBox[] for this reference. The index value i from 0 to (amiAmNumber-1) is an index used in conjunction with the array of attenuation map information and function calls in the AttenuationMapInformationIndicationMetaDataSample class, and corresponds to the track_IDs[] array of the TrackReferenceTypeBox box that references the type "damt" ("damt" is an abbreviation for the type of attenuation map displayed). In some embodiments, the amiAmNumber field can be, for example, 1 or 2, and the amID field is not used within the AttenuationMapInformationIndicationMetaDataSample class.

[0172] Table 1 describes each of these new attributes. Attribute Name describe amiCancelFlag The current decay map information sample cancels the persistence of any previous samples. amiDisplayModel This indicates which type (and which types) of display the attenuation map should be applied to on the receiver side. For example, amiDisplayModel can indicate all types of emitting displays, such as OLED displays. amiMapApproximationModel Indicates which type of interpolation model should be used to infer a decay map with a different rate of decrease than the available decay map. amiAttenuationUseIdc Indicates which type of processing should be used to apply the current attenuation map(s) to the associated video component representation to be displayed. For example, the attenuation map can be subtracted, added, or multiplied with the associated video component representation, thereby reducing the level of pixel values. amiAttenuationCompIdc While applying one or more attenuation maps, indicate the mapping between the components of the attenuation map and the components represented by the associated video components. amiBoxXstart Define the x-coordinate of the bounding box, which defines the area where the attenuation map will be applied to the associated video component representation. amiBoxYstart Define the y-coordinate of the bounding box, which defines the area where the attenuation map will be applied to the associated video component representation. amiBoxWidth Define the width of the border, which defines the area where the attenuation map will be applied to the associated video component representation. amiBoxHeight Define the height of the border, which defines the area where the attenuation map will be applied to the associated video component representation. amiPreprocessingFlag Specify that attenuation map samples should be presampled before being applied to the associated video component representation. amiPreprocessingTypeIdc Specify the recommended type of interpolation (e.g., bicubic interpolation) used to presample the attenuation map samples before applying the attenuation map to the associated video component representation. amiPreprocessingScale Specifies which scaling should be applied to the attenuation map to obtain attenuation map sample values ​​before applying the attenuation map to the associated video component representation. amiBacklightScalingFlag This specifies the procedure for calculating the scaling factor of the backlight of a transmissive pixel display derived from attenuation map sample values. amiBacklightScalingIdc Specify the procedure for calculating the scaling factor of the backlight of the transmissive pixel display obtained from the attenuation map sample values. amiMaxValue Indicates the maximum value of the attenuation map. This maximum value can optionally be used to further adjust the dynamics of the encoded attenuation map during scaling. amiEnergyReductionRate The percentage for the current decay map indicates the corresponding level of energy reduction that can be expected through the use of this decay map. amiQualityMetric Indicates the quality metric considered when amiVideoQualityReduction is calculated. amiVideoQualityReduction This indicates a decrease in video quality compared to the nominal value after applying an attenuation map to reduce the energy of the original image. Table 1.

[0173] Attenuation map information sample entry semantics Setting amiCancelFlag to 1 indicates that the persistence of this sample is canceled according to the output order, indicating any previous decay map information. Setting amiCancelFlag to 0 indicates that the decay map information parameter follows. This flag is used for... Figure 7B , 8B The exemplary code shown in 9B, and the value of 0 for amiCancelFlag (or "ami_cancel_flag" as used in the sample code) allows the rest of the class to be created and used. Some embodiments may use the amiCancelFlag attribute, while others may not.

[0174] In Table 2, the amiDisplayModel attribute is a bit field mask indicating which display models the attenuation map can be used with. An example of amiDisplayModel = 3 means that the attenuation map can be used with both non-emissive and emissive display models. Bit Model Bit 0 Non-emission Bit 1 emission Position 2.3 Reserved for future types Table 2.

[0175] The attribute amiMapApproximationModel shown in Table 3 illustrates a model for extrapolating (one or more) decay map sample values ​​from a set of decay maps with (one or more) individual energy reduction rates to another set of decay map sample values ​​with different energy reduction rates.

[0176] Setting amiMapApproximationModel to 0 indicates that, taking into account its corresponding amiEnergyReductionRate, linear scaling of the decay map sample values ​​of the current decay map should be considered to obtain the corresponding decay map sample values ​​for another energy reduction rate.

[0177] Setting amiMapApproximationModel to 1 indicates that, taking into account its corresponding amiEnergyReductionRate, interpolation of the current decay map sample values ​​of the Lanczos type should be considered to obtain the corresponding decay map sample values ​​for another energy reduction rate.

[0178] Setting amiMapApproximationModel to 2 indicates that, taking into account its corresponding amiEnergyReductionRate, a bicubic interpolation between the current decay map sample values ​​should be considered to obtain the corresponding decay map sample values ​​for another energy reduction rate.

[0179] Setting amiMapApproximationModel to 3 indicates that a proprietary, user-defined process can be used to infer the corresponding decay map sample value for another energy reduction rate from the decay map sample value, taking into account the corresponding amiEnergyReductionRate. value The process of interpolating another attenuation map 0 linear scaling 1 Lanczos interpolation 2 Bicubic interpolation 3 User-defined 4..15 Reserved for future use Table 3.

[0180] The approximate model is applicable to all decay map representations within the current adaptive set.

[0181] `amiBoxXstart`, `amiBoxYstart`, `amiBoxWidth`, and `amiBoxHeight` define the x-coordinate, y-coordinate, width, and height of the border, respectively. This border defines the area of ​​the decoded image to which the attenuation map will be applied. The size of the attenuation map is thus defined.

[0182] Table 4 shows the amiAttenuationUseIdc attribute to indicate how the attenuation map is used.

[0183] Setting the attribute amiAttenuationUseIdc to 0 specifies that the attenuation map sample should be added to the sample represented by the associated video component before being displayed on the screen.

[0184] Setting the attribute amiAttenuationUseIdc to 1 specifies that the attenuation map samples should be subtracted from the samples represented by the associated video components before being displayed on the screen.

[0185] Setting the attribute amiAttenuationUseIdc to 2 specifies that the attenuation map sample should be multiplied by the sample represented by the associated video component before being displayed on the screen.

[0186] Setting the attribute amiAttenuationUseIdc to 3 specifies that, before being displayed on the screen, the attenuation map sample should be used as a sample of the associated video component representation, according to a proprietary user-defined process. value The process applied to the associated main image decoded sample 0 addition 1 Subtraction 2 multiplication 3 User-defined 4..15 Reserved for future use Table 4.

[0187] Table 5 shows how the attribute amiAttenuationCompIdc can be specified to indicate which (or which) components of the associated video component representation the attenuation map can be applied to using the procedure defined by @amiAttenuationUseIdc. The attribute amiAttenuationCompIdc can also specify how many components the attenuation map should contain.

[0188] Setting the attribute amiAttenuationCompIdc to 0 specifies that the attenuation map contains only one component, and this component should be applied to the luminance component represented by the associated video component.

[0189] Setting the attribute amiAttenuationCompIdc to 1 specifies that the attenuation map contains two components, and the first component should be applied to the luminance component represented by the associated video component, and the second component should be applied to the two chrominance components represented by the associated video component.

[0190] Setting the attribute amiAttenuationCompIdc to 2 specifies that the attenuation map contains only one component, and this component should be applied to the luminance and chrominance components represented by the associated video component.

[0191] Setting the attribute amiAttenuationCompIdc to 3 specifies that the attenuation map contains only one component, and this component should be applied to the RGB component of the associated video component representation (after YUV to RGB conversion).

[0192] Setting the attribute amiAttenuationCompIdc to 4 specifies that the attenuation map contains three components, and these components should be applied to the luminance and chrominance components represented by the associated video components, respectively.

[0193] Setting the attribute amiAttenuationCompIdc to 5 specifies that the attenuation map contains three components, and these components should be applied separately to the RGB components of the associated video component representation (after YUV to RGB conversion).

[0194] Setting the attribute amiAttenuationCompIdc to 6 specifies that the mapping between the associated video component representation and the component with the applied attenuation map corresponds to some proprietary, user-defined process. Table 5.

[0195] Table 6 shows how the attribute amiPreprocessingFlag can be used to instruct the attenuation map samples to be presampled before applying the attenuation map to the associated video component representation. If the attribute amiPreprocessingTypeIdc exists, it specifies the recommended type of interpolation (e.g., bicubic interpolation) for pre-sampling the attenuation map sample values.

[0196] Setting amiPreprocessingFlag to 0 specifies that bicubic interpolation between attenuation map sample values ​​should be taken into account to obtain attenuation map sample values, which are then applied to the sample values ​​of the associated video component representation.

[0197] Setting amiPreprocessingFlag to 1 specifies that interpolation of the type Lanczos between attenuation map sample values ​​should be taken into account to obtain attenuation map sample values, which are then applied to the sample values ​​of the associated video component representation.

[0198] Setting amiPreprocessingFlag to 2 specifies that a proprietary, user-defined process should be used to presample attenuation map sample values ​​for application to the sample values ​​of the associated video component representation. value The process of interpolating another attenuation map 0 Bicubic interpolation 1 Lanczos interpolation 2 User-defined 3..15 Reserved for future use Table 6.

[0199] Table 7 shows how the attribute amiPreprocessingScale can be used to indicate which scaling should be applied to the attenuation map to obtain attenuation map sample values ​​before applying the attenuation map to the associated video component representation.

[0200] Setting the amiPreprocessingScale attribute to 0 indicates that a scaling of 1 / 255 should be applied to the attenuation map. This is the preferred embodiment.

[0201] Setting the amiPreprocessingScale property to 1 indicates that a proprietary, user-defined scaling should be applied to the attenuation map. value Attenuation map scaling preprocessing 0 1 / 255 scaling 1 User-defined 2..15 Reserved for future use Table 7.

[0202] Table 8 shows how the attribute amiBacklightFlag can be used to indicate the process of calculating the scaling factor of the backlight of a transmissive pixel display derived from attenuation map sample values.

[0203] The attribute amiBacklightScalingIdc indicates the process of calculating the scaling factor of the backlight of the transmissive pixel display obtained from the attenuation map sample values.

[0204] Setting the amiBacklightFlag attribute to 0 indicates that the scaling of the backlight to be applied to the display is calculated as the ratio of the maximum value of the associated video component representation before and after the application of the attenuation map sample values. One or more associated video component representation samples for which attenuation map sample values ​​are applied are further rescaled to their maximum value before the application of the attenuation map sample values.

[0205] Setting the attribute amiBacklightFlag to 1 indicates that the scaling of the backlight to be applied to the display is determined based on a proprietary, user-defined process derived from the attenuation map sample value of the decoded auxiliary image at index i. This is summarized in Table 9 below. value Backlight scaling processing type 0 Scaled according to the ratio of the maximum value before and after using the attenuation map. 1..15 Reserved for future use Table 8.

[0206] The amiMaxValue attribute indicates the maximum value of the attenuation map. This maximum value can optionally be used to further adjust the dynamics of the encoded attenuation map during scaling.

[0207] The attribute `amiEnergyReductionRate` indicates the expected energy saving rate when the associated video component representation is displayed after applying the attenuation map sample values ​​of the current attenuation map. Example units for `@amiEnergyReductionRate` are percentages or values ​​in watts.

[0208] The `amiVideoQualityReduction` attribute indicates the quality of the displayed video after applying the attenuation map sample values ​​of the current attenuation map. Examples of metrics that can be stored in `@amiVideoQuality` are the PSNR, V-MAF, or SSIM values ​​of the modified image after applying the attenuation map.

[0209] These quality metrics can be calculated by the decoder, but to reduce energy consumption, they can also be inferred on the encoder side. In this case, they can correspond to the values ​​of the desired minimum quality.

[0210] Table 9 shows how the attribute amiVideoQualityMetric can be used to indicate a quality metric used to calculate video quality degradation when an attenuation map is applied to obtain the energy reduction rate. value Quality metric name 0x00 PSNR 0x01 SSIM 0x02 wPSNR 0x03 WS-PSNR 0x04 V-MAF 0x05..0x07 Reserved for future measurements Table 9.

[0211] The following exemplary XML manifest file provides an example of an MPD manifest file with information for energy reduction: Figure 11A-11B A list of codes that forms an exemplary MPD manifest file according to some embodiments. Figure 11A and 11B Exemplary code lists 1100 and 1150 are shown.

[0212] Figure 11A-11BThe diagram shows an adaptive set with id=ami and mimetype=video / mp4 corresponding to the type of attenuation map, and an adaptive set with id=green_video and codecs=amii corresponding to the type of timing metadata for attenuation map information. The representation elements of this adaptive set carry information about the attenuation maps listed below.

[0213] Figure 11A-11B Also shown is the attenuation map representation of id="ami0" associated with the video component representation id="v0", which can be used for both emitted and non-emitting displays, allowing for a 20% reduction in power consumption. An approximate model can be provided to generate other attenuation maps with different reduction rates on the DASH client side.

[0214] Figure 11A-11B This example represents a first exemplary MPD manifest file according to an embodiment, which includes information that allows for reduced power consumption when displaying video. This example uses an adaptive set of @id=ami and mimetype=video / mp4 corresponding to the type of the attenuation map representation, an attenuation map representation of @id="ami0" associated with the video component representation @id="v0" using the associated type="amit", which can be used on both emitted and non-emitting displays (amiDisplayModel="3"), allows for a 20% reduction in power consumption (amiEnergyReductionRate="20"), a 5% reduction in PSNR quality video metrics, and utilizes a linear approximation model (amiMapApproximationModel="0").

[0215] exist Figure 11A-11B In the example, the attributes @associationId and @associationType are carried by the decay graph representation element. In another implementation, the attributes @associationId and @associationType are common attributes of all decay graph representations and are carried directly by the adaptive set element.

[0216] Figure 12A-12B A list of codes that forms an exemplary MPD manifest file according to some embodiments. Figure 12A and 12B Example code lists 1200 and 1250 are shown.

[0217] Figure 12A-12B Showing the adaptive set with id=ami and mimetype=video / mp4 corresponding to the type of the attenuation map. Figure 12A-12BAlso shown is an adaptive set with id=green video and codecs=amii, corresponding to the type of timing metadata for the attenuation map information. The representation elements of this adaptive set carry information about the two attenuation maps listed below.

[0218] Figure 12A-12B The diagram shows two attenuation map representations with id="ami0" and id="ami1" associated with the video component representation id="v0". Figure 12A-12B As shown, both attenuation maps can be used for both emitting and non-emitting displays. Figure 12A-12B The diagram shows that one attenuation plot allows for a 20% reduction in energy consumption, while another attenuation plot allows for a 40% reduction in energy consumption. Figure 12A-12B As shown, an approximate model is provided to generate other decay maps with different reduction rates on the DASH client side.

[0219] Figure 12A-12B This represents a second exemplary MPD manifest file according to an embodiment, which includes information enabling power consumption reduction when displaying video. This second example uses an adaptive set of attenuation maps corresponding to the type of the attenuation map (@id=ami and mimetype=video / mp4), and two attenuation map representations (@id=“ami0” and @id=“ami1”) associated with the video component representation (@id=“v0”). Both attenuation maps are used for both emitted and non-emitting displays. One attenuation map allows for a 20% reduction in power consumption, and the other allows for a 40% reduction. Both maps use the Lanczos approximation model (amiMapApproximationModel="1").

[0220] Figure 13A This is a flowchart illustrating an exemplary DASH server-side application process according to some embodiments. Figure 13B This is a flowchart illustrating an exemplary DASH server-side application process according to some embodiments. The two exemplary processes 1300 and 1350 are very similar to each other. Figure 13A In this context, the energy reduction rate 1322 is the input to block 1306, which calculates and encodes the attenuation map (AM). Figure 13B In this process, a list 1372 of energy reduction rates is used as input, and for each energy reduction rate on the list, a loop process 1374 can be executed. In some embodiments, input videos 1324, 1376 are used to encode video frames 1302, 1352. For each of these corresponding exemplary processes 1300, 1350, the encoded output can be processed via default decoding blocks 1304, 1354.

[0221] Attenuation graph metadata 1308 and 1358 are used to generate 1310 and 1360. Attenuation graph metadata 1308 and 1358 are used to create a new adaptive set id="ami" (at least the prefix "ami" should be used in the id to identify the type of adaptive set elements). The new adaptive set has a new association type (@associationType) for the representation. Attenuation graph(s) are computed by the graph computation entity on the encoder side 1306 and 1356.

[0222] Figure 13A and 13B Block diagrams depicting the process 1300, 1350 of generating an MPD manifest file with a new adaptive set id="ami" and a decay map representation, performed during encoding according to an embodiment (by computation and encoding entities within the encoder and using internally decoded video).

[0223] In this embodiment, during a given time period, a new adaptive set id="ami" is inserted at 1312 and 1362. Image encoding, performed by the encoding entity, is executed, resulting in a set of bitstreams with different characteristics (i.e., bitrate, resolution, etc.). The bitstreams are decoded internally, and the attenuation map corresponding to the image is calculated and encoded by the attenuation map calculation entity. Data regarding its usage, its expected energy reduction, and the corresponding expected quality are collected. This information is collected in the attenuation map information timing metadata and inserted into the attenuation map information sample entries at 1314 and 1364, and signaled in the MPD manifest file with the adaptive set id="green video" with codecs="amii". The representation of this adaptive set is associated (associationType="cdsc") with the attenuation map representation. A new adaptive set id="ami" with attenuation map representation and an adaptive set id="green video" with codecs="amii" are inserted into the MPD at 1316 and 1366, respectively. The MPD is then published by the MPD delivery function at 1318 and 1368. Upon request from the DASH client, the video component, green video, and the segment with attenuation map representation are transmitted to the DASH segment delivery function at 1320 and 1370.

[0224] In another embodiment, multiple adaptive sets of attenuation maps can exist in the MPD manifest file, with id="amiX", X=0..n. This allows, for example, attenuation maps associated with the video representation to be grouped into the same adaptive set element.

[0225] In another embodiment, instead of using id="ami" or id="amiX" for the new adaptive set element, the @contentType attribute of this element can be set to a decay map. In this case, the id of the adaptive set can be different from "ami" or "amiX".

[0226] At least one of these two possibilities will be used to notify the client: the adaptive set element signals the decay graph representation.

[0227] In another embodiment, when all attenuation maps of an adaptive set are associated with the same video representation, the attribute @associationType can be an attribute of the adaptive set element, rather than an attribute of each representation element.

[0228] In another embodiment, the calculation of the attenuation map and the collection of associated metadata are implemented outside the encoder. The input video used to calculate the attenuation map is the raw video, not the output video from the encoder's internal decoder. The associated metadata is passed to the DASH media rendering preparation entity to create a new adaptive set id="ami" and an adaptive set id="green video" with codecs="amii", and inserts them into the MPD manifest file. The attenuation map corresponding to the image is calculated and encoded by the attenuation map calculation entity. The raw video is encoded by the encoder, and the synchronous bitstream output of both processes is passed to the Dash segment delivery function.

[0229] In another embodiment, the adaptive set id="green video" of the MPD manifest with codecs="amii" has a timing metadata representation of attenuation map information, which carries information for only one attenuation map in a sample entry.

[0230] In another embodiment, the adaptive set id="green video" of the MPD manifest with codecs="amii" has a timing metadata representation of attenuation map information, which carries information in several sample entries, with each attenuation map corresponding to one sample entry.

[0231] In another embodiment, the adaptive set id="green video" of the MPD manifest with codecs="amii" has a timing metadata representation of attenuation map information, which carries information for several attenuation maps in a sample entry.

[0232] In another embodiment, the amiDisplayModel information is present in the attenuation map information timing metadata to indicate to the DASH client that the associated attenuation map representation can only be used for a given display type. The client can then make an appropriate request to the DASH server, without requesting an attenuation map that cannot be used for the display it is connected to. This embodiment allows for reduced data transfer between the DASH server and the client.

[0233] In another embodiment, several attenuation maps with different reduction rates can be computed, and the new adaptive set id="ami" element contains several attenuation map representations for the same video component representation.

[0234] In another embodiment, attenuation maps are calculated according to different reduction rates, and the amiMapApproximationModel is added to the attenuation map information timing metadata to allow the DASH client to generate a new attenuation map representation based on the attenuation map representation it has received from the DASH server. This embodiment allows for reduced network bandwidth usage.

[0235] For example, having an energy reduction rate and Two attenuation maps are calculated. This will allow for adjustments to any other attenuation rate on the decoder side. Perform interpolation, such as .

[0236] In another embodiment, amiBoxXstart, amiBoxYstart, amiBoxWidth, and amiBoxHeight are added to the attenuation map timing metadata to indicate the portion of the image where the attenuation map should be applied. Instead of transmitting an attenuation map of the same size with a video representation, only the areas of the image where a significant reduction in display power consumption is allowed are given. This can also be viewed as an alternative representation choice for the DASH client between partial or complete attenuation maps. In this case, the DASH server can create two attenuation map timing metadata sets, one with amiBoxXstart, amiBoxYstart, amiBoxWidth, and amiBoxHeight, and the other without.

[0237] Because attenuation maps (one or more) represent different levels that may be present in a video media component, the following granularity can be used: • Granularity 1 – Image • Granularity 2 – Parts of the image: slices, tiles, sub-images • Granularity 3 – GOP or Scene The decay map representation elements, which combine the adaptive set id="ami", the adaptive set id="green video" with codecs="amii", and the attachment with AssociationType="amit", can be updated to reflect changes in presentation over time.

[0238] In an embodiment, when MPD@type = static, the update can be performed by defining different @periods in the MPD represented by an attached attenuation map with different kinds of adaptive set id="ami", an adaptive set id="green video" with codecs="amii", and AssociationType="amit". Alternatively, when MPD@type = "dynamic", the update can be performed by updating a unique new adaptive set id="ami".

[0239] Figure 14 This is a flowchart illustrating an exemplary DASH client-side process according to some embodiments.

[0240] Figure 14 The illustration depicts an exemplary process, according to an embodiment, for representation using a decay map. This process 1400 can be implemented by an energy-sensing DASH client (such as a display device). This process is implemented, for example, by a processor of such a device. This process is initiated, for example, by a user requesting streaming multimedia content.

[0241] Prior to this process, the target reduction rate has been selected. This selection can be made using different techniques. In one embodiment, the target reduction rate can be selected through manual user operation by setting a numerical value for the target. For example, a slider can be displayed on the screen and controlled by the user to adjust a value representing the target reduction rate. The value can also be directly entered using the numeric keys on a keyboard.

[0242] In this embodiment, a list of potential target reduction rates may be displayed on the screen to allow the user to select one of the potential target reduction rates, thus making it the target reduction rate. The list of potential target reduction rates may be, for example, a list of @amiEnergyReductionRate parameters constrained in the MDP manifest file of the selected multimedia content.

[0243] In this embodiment, the target reduction rate is selected through the display device's configuration settings before displaying multimedia content, and the target reduction rate is obtained from the display device without user intervention. For example, through a dedicated user interface, this configuration setting should preferably be under user control.

[0244] In this embodiment, the target reduction rate is selected based on the type of multimedia content and user configuration. The type may correspond to categories, such as allowing differentiation between movies, news, advertisements, talk shows, music programs, etc. Users will be able to select the target reduction rate for each category using a dedicated user interface.

[0245] The DASH client requests the MPD manifest file at 1402. After obtaining the MPD manifest file, it is processed at 1404 to extract data needed to select the video component representation, attenuation map representation (one or more), and parameters for configuring the decoding module, attenuation map post-processing module, and rendering module. The request can be sent at 1406, and a response of green video timing metadata is received. The DASH client checks at 1408 whether the display model corresponding to the screen where the multimedia content will be displayed is in the MPD's list of display models. This is achieved by comparing the screen's display model (or type) information with the @amiDisplayModel parameter in the MPD.

[0246] In the example, the `@amiDisplayModel` parameter in the MPD is set to 1 to indicate that the attenuation map representation should be used for the transmitting display. If, for example, there is a mismatch for a first DASH client with a non-transmitting display, the first DASH client requests 1410 and receives the video representation segment, decodes the video image 1412, and provides the image to the screen for display. It is expected that energy reduction will not be available for this first DASH client.

[0247] When, for example, a second DASH client with a non-emitting display matches a @amiDisplayModel set to 1, the second DASH client will be able to benefit from the energy reduction allowed by the embodiment and will display an energy-reduced version of the multimedia content, thus reducing its power consumption. In this case, the second DASH client requests 1414 an attenuation map representation segment corresponding to the selected target reduction rate and receives the attenuation map representation segment. The attenuation map representation is then decoded 1416 according to the parameters of the "ami" adaptive set, and optionally preprocessed 1418, and applied 1420 to the decoded image. For example, the attenuation map representation will be subsampled to reduce the amount of data to be encoded. In this case, line multiplication is performed on the attenuation so that its resolution corresponds to the resolution of the image to be displayed. Independently (i.e., possibly simultaneously or sequentially), the second DASH client requests 1422 a video component representation segment and receives the video component representation segment. The image of the video component representation segment is then decoded 1424. When both the attenuation map representation and the corresponding image have been decoded, the second DASH client sends 1426 the reduced image for display. Compared to the display of a corresponding non-attenuated image, the device will reduce its energy consumption because it displays a reduced-energy version of the image.

[0248] In addition, in examples where none of the available attenuation map representations offers a target energy reduction rate selected by the user, the device will select one of the available attenuation map representations and perform interpolation of the attenuation map representation values ​​to obtain the selected target energy reduction rate. This selection is made by, for example, choosing the attenuation with the closest reduction rate to the selected target reduction rate. If the selected target energy reduction rate falls between two available target energy reduction rates, the attenuation map representations corresponding to these two reduction rates are requested, received, and decoded so that interpolation can be performed between their values. For example, if the user selects a 30% reduction rate and the available attenuation map representations have reduction rates of 20% and 40%, the two maps will be interpolated by simply taking their average.

[0249] In this embodiment, the DASH client is not in power-saving mode, and therefore, the "ami" adaptive set and the attached attenuation map representation are not considered. Only the video component representation segments are requested.

[0250] In this embodiment, the DASH client only requests attenuation map representations with the `@amiAttenuationUseIdc` attribute that it can process; that is, it lacks the capability to perform the process of applying the attenuation map representation to the decoded video. In this embodiment, the DASH client only requests attenuation map representations with the `@amiPreprocessingTypeIdc` attribute that it can process; that is, it lacks the capability to perform preprocessing methods before applying the attenuation map representation to the decoded video. In this embodiment, the DASH client only requests attenuation maps with an acceptable value (i.e., what the content provider expects) for the `@amiVideoQuality` attribute. In this embodiment, the DASH client prioritizes attenuation map representations with the attributes `@amiBoxXstart`, `@amiBoxYstart`, `@amiBoxWidth`, and `@amiBoxHeight`, rather than selecting an attenuation map representation of the same size as the video representation. By using partial attenuation map representations, the selection of these representations allows for reduced network bandwidth usage for transmitting the attenuation map representation, and therefore, reduced display power consumption.

[0251] Several embodiments using attenuation maps and their accompanying metadata are conceivable. Figure 14 A block diagram depicts MPD used in an end device according to an embodiment, the end device including a display compatible with amiDisplayModel, the MPD using a greening strategy by using a decay map.

[0252] In another embodiment, the end-user device can decide not to consider the new type of adaptive set id="ami" and the attached attenuation map representation, and not to request any attenuation map because the display model is not aligned with the amiDisplayModel field obtained in the attenuation map information timing metadata.

[0253] In another embodiment, the end-user device can decide not to consider the new type of adaptive set id="ami" and the attached attenuation map representation, and not to request any attenuation map because it is not in power-saving mode. Only the video component representation segment is requested.

[0254] In another embodiment, when the end user device is able to use the amiMapApproximationModel of the attenuation map information timing metadata to generate new attenuation map representations with different reduction rates, the end user device can decide to request some attenuation maps with different reduction rates. This embodiment allows for reduced network bandwidth usage.

[0255] For example, having an energy reduction rate and Two attenuation maps are calculated. This will allow for adjustments to any other attenuation rate on the decoder side. Perform interpolation, such as .

[0256] In another embodiment, the end-user device can decide to request only the attenuation map with the attenuation map information timing metadata that it can process; that is, it does not have the ability to perform the process of applying the attenuation map to the decoded video.

[0257] In another embodiment, the end-user device is able to decide to request only the attenuation map of amiPreprocessingTypeIdc with attenuation map information timing metadata that it can process; that is, it does not have the ability to perform a preprocessing method before applying the attenuation map to the decoded video.

[0258] In another embodiment, the end-user device is able to determine only the acceptable value (i.e., the content provider's expectation) of the attenuation map that requests only the timing metadata of the attenuation map information of amiVideoQualityReduction.

[0259] In another embodiment, the end-user device can decide to select an attenuation map representation with amiBoxXstart, amiBoxYstart, amiBoxWidth, and amiBoxHeight present in the attenuation map information timing metadata, rather than selecting an attenuation map representation of the same size as the video representation. This allows for reduced network bandwidth usage to transmit the attenuation map and reduces display power consumption by utilizing the least significant values.

[0260] Figure 15 This is a schematic illustration of an exemplary DASH client-side process according to some embodiments. In some embodiments of this process 1500, an MPD file 1508 and data 1510 in multiple segments are received by a DASH access engine 1504. Selection is performed. The DASH access engine 1504 may send MPD selection metadata 1512 to a selection logic process 1502, which may include a new adaptive set. The selection process 1502 may send an indication 1514 back to the DASH access engine, indicating the selected AMI time metadata, video, and attenuation map representation. The DASH access engine 1504 may send 1516 MPEG format video media, attenuation map, and timing information to a media engine 1506. The media engine 1506 may use this received data to generate and / or display reduced-energy video media.

[0261] This application affects the DASH server and player. The presence of the attenuation map in the DASH Media Presentation Description (MPD) manifest file can be checked on the DASH adaptive streaming player side when the following conditions are met: (1) an MPD request is executed and a new adaptive set for accessing the attenuation map segment is available; (2) an MPD request is executed and an adaptive set id="green video" with @codecs="amii" is available; (3) an HTTP request to receive one or more attenuation map information timing metadata is executed and the segment carrying the attenuation map information timing metadata is transmitted from the server to the player; and (4) an HTTP request to receive one or more attenuation maps is executed and the segment carrying the attenuation map is transmitted from the server to the player.

[0262] The check can be performed to determine whether, for different display types, the energy consumed is reduced in conjunction with the selected adaptive set in the MPD. In cases where different adaptive sets exist in the MPD for different energy reduction rates, the check can be performed to determine whether the energy consumed by the modified video conforms to one of the energy reduction rates provided by an adaptive set in the MPD's adaptive set for the current time period.

[0263] Figure 16 This is a flowchart illustrating an exemplary process for generating an attenuated image for display, according to some embodiments. For some embodiments, exemplary process 1600 may include: obtaining 1602 a manifest file corresponding to visual content. For some embodiments of exemplary process 1600, the manifest file includes: information related to a video representation and information related to a set of attenuation map representations of the visual content. For some embodiments, exemplary process 1600 may also include: obtaining 1604 segments of the video representation. For some embodiments, exemplary process 1600 may also include: obtaining 1606 segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate. For some embodiments, exemplary process 1600 may also include: decoding an image from the obtained segments of the video representation 1608. For some embodiments, exemplary process 1600 may also include: decoding an attenuation map representation from the obtained segments of the attenuation map representation 1610. For some embodiments, exemplary process 1600 may also include: applying 1612 the decoded attenuation map representation to the decoded image to generate an attenuated image for display.

[0264] Figure 17This is a flowchart illustrating an exemplary process for generating an attenuation image for display, according to some embodiments. For some embodiments, exemplary process 1700 may include obtaining 1702 a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; information related to a set of attenuation map representations of the visual content; and an adaptive set having an identifier field corresponding to green video and a codec attribute having a value corresponding to an Attenuation Map Information Indication (AMII). For some embodiments, exemplary process 1700 may further include obtaining 1704 segments of the video representation. For some embodiments, exemplary process 1700 may further include obtaining 1706 segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate. For some embodiments, exemplary process 1700 may further include decoding an image from the obtained segments of the video representation 1708. For some embodiments, exemplary process may further include decoding an attenuation map representation from the obtained segments of the attenuation map representation 1710. In some embodiments, exemplary process 1700 may further include: applying 1712 to the decoded image with a decoded attenuation image representation to generate an attenuation image for display.

[0265] Figures 18A-18B A list of codes is provided to form a sample procedure for an exemplary attenuation map information indication (AMII) according to some embodiments. Each representation of the green video adaptive set with @codecs="amii" carries information for only one attenuation map. Figures 18A-18B yes Figures 7A-7B The inference, Figures 18A-18B This demonstrates the use of the amiCancelFlag property in some examples.

[0266] Figures 19A-19B A list of codes is provided to form an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Each representation of the green video adaptive set with @codecs="amii" carries information about several attenuation maps in separate sample entries. An amID data field is added to identify the attenuation map and obtain relevant information for use with the attenuation map. Figures 19A-19B yes Figures 8A-8B The inference, Figures 19A-19B This demonstrates the use of the amiCancelFlag property in some examples.

[0267] Figures 20A-20B A list of codes is provided to form an exemplary attenuation map information indication (AMII) sample procedure according to some embodiments. Each representation of the green video adaptive set with @codecs="amii" carries information about several attenuation maps in a unique sample entry. An amID data field is added to identify the attenuation map and obtain relevant information for use with the attenuation map. Figures 20A-20B yes Figures 9A-9B The inference, Figures 20A-20B This demonstrates the use of the amiCancelFlag property in some examples.

[0268] While methods and systems according to some embodiments are generally discussed within the context of extended reality (XR), some embodiments can be applied to any XR context, such as, for example, virtual reality (VR) / mixed reality (MR) / augmented reality (AR) contexts. Furthermore, although the term "head-mounted display (HMD)" is used herein according to some embodiments, for some embodiments, some embodiments can be applied to wearable devices capable of performing, for example, XR, VR, AR, and / or MR (the wearable device may or may not be attached to the head).

[0269] A first exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; and information related to a set of attenuation map representations of the visual content; obtaining segments of the video representation; obtaining segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate; decoding an image from the obtained segments of the video representation; decoding the attenuation map representations from the obtained segments of the attenuation map representations; and applying the decoded attenuation map representations to the decoded image to produce an attenuated image for display.

[0270] In some embodiments of the first exemplary method, the manifest file includes an adaptive set having an identifier field corresponding to attenuation map information (AMI).

[0271] In some embodiments of the first exemplary method, the manifest file includes an adaptive set having an identifier field corresponding to the green video and a codec attribute having a value corresponding to the Attenuation Map Information Indication (AMII).

[0272] In some embodiments of the first exemplary method, the identifier field is accessible using an external class.

[0273] Some embodiments of the first exemplary method may further include: in response to finding an adaptive set having an identifier field corresponding to attenuation map information (AMI) in the manifest file, obtaining a list of one or more available pixel-wise attenuation maps; and selecting an attenuation map from the list, wherein the selected attenuation map corresponds to a selected attenuation map representation.

[0274] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the quality of the image, and the attenuation map is selected from the list based on the information corresponding to the quality of the image.

[0275] Some embodiments of the first exemplary method may further include: rendering the attenuation image.

[0276] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information representing the type of interpolation.

[0277] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the scaling of the pixels of the image.

[0278] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the backlight of the image.

[0279] In some embodiments of the first exemplary method, the information associated with the attenuation map representation also includes information corresponding to the quality of the image.

[0280] In some embodiments of the first exemplary method, the manifest file and the segment are based on MPEG-DASH.

[0281] In some embodiments of the first exemplary method, an adaptive set having an identifier field corresponding to the green video type is used to obtain the segment represented by the attenuation map.

[0282] A first exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0283] A second exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; and information related to a set of attenuation map representations of the visual content; in response to finding an adaptive set having an identifier field corresponding to attenuation map information (AMI) in the manifest file, obtaining a list of one or more available pixel-wise attenuation maps; and selecting an attenuation map from the list, wherein the selected attenuation map corresponds to an attenuation map representation selected from the set of attenuation map representations; obtaining a segment of the video representation; obtaining a segment of the selected attenuation map representation; decoding an image from the obtained segment of the video representation; decoding the selected attenuation map representation from the obtained segment of the selected attenuation map representation; and applying the decoded attenuation map representation to the decoded image to produce an attenuated image.

[0284] A second exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0285] A third exemplary method according to some embodiments may include: obtaining a manifest file corresponding to visual content, wherein the manifest file includes: information related to a video representation; information related to a set of attenuation map representations of the visual content; and an adaptive set having an identifier field corresponding to a green video and a codec attribute having a value corresponding to an attenuation map information indication (AMII); obtaining segments of the video representation; obtaining segments of attenuation map representations selected from the set of attenuation map representations based on a selected energy reduction rate; decoding an image from the obtained segments of the video representation; decoding the attenuation map representations from the obtained segments of the attenuation map representations; and applying the decoded attenuation map representations to the decoded image to produce an attenuated image for display.

[0286] A third exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0287] A fourth exemplary method according to some embodiments may include: creating a manifest file corresponding to visual content, wherein the manifest file includes: information related to video representation; and information related to a set of attenuation map representations of the visual content; and sending the manifest file corresponding to the visual content to a client.

[0288] Some embodiments of the fourth exemplary method may further include: receiving a request for a segment of the video representation; receiving a request for a segment of attenuation map representation selected from the set of attenuation map representations based on a selected energy reduction rate; sending the segment of the video representation to the client; and sending the segment of attenuation map representation selected from the set of attenuation map representations based on a selected energy reduction rate to the client.

[0289] Some embodiments of the fourth exemplary method may further include: encoding an image as a segment of the video representation; and encoding a selected attenuation map representation as a segment of the selected attenuation map representation.

[0290] A fourth exemplary device according to some embodiments may include: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform any of the methods listed above.

[0291] An exemplary server device according to some embodiments may include: one or more processors configured to generate a manifest file including information configured and usable by a client to reduce the power consumption of a video representation on a pixel-by-pixel basis on a client display, wherein the one or more processors are further configured to generate the manifest file in part by obtaining the information from attenuation map information obtained from the server.

[0292] In some embodiments of the exemplary server device, the server is a DASH server.

[0293] For some embodiments of the exemplary server device, the manifest file is a DASH MPD file.

[0294] An exemplary client device according to some embodiments may include one or more processors and communicate with a display, the one or more processors being configured to obtain a manifest file including information configured and usable by the client to reduce the power consumption of a video representation on a pixel-by-pixel basis on the display, wherein the information is obtained from attenuation map information, and wherein the one or more processors are further configured to update the display according to the manifest file.

[0295] In some embodiments of the exemplary client device, the client includes the display.

[0296] In some embodiments of the exemplary client device, the client is a DASH client.

[0297] For some embodiments of exemplary client devices, the manifest file is a DASH MPD file.

[0298] In some embodiments of the exemplary client device, the client selects information obtained from the attenuation map information from the server.

[0299] In some embodiments of the exemplary client device, the server is a DASH server.

[0300] A fifth exemplary device according to some embodiments may include: at least one processor configured to perform any of the methods listed above.

[0301] A sixth exemplary device according to some embodiments may include: a computer-readable medium storing instructions for causing one or more processors to perform any of the methods listed above.

[0302] A seventh exemplary device according to some embodiments may include: at least one processor; and at least one non-transitory computer-readable medium storing instructions for causing the at least one processor to perform any of the methods listed above.

[0303] A computer-readable medium according to some embodiments may include: a computer-readable medium storing a bit stream generated according to any of the methods listed above.

[0304] The signal according to some embodiments may include: a bit stream generated according to any of the methods listed above.

[0305] This disclosure describes various aspects, including tools, features, embodiments, models, solutions, etc. Many of these aspects are described in detail and are often described in a manner that may sound restrictive, at least to illustrate individual characteristics. However, this is for the purpose of clarity of description and not to limit the disclosure or scope of those aspects. In fact, all aspects of the different aspects can be combined and interchanged to provide other aspects. Furthermore, aspects can also be combined and interchanged with aspects described in earlier documents.

[0306] The aspects described and contemplated in this disclosure can be implemented in many different forms. Although some embodiments are specifically illustrated, other embodiments are contemplated, and the discussion of particular embodiments does not limit the breadth of implementation. At least one aspect generally relates to video encoding and decoding, and at least one other aspect generally relates to transmitting bitstreams generated or encoded. 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 methods described, and / or computer-readable storage media having bitstreams generated according to any of the methods described stored thereon.

[0307] In this disclosure, the terms “reconstruction” and “decoding” are used interchangeably, as are the terms “pixel” and “sample”, and the terms “image,” “picture,” and “frame.” Typically, but not necessarily, the term “reconstruction” is used on the encoder side, while “decoding” is used on the decoder side.

[0308] The terms HDR (High Dynamic Range) and SDR (Standard Dynamic Range) often convey specific values ​​of dynamic range to those skilled in the art. However, it is also intended to use alternative embodiments in which references to HDR are understood to mean "higher dynamic range" and references to SDR are understood to mean "lower dynamic range." Such alternative embodiments are not bound by any specific value of dynamic range that may be frequently associated with the terms "high dynamic range" and "standard dynamic range."

[0309] Various methods are described herein, and each of these methods includes one or more steps or actions for implementing the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and / or use of specific steps and / or actions may be modified or combined. Furthermore, terms such as "first," "second," etc., may be used in various embodiments to modify elements, components, steps, operations, etc., such as, for example, "first decoding" and "second decoding." Unless explicitly required, the use of such terms does not imply an ordering of the modified operations. Therefore, in this example, the first decoding does not need to be performed before the second decoding and may occur, for example, before the second decoding, during the second decoding, or in a time period overlapping with the second decoding.

[0310] For example, various numerical values ​​may be used in this disclosure. Specific values ​​are for illustrative purposes, and the aspects described are not limited to these specific values.

[0311] The embodiments described herein can be implemented using computer software, or a combination of hardware and software, implemented by a processor or other hardware. As a non-limiting example, embodiments can be implemented using one or more integrated circuits. The processor can be of any type suitable for the technical environment, and as a non-limiting example, can include one or more of microprocessors, general-purpose computers, special-purpose computers, and processors based on multi-core architectures.

[0312] Various implementations involve decoding. As used in this disclosure, "decoding" can include all or part of a process performed, for example, on a received encoded sequence to produce a final output suitable for display. In various embodiments, such a process includes one or more processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. In various embodiments, such a process also includes, or alternatively includes, processes performed by a decoder of the various implementations described in this disclosure, such as extracting images from chunked (packed) images, determining an upsampling filter to use and subsequently upsampling the images, and flipping the images back to their intended orientation.

[0313] As another example, in one embodiment, "decoding" refers only to entropy decoding; in another embodiment, "decoding" refers only to differential decoding; and in yet another embodiment, "decoding" refers to a combination of entropy decoding and differential decoding. It will be clear, based on the context of the specific description, whether the phrase "decoding process" is intended to specifically refer to a subset of operations or generally to a broader decoding process.

[0314] Various implementations involve encoding. Following a similar manner to the above discussion of “decoding,” as used in this disclosure, “encoding” can include all or part of a process performed, for example, on an input video sequence to produce an encoded bitstream. In various embodiments, such a process includes one or more processes typically performed by an encoder, such as splitting, differential coding, transform, quantization, and entropy coding. In various embodiments, such a process also includes, or alternatively includes, processes performed by encoders of the various implementations described in this disclosure.

[0315] As another example, in one embodiment, "encoding" refers only to entropy encoding; in another embodiment, "encoding" refers only to differential encoding; and in yet another embodiment, "encoding" refers to a combination of differential and entropy encoding. It will be clear, based on the context of the particular description, whether the phrase "encoding process" is intended to specifically refer to a subset of operations or generally to a broader encoding process.

[0316] Various implementations involve rate-distortion optimization. In particular, during the encoding process, often constrained by computational complexity, a balance or trade-off between code rate and distortion is typically considered. Rate-distortion optimization is generally expressed as minimizing a rate-distortion function, which is a weighted sum of code rate and distortion. Different schemes exist to address the rate-distortion optimization problem. For example, a scheme may be based on extensive testing of all coding options, including all considered modes or decoding parameter values, to fully evaluate their decoding costs and the associated distortion of the reconstructed signal after decoding and decoding. To save coding complexity, faster schemes may also be used, specifically, to compute approximate distortion based on prediction or prediction of the residual signal rather than the reconstructed signal. Hybrid schemes, such as using approximate distortion for only some of the possible coding options and full distortion for others, can also be used. Other schemes evaluate only a subset of the possible coding options. More generally, many schemes employ any of the techniques available to perform optimization, but optimization is not necessarily a complete evaluation of both decoding costs and associated distortion.

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

[0318] The implementations and aspects described herein can be implemented as, for example, methods or processes, devices, 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 implementation of the features discussed can be implemented in other forms (e.g., devices or programs). Devices can be implemented as, for example, suitable hardware, software, and firmware. Methods can be implemented as, for example, processors, which generally refer to processing devices, including, for example, computers, microprocessors, integrated circuits, or programmable logic devices. 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.

[0319] References to “an embodiment” or “an embodiment” or “an implementation” or “an implementation” and other variations thereof mean that a particular feature, structure, characteristic, etc., described in connection with that embodiment is included in at least one embodiment. Therefore, the phrases “in an embodiment” or “in an embodiment” or “in an implementation” or “in an implementation” appearing in various places throughout this disclosure, and any other variations thereof, do not necessarily all refer to the same embodiment.

[0320] Additionally, this disclosure may involve "determining" various information segments. Determining information can include one or more of the following: estimated information, extrapolated information, predicted information, or information retrieved from memory.

[0321] In addition, this disclosure may involve “accessing” various information segments. 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.

[0322] Furthermore, this disclosure may relate to "receiving" various information segments. Like "accessing," receiving is intended to be used as a broad term. Receiving information can include, for example, one or more of the following: accessing information or retrieving information (e.g., from memory). Additionally, "receiving" is typically involved during operation in one manner or another, such as, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0323] To be understood, for example, in the cases of “A / B,” “A and / or B,” and “at least one of A and B,” the use of any of the above “ / ,” “and / or,” and “at least one of…” is intended to include: selecting only the first listed option (A), or selecting only the second listed option (B), or selecting both options (A and B). As another example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” this phrase is intended to include: selecting only the first listed option (A), or selecting only the second listed option (B), or selecting only the third listed option (C), or selecting only the first and second listed options (A and B), or selecting only the first and third listed options (A and C), or selecting only the second and third listed options (B and C), or selecting all three options (A, B, and C). This can be expanded for any number of listed items.

[0324] Furthermore, as used herein, the term "signal" refers, among other meanings, to instructing a corresponding decoder. For example, in some embodiments, the encoder signals a specific parameter among a plurality of parameters for region-based filter parameter selection for artifact removal filtering. In this way, in embodiments, the same parameter is used on both the encoder and decoder sides. Thus, for example, the encoder can transmit (explicitly signal) a specific parameter to the decoder, allowing the decoder to use the same specific parameter. Conversely, if the decoder already has that specific parameter along with other parameters, the signal can be used without transmission (implicitly signal) to simply allow the decoder to know and select that specific parameter. In various embodiments, bit saving is achieved by avoiding the transmission of any actual functionality. It should be understood that signaling can be done in various ways. For example, in various embodiments, one or more syntax elements, tags, etc., are used to signal information to the corresponding decoder. Although the verb form of the term "signal" has been referred to above, the term "signal" can also be used herein as a noun.

[0325] The implementation can generate various signals, which are formatted to carry information, and the messages can be stored or transmitted, for example. The information can include, for example, instructions for performing a method or data generated by one of the described implementations. For example, the signal can be formatted to carry a bitstream of the described embodiment. For example, such a signal can be formatted as an electromagnetic wave (e.g., using the radio frequency portion of the spectrum) or as a baseband signal. Formatting can include, for example, encoding the data stream and modulating a carrier wave using the encoded data stream. The information carried by the signal can be, for example, analog or digital information. It is well known that signals can be transmitted via various wired or wireless links. The signal can be stored on a processor-readable medium.

[0326] We have described numerous embodiments. Features of these embodiments can be provided, individually or in any combination, across various types and classes of claims. Additionally, embodiments can include one or more of the following features, means, or aspects, individually or in any combination, across various types and classes of claims: • Bitstream or signal, including one or more syntax elements or variations thereof in the described syntax elements.

[0327] • A bitstream or signal, including a syntax that conveys information generated according to any embodiment of the described embodiments.

[0328] • To create and / or transmit and / or receive and / or decode bitstreams or signals, which include one or more syntax elements or variations thereof from the described syntax elements.

[0329] • Create and / or transmit and / or receive and / or decode according to any of the embodiments described.

[0330] • Methods, processes, apparatus, media for storing instructions, media for storing data, or signals according to any of the embodiments described.

[0331] It should be noted that the various hardware elements in one or more embodiments described are referred to as “modules”, which perform (i.e., execute, implement, etc.) the various functions described herein in connection with the respective module. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs), one or more memory devices) that are deemed suitable for a given implementation by those skilled in the art. Each described module may also include instructions that are executable to perform the one or more functions described as being performed by the respective module, and it should be noted that such instructions may take the form of hardware (i.e., hard-connected) instructions, firmware instructions, software instructions, etc., or may include hardware (i.e., hard-connected) instructions, firmware instructions, software instructions, etc., and may be stored in any suitable one or more non-transitory computer-readable media, such as commonly referred to as RAM, ROM, etc.

[0332] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware included in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method comprising: Obtain the manifest file corresponding to the visual content. The manifest file includes: Information related to the video representation; and Information related to a set of attenuation maps representing the visual content; Obtain the segment represented by the video; Obtain the segment represented by the selected attenuation map from the set of attenuation maps based on the selected energy reduction rate; Decode the image from the obtained video representation segment; The attenuation map representation is decoded from the obtained attenuation map representation segments; and The decoded attenuation map representation is applied to the decoded image to produce an attenuation image for display.

2. The method of claim 1, wherein the manifest file includes an adaptive set having an identifier field corresponding to attenuation map information (AMI).

3. The method of claim 1, wherein the manifest file includes an adaptive set having an identifier field corresponding to the green video and a codec attribute having a value corresponding to the Attenuation Map Information Indication (AMII).

4. The method of any one of claims 1-3, wherein the identifier field is accessible using an external class.

5. The method according to any one of claims 1-4, further comprising: In response to finding an adaptive set with identifier fields corresponding to Attenuation Map Information (AMI) in the manifest file, a list of one or more available pixel-wise attenuation maps is obtained; and Select an attenuation map from the list. The selected attenuation map corresponds to the selected attenuation map representation.

6. The method of claim 5, wherein the information associated with the attenuation map representation further includes information corresponding to the quality of the image, and The attenuation map is selected from the list based on information corresponding to the quality of the image.

7. The method according to any one of claims 1-6, further comprising: Render the attenuation image.

8. The method of any one of claims 1-7, wherein the information associated with the attenuation map representation further includes information representing the type of interpolation.

9. The method of any one of claims 1-8, wherein the information associated with the attenuation map representation further includes information corresponding to the scaling of the pixels of the image.

10. The method of any one of claims 1-9, wherein the information associated with the attenuation map representation further includes information corresponding to the backlight of the image.

11. The method of any one of claims 1-10, wherein the information associated with the attenuation map representation further includes information corresponding to the quality of the image.

12. The method of any one of claims 1-11, wherein the manifest file and the segment are based on MPEG-DASH.

13. The method of any one of claims 1-12, wherein an adaptive set having an identifier field corresponding to the green video type is used to perform the acquisition of the segment represented by the attenuation map.

14. An apparatus comprising: processor; and A non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform the method as described in any one of claims 1 to 13.

15. A method comprising: Obtain the manifest file corresponding to the visual content. The manifest file includes: Information related to the video representation; and Information related to a set of attenuation maps representing the visual content; In response to finding an adaptive set with identifier fields corresponding to Attenuation Map Information (AMI) in the manifest file, a list of one or more available pixel-wise attenuation maps is obtained; and Select an attenuation map from the list. The selected attenuation map corresponds to the attenuation map representation selected from the set of attenuation map representations; Obtain the segment represented by the video; Obtain the segment represented by the selected attenuation map; Decode the image from the obtained video representation segment; Decode the selected attenuation map representation from the obtained selected attenuation map representation segments; and The decoded attenuation map representation is applied to the decoded image to produce an attenuation image.

16. An apparatus comprising: processor; and A non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform the method of claim 15.

17. A method comprising: Obtain the manifest file corresponding to the visual content. The manifest file includes: Information related to the video representation; Information related to a set of attenuation maps representing the visual content; and An adaptive set, having an identifier field corresponding to the green video and a codec attribute having a value corresponding to the Attenuation Map Information Indication (AMII); Obtain the segment represented by the video; Obtain the segment represented by the selected attenuation map from the set of attenuation maps based on the selected energy reduction rate; Decode the image from the obtained video representation segment; The attenuation map representation is decoded from the obtained attenuation map representation segments; and The decoded attenuation map representation is applied to the decoded image to produce an attenuation image for display.

18. An apparatus comprising: processor; and A non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform the method of claim 17.

19. A method comprising: Create a manifest file corresponding to the visual content. The manifest file includes: Information related to the video representation; and Information related to a set of attenuation maps representing the visual content; and Send a manifest file corresponding to the visual content to the client.

20. The method of claim 19, further comprising: Receive a request for a segment of the video representation; Receive a request for a segment of attenuation map representation selected from the set of attenuation map representations based on the selected energy reduction rate; Send the segment represented by the video to the client; and Send to the client a segment of the attenuation map representation selected from the set of attenuation map representations based on the selected energy reduction rate.

21. The method of claim 20, further comprising: Encode the image into the segment represented by the video; and The selected attenuation map representation is encoded as the segment represented by the selected attenuation map.

22. An apparatus comprising: processor; and A non-transitory computer-readable medium storing instructions that, when executed by the processor, are operable to cause the device to perform the method as described in any one of claims 19 to 21.

23. A server device, comprising: One or more processors are configured to generate a manifest file that includes information configured and usable by a client to reduce the power consumption of a video representation on a pixel-by-pixel basis on a client display, wherein the one or more processors are further configured to generate the manifest file in part by obtaining the information from attenuation map information obtained from the server.

24. The server device of claim 23, wherein the server is a DASH server.

25. The server device of claim 23, wherein the manifest file is a DASH MPD file.

26. A client device including one or more processors and communicating with a display, the one or more processors being configured to obtain a manifest file including information configured and usable by the client to reduce the power consumption of a video representation on a pixel-by-pixel basis on the display, wherein the information is obtained from attenuation map information, and wherein the one or more processors are further configured to update the display according to the manifest file.

27. The client device of claim 26, wherein the client includes the display.

28. The client device of claim 26, wherein the client is a DASH client.

29. The client device of claim 26, wherein the manifest file is a DASH MPD file.

30. The client device of claim 26, wherein the client selects information obtained from the attenuation map information from the server.

31. The client device of claim 30, wherein the server is a DASH server.

32. An apparatus comprising: At least one processor is configured to perform the method as described in any one of claims 1-13, 15, 17 and 19-21.

33. An apparatus comprising: A computer-readable medium storing instructions for causing one or more processors to perform the method as described in any one of claims 1-13, 15, 17, and 19-21.

34. An apparatus comprising: At least one processor; and at least one non-transitory computer-readable medium storing instructions for causing the at least one processor to perform the method as described in any one of claims 1-13, 15, 17, and 19-21.

35. A computer-readable medium storing a bit stream generated according to any one of claims 1-13, 15, 17 and 19-21.

36. A signal comprising a bit stream generated according to any one of claims 1-13, 15, 17 and 19-21.

Images