ISO/IEC 23090-2:2023/Amd 1:2026

• Status: Published
• Publication Date: 10-Nov-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 - Coding of audio, picture, multimedia and hypermedia information
• Current Stage: 6060 - International Standard published
• Start Date: 11-Nov-2026
• Completion Date: 11-Nov-2026

• Amends: ISO/IEC 23090-2:2023 - Information technology — Coded representation of immersive media — Part 2: Omnidirectional media format
• Effective Date: 19-Aug-2023

ISO/IEC 23090-2:2023/Amd 1 is an ISO amendment to Part 2 of the coded representation of immersive media series. It adds server-side dynamic adaptation for omnidirectional media, including new DASH request parameters, new ISOBMFF signalling, and new restricted video scheme types for projected omnidirectional video with dynamic region-wise packing.

What does ISO/IEC 23090-2:2023/Amd 1 specify?

ISO/IEC 23090-2:2023/Amd 1 updates the omnidirectional media format in ISO/IEC 23090-2 by adding a normative Annex H for server-side dynamic adaptation and by amending several tables and container rules. In practice, it tells implementers how a server can receive adaptation parameters, select or adapt OMAF media segments, and signal new projected-video packing cases.

Annex	What it covers
Annex H	Server-side dynamic adaptation, including architecture, signalling, ISOBMFF extensions, segment format rules, and restricted video schemes

The amendment touches the signalling used in clause 4.7.5, the container rules in clause 7.6, and the new dynamic-adaptation rules in Annex H. That matters to anyone packaging, delivering, or playing OMAF content because it changes what can be signalled in a segment or request.

What are the key requirements of ISO/IEC 23090-2:2023/Amd 1?

Server-side adaptation signalling

ISO/IEC 23090-2:2023/Amd 1 adds a server-side dynamic adaptation model in Annex H. Adaptation parameters can be sent in HTTP URL query parameters and/or HTTP header parameters for OMAF related media segments, and an OMAF player with an SSDA descriptor is expected to include them in requests.

When an SSDA descriptor is present in an AdaptationSet or Representation, the DASH profile urn:mpeg:mpegI:omaf:dash:profile:serverSideDynamicAdaptation applies. For implementers, this means the adaptation logic is signalled as part of DASH delivery and not only handled inside the client.

Track selection and viewport parameters

Annex H defines parameters for track selection or switching in Table H.1. These include scsw, scsh, bitr, frar, and nvws. The table also states which values should stay stable across successive requests, which is important when a client is trying to keep a representation consistent while still allowing adaptation.

Table H.2 defines viewport-related parameters: azim, elev, tilt, azrg, elrg, and styp. Requests related to a viewport shall include azrg, elrg, and styp. In practice, this lets a server return a segment targeted to the requested viewing region, with viewport quality at least matching the background.

ISOBMFF signalling for dynamic packing

ISO/IEC 23090-2:2023/Amd 1 adds the rwpk sample grouping for region-wise packing. The rwpk grouping_type maps packed regions to projected regions and records guard band location and size. If rwpk sample grouping is used, the region-wise packing box shall not also be present.

The amendment also allows ProjectedOmniVideoDynamicPackingBox in the container rules of 7.6.5.1 and 7.6.6.1. That matters because it makes the dynamic-packing box part of the normal signalling path for projected omnidirectional video and related spatial descriptions.

New restricted video scheme types

The amendment adds two scheme types in Annex H:

• podr - an open-ended scheme type for projected omnidirectional video with dynamic region-wise packing
• erdp - a closed scheme type for packed equirectangular or cubemap projected video with dynamic region-wise packing

podr allows the ProjectedOmniVideoDynamicPackingBox and optional StereoVideoBox, while erdp narrows the allowed projection formats and box combinations. For a buyer or engineer, this tells you whether a track is a general dynamic-packing track or a constrained profile for equirectangular/cubemap content.

Segment consistency rules

If any sample in a media segment is mapped to the rwpk sample group, all samples in that segment shall use the same rwpk description entry. This keeps the segment internally consistent, which is important for correct decoding and rendering after server-side rewriting or adaptation.

What terms does ISO/IEC 23090-2:2023/Amd 1 define?

