ISO/IEC 23009-9:2025

International
Standard
ISO/IEC 23009-9
First edition
Information technology — Dynamic
2025-05
adaptive streaming over HTTP
(DASH) —
Part 9:
Redundant encoding and packaging
for segmented live media (REaP)
Technologies de l'information — Diffusion adaptative dynamique
sur HTTP (DASH) —
Partie 9: Encodage et empaquetage redondant des segments
médias en direct (REaP)
Reference number
© 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
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms.2
3.2 Abbreviated terms .3
4 Overview . 4
5 Reference workflow for redundant encoding and packaging (REaP) . 4
5.1 Reference workflow for REaP .4
5.2 REaP assumptions .5
5.3 General workflow and operation .6
6 Formats for Redundant distribution Encoding . 7
6.1 Constraints on the Ingest Media Presentation Description (I-MPD) .7
6.2 Constraints on the redundant encoder track and segment format .8
6.2.1 Mixed file and live inputs to the encoder . .10
7 Constraints on encoder requests to packager . 10
8 Formats for redundant media presentation packaging .12
8.1 General requirements on redundant packager input . 12
8.2 General requirements on the redundant packager output format(s) . 12
8.3 Specific requirements on the redundant packager D-MPD output format . 12
8.4 Specific requirements on the redundant packager HLS output format . 13
8.5 General requirements on the origin output format . 13
9 Asset storage and recording format .13
9.1 General . 13
9.2 Track format for storage of live archives .14
9.2.1 Storage track file .14
9.2.2 Storage track identifiers .14
9.3 Storage media presentation description (S-MPD) . 15
9.3.1 Overview . 15
9.3.2 Constraints on the S-MPD for 24x7 live archiving and recording .16
9.3.3 Constraint on the S-MPD for recording 24x7 live content .16
Annex A (informative) Example media presentation description . 17
Annex B (informative) Recommended segment durations for encoder synchronization.24
Annex C (informative) Example applications .25
Annex D (informative) Example methods of carriage of source timing .26
Annex E (informative) Synchronization Time Stamp (STS) usage .27
Annex F (Informative) Example method for redundant encoder tracks generation .28
Annex G (informative) Example method for generating a recording S-MPD from an I MPD .30
Annex H (informative) Exchanging synchronization information between distribution encoders .31
Bibliography .32

© ISO/IEC 2025 – 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 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 23009 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
iv
Introduction
This document specifies a reference architecture for redundant encoding and packaging of segmented
live media.
In addition, it specifies format constraints to enable encoding and packaging of interchangeable media
segments and media presentation descriptions.
This document also specifies formats for 24x7 live recording and archiving of segmented live media.
Listed examples in this document are also available at https://standards.iso.org/iso-iec/23009/-9/ed-1/en/ .

© ISO/IEC 2025 – All rights reserved
v
International Standard ISO/IEC 23009-9:2025(en)
Information technology — Dynamic adaptive streaming over
HTTP (DASH) —
Part 9:
Redundant encoding and packaging for segmented live
media (REaP)
1 Scope
This document specifies formats for redundant encoding and packaging of live segmented media (REaP).
This document specifies:
a) formats for Interchangeable Live Media Ingest and stream announcement;
b) format and segmentation strategy to generate interchangeable segments;
c) formats for generating interchangeable media presentation descriptions or playlists;
d) formats for efficient cloud storage access and archiving of live segmented media.
e) a protocol for communicating media descriptor files and fragmented media between encoders and
packagers.
REaP enables the following:
1) failover support and rejoining of distributed components in the workflow (see Annex E);
2) workflows for live with dynamic ad insertion (DAI) with a decisioning system.
3) workflows with digital rights management (DRM) and content protection.
4) Mixing file and live inputs.
This document specifies additional constraint to formats defined in ISO/IEC 14496-12, ISO/IEC 23009-1,
ISO/IEC 23000-19 and IETF RFC 8216.
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-12, Information technology — Coding of audio-visual objects — Part 12: ISO base media file format
ISO/IEC 23009-1, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media
presentation description and segment formats
ISO/IEC 23000-19, Information technology — Multimedia application format (MPEG-A) — Part 19: Common
media application format (CMAF) for segmented media
IETF RFC 8216, HTTP Live Streaming

