ISO/IEC 23001-19:2026

• Abstract:

  This document defines a storage and delivery format for metadata for energy-efficient decoding, encoding, presentation, and selection of media (green metadata) as defined in ISO/IEC 23001-11. The green metadata are timed metadata which can be associated with other tracks in the ISO Base Media File Format. Timed metadata such as power consumption information and their metrics are defined in this document for carriage in files based on ISO/IEC 14496-12. In the context of DASH delivery, the green metadata representations and their association to the media representations are also defined using the signalling mechanisms specified in ISO/IEC 23009-1:2022 and ISO/IEC 23009-3[1]. These metadata can be used for multiple purposes, including optimizing power consumption during playback and supporting dynamic adaptive streaming.

• Status: Published
• Publication Date: 03-Aug-2026
• ICS: 35.040.40 - Coding of audio, video, multimedia and hypermedia information
• Technical Committee: ISO/IEC JTC 1/SC 29 - Coding of audio, picture, multimedia and hypermedia information
• Drafting Committee: ISO/IEC JTC 1/SC 29/WG 3 - MPEG Systems
• Current Stage: 6060 - International Standard published
• Start Date: 04-Aug-2026
• Due Date: 21-Jul-2027
• Completion Date: 04-Aug-2026

Overview

ISO/IEC 23001-19: Information technology - MPEG systems technologies - Part 19: Carriage of green metadata is an international standard developed by ISO and IEC. This standard defines the storage and delivery format for green metadata, which consists of information intended to reduce energy consumption throughout the video distribution chain. With increased focus on sustainability, ISO/IEC 23001-19 provides guidelines for representing, encapsulating, and transmitting green metadata, making media processing more energy-efficient from encoding to end-user playback.

This part of the MPEG systems technologies covers:

• Storage of green metadata using the ISO Base Media File Format (ISOBMFF).
• Encapsulation and signaling of green metadata for streaming systems, with a focus on MPEG-DASH (Dynamic Adaptive Streaming over HTTP).

Key Topics

1. Green Metadata Purpose

• Green metadata supports energy-efficient decoding, encoding, media presentation, and selection processes.
• It enables tracking and optimizing the power consumption for various parts of the video distribution workflow.

2. ISO Base Media File Format Integration

• Defines how green metadata can be carried as timed metadata within ISOBMFF-based files.
• Specifies the association of metadata tracks with relevant media tracks, using reference types such as ‘cdsc’ (content describes).
• Includes types of metadata such as decoder-power indication and display-power reduction information.

3. Streaming & Signaling in MPEG-DASH

• Provides mechanisms to encapsulate green metadata in media streams for adaptive HTTP streaming.
• Specifies signaling within MPEG-DASH manifests (MPD) to associate green metadata with corresponding media representations.
• Usage of unique Uniform Resource Names (URNs), restricted scheme types, and sample entry codes to ensure clear identification and compatibility.

4. Types of Green Metadata Handled

• Decoder-power indication: Metadata specifying power-related decoder characteristics.
• Display-power reduction: Metadata enabling display sub-systems to adjust settings for reduced energy use.
• Display attenuation map: Data supporting fine-grained display power management during media playback.

Applications

Implementing ISO/IEC 23001-19 provides significant benefits for a wide array of industries and use cases:

• Media Encoding and Authoring Workflows: Content providers and media professionals can integrate green metadata into their encoding pipelines, enabling downstream energy optimizations.
• Streaming Platforms and OTT Services: Video streaming services using ISOBMFF and MPEG-DASH can deliver content more efficiently, signaling power-saving parameters to clients.
• Consumer Electronics and Smart Devices: Device manufacturers can leverage green metadata to dynamically adjust decoding and display parameters, optimizing battery life and reducing environmental impact.
• Network Operators and ISPs: Facilitates more sustainable media delivery by enabling energy-efficient streaming at scale.

By adopting this standard, organizations in the media and technology sectors demonstrate a commitment to sustainability, improved battery life for consumer devices, and potential cost savings through optimized power consumption.

Related Standards

ISO/IEC 23001-19 is closely linked to other international standards, including:

• ISO/IEC 23001-11: MPEG systems technologies - Part 11: Energy-efficient media consumption (green metadata)
  Defines the green metadata referenced in this document.

