ISO/IEC 23001-17:2024/Amd 2:2025

International
Standard
ISO/IEC 23001-17
First edition
Information technology — MPEG
2024-02
systems technologies —
AMENDMENT 2
Part 17:
2025-08
Carriage of uncompressed video and
images in ISO base media file format
AMENDMENT 2: Generic compression
for samples and items in ISOBMFF
Technologies de l'information — Technologies des systèmes MPEG —
Partie 17: Transport de vidéos et d'images non compressées dans
le format ISO de base pour les fichiers médias
AMENDEMENT 2: Compression générique pour les échantillons et
les articles au format ISOBMFF
Reference number
ISO/IEC 23001-17:2024/Amd. 2:2025(en) © ISO/IEC 2025

ISO/IEC 23001-17:2024/Amd. 2:2025(en)
© ISO/IEC 2025
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
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 www.iso.org/directives or 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 not
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 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 www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, SC 29,
Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 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 www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
iii
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
Introduction
0.1  General
This amendment to ISO/IEC 23001-17 includes the following additions and corrections:
— defines the capability to apply generic compression to still and motion imagery as well as other media
types (e.g. KLV metadata tracks);
— clarifies the original standard text related to padding of images using subsampled chroma components;
— corrects a typographical error in subclause 5.3.2, Table 5;
— corrects a typographical error in subclause 6.1.11.2;
— adds the capability to encode signed integer components;
— adds brands for generically compressed media.
While ISO/IEC 23001-17 nominally defines the mechanism to carry uncompressed imagery and raster data
within ISOBMFF, it also more generically defines a mechanism to define the in-memory layout for an item or
sample, and then store the image using that layout. Key aspects of that in-memory layout are:
— component value types and sizes;
— tiling to enable efficient spatial-based access for large imagery;
— padding to ensure that individual component values or groups of component values can be accessed by
the processing unit without having to perform bit shifts for every single access, and without having to
cross key storage/memory page boundaries.
This capability brings ISOBMFF on par with other generic storage formats for numeric data (such as HDF5)
with one exception – data-agnostic numerically-lossless and bitwise-lossless compression, transparent to
the end user. In HDF5, for example, a large N-dimensional array of numerical data can be chunked (i.e. tiled)
and then each chunk is compressed using off-the-shelf ubiquitous data-agnostic compression tools (e.g.
deflate). This provides storage and transmission savings similar to numerically lossless image coders, with
minimal computational performance impact. These capabilities can be applied not only to typical integer-
based pixel formats, but also to IEEE 754 floating-point pixel formats that are unsupported in most imagery
compression algorithms.
Adding this capability to ISO/IEC 23001-17 is expected to provide cost savings (for both storage and network
transmission), particularly for applications and datasets involving large amounts of uncompressed content,
such as geospatial and scientific imagery, without significantly changing how those applications access the
pixel data.
In this amendment, this mechanism is applied to KLV formatted metadata tracks in addition to image
samples and items. Application to other media types can be defined in future standards.
0.2  Use cases
— Data producer generates a large image (or image sequence) using 32-bit IEEE 754 binary floating
point component values after calibration. The image is tiled using 1024 × 1024 tiles and each tile is
independently compressed using deflate.
— Data consumer desires to load only a specific spatial region from an image or sample based on some
form of chunking of the image (chunk by rectangular tiles or chunk by rows). Consumer uses offset/size
information provided within the ISOBMFF file to locate only the desired chunks. Each of those chunks
can be independently decompressed.
— Data consumer desires to load only a spatial region from a large tiled image, where the desired region
is smaller than a region contained within a single compressed tile. After decompressing the tile, the
order, alignment and padding of the component data is maintained, enabling the consumer to calculate

© ISO/IEC 2025 – All rights reserved
iv
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
individual component value offsets – parsing through the decompressed tile to locate specific pixels/
component is not necessary.
— A data producer collects an image of the Earth scanning diagonally from northwest to southeast. For
simpler human viewing of the image, the collected image is rotated 45 degrees to align north to up, and
additional padding is added to form a tiled, rectangular image buffer. Since the four corner tiles are
entirely fill data, they are omitted from the data stored within the ISOBMFF file.
— Legal requirements for records management require bitwise-lossless compression of the image data – it
is not sufficient that the decompressed pixel value is numerically equal to the original pixel value; the
specific bit patterns must also be the same.
0.3  Capabilities
— Numerically and bitwise lossless compression of items and track samples, especially when consisting of
floating-point formatted media.
— Pixel organization prior to compression (as well as post-decompression) is defined by the uncompressed
spec in ISO/IEC 23001-17. The point is for the encoder to determine how to best organize the pixel/
component data when in a directly-accessible form, and then to implement simple off-the-shelf,
numerically/bitwise-lossless compression on that data.
— Utilization of existing compression technology with open licensing, broad/mature support, and
availability of open-source software and tools.
— Ability to access portions of the image without fully decompressing the entire sample or item.
— Ability to compress, access, and decompress tiles independently. This includes gridded items as well
as tiles defined within ISO/IEC 23001-17.
— Ability to minimize coding/inclusion of fill data.
— e.g. a large geospatial image is rotated within the rectangular pixel boundaries so north is up.
This causes the corners of the expanded rectangular image to be just fill pixels, with a resulting
preference to not have to store those fill pixels
— Specifying a transformative property for arbitrary rotation is ultimately not sufficient as there
are many means to precisely georeference an image (e.g. orthorectification) involving pushing
pixels around based on imaging geometry and terrain.
— Determine if sub images of a gridded item can be omitted.
— Orthogonal capability to the ISO/IEC 23001-17 component value alignment, padding and component
value organization is highly desired. Upon decompression, each chunk is used exactly as if the respective
uncompressed values had been loaded directly from storage or the network.
— Constructive interaction between transformational properties is desired. For example, if the sample is
compressed as individual chunks, but the compressed sample is then encrypted as a single chunk, the
independence of those chunks might be lost.
— Ability to compress KLV metadata tracks and items.

© ISO/IEC 2025 – All rights reserved
v
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
Information technology — MPEG systems technologies —
Part 17:
Carriage of uncompressed video and images in ISO base
media file format
AMENDMENT 2: Generic compression for samples and items
in ISOBMFF
Clause 2
Add the following entries to the list of Normative references
— IETF RFC 1951, DEFLATE Compressed Data Format Specification version 1.3
— IETF RFC 1950, ZLIB Compressed Data Format Specification version 3.3
— IETF RFC 7932, Brotli Compressed Data Format
Clause 3
Add the following new terms after term entry 3.11
3.12
generically-compressed,adj
compressed using one of a defined set of lossless compression algorithms
Note 1 to entry: Supported compression algorithms are specified in Table 7.
3.13
generically-compressed item
item that has been generically-compressed
3.14
generically-compressed sample
sample that has been generically-compressed

Subclause 5.2.1.3, Table 2
Add the following row and modify the last row to reflect use of the previously reserved value 3:
Table 2 — Component formats
Value Description
3 Component value is a signed two’s complement integer coded on component_bit_
depth bits. For this component format, component_bit_depth values shall be great-
er than 1.
other values ISO/IEC reserved for future definition

© ISO/IEC 2025 – All rights reserved
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
Subclause 5.2.1.5.3
Replace the last two lists with the following:

If row_align_size is not 0 and interleave_type is 0:
— row_align_size shall be a multiple of 2
If tile_align_size is not 0:
— tile_align_size shall be a multiple of 2

Subclause 5.2.1.5.4
Replace the last two lists with the following:
If row_align_size is not 0 and interleave_type is 0:
— row_align_size shall be a multiple of 2
If tile_align_size is not 0:
— tile_align_size shall be a multiple of 4

Subclause 5.2.1.5.5
Replace the last two lists with the following:
If row_align_size is not 0 and interleave_type is 0:
— row_align_size shall be a multiple of 4
If tile_align_size is not 0:
— tile_align_size shall be a multiple of 4

nd
Subclause 5.2.1.7, 2 paragraph after NOTE4
Replace:
Rows of tiles shall be byte-aligned at the end of the row:
with the following:
Rows and tile rows shall be byte-aligned at the end of the row:

Subclause 5.2.1.7
Replace:
If row_align_size is 0, no additional padding is present at the end of rows of tiles. Otherwise, let RowSize be
the number of bytes required to contain, for a given row R:
— all values of all components of row R if interleave_type is 1 or 5 or if interleave_type is 2 and component
type is ‘U’ or ‘V’ (including all component, block and pixel padding within and at the end of the sample
data for row R);
© ISO/IEC 2025 – All rights reserved
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
— all values of the current component for row R (including all component and block padding within the
sample data for row R) otherwise.
with the following:
If row_align_size is 0, no additional padding is present at the end of rows and tile rows. Otherwise, let
RowSize be the number of bytes required to contain, for a given row R:
— all values of all components of row R (including all component, block and pixel padding within and at the
end of the sample data for row R) if interleave_type is 1 or 5;
— all values of pixel interleaved components (‘U’ and ‘V’) of row R if interleave_type is 2 and component
type is ‘U’ or ‘V’ (including all component, block and pixel padding within and at the end of the sample
data for row R);
— all values of the current component for row R (including all component and block padding within the
sample data for row R) otherwise.

Subclause 5.3.2, Table 5
Correct the last row of the table to be the following.
Table 5 — Predefined uncompressed frame formats
Profile identifier Description Field values for UncompressedFrameConfigBox
…
'yv20'
YUV 420 8 bits planar {'yv20', [{1,7},{3,7},{2,7}], 2, 0}
YCrCb
Subclause 6.1.11.2
Change “DepthInfoBox” “DepthMappingInformationBox”

Clause 8
Add the following new clauses after Clause 8
9  Generic compression of items and sample data
9.1  Overview
Storing uncompressed item and sample data is required in many use cases, some of which are not well-
supported by typical image compression algorithms (e.g. floating point or very high-bit depth imagery).
Other types of sample data, such as KLV (SMPTE 336M-2007), are only compressible by standard generic
data compression mechanisms. The ability to compress data for any media type without compression loss is
desirable for reducing storage sizes and transmission times, such as in the following scenarios.
— A data producer generates a large image (or image sequence) using 32-bit IEEE 754 binary floating
point component values after calibration. The image is tiled using 1024 × 1024 tiles and each tile is
independently compressed using deflate.
— A data consumer desires to load only a specific spatial region from an image or sample based on some
form of chunking of the image (chunk by rectangular tiles or chunk by rows). Consumer uses offset/size
information provided within the file to locate only the desired chunk(s). Each chunk is independently
decompressed.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 23001-17:2024/Amd. 2:2025(en)
— A data consumer desires to load only a spatial region from a large tiled image, where the desired region
is smaller than a region contained within a single compressed chunk. After decompressing the chunk,
the order, alignment and padding of the component data is maintained, enabling the consumer to locate
individual component values via calculated offsets.
— A data producer collects an image of the Earth scanning diagonally from northwest to southeast. For
simpler human viewing of the image, the collected image is rotated 45 degrees to align north to up, and
additional padding is added to form a tiled, rectangular image buffer. Since the four corner tiles are
entirely fill data, they can more efficiently be stored than simply compressing multiple blocks of fill data.
— A data producer generates multiple blocks of metadata, encoded using Key-Length-Value encoding, and
stores them as individual items. The value portion of each KLV metadata item is a set or pack containing
binary metadata and is generically compressed to save space.
To decompress a complete media sample or item, the file reader locates the data as given by the sample or
item’s compressed units description. The extracted compressed data is then decompressed according to the
compression algorithm specified by the compression_type field in the CompressionConfigurationBox. The
resultant data is formatted exactly as was specified by the underlying media format, including any padding
placed at the end of the element to align the next element.
If the value of the compressed_unit_type field in the CompressionConfigurationBox is not 0, decompression
of individual portions of the sample is possible. In those cases, the individual ranges specified in the Generi
callyCompressedUnitsInfoBox map to the individual units as specified by the compressed_unit_type field,
in the order those units would have been found in the coded data were that coded data left uncompressed as
specified in Clause 5.
For media tracks, generic compression is signalled using a restricted transformation scheme as specified in
subclause 9.3, and can be used in conjunction with other track transformation such as encryption or other
restricted video transformation, as specified in ISOBMFF.
For items, generic compression is signalled using an essential property as specified in subclause 9.4 and can
be used in conjunction with item protection as defined in ISOBMFF.
9.2  Compression Configuration Box
9.2.1  Definition
Box Type: 'cmpC'
Container: SchemeInformationBox or ItemPropertyContainerBox
Mandatory: Yes (when the SchemeType is 'gcmp')
Quantity: One
The CompressionConfigurationBox specifies the specific data compression method used and codec-specific
type of compressed units within a media sample or item data.
This box can be:
— added to a restricted video sample entry for media tracks;
— added as properties associated with an item.
The syntax in this section is given for a video sample entry container and the defined box therefore extends
FullBox. When used in an ItemPropertyContainerBox, the same syntax applies but the defined boxes extends
ItemFullProperty. The properties defined in the following sections are descriptive properties.
The definition of each value of compression_type specifies not only the algorithm but also the bitstream
format for each compressed subsample. For example, ‘zlib’ specifies the use of the deflate algorithm as
packaged in the zlib format de
...