ISO/IEC 23090-2:2023/Amd 1

• Status: Not Published
• 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: 6000 - International Standard under publication
• Start Date: 18-Sep-2026
• Completion Date: 10-Oct-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.

FINAL DRAFT
Amendment
ISO/IEC
23090-2:2023/
FDAM 1
ISO/IEC JTC 1/SC 29
Information technology — Coded
Secretariat: JISC
representation of immersive
Voting begins on:
media —
2026-07-23
Part 2:
Voting terminates on:
2026-09-17
Omnidirectional media format
AMENDMENT 1: Server-side dynamic
adaptation
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/IEC 23090­2:2023/FDAM 1:2026(en) © ISO/IEC 2026

FINAL DRAFT
ISO/IEC 23090-2:2023/FDAM 1:2026(en)
Amendment
ISO/IEC
23090-2:2023/
FDAM 1
ISO/IEC JTC 1/SC 29
Information technology — Coded
Secretariat: JISC
representation of immersive
Voting begins on:
media —
Part 2:
Voting terminates on:
Omnidirectional media format
AMENDMENT 1: Server-side dynamic
adaptation
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO/IEC 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
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 Reference number
ISO/IEC 23090­2:2023/FDAM 1:2026(en) © ISO/IEC 2026

© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC 23090-2:2023/FDAM 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/FDAM 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/FDAM 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/FDAM 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/FDAM 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/FDAM 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/FDAM 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,
...

ISO/IEC 23090-2.2:2023/DAMFDAmd 1:2025(en)
ISO/IEC JTC 1/SC 29
Secretariat: JISC
Date: 20252026-07-08-30
Information technology — Coded representation of immersive
media — —
Part 2:
Omnidirectional media format
Amendment AMENDMENT 1: Server-side dynamic adaptation
FDIS stage
ISO/IEC 23090-2:2023/FDAmd 1(en)
© ISO/IEC 20252026
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'sISO’s member body in the country of the requester.
ISO Copyright Officecopyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: [e-mail]
E-mail: [e-mail]
Website: www.iso.orgwww.iso.org
Published in Switzerland.
© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC 23090-2.2:2023/DAMFDAmd 1: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/directiveswww.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Field Code Changed
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.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.www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-
Field Code Changed
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.htmlwww.iso.org/members.html and
www.iec.ch/national-committees.
Field Code Changed
© ISO/IEC 20252026 – All rights reserved
iii
ISO/IEC 23090-2.2:2023/DAM 1:2025(en)
Information technology — Coded representation of immersive media
— —
Part 2:
Omnidirectional media format
Amendment
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:
mo 7.6.7
mesh omnidirectional video box
vd
me 7.6.8
mesh box
sh
rot 7.6.5
rotation box
n
add the following table rows before the table row labeled as "sphere region sample entry":
por H.6. projected omnidirectional video with dynamic

d 2 region-wise packing
prf 7.6.
projection format box
r 2
rot 7.6.
rotation box
n 5
cov 7.6.
coverage information box
i 6
In 4.7.5.8, add the following entry to Table 9 at the end:
© ISO/IEC 2025 – All rights reserved
ISO/IEC 23090-2:2023/FDAmd 1(en)
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:
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 GH
Add a new annex (Annex H) after Annex G.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2.2:2023/DAMFDAmd 1:2025(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 20252026 – All rights reserved
ISO/IEC 23090-2:2023/FDAmd 1(en)

© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2.2:2023/DAMFDAmd 1:2025(en)

Figure H.1 — Content flow process for omnidirectional media with projected video
The following interfaces are specified in this document:
— — E'a, E'v, E'i: audio bitstream, video bitstream, coded image(s), respectively; see Clause 10.
— — 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' , respectively,
a v i a v i
the input interface to the file/segment encapsulation module is not specified.
NOTE 3 While the syntax and semantics of the bitstreams Ev, is the same as for E'v-s the input interface to the
file/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 (B )
i a
© ISO/IEC 20252026 – All rights reserved
ISO/IEC 23090-2:2023/FDAmd 1(en)
signals. The cameras/lenses typically cover all directions around the centre point of the camera set or camera
device, thus the name of 360-degree video.
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,
i
possibly 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 (Ei) or a coded video bitstream (Ev). The captured
audio (B ) is encoded as an audio bitstream (E ). The coded images, video or audio are then composed into a
a 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, the media container file format
s a
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.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 23090-2.2:2023/DAMFDAmd 1:2025(en)
The segments Fa are delivered using a delivery mechanism to dynamic adaptation service.
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 determined by delivery
ad
mechanism are identical to the segments (F ) except when bitstream rewriting is needed. Viewport-dependent
a
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 for streaming (F ) in the
v-s v-s ad
File/segment encapsulation module, according to a particular media container file format. The segments Fad
are delivered to an OMAF player.
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 (Fad) are contained in a file and delivered to an OMAF player, the file is a file that contains 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's and F’ad) and extracts the coded bitstreams
(E' , E' , or E' ) and parses the metadata. Viewport-dependent video may be carried in multiple tracks, which
a v i
may be merged in the bitstream rewriting into a single video bitstream E' prior to decoding. The audio, video
v
or images are then decoded into decoded signals (B'a for audio, and D' for images/video). 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,
a
e.g. through headphones, according to the current viewing orientation. The current 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 possibly also eye tracking. When sphere-relative
overlays are in use, the viewing orientation tracking functionality can include
...