REaP is Now an ISO Standard and Netflix is Already Proving Its Power

How the new MPEG standard (ISO/IEC 23009-9) is redefining resilience for global live streaming.

Live streaming has always been a high-stakes discipline. When a signal drops, an encoder crashes, or a packager falls over mid-broadcast, there is no pause button. The industry has long relied on proprietary, fragile synchronization solutions that break the moment encoders are spread across geographies or data centers. That changes with ISO/IEC 23009-9, better known as REaP: Redundant Encoding and Packaging for segmented live media.

Ateme is proud to have been a co-chair in the creation of this standard. And we are even prouder that industry leaders like Netflix have already adopted it in their production workflows.

What is REaP?

REaP defines a reference architecture and a set of open format constraints that allow multiple encoders, distributed across different locations or data centers, to operate in perfect synchronization, producing interchangeable media segments and manifests regardless of where they physically run.

The core idea is elegant: if every encoder in the chain shares the same segment duration and anchors its timestamps to a common epoch known in advance, then any packager can identify and consume segments from any encoder at any time. The epoch itself can be the Unix epoch or a custom time code anchor, what matters is that all encoders agree on a common time anchor before the stream begins, and map their internal timestamps to it consistently. No proprietary handshake. No fragile point-to-point synchronization. Just open, deterministic alignment.

REaP specifically defines:

  • Formats for interchangeable live media ingest and stream announcement (the I-MPD)
  • Segment format constraints to guarantee boundary alignment across distributed encoders
  • Delivery manifest formats (D-MPD and HLS) for synchronized packaging
  • Storage and archiving formats for 24×7 live recording (S-MPD)
  • A protocol for encoder-to-packager communication

Why it matters for the industry

Before REaP, achieving true segment-aligned output from geographically distributed encoders required either a tightly coupled proprietary setup or a painful custom integration layer. The moment you spread your encoding infrastructure across regions for latency, resilience, or cloud cost reasons, you introduced the risk of segment boundary drift and misaligned manifests.

REaP closes that gap. A workflow built on REaP can have encoding nodes in different data centers, different cloud regions, or different continents, and they will all produce segments identified by the same timestamp key, perfectly interchangeable at the packager level. If one encoding site goes dark mid-stream, another site’s segments slot in seamlessly. The viewer never knows.

This also enables sophisticated distributed cloud architectures: encoding at the edge, packaging centrally, archiving globally, all synchronized through nothing more than a shared configuration and a pre-agreed epoch anchor.

What Ateme brings to REaP

As a co-chair of the standardization process within ISO/IEC JTC 1/SC 29, Ateme did a major contribution to shape the architecture. Our encoders are built to be fully REaP-compliant, meaning our customers can deploy geographically distributed encoding workflows today, with the confidence of an internationally ratified standard behind them.

Whether you are running a national broadcaster, a sports rights holder, or a global streaming platform, REaP gives your distributed live infrastructure the synchronization and resilience it deserves.

Conclusion

ISO/IEC 23009-9 is a milestone for the live streaming industry. It replaces fragile proprietary synchronization with an open, proven architecture, flexible enough for any epoch anchor, proven at live streaming world leader scale. Ateme helped build it, and we are ready to help you deploy it.

Get in touch with our team to learn how to migrate your live workflow to a REaP-compliant architecture.



Leave a comment

Your email address will not be published. Required fields are marked *