• ISO/IEC 14496-12: Information technology - Coding of audio-visual objects - Part 12: ISO base media file format (ISOBMFF)
  Provides the base format for metadata carriage.

• ISO/IEC 23009-1: Dynamic adaptive streaming over HTTP (DASH)
  Details segment and manifest structures for adaptive streaming, with provisions for green metadata signaling.

• ISO/IEC 23001-10: MPEG systems technologies - Part 10: Carriage of timed metadata metrics
  Related to the carriage of timed metadata in multimedia file formats.

These standards work together to enable energy-aware, sustainable video workflows across the global media ecosystem.

---

Keywords: ISO/IEC 23001-19, green metadata, MPEG systems technologies, energy-efficient media, ISO Base Media File Format, MPEG-DASH, sustainable video streaming, power reduction, media sustainability standards.

International
Standard
ISO/IEC 23001-19
First edition
Information technology — MPEG
2026-08
systems technologies —
Part 19:
Carriage of green metadata
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .2
4 Overview . 2
4.1 Overall architecture for carriage of green metadata .2
4.2 Referenceable code points.3
4.2.1 Uniform resource names .3
4.2.2 Restricted scheme types .3
4.2.3 Sample entry types .3
4.2.4 Track reference types .3
4.2.5 Box types .3
5 Carriage of green metadata in ISO Base Media File Format . 4
5.1 General .4
5.2 Decoder-power indication metadata .4
5.2.1 Definition .4
5.2.2 Syntax . .4
5.2.3 Semantics .5
5.3 Display-power reduction metadata .5
5.3.1 General .5
5.3.2 Display power indication metadata .5
5.3.3 Display fine control metadata .6
5.3.4 Display attenuation map metadata .7
6 Encapsulation and signalling in MPEG-DASH.12
6.1 General . 12
6.2 Decoder-power indication . 12
6.3 Display-power indication . 13
6.4 Display attenuation map information .14
6.4.1 Metadata signalling in the MPD manifest file .14
6.4.2 Descriptors . 15
7 Conformance and reference software. 19
Annex A (normative) Green metadata MPEG-DASH schema .20
Annex B (informative) MPEG-DASH MPD examples .22
Annex C (informative) Conformance and reference software .32
Annex D (informative) Generation and use of green metadata .34
Bibliography . 41

© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see https://www.iso.org/directives or https://www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at https://www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO’s adherence to the World Trade Organization
(WTO) principles in the Technical Barriers to Trade (TBT) see https://www.iso.org/iso/foreword.html. In
the IEC, see https://www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO 23001 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at https://www.iso.org/members.html and
https://www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
Introduction
Green metadata is used for representing information that will help to reduce the energy consumption in the
video distribution chain, towards a more sustainable industry.
This document addresses technologies defining the carriage of green metadata for storage and delivery
purposes. This document includes (but is not limited to):
— Storage and carriage of green metadata using the ISO Base Media File Format (ISOBMFF) as specified in
ISO/IEC 14496-12;
— Encapsulation, signalling, and streaming of green metadata data in a media streaming system, e.g.,
dynamic adaptive streaming over HTTP (DASH) as specified in ISO/IEC 23009-1.

© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 23001-19:2026(en)
Information technology — MPEG systems technologies —
Part 19:
Carriage of green metadata
1 Scope
This document defines a storage and delivery format for metadata for energy-efficient decoding, encoding,
presentation, and selection of media (green metadata) as defined in ISO/IEC 23001-11. The green metadata
are timed metadata which can be associated with other tracks in the ISO Base Media File Format. Timed
metadata such as power consumption information and their metrics are defined in this document for
carriage in files based on ISO/IEC 14496-12.
In the context of DASH delivery, the green metadata representations and their association to the media
representations are also defined using the signalling mechanisms specified in ISO/IEC 23009-1:2022 and
[1]
ISO/IEC 23009-3 .
These metadata can be used for multiple purposes, including optimizing power consumption during
playback and supporting dynamic adaptive streaming.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 14496-5, Information technology — Coding of audio-visual objects — Part 5: Reference software
ISO/IEC 14496-12, Information technology — Coding of audio-visual objects — Part 12: ISO base media file
format
ISO/IEC 14496-15, Information technology — Coding of audio-visual objects — Part 15: Carriage of network
abstraction layer (NAL) unit structured video in the ISO base media file format
ISO/IEC 23001-10:2020, Information technology — MPEG systems technologies — Part 10: Carriage of timed
metadata metrics of media in ISO base media file format
ISO/IEC 23001-11:2023, Information technology — MPEG systems technologies — Part 11: Energy-efficient
media consumption (green metadata)
ISO/IEC 23009-1:2022, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1:
Media presentation description and segment formats
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23001-11 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp

© ISO/IEC 2026 – All rights reserved
— IEC Electropedia: available at https:// www .electropedia .org/
3.2 Abbreviated terms
DASH dynamic adaptive streaming over HTTP (specified in ISO/IEC 23009-1)
ISOBMFF ISO base media file format (specified in ISO/IEC 14496-12)
4 Overview
4.1 Overall architecture for carriage of green metadata
Figure 1 shows the functional architecture utilizing green metadata. The media pre-processor is applied to
analyse and to filter the content source and a video encoder is used to encode the content to a bitstream for
delivery. The bitstream is delivered to the receiver and decoded by a video decoder with the output rendered
on a presentation subsystem that implements a display process.
Figure 1 — Functional architecture
The green metadata is extracted from either the media encoder or the media pre-processor. In both cases,
the green metadata is multiplexed or encapsulated in the conformant bitstream. Such green metadata is
used at the receiver to reduce the power consumption for video decoding and presentation.
The bitstream is packaged into a file (F) or a sequence of an initialization segment and media segments for
streaming (Fs), according to a particular media container file format. In this document, the media container
file format is the ISO Base Media File Format specified in ISO/IEC 14496-12. The file encapsulator may also
include metadata into the file or the segments. Both are delivered using a delivery mechanism to the receiver,
for decoding and presentation.
A file decapsulator processes the received file (F’) or the received segments (Fs’) and extracts the green
metadata sample description boxes and coded bitstreams and parses the metadata. The file (F) or segments
(Fs) that the file encapsulator outputs are identical to the file (F’) or segments (Fs’) that the file decapsulator
takes as input. At the receiver, the metadata extractor sends the extracted green metadata to a power
optimization module for efficient power control. For instance, the power optimization module interprets the
green metadata and then applies appropriate operations to reduce the video decoder’s power consumption
when decoding the video and to reduce the presentation subsystem’s power consumption when rendering
the video.
The following interfaces are normatively specified in this document:
— F/F’: media file including the specification of the track formats, which may contain constraints on the
elementary streams contained within the samples of the tracks; see Clause 5 for timed metadata.

© ISO/IEC 2026 – All rights reserved
— Clause 6 specifies the delivery related interfaces for DASH delivery.
See Annex D for more information on the generation and use of the green metadata.
4.2 Referenceable code points
4.2.1 Uniform resource names
The URNs specified in this document are listed in Table 1.
Table 1 — URNs specified in this document
URN Clause Informative description
urn:mpeg:mpegI:green:2025
6.4.2 Namespace for the XML elements and attributes spec-
ified in this document
urn:mpeg:mpegI:green:2025:ami
6.4.2 Scheme identifier for the display attenuation map DASH
MPD descriptor
urn:mpeg:mpegI:green:2025:role
6.4.1 Scheme identifier for a DASH MPD role descriptor for
green metadata.
4.2.2 Restricted scheme types
The restricted scheme types specified in this document are listed in Table 2.
Table 2 — Restricted scheme types specified in this document.
Restricted scheme type Clause Informative description
gmat
5.3.3.2 Restricted scheme type for a display attenuation map track
4.2.3 Sample entry types
The sample entry types specified in this document are listed in Table 3.
Table 3 — Sample entry types specified in this document.
Sample entry type Clause Informative description
depi
5.2.1 Sample entry for a track carrying Decoder-Power Indication metadata
dipi
5.3.2.1 Sample entry for a track carrying Display-Power Indication metadata
dfce
5.3.2.1 Sample entry for a track carrying Display Fine Control metadata
4.2.4 Track reference types
The track reference types specified in this document are listed in Table 4.
Table 4 — Track reference types specified in this document.
Track reference type Clause Informative description
gmam
5.3.4.2.1 Referenced track is a video track to which the display attenuation map
applies.
4.2.5 Box types
The box types specified in this document are listed in Table 5. In the table, the box types specified in
ISO/IEC 23001-19 are in black text with links to the corresponding clauses in the specification. Related
container boxes specified in ISOBMFF are marked in grey. Non-related ISOBMFF boxes are not included in