© ISO/IEC 2025 – All rights reserved
3 Terms, definitions and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 14496-12, ISO/IEC 23009-1,
ISO/IEC 23000-19 and the following 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
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 Terms
3.1.1
media presentation
CMAF presentation, DASH Media Presentation description, or multi variant HTTP master playlist
3.1.2
distribution encoder
entity or computational unit used to encode or transcode an input to one or more ISO BMFF tracks
3.1.3
packager
entity or computational unit used to package an input to a Media Presentation
3.1.4
ingest session
transmission of related media segments from distribution encoder to origin/packager
3.1.5
interchangeable segments
segments that represent the same time interval, content and media characteristics
3.1.6
interchangeable media presentation
media presentations that describe the same segments with the same availabilityStartTime
3.1.7
origin
entity or computational unit used to serve media content based on HTTP requests
3.1.8
redundant encoding
content representations created by different network entities that are functionally equivalent
3.1.9
redundant packaging
adding functionally equivalent metadata to redundantly encoded content
3.1.10
unix epoch
seconds elapsed since 00:00:00 UTC on January 1st 1970 excluding leap seconds
3.1.11
ceil()
nearest integer larger than or equal to the input number
3.1.12
storage track file
file that follows constraints from ISO/IEC 23000-19:2024, 7.3.3 with the exception that the earliest video
media sample may not be zero and that there may be one or more SegmentIndexBoxes following first CMAF
fragment
© ISO/IEC 2025 – All rights reserved
3.2 Abbreviated terms
AF adaptation field
API application programming interface
CMAF common media application format as defined in ISO/IEC 23000-19
DAI dynamic ad insertion
DASH MPEG-DASH as defined in ISO/IEC 23009-1
DASH-IF DASH industry forum
D-MPD delivery media presentation description
EBP encoder boundary point
E-STS encoder synchronization time stamp
fps frames per second
HLS HTTP live streaming as defined in IETF RFC 8216
ID identifier
I-MPD ingest media presentation description
ISO BMFF ISO base media file format
MPD media presentation description
PCM pulse code modulation
PID packet identifier
PTP precision time protocol
REaP redundant encoding and packaging
S-MPD storage media presentation description
STS synchronization time stamp
TEMI timeline and external media information
TS transport stream
URL uniform resource locator
UUID universally unique identifier
VANC vertical ancillary data space
VBI vertical blanking interval
PTP precision time protocol
P-STS packager synchronization time stamp

© ISO/IEC 2025 – All rights reserved
4 Overview
Clause 5 describes a reference workflow for redundant encoding and packaging of live segmented media. In
addition the objectives and assumptions are detailed.
Clause 6 specifies formats for redundant encoder synchronization.
Clause 7 specifies formats for redundant packager synchronization.
Clause 8 specifies the track format and MPD constraints for asset storage.
Annex A provides example media presentation descriptions for the ingest, storage and distribution
applications.
Annex B provides recommendations for media segment durations.
Annex C provides example applications and use cases.
Annex D provides different ways a contribution signal may carry timing information.
Annex E provides guidelines for the usage of the Synchronization Time Stamp (STS) at both the distribution
encoder and packager.
Annex F provides an example method for the generation of redundant encoder tracks.
Annex G provides an example method for generating a recording S-MPD from an I-MPD.
Annex H provides guidelines for the exchange of synchronization information between the distribution
encoders.
5 Reference workflow for redundant encoding and packaging (REaP)
5.1 Reference workflow for REaP
Figure 1 — Reference workflow for redundant encoding and packaging of live segmented media
Figure 1 illustrates a reference workflow for redundant encoding and packaging (REaP). REaP enables new
encoders and/or packagers to join the reference workflow at any time and be able to produce the same
segments and manifests as other encoders and packagers already in the workflow. The workflow in Figure 1
is an example of how the formats defined in Clauses 6 to 8 can be used. The usage of these formats is not