• SSDA - Server-side dynamic adaptation, where the server performs the dynamic selection or adaptation of media segments from request parameters.
• CSDA - Client-side dynamic adaptation, the complementary approach where the client performs more of the adaptation work.
• rwpk - The region-wise packing sample grouping that links packed regions to projected regions and records guard bands.
• podr - The open-ended scheme type for projected omnidirectional video with dynamic region-wise packing.
• erdp - The closed scheme type for packed equirectangular or cubemap projected video with dynamic region-wise packing.
• ProjectedOmniVideoDynamicPackingBox - The box used to carry projection, packing, rotation, and optional coverage information for the dynamic-packing case.

Who uses ISO/IEC 23090-2:2023/Amd 1?

ISO/IEC 23090-2:2023/Amd 1 is used by engineers working on OMAF players, media packagers, and streaming servers. It is also relevant to CDN and adaptation-service implementers who process HTTP requests and rewrite or select media segments.

Quality managers and test teams use it to verify that segment signalling, request parameters, and track-selection behavior match the intended OMAF workflow. It is especially relevant in immersive media, 360-degree video, and head-mounted display delivery chains.

What changed in ISO/IEC 23090-2:2023/Amd 1 from the previous edition?

ISO/IEC 23090-2:2023/Amd 1 amends ISO/IEC 23090-2:2023 with server-side dynamic adaptation support. The amendment:

• adds Annex H on server-side dynamic adaptation
• adds the podr and erdp scheme types
• adds the rwpk sample grouping for dynamic region-wise packing
• updates container rules to allow ProjectedOmniVideoDynamicPackingBox
• adds DASH request parameters for track selection, switching, and viewport adaptation

Which standards are used with ISO/IEC 23090-2:2023/Amd 1?

• ISO/IEC 23009-1 - used for DASH URL query parameters and HTTP delivery related to media segments.
• ISO/IEC 14496-12 - defines the ISO Base Media File Format used for the media file and segment container.
• ISO/IEC 23091-3 - provides the loudspeaker layout definitions referenced for channel-based audio signals.

What does the ISO/IEC 23090-2:2023/Amd 1 document contain?

ISO/IEC 23090-2:2023/Amd 1 contains amendment text that inserts new entries into existing tables and updates clause references for the new dynamic-packing boxes. It also adds Annex H, which includes the overall architecture, signalling rules, ISOBMFF extensions, segment format rules, and restricted video scheme definitions.

The annex includes two figures showing the content flow and an example streaming system, plus tables for track-selection parameters and viewport-related parameters. It also gives the syntax and semantics of the rwpk grouping and the ProjectedOmniVideoDynamicPackingBox, together with the rules needed for implementation, packaging, delivery, and verification.

International
Standard
ISO/IEC 23090-2
Third edition
Information technology — Coded
2023-06
representation of immersive
media —
AMENDMENT 1
2026-11
Part 2:
Omnidirectional media format
AMENDMENT 1: Server-side dynamic
adaptation
Technologies de l'information — Représentation codée de média
immersifs —
Partie 2: Format de média omnidirectionnel
AMENDEMENT 1: Adaptation dynamique côté serveur
Reference number
ISO/IEC 23090-2:2023/Amd. 1:2026(en) © ISO/IEC 2026

ISO/IEC 23090-2:2023/Amd. 1:2026(en)
© ISO/IEC 2026
All rights reserved.
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued by ISO,
an ISO member body, or an authorized third-party distributor.
Except as required for implementation or expressly permitted by a separate licence, no part of this ISO publication may be
reproduced, distributed, modified, used, or made available in any form or by any means – electronic or mechanical, including
photocopying, scanning, recording, or posting on internal or external digital platforms.
Any use beyond the scope of the granted rights is prohibited and may result in legal action.
ISO copyright office
CP 401 • CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC 23090-2:2023/Amd. 1:2026(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,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 23090 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 2026 – All rights reserved
iii
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
Information technology — Coded representation of
immersive media —
Part 2:
Omnidirectional media format
AMENDMENT 1: Server-side dynamic adaptation

In 4.7.5.3, add the following entries to Table 4 at the end:
podr
H.6.1.1 An open-ended restricted scheme type for projected omnidirectional
video with dynamic region-wise packing.
erdp
H.6.1.2 Packed equirectangular or cubemap projected video with dynamic
region-wise packing.
In 4.7.5.5, next to the following table rows:
movd 7.6.7 mesh omnidirectional video box
mesh 7.6.8 mesh box
rotn 7.6.5 rotation box
add the following table rows before the table row labeled as "sphere region sample entry":
pord H.6.2 projected omnidirectional video with dynamic

region-wise packing
prfr 7.6.2 projection format box
rotn 7.6.5 rotation box
covi 7.6.6 coverage information box

In 4.7.5.8, add the following entry to Table 9 at the end:
rwpk
H.4.1.1 Sample grouping specifying the mapping between packed regions and
the corresponding projected regions and specifying the location and
size of the guard bands, if any.

In 7.6.5.1, replace:
Container: ProjectedOmniVideoBox or MeshOmniVideoBox

with:
© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
Container: ProjectedOmniVideoBox, MeshOmniVideoBox, or
ProjectedOmniVideoDynamicPackingBox

In 7.6.6.1, replace:
Container: ProjectedOmniVideoBox or
SpatialRelationship2DDescriptionBox

with:
Container: ProjectedOmniVideoBox,
SpatialRelationship2DDescriptionBox, or
ProjectedOmniVideoDynamicPackingBox

In 4.7.5.1 and C.1.4, replace:
cvvc
with:
cvvi
Annex H
Add a new annex after Annex G.

© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
Annex H
(normative)
Server-side dynamic adaptation
H.1 General
This annex provides an overall architecture and adaptation parameters to support server-side dynamic
adaptation. These parameters can be used as part of HTTP requests for OMAF related media segments in
URL parameters as specified in ISO/IEC 23009-1, in the forms of
— URL query parameters, and/or
— HTTP header parameters.
It is expected that, when received at dynamic adaptation server, OMAF content (e.g. in the form of streaming
segments) will be dynamically selected and/or adapted, according to the received adaptation parameters,
and delivered back to an OMAF player.
H.2 Overall architecture
This clause describes an overall architecture for an omnidirectional media application. Some of the described
features are not enabled when the server-side dynamic adaptation specified in this Annex is in use.
Figure H.1 shows a typical content flow process for an omnidirectional media application.
NOTE 1 In this content flow process, the dynamic adaptation service is a different server process than the content
generation process.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
Figure H.1 — Content flow process for omnidirectional media with projected video
The following interfaces are specified in this document:
— E' , E' , E' : audio bitstream, video bitstream, coded image(s), respectively; see Clause 10.
a v i
— E' : video bitstream, see Clause 10.
v-s
— F/F': media file; see Clause 7. Moreover, media profiles specified in Clause 10 include the specification of
the track formats for F/F', which may contain constraints on the elementary streams contained within
the samples of the tracks.
— Clause 8 specifies the delivery related interfaces for DASH delivery.
— Clause 9 specifies the delivery related interfaces for MMT delivery.
The other interfaces in Figure 1 are not specified in this document.
NOTE 2 While the syntax and semantics of the bitstreams E , E , and E are the same as those for E' , E' , E' ,
a v i a v i
respectively, the input interface to the file/segment encapsulation module is not specified.
NOTE 3 While the syntax and semantics of the bitstreams E , is the same as for E' the input interface to the file/
v v-s
segment encapsulation module is not specified.
A real-world audio-visual scene (A) is captured by audio sensors as well as a set of cameras or a camera
device with multiple lenses and sensors. The acquisition results in a set of digital image/video (B ) and audio
i
(B ) signals. The cameras/lenses typically cover all directions around the centre point of the camera set or
a
camera device, thus the name of 360-degree video.

© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
Audio may be captured using many different microphone configurations and stored as several different
content formats, including channel-based signals, static or dynamic (i.e. moving through the 3D scene) object
signals, and scene-based signals (e.g. Higher Order Ambisonics). The channel-based signals typically conform
to one of the loudspeaker layouts defined in ISO/IEC 23091-3. In an omnidirectional media application, the
loudspeaker layout signals of the rendered immersive audio program are binauralized for presentation via
headphones.
For audio, no stitching process is needed, since the captured signals are inherently immersive and
omnidirectional.
This document specifies the following types of omnidirectional video and images, which differ in the
architecture in the image pre-processing for encoding and in the image rendering processing blocks.
— Projected omnidirectional video/images:
— Image pre-processing for encoding: The images (B ) of the same time instance are stitched, possibly
i
rotated, and projected onto a 2D picture coordinates using a mathematically specified projection
format. Optionally, the resulting projected pictures may be further mapped region-wise onto a
packed picture. Either projected pictures or packed pictures are subject to video or image encoding.
— Image rendering: Either regions of the decoded packed pictures (if region-wise packing has been
applied) or the entire projected picture (otherwise) is mapped onto a rendering mesh suitable for
the projection format in use.
— Fisheye omnidirectional video/images:
— Image pre-processing for encoding: Circular images (Bi) captured by fisheye lenses are arranged
onto a 2D picture, which is then input to video or image encoding.
— Image rendering: The decoded circular images are stitched using the signalled fisheye-specific
parameters.
— Mesh omnidirectional video:
— Image pre-processing for encoding: A 3D mesh consisting of mesh elements is generated, where
mesh elements can be either parallelograms or regions of a sphere surface. The images (Bi) of the
same time instance are stitched, possibly rotated, and projected onto the 3D mesh. Mesh elements
are mapped onto rectangular regions of one or more 2D pictures, which are input to video encoding.
— Image rendering: Rectangular regions of the decoded 2D picture(s) are mapped to the 3D mesh,
which is used directly as the rendering mesh.
Further details of the architecture for projected, fisheye, and mesh omnidirectional video/images are
provided in subclauses 4.3, 4.4, and 4.5, respectively.
The pre-processed pictures (D) are encoded as coded images (E ) or a coded video bitstream (E ). The
i v
captured audio (B ) is encoded as an audio bitstream (E ). The coded images, video or audio are then
a a
composed into a media file for file playback (F) or a sequence of an initialization segment and media
segments for streaming (F , F ), according to a particular media container file format. In this document,
s a
the media container file format is the ISO Base Media File Format specified in ISO/IEC 14496-12. The file
encapsulator also includes metadata into the file or the segments.
The segments F are delivered using a delivery mechanism to dynamic adaptation service.
a
In the dynamic adaptation service, the dynamic adaptation parameters, such as bitrate (see Clause H.3),
are sent from the Strategy module in OMAF player to the Adaptation engine module in dynamic adaptation
service, which determines which segments to be received based on the dynamic adaptation parameters,
according to what Adaptation logic module instructs. The received segments (F ) carried in tracks
ad
determined by delivery mechanism are identical to the segments (F ) except when bitstream rewriting is
a
needed. Viewport-dependent video may be carried in multiple tracks, which may be processed and extract
the coded video streams in File/segment decapsulator. The coded video streams are merged in the bitstream
rewriting into a single video bitstream (E' ). This single video bitstream (E' ) is composed into segments
v-s v-s
© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2:2023/Amd. 1:2026(en)
for streaming (F ) in the File/segment encapsulation module, according to a particular media container file
ad
format. The segments F are delivered to an OMAF player.
ad
NOTE 4 When the OMAF player uses the dynamic adaptation service, the OMAF player can perform a reduced
process because, instead of the dynamic adaptation service handling the adaptation and bitstream merging function,
the OMAF player can only send the dynamic adaptation parameters.
NOTE 5 If the segments (F ) are contained in a file and delivered to an OMAF player, the file is a file that contains
ad
the adapted segments, and is not an entire duration file containing content longer than the segments.
The segments F are delivered using a delivery mechanism to an OMAF player.
s
The file that the file encapsulator outputs (F) is identical to the file that the file decapsulator inputs (F').
A file decapsulator processes the file (F') or the received segments (F' and F’ ) and extracts the coded
s ad
bitstreams (E' , E' , or E' ) and parses the metadata. Viewport-dependent video may be carried in multiple
a v i
tracks, which may be merged in the bitstream rewriting into a single video bitstream E' prior to decoding.
v
The audio, video or images are then decoded into decoded signals (B' for audio, and D' for images/video).
a
In the image rendering block, the decoded pictures (D') are projected onto the screen of a head-mounted
display or any other display device based on the metadata parsed from the file. Likewise, decoded audio
(B' ) is rendered, e.g. through headphones, according to the current viewing orientation. The current
a
viewing orientation is determined by the viewing orientation tracking functionality. When a head-mounted
display is in use, the viewing orientation tracking can involve head tracking and
...