© ISO/IEC 2026 – All rights reserved
the table. Mandatory boxes are, as in ISOBMFF, marked with an asterisk. Box types without a four character
code are marked with ‘-‘ in the structure.
Table 5 — Box types specified in this document.
Box types, structure, and cross-reference (Informative)
moov     * ISOBMFF container for all the metadata
trak    * ISOBMFF container for an individual track or stream
mdia    * ISOBMFF container for the media information in a track
minf   * ISOBMFF media information container
stbl   * ISOBMFF sample table box, container for the time/space map
stsd  * ISOBMFF sample descriptions (codec types, initialization etc.)
-  ISOBMFF sample entry or restricted sample entry
rinf  ISOBMFF restricted scheme info box
frma ISOBMFF original format box
schm ISOBMFF scheme type box
schi ISOBMFF scheme information box
amid 5.3.3.1 attenuation map information box
depi  5.2.1 decoder power indication metadata sample entry
dipi  5.3.1 display power indication metadata sample entry
dfce  5.3.2.1 display fine control metadata sample entry
dfcC  5.3.2.1 display fine control configuration box

5 Carriage of green metadata in ISO Base Media File Format
5.1 General
If green metadata is carried in an ISO Base Media File Format, it shall be carried in the metadata tracks
within the ISO Base Media File Format. Different green metadata types and corresponding storage formats
are identified by their unique sample entry codes.
A metadata track carrying green metadata is linked to the track it describes by means of a ‘cdsc’ (content
describes) track reference.
5.2 Decoder-power indication metadata
5.2.1 Definition
Sample Entry Type: ‘depi’
Container: Sample Description Box (‘stsd’)
Mandatory: No
Quantity: 0 or 1
The Decoder-Power Indication metadata is defined in ISO/IEC 23001-11. It provides decoder complexity
reduction ratios for the media track to which the metadata track refers by means of ‘cdsc’ reference.
5.2.2 Syntax
The Decoder-Power Indication metadata uses the following entry:

class DecoderPowerIndicationMetaDataSampleEntry()
extends MetaDataSampleEntry (‘depi‘) {

© ISO/IEC 2026 – All rights reserved
}
The Decoder-Power Indication metadata samples use the following syntax:

aligned(8) class DecoderPowerIndicationMetaDataSample(){
unsigned int(8) dec_ops_reduction_ratio_from_max;
signed int(16) dec_ops_reduction_ratio_from_prev;
}
5.2.3 Semantics
Semantics are defined in ISO/IEC 23001-11.
5.3 Display-power reduction metadata
5.3.1 General
The Display-Power Reduction metadata is defined in ISO/IEC 23001-11. Display-Power Reduction metadata
provides frame statistics and quality indicators for the media track that the metadata track refers to by
means of ‘cdsc’ reference. These metadata allow the client to attain a specified quality level by scaling frame-
buffer pixels and to reduce power correspondingly by decreasing the display backlight or OLED voltage.
Display-Power Reduction metadata is of three types:
1. metadata that indicates power saving at different quality levels over the sample duration. This metadata
shall use the 'dipi’ (Display Power Indication) sample entry type.
2. metadata that allows fine control of the display to achieve power reduction at a specified quality level.
This metadata shall use the ’dfce’ (Display Fine Control) sample entry type.
3. metadata that conveys pixel-wise information that can be applied to frames in the original video
sequence to reduce the total energy consumption resulting from rendering the frames of that video.
This metadata shall use the ‘amid’ (Display Attenuation Map) sample entry type.
Static metadata for the display fine control is stored in the sample entry. Dynamic metadata is stored in the
samples.
5.3.2 Display power indication metadata
5.3.2.1 Definition
‘dipi’
Sample Entry Type:
Container: Sample Description Box (‘stsd’)
Mandatory: No
Quantity: 0 or 1
This metadata indicates potential power savings at different quality levels over the sample duration.
5.3.2.2 Syntax
The Display Power Indication metadata uses the following sample entry:

aligned(8) class DisplayPowerIndicationMetaDataSampleEntry() extends
MetaDataSampleEntry (‘dipi‘) {
}
© ISO/IEC 2026 – All rights reserved
The Display Power Indication metadata samples use the following syntax:

class QualityLevels (num_quality_levels) {
unsigned int(8) rgb_component_for_infinite_psnr;
for (i = 1; i <= num_quality_levels; i++) {
unsigned int(8) max_rgb_component;
unsigned int(8) scaled_psnr_rgb;
}
}
aligned class DisplayPowerIndicationMetaDataSample () {
unsigned int(4) num_quality_levels;
unsigned int(4) reserved=0;}
QualityLevels(num_quality_levels)
}
The PSNR variables appearing in the syntax presented above are as defined in ISO/IEC 23001-11 and should
not be confused with the PSNR metric defined in ISO/IEC 23001-10:2020, 4.2.
5.3.2.3 Semantics
Semantics are defined in ISO/IEC 23001-11.
5.3.3 Display fine control metadata
5.3.3.1 Definition
‘dfce’
Sample Entry Type:
Container: Sample Description Box (‘stsd’)
Mandatory: No
Quantity: 0 or 1
The dynamic Display Fine Control metadata is stored in the samples and is associated with one or more
video frames.
The Decoding Time to Sample box provides the decoding time for the sample so that the metadata contained
therein is made available to the display with sufficient lead time relative to the video composition time. The
video composition time and metadata composition time are identical. The lead time is required because
display settings have to be adjusted in advance of presentation time for correct operation. If num_constant_
backlight_voltage_time_intervals > 1, then the lead time should be larger than the largest constant_
backlight_voltage_time_interval.
5.3.3.2 Syntax
The Display Fine Control metadata uses the following sample entry:

class DisplayFineControlMetaDataSampleEntry()
extends MetaDataSampleEntry (‘dfce‘) {
DisplayFineControlConfigurationBox();
}
aligned(8) class DisplayFineControlConfigurationBox
extends FullBox(‘dfcC’, version = 0, flags = 0) {
unsigned int(2) num_constant_backlight_voltage_time_intervals;
unsigned int(6) reserved = 0;
unsigned int(16)constant_backlight_voltage_time_interval[
num_constant_backlight_voltage_time_intervals ];
unsigned int(2) num_max_variations;
unsigned int(6) reserved = 0;
© ISO/IEC 2026 – All rights reserved
unsigned int(16) max_variation[ num_max_variations ];
}
The Display-Fine Control metadata samples use the following syntax:

class QualityLevels (num_quality_levels) {
unsigned int(8) rgb_component_for_infinite_psnr;
for (i = 1; i <= num_quality_levels; i++) {
unsigned int(8) max_rgb_component;
unsigned int(8) scaled_psnr_rgb;
}
}
class MetadataSet (num_quality_levels) {
unsigned int(8) lower_bound;
if (lower_bound > 0)
unsigned int(8) upper_bound;
QualityLevels(num_quality_levels);
}
class DisplayPowerReductionMetaDataSample {
unsigned int(4) num_quality_levels;
unsigned int(4) reserved = 0;
for (k=0; k for (j = 0; j < num_max_variations; j++)
MetadataSet(num_quality_levels);
}
5.3.3.3 Semantics
Semantics are defined in ISO/IEC 23001-11.
5.3.4 Display attenuation map metadata
5.3.4.1 General
A display attenuation map video is a 2D video where each frame conveys pixel-wise information that can be
applied to a corresponding frame in the original video sequence through a processing operation to reduce
the total energy consumption resulting from rendering the frames of that video.
5.3.4.2 Attenuation map information box
5.3.4.2.1 Definition
An AttenuationMapInformationBox contains information about the characteristics of the display attenuation
map data stream carried by the track in which it is signalled. It is identified by the 4CC ‘amid’. The information
in the payload of the track may include pre-processing operations that should be applied to the samples of
the display attenuation map as well as other information that may distinguish one display attenuation map
track from another for the same content, which enables a player to select the most suitable track based on its
energy reduction strategy.
5.3.4.2.2 Syntax
aligned(8) class AMIApproximationModel() {
bit(4) reserved = 0;
unsigned int(4) ami_map_approx_model;
}
aligned(8) class AMIWindowInfo() {
unsigned int(8) ami_window_x;
unsigned int(8) ami_window_y;
© ISO/IEC 2026 – All rights reserved
unsigned int(8) ami_window_width;
unsigned int(8) ami_window_height;
}
aligned(8) class AMIVideoQualityInfo() {
bit(5) reserved = 0;
unsigned int(3) ami_quality_metric;
unsigned int(8) ami_quality_reduction;
}
aligned(8) class AMIPreprocessingInfo() {
bit(6) reserved = 0;
unsigned int(2) ami_preprocessing_type;
unsigned int(8) ami_max_value;
unsigned int(8) ami_preprocessing_scale;
}
aligned(8) class AttenuationMapInformationBox() extends FullBox('amid', version = 0, flags) {

bit(3) reserved = 0;
unsigned int(1) ami_preprocessing_info_present_flag;
unsigned int(1) ami_approx_model_present_flag;
unsigned int(1) ami_window_info_present_flag;
unsigned int(1) ami_video_quality_info_present_flag;

unsigned int(5) ami_energy_reduction_rate;
unsigned int(4) ami_display_model;
unsigned int(4) ami_attenuation_use_idc;
unsigned int(4) ami_attenuation_component_idc;

if (ami_preprocessing_info_present_flag) {
AMIPreprocessingInfo();
}
if (ami_approx_model_present_flag) {
AMIApproximationModel();
}
if (ami_window_info_present_flag) {
AMIWindowInfo();
}
if (ami_video_quality_info_present_flag) {
AMIVideoQualityInfo();
}
}
5.3.4.2.3 Semantics
The semantics of the fields defined in AttenuationMapInformationBox are as follows:
ami_preprocessing_info_present_flag is a flag indicating whether preprocessing information is present.
Value 1 indicates that the box contains preprocessing information.
ami_approx_model_present_flag is a flag indicating whether approximation model information is present.
Value 1 indicates that the box contains approximation model information.
ami_window_info_present_flag is a flag indicating whether window information is present. Value 1 indicates
that the box contains window information.

© ISO/IEC 2026 – All rights reserved
ami_video_quality_info_present_flag is a flag indicating whether video quality information is present.
Value 1 indicates that the box contains video quality information.
ami_energy_reduction_rate indicates the expected energy saving rate (percentage) when the associated
video is displayed after applying the display attenuation map sample values on the sample values of the
associated video.
ami_display_model indicates the display models on which the display attenuation map
sample values may be used. The semantics of the bits of this field are described in Table 6.
Table 6 — Semantics of the bits of the ami_display_model field.
Bit number Display model
0 Transmissive pixel
1 Emissive pixel
2 . 3 Reserved for future use
ami_attenuation_use_idc indicates which operation shall be used to apply the display attenuation
map sample values to the corresponding frame in the associated video before rendering the
frame on the display. The semantics of the values assigned to this field are described in Table 7.
Table 7 — Semantics of the values assigned to ami_attenuation_use_idc.
Value Description
0 The display attenuation map sample values shall be added to the associated
video frame sample values.
1 The display attenuation map sample values shall be subtracted from the
associated video frame sample values.
2 The associated video frame sample values shall be multiplied by the display
attenuation map sample values.
3 The display attenuation map sample values shall be applied to the associated
video frame according to a proprietary user-defined process.
ami_attenuation_component_idc indicates on which color component(s) of the associated
video the display attenuation map shall be applied using the operation defined by
ami_attenuation_use_idc. It also specifies the number of components of the display
attenuation map. The semantics of the values assigned to this field are described in Table 8.

© ISO/IEC 2026 – All rights reserved
Table 8 — Semantics of the values assigned to ami_attenuation_component_idc.
Value Description
0 The display attenuation map contains only one component, and this component
shall be applied to the luma component of the associated video.
1 The display attenuation map contains two components, and the first com-
ponent shall be applied to the luma component of the associated video, and
the second component should be applied to both chroma components of the
associated video.
2 The display attenuation map contains only one component, and this compo-
nent shall be applied to the luma component and the chroma components of
the associated video.
3 The display attenuation map contains only one component, and this compo-
nent shall be applied to the RGB components (after YUV to RGB conversion)
of the associated video.
4 The display attenuation map contains three components, and these compo-
nents shall be applied respectively to the luma and chroma components of
the associated video.
5 The display attenuation map contains three components, and these compo-
nents shall be applied, respectively, to the RGB components (after YUV to RGB
conversion) of the associated video.
6 The mapping between the components of the display attenuation map and
the components of the associated video to which the display attenuation map
is applied is based on some proprietary user-defined process.
7 . 15 Reserved for future use
Key:
YUV = colour space with luma (Y) and chroma (U,V) components
ai_preprocessing_type indicates which type of pre-processing interpolation model should be used to re-sample
the display attenuation map sample values at the same resolution as the associated video before applying
it to the associated video frame. The semantics of the values assigned to this field are described in Table 9.
Table 9 — Semantics of the values assigned to ami_preprocessing_type.
Value Description
0 Bicubic interpolation.
1 Bilinear interpolation.
2 Lanczos interpolation.
3 User-defined interpolation process.
ami_max_value indicates the maximum value of the display attenuation map. This value may be used to
further adjust the dynamic range of the encoded display attenuation map in the scaling process.
ami_preprocessing_scale indicates which scaling shall be applied to obtain the display
attenuation map sample values before applying them on the sample values of the associated
video. The semantics of the values assigned to this field are described in Table 10.
Table 10 — Semantics of the values assigned to ami_preprocessing_scale
Value Description
0 A scaling of 1/255 shall be applied.
1 User-defined scaling operation.
2.7 Reserved for future use.
© ISO/IEC 2026 – All rights reserved
ami_map_approx_model specifies which model should be used to extrapolate the display attenuation map
with individual energy reduction rate to another set of display attenuation map with a different
energy reduction rate. The semantics of the values assigned to this field are described in Table 11.
Table 11 — Semantics of the values assigned to ami_map_approximation_model
Value Description
0 Extrapolation to another target energy reduction rate should be applied
through a linear scaling of the display attenuation map sample values given
its ami_energy_reduction_rate value and the target energy reduction rate.
1 User-defined extrapolation process.
2.3 Reserved for future use.
ami_window_x indicates the x-coordinate of the top-left corner of the bounding window defining a region of
the associated video to which the display attenuation map carried by the display attenuation map track
shall be applied.
ami_window_y indicates the y-coordinate of the top-left corner of the bounding window defining a region of
the associated video to which the display attenuation map carried by the display attenuation map track
shall be applied.
ami_window_width indicates the width, in number of pixels, of the bounding window defining a region of the
associated video to which the display attenuation map carried by the display attenuation map track
shall be applied.
ami_window_height indicates the height, in number of pixels, of the bounding window defining a region of
the associated video to which the display attenuation map carried by the display attenuation map track
shall be applied.
ami_quality_metric indicates the type of the objective quality metric used for the measured quality reduction
value resulting from applying the display attenuation map to the associated video and assigned to the
ami_quality_reduction field. The semantics of the values assigned to this field are described in Table 12.
Table 12 — Semantics of the values assigned to ami_quality_metric
Value Quality metric
0 PSNR
1 SSIM
2 wPSNR
3 WS-PSNR
4 User-defined
ami_quality_reduction specifies the percentage of quality reduction that can be expected in the associated
video as a result of applying the display attenuation map to it.
5.3.4.3 Display attenuation map tracks
5.3.4.3.1 General
A display attenuation map track is a restricted video track with the sample entry type 'resv'. The original
sample entry type, which is based on the video codec used for encoding the stream, is stored within the
OriginalFormatBox in the RestrictedSchemeInfoBox. The scheme_type field in SchemeTypeBox shall be set to
'gmat', indicating a display attenuation map restricted scheme. The SchemeInformationBox shall include an
AttenuationMapInformationBox, as defined in subclause 5.3.3.2. In the track header, the track_in_movie flag
shall be set to 0 to indicate that this track should not be presented alone.

© ISO/IEC 2026 – All rights reserved
5.3.4.3.2 Association with video tracks
A TrackReferenceTypeBox with the reference type 'gmam' shall be added to a TrackReferenceBox within the
TrackBox of the track carrying the display attenuation map data. The TrackReferenceTypeBox shall contain
an array of track_IDs designating the identifiers for the referenced video tracks.
5.3.4.3.3 Sample format
Each sample in a display attenuation map track carries a sequence of video NAL units corresponding to the
encoded display attenuation map for a single access unit (AU) in the associated video track(s) and shall be
encapsulated based on the sample formats defined in ISO/IEC 14496-15.
5.3.4.3.4 Signalling alternative attenuation map tracks
Multiple display attenuation map tracks may be present in an ISOBMFF file. When more than one version of a
display attenuation map is available for the same video track in the ISOBMFF container (e.g., different energy
consumption levels or different video qualities), each version is carried in a separate display attenuation
map track.
Display attenuation map tracks that are alternatives of each other shall be signalled as alternatives of each
other by either setting the alternate_group field in their respective TrackHeaderBox(es) to the same value or
grouping the tracks together with an EntityToGroupBox with grouping_type equal to 'altr', indicating that
the display attenuation map tracks which are mapped to this grouping are alternatives to each other, and
only one of them should be processed.
6 Encapsulation and signalling in MPEG-DASH
6.1 General
This clause explains how the green metadata can be computed at the server for adaptive streaming scenarios
and how such metadata can be used at the client.
In the context of DASH delivery, a specific adaptation set within the MPD can define the available green
metadata representations and their association to the available media representations, using the signalling
[1]
mechanisms specified in ISO/IEC 23009-1:2022 and ISO/IEC TR 23009-3 and illustrated in Annex D.
6.2 Decoder-power indication
In the DASH context, the metadata files created for one or multiple video Representations are considered as
metadata Representations. The available metadata Representations are signalled in a specific Adaptation
Set within the MPD manifest file. The association of a metadata Representation with a media Representation
is signalled in the MPD through the @associationId and @associationType attributes. A metadata Segment
and its associated media Segment(s) are time aligned on Segment boundaries.
The Decoder-Power Indication metadata Representation is associated with a single media Representation as
shown in Figure 2.
© ISO/IEC 2026 – All rights reserved
Key
p metadata adaptation set (multiple representations)
q media adaptation set (multiple representations)
r initialization segment
S segment #i
i
Figure 2 — One metadata representation for one media representation
See Annex B for example MPDs with decoder power indication metadata.
6.3 Display-power indication
The Display-Power Indication metadata Representation is associated with all the available media
Representations as shown in Figure 3.

© ISO/IEC 2026 – All rights reserved
Key
p metadata adaptation set (single representation)
q media adaptation set (multiple representations)
r initialization segment
S segment #i
i
Figure 3 — One metadata representation for all media representations.
See Annex B for example MPDs with display power indication metadata.
6.4 Display attenuation map information
6.4.1 Metadata signalling in the MPD manifest file
Display attenuation map Representations for a video are signalled in their own Adaptation Set within the
MPD file. This Adaptation Set is henceforth referred to as a Display Attenuation Map Adaptation Set. The @
codecs attribute for a Display Attenuation Map Adaptation Set, or Representations of this Adaptation Set if @
codecs is not signalled for the AdaptationSet element, is set based on the respective codec used for encoding
the display attenuation map. The value of @codecs shall be set to 'resv.gmat.XXXX', where XXXX corresponds
to the four-character code (4CC) of the video codec and shall be identical to the original_format field in the
RestrictedSchemeInfoBox of the sample entry of the corresponding ISOBMFF track, clause 5.3.3.
The association of a display attenuation map Representation element with one or more video
Representation(s) is signalled in the MPD through the @associationId and @associationType attributes.
The @associationId attribute is set to a space separated list that includes the @id attribute values of the
associated video Representations. The @associationType attribute shall be set to “amit”, indicating that this
association is for display attenuation map information.

© ISO/IEC 2026 – All rights reserved
Multiple display attenuation maps with different characteristics (e.g., different values of ami_energy_
reduction_rate, different values of ami_display_model, different resolutions, etc.) can be generated
for the same video Representation and each alternative display attenuation map is represented by one
Representation in the Display Attenuation Map Adaptation Set. As specified in subclause 5.3.4.3.4, these
display attenuation map Representations that are alternatives of each other shall be indicated by the same
value of alternate_group in the TrackHeaderBox.
A number of Display Attenuation Map Adaptation Sets may be associated with the same video. For example,
each Display Attenuation Map Adaptation Set may be related to a particular region (window) within the
v
...