© ISO/IEC 2025 – All rights reserved
limited to usage as depicted in Figure 1, but Figure 1 illustrates a workflow as can be deployed in practice to
enable redundant encoding and packaging.
A contribution encoder or other source transmits a signal to 2 (or more) distribution encoders that generate
live segmented media. The 2 (or more) distribution encoders transmit live segmented media to 2 (or more)
packagers that generate media presentations and transmit those through 1 or more origins to players or
devices. In some setups the distribution encoder can combine a file input with a live input from a contribution
encoder, in this case the transcoded output is a combination of the file and live input.
In addition, in this workflow, streams can be recorded or stored in a distributed storage.
Figure 1 details the assumptions and intended usage of the defined formats in the rest of this document as
follows.
The definition of formats produced by the contribution encoder are out of scope of this document. However,
it is assumed that such formats contain a common time information signal (based on a common time anchor
such as the Unix epoch). Example formats from the contribution encoder and relevant common timing
formats are given in Annex D.
The redundant distribution encoders 1 and 2 generate multiple representations of segmented media.
Clause 6 specifies the ingest media presentation description (I-MPD) for announcing these representations.
In addition, it specifies the segment format constraints for the transmission of live segmented media in ISO
BMFF Tracks.
The packagers 1 and 2 are responsible for generating the Delivery Media Presentation Description (D-MPD)
for delivery to 1 or more clients through 1 or more origins. Constraints on the HTTP master playlist, D-MPD
based and live media segments are defined in Clause 7. In addition, packagers 1 and 2 can apply additional
transformations on the ISO BMFF tracks, such as trans-multiplexing, encryption, decryption or other
operations to prepare the content for delivery.
A license server can be present, to enable a packager to request a license and decrypt incoming tracks. An
encryption key server can be present, the packager can use such a server to request documents for obtaining
an encryption key(s) for an incoming track or presentation in case the packager applies a (re-)encryption.
A decisioning system can be present to insert timed events by a packager or encoder. The interface to the
decisioning system is out of scope for this document, but it is expected that redundant packagers/encoders
will receive functionally equivalent input from the decisioning system. The configurator is a component that
can exist to configure the distribution encoders and packagers, the interfaces to the configurator are not in
scope of the current document.
The functional block for storage is used to record and store media. Clause 8 specifies the S-MPD (Storage
MPD) to support recording and storage of redundant live segmented media.
Annex C describes some of the intended use cases of the format defined in REaP.
5.2 REaP assumptions
The implementation of the reference workflow with the formats defined in this document enables redundant
encoding and packaging. However, it is based on several assumptions that should hold in order to achieve
redundant encoding and packaging.
a) Common contribution signaling with timing information is present, e.g. see Annex D.
b) Timing information can be mapped back to a time relative to Unix Epoch.
NOTE Leap seconds occur every few years adding a second after midnight. Currently, international
discussions are ongoing to reduce the number of leap seconds occurring in practice in the coming years. However,
as this document uses timing since 1-1-1970, leap seconds that occurred in the past are explicitly excluded.
c) Cross transmission is possible between distribution encoders and packagers and origins.
d) Distributed workflows such as with multiple data centers may be used to deploy REaP.

© ISO/IEC 2025 – All rights reserved
e) Encoders share a common configuration, which includes segment duration.
f) Packagers share a common configuration which includes segment duration.
5.3 General workflow and operation
Figure 2 — Example workflow for redundant distribution encoder and packager operation
Figure 2 illustrates an example of using redundant distribution encoders that follows the general reference
workflow of Figure 1. In Figure 2, the origin and packager functional entities are combined for simplicity.
The example workflow shows the output of the (distribution) encoders: interchangeable media segments S1,
S2, etc. The segments are transmitted to packagers/origins and the output of these entities in Figure 2 is a
media presentation such as based on DASH Media Presentation Description or an HTTP master playlist.
In order to produce interchangeable data, encoders and packagers are configured with a common
configuration, as described below.
NOTE 1 Additional elements can be part of the configuration (e.g. packager URLs) and can be different. For example,
if cross-publication is not enabled, encoder 1 will be configured to transmit to packager 1 only, while encoder 2 is
configured to transmit data to packager 2 only.
The first common configuration element is the segment duration D. The segment duration should be
provided such that it corresponds to an integer number of samples. It may be given using a rational number
when fractional video frame rates are used. Annex B provides configurations for different video frame rates
and timescales that can be used to achieve constant segment durations.
The second common configuration element is an optional synchronization time stamp (STS). It is used
indicate the offset from the input timestamps to the Unix Epoch.
EXAMPLE The configuration can indicate that the source data with timestamp 90000 (in a timescale of 90000)
maps to January 1st, 2024, noon UTC. In that case, the STS would be 1704110400 (i.e. seconds elapsed since January
1st, 2024, noon UTC) minus 1 (i.e. the source timestamp expressed in seconds).

© ISO/IEC 2025 – All rights reserved
If an STS is not provided, the timing information in the source should be interpreted as being directly relative
to Unix Epoch (e.g. using timecodes, i.e. the same as the STS being 0).
When the STS is part of the encoder configuration, it is referred to as the E-STS in this document. Similarly, if
it is part of packager configuration, it is referred to as P-STS in this document.
NOTE 2 As indicated in Annex E, the values of E-STS or P-STS can be different per entity. The common configuration
refers to the fact that all entities can use that parameter, not that their value is common.”
The packager may change the incoming segments as long as the requirement that the resulting new segments
are conforming REaP segments is met. The applied protocol is assumed to comprise at least the following
steps (Clause 7 provides specific constraints on encoder to packager communication).
a) The receiver packager sets up a URL endpoint that the distribution encoder can issue requests to.
b) The encoder authenticates, connects, and sends an ingest media presentation description (I-MPD) and
initialization segments for each segmented live media representation.
c) The receiver packager reads the I-MPD. When the CMAF profile for DASH is used, or when content
is formatted according to the CMAF track format, representations map to CMAF tracks, and the
AdaptationSet elements map to CMAF switching sets.
d) The initialization segment is transmitted from the distribution encoder. Retransmission of media
segments in a track/representation may happen in case of failures. In such cases, it is recommended to
retransmit the initialization segment.
e) The distribution encoder sends each media segment using a separate request. The URL is derived
from the URL endpoint (Step a) combined with the segment name derived from the SegmentTemplate
Element.
NOTE 3 The media segment's earliest presentation time is used as a “key” of segments in a track. The track name
identified by Representation@id is used as a key for the track. Using these keys, interchangeable segments for different
tracks from different senders can be identified by the receiver.
6 Formats for Redundant distribution Encoding
6.1 Constraints on the Ingest Media Presentation Description (I-MPD)
As indicated in Clause 5, and in Figure 1, encoders produce an I-MPD. The I-MPD declares incoming content
to the packager which allows for the generation of the D-MPD. The I-MPD is also used to establish the
naming convention of the segments and grouping of tracks. I-MPD files produced by encoders compliant to
this specification shall conform to ISO/IEC 23009-1.
Additional constraints on the I-MPD are as follows:
a) The I-MPD should follow the CMAF profile and iso live profiles, the MPD@ profiles should include
urn:mpeg:dash:profile:cmaf:2019 and the ISO live profile of DASH urn:mpeg:dash:profile:isoff-live:2011.
NOTE 1 In this case, each representation in the I-MPD represents a CMAF track, each AdaptationSet in the
I-MPD represents a CMAF switching set.
b) The I-MPD shall contain a single Period element. The Period @start should be set to PT0S or a
semantically equivalent values.
c) The MPD@ a vailabilit yStartTime shall be set to Unix epoch plus E-STS.
d) The Period BaseURL element shall be absent.
e) The I-MPD shall contain a SegmentTemplate element in each AdaptationSet element but none shall be
present in Representation Elements.
f) The AdaptationSet BaseURL element shall be absent.

© ISO/IEC 2025 – All rights reserved
g) The SegmentTemplate@ initialization in the I-MPD shall contain a single substring $RepresentationID$
and the SegmentTemplate@ media shall contain a single substring $RepresentationID$ and a single
substring $Number$ or $Time$ (not both). If one or more Representation@id ends (respectively
starts) with a number, the $Number$ (or $Time$) shall not immediately follow (respectively precede)
$Representation$, a separator character (- or _) may be between $Representation$ and $Number$ (or
$Time$).
1) An example of a conforming SegmentTemplate Element is: “ initialization="sample-$RepresentationID$.dash" media="sample-$RepresentationID$-$Time$.
dash"> ”
h) SegmentTemplate@ media shall be identical for each SegmentTemplate element
i) SegmentTemplate@ initialization shall be identical for each SegmentTemplate element
j) Each SegmentTemplate element should contain a SegmentTimeline element
1) A SegmentTimeline element may be empty.
k) Distribution Encoders may send an updated I-MPD
1) In case of an updated I-MPD, identical naming conventions apply as in the previous I-MPD.
l) In the case an AdaptationSet signals encrypted tracks, and decryption is required, the ContentProtection
element shall be present with the following constraints:
1) The ContentProtection element should contain a URL of a license server.
2) The URL of the license server should start with https:// ,
NOTE 2 DRM used by packagers to decrypt a stream can be different from DRM used by players, a simple DRM
for packagers can use a document with a decryption key included.
m) The I-MPD may signal requirements for encryption of an AdaptationSet by the packager
1) In this case an EssentialProperty with the schemeIDUri: urn:mpeg:dash:encryptionkey-server shall
be present in the AdaptationSet element.
2) The EssentialProperty@ value shall be a url to request a document from an encryption key server
that describes the required encryption keys
An example of the I-MPD is given in Annex A.
NOTE 3 It is assumed that the encoder configuration for redundant encoders is such that redundant encoders
produces interchangeable MPDs (e.g. the segment duration, the E-STS, etc…).
6.2 Constraints on the redundant encoder track and segment format
Encoders conforming to this document and ISO/IEC 23009-1 (DASH) shall produce media segments as
described in ISO/IEC 23009-1.
Encoders conforming to this document and ISO/IEC 23000-19 (CMAF) shall produce media segments
in conformance with ISO/IEC 23000-19:2024, Clause 7 resulting in CMAF tracks and apply the track
synchronization model specified in ISO/IEC 23000-19, Clause 6 where the CMAF common timeline origin
shall be the Unix epoch. Therefore, media presentation times shall be defined relative to 00:00:00 on January
1st 1970 excluding leap seconds.
EXAMPLE A media sample with a corresponding presentation time of January 1, 2024 noon (possibly after
applying the E-STS) will have a presentation time in the CMAF track of 1704110400 seconds.
NOTE 1 Large values can require the use of 64-bit encoding constructs defined in ISO/IEC 14496-12 (ISOBMFF).
In order to enable a) cross-delivery of encoded data to different packagers and b) the generation of
interchangeable media by encoders and packagers, it is necessary that encoders produce segments that have

© ISO/IEC 2025 – All rights reserved
the same boundaries. Given the assumption that a) encoders share the same segment duration parameter, b)
that the source signal contains the same timing information, and c) that encoders share approximate clock
information, encoders can generate interchangeable segments.
Encoder entities conforming to this document that produce CMAF or DASH media segments shall generate
boxes of the type MovieFragmentBox (moof) and optionally of the type SegmentTypeBox with the following
constraints:
a) A media segment K shall contain all the frames F that have a start time in the presentation time interval of
segment K, which is (K-1)*D to K*D. The start time of a frame is the time signal for that frame plus the E-STS.
b) Media segments should be of a constant segment duration D, where the duration is the sum of all media
sample presentation durations. Example configurations to achieve constant segment durations are given
in Annex B. When segments cannot have a constant duration, redundant encoders shall be configured
such that they produce segments with a duration different from D at the same time.
c) When a media segment is created with a different duration A instead, the next media segment shall be of
duration 2 x D - A to keep the numbering and the number of segments since epoch.
NOTE 2 Depending on their configuration, when inserting points for splicing, some encoders produce shorter
segments or insert an IDR frame within the media segment without creating variable duration segments.
d) The SegmentTypeBox may contain a ‘slat’ brand in case the input of the encoder was missing frames and
the encoder filled the gap with filler frames. When media input to the distribution encoder is lost, the
segment generated by the distribution encoder shall carry the brand `miss` (if it contains no usable
media) or `slat` (when it is a slate segment).
NOTE 3 Frames can be missing in one encoder but not in another. In that case, the segments can be different
and not interchangeable.
e) In case the segment is the last segment, the SegmentTypeBox should contain the ‘lmsg’ brand. The
duration of the last segment may be shorter or longer than expected.
f) The sequence number in the MovieFragmentHeaderBox shall be set to K as defined in bullet a).
g) An edit list, i.e. EditListBox shall not be used in the initialization segment.
NOTE 4 Care has to be taken to preserve audio video synchronization.
h) The 'roll' sample group may be used to indicate requirements for audio playout-based pre- roll samples.
i) Samples that overlap a leap second, may be adjusted to account for the leap second (reducing the
duration of samples). Otherwise, media frames occurring during the leap second may be discarded by
the encoder and not included in track as media sample.
j) In case media segments carry TTML that conforms to ISO/IEC 14496-30 and to CMAF, TTML times shall
also be relative to Unix epoch excluding leap seconds. If the TTML samples carry timing information,
then this timing information shall also be relative to Unix epoch excluding leap seconds.
NOTE 5 This can result in a large number of hours in the encapsulated TTML document.
k) Each ISO-BMFF fragment (e.g. CMAF chunk) shall have one or more ProducerReferenceTime boxes
(`prft`) showing the time the fragment was generated. When present, the ProducerReferenceTime shall
contain the time a segment entered the encoder if the flags field was set to 0 or the time it was encoded
if the flags field was set to 1.
l) Additional encoder configuration aspects for delayed input and file inputs
m) If DASHEventMessageBoxes are produced by the encoder, they shall be repeated in segments as long as
the corresponding event overlaps the segment media presentation times.
n) If a separate segmented timed metadata track is produced by the encoder, metadata shall be repeated in
samples as long as it applies.

© ISO/IEC 2025 – All rights reserved
6.2.1 Mixed file and live inputs to the encoder
In some settings, the encoder combines live input with file based input (see Figure 1). In this case, a
configuration API may be used to determine when to switch between live and file input. The API or
configuration format of the switch is out of scope, but the switching should be based on the media timeline,
which is defined as being relative to Unix epoch.
NOTE 1 The API is assumed proprietary, and not in the scope of the REaP formats defined in this document.
Examples of file inputs include pre-roll or interstitials inserted by the encoder. To enable seamless switching,
it is recommended to set E-STS to a non-zero value at the distribution encoder. This way the file can be
played out as scheduled based one the media time, and due to the delay on the live input it will be possible to
switch back seamlessly to the live feed.
This way, two different encoders scheduled to play the same file from 3.00 to 4.00 on date XX (for example)
will generate media segments with the same segment timings (timestamps corresponding to 3.00 to 4.00 at
date XX on the media timeline in ticks since epoch (excluding leap seconds)).
The following applies when combining file and live inputs to the distribution encoder.
a) Synchronization Time Stamp STS shall be configured at the different distributed encoders to produce
output presentation times close to the wall clock time from the live input.
b) The file input may be transcoded to media presentation times based on the scheduled media start time
and media end time of playback of the asset.
c) A third party Application Programming Interface (API) or configuration may be used to define the
transition points between file and live input to the encoder based on the output media timeline. In
this case the API shall trigger identical transition points at different encoders based on a target media
presentation time using identical input files.
NOTE 2 In some implementations it can be easier to mix live and static input at the packager, such mixing/combining
can therefore also be applied at the packager instead of the distribution encoder. This is because not all encoders can
handle mixing and combining live inputs.
7 Constraints on encoder requests to packager
In the following, “encoder” refers to a distribution encoder. This document assumes the use of HTTP 1.1 or higher.
a) Encoders shall transmit segments within configurable bounds. Therefore, a segment with earliest
presentation T shall be transmitted within T + segment duration and T + segment duration + a
configurable encoder processing delay
b) The encoder should use HTTP PUT for communicating the I-MPD and HTTP POST for communicating
the media segments with the packager.
Note 1 It is assumed that the PUT and POST operations are implemented as atomic operations.
c) At the start of the ingest session the encoder shall issue an HTTP request to send the I-MPD to the
packager. If the packager is unwilling to accept the media from the encoder, the packager shall respond
with status code 403. The encoder shall not try to re-establish the connection.
d) If the response status code is 200, the encoder shall send the segments using the following order:
1) All initialization segments
i) Initialization segments may be delivered in any order.
2) All media segments available to the packager which:
i) Are described in the sent I-MPD
ii) Were generated between MPD@ publishTime and MPD@ publishTime - MPD@ timeshiftBuffer.

© ISO/IEC 2025 – All rights reserved
iii) For all segments or partial segments generated between the MPD@ PublishTime of the previous
I-MPD and of the most recent I-MPD:
3) The encoder shall first send the I-MPD;
4) If the I-MPD is successfully sent, the encoder shall send each media segment immediately after its
last sample has become available;
NOTE 2 A fragment can be a media segment, a partial media segment or CMAF chunk.
5) If the media input to the encoder (or some of its components) is lost, the encoder shall send Missing
Segments for the missing components or Slate Segments for content generated in lieu of the input.
i) Initialization segments shall be sent at session establishment or when new initialization
segments are needed. It is not recommended that multiple initialization segments are sent.
NOTE 3 Initialization segments can be needed, for example, due to a change in codec.
e) A session shall be terminated in the following cases:
1) Timeout due to configuration parameters (e.g. no response for a configured period of time from
either encoder or packager).
2) The packager closes one of the connections for any reason.
3) HTTP 4xx/5xx responses are received from the packager.
4) After the end of the presentation as described in the final send I-MPD.
5) When the packager receives a Presentation Termination event in an I-MPD or Media Segment.
f) If the session was terminated due to packager error but the encoder is still running, the encoder should
still generate and store segments while trying to establish a new session. These can be sent as described
in step 2 above when a new session is established.
g) When multiple individual ISO-BMFF fragments (e.g. CMAF chunks) are sent in the same POST request, then:
1) For HTTP/1.1, chunked transfer coding shall be used, and each HTTP chunk should contain bytes
belonging to only one ISO-BMFF fragment.
2) For HTTP/2 and HTTP/3, DATA frames shall be sent, and each DATA frame should contain bytes
belonging to only one ISO-BMFF fragment.
i) Permanent redirect shall be followed throughout the duration of a session. The packager shall
use HTTP status code 308 for this purpose.
ii) Temporary redirect shall be followed once, for the request for which it was returned. The origin
shall use HTTP status code 307 for this purpose.
NOTE 4 The above method can be used to acquire a token using mechanisms such as CTA WAVE
Common Access Token.
h) If the I-MPD is used for event carriage, then the I-MPD shall be sent immediately as the event becomes
known to the encoder. For example, if an event is encountered in the input or provided via an out-of-
band API, a new I-MPD including it will be immediately set to the origin.
1) The event transmission method shall be signaled in the I-MPD. In particular, I-MPD shall carry
EventStream elements for I-MPD events, InbandEventStream elements for carriage in ISO-BMFF
fragments, and a metadata track AdaptationSet for metadata tracks
NOTE 5 Encoders can be configured to retry any of the above listed requests.

© ISO/IEC 2025 – All rights reserved
8 Formats for redundant media presentation packaging
8.1 General requirements on redundant packager input
Additional requirements on formats used as input to redundant packagers are defined as follows:
a) As shown in Figure 1, encoders cross-transmit segments to the different available redundant packagers
in the workflow. Each encoder 1……N transmits all output media segments to all packagers 1….M.
Interchangeable segments of each Representation shall have identical earliest media presentation time,
for example K x D x track_timescale.
NOTE 1 In some practical cases, cross transmission can be costly. Optimizations in the transmission protocol
and delivery are encouraged.
NOTE 2 In some workflows, a packager can modify segment boundaries.
b) Given the encoder constraints in Clause 7, redundant packagers should receive interchangeable input
media segments within bounded time differences.
NOTE 2 In some setups a backup redundant distribution encoder is configured to transmit at a slight delay, i.e.
such as half a segment duration compared to the main distribution encoder.
c) If a packager is used to splice media fragments (beyond the reference workflow), splice information
and metadata should be available at each of the packagers prior to the splice point time. In addition,
the P- STS shall be configured at the different distributed packagers to produce continuous output
presentation times.
8.2 General requirements on the redundant packager output format(s)
The Packager is responsible for converting the I-MPD and live media segments to a valid delivery MPD
(D-MPD) or media playl
...