A modern catalog is not delivered to one platform. It is delivered to roughly a hundred. Each one wants its own files, its own metadata profile, its own cadence, and its own definition of "ready." The operational model the streaming era inherited from the broadcast era assumed five large counterparties. The 2026 reality is closer to a hundred small ones. This post is a synthesis of what we have published across our blog about how content actually gets to Netflix, Apple TV+, Prime Video, and the long tail of FAST and AVOD platforms behind them, and what eight years of pushing thousands of titles through those pipes has taught us.

The shape of modern delivery

When we wrote about the insatiable demand for content in 2022, the count of meaningful destinations a film distributor was expected to serve was already growing past what a manual operations team could handle. By 2026, the count is past 100. The major SVOD platforms (Netflix, Apple TV+, Amazon Prime Video, Disney+, Max, Paramount+, Peacock) sit on top. Below them, EMA-driven transactional and subscription platforms (iTunes, Google Play, Microsoft Movies and TV, Vudu, Xfinity, in-region equivalents in EMEA and LATAM). Below that, the FAST and AVOD layer (Tubi, Pluto TV, The Roku Channel, Samsung TV Plus, Freevee, LG Channels, Vizio WatchFree+, Plex, Xumo, Crackle, Sling Freestream, Local Now, plus dozens of regional FAST channels and increasingly device-OEM-specific marketplaces).

Each of those layers has its own logic. The mistake we made in our first version of the product, and that we still see distributors making in 2026, is treating delivery as one workflow. It is not. It is at least three.

Premium SVOD: Netflix, Apple TV+, Prime Video, Disney+, Max

The premium tier is high-touch by design. Each delivery is a multi-week process touching encoding, conformance, captioning, audio mastering, metadata, art, trailers, and contractual proof of rights. The platforms publish detailed delivery specifications and update them on their own schedules. Apple's iTunes Asset Specification has gone through dozens of revisions. Netflix's Originals Delivery Specification is a multi-hundred-page document. Prime Video maintains separate spec families for direct-publishing, channels, and licensing deliveries.

The three rules we have learned the hard way:

1. Read every spec twice, every time. Specs change. Codecs deprecate. Audio loudness targets shift. The first rejection on a previously-accepted spec almost always traces to a quiet update we missed.
2. Track what was pitched, where, and when. We made the case in our post on pitching the same titles to Amazon Prime that managing this manually via spreadsheets is not a process; it is a compliance risk. A single source of truth that answers "what titles in our library have not been pitched to Amazon Prime?" in 20 seconds is not a nice-to-have at this tier; it is the difference between a clean platform relationship and a contractual dispute.
3. Premium platforms reject silently. Many SVOD platforms accept a delivery and then surface failures days later via portal status pages rather than active notification. Build the polling and the alerting yourself, or you will discover a six-week-old failure on the eve of a release window.

EMA-driven distribution: iTunes, Google Play, Microsoft, and the long middle

Below the premium tier, EMA (Entertainment Merchants Association) standards do most of the heavy lifting. The EMA delivery package is the closest thing the industry has to a common denominator for transactional and subscription platforms. It bundles the manifest, the rights window, the territory list, the content references, and the metadata into a single XML structure that platforms like iTunes, Google Play, Microsoft Movies and TV, and a long list of regional aggregators consume directly.

EMA is a gift and a trap. The gift is that one well-formed package, mostly, lands at multiple destinations. The trap is that "mostly" is doing a lot of work in that sentence. Every consuming platform has its own validation layer on top of the EMA standard, its own region-specific extensions, and its own opinions about how exclusivity windows, holdback periods, and territory exclusions should be encoded. A package that validates against EMA Movies 4.6 will land cleanly at iTunes and reject at Google Play because Google's validator wants a specific encoding of the audio language tag that EMA itself treats as optional.

This is where we built our prepopulated delivery templates. The argument we made then was that "each platform has its unique specifications, often subject to change, making the preparation of content packages a labor-intensive task fraught with potential for error," and that the answer was deep data integration that auto-fills platform-specific fields rather than tedious copy-pasting. Two years later, that argument has only gotten more true. The platforms keep multiplying. The specs keep drifting. Manual per-platform delivery does not scale past about a dozen destinations before quality breaks.

FAST and AVOD: Tubi, Pluto, Roku Channel, Samsung TV+, and the rest

FAST and AVOD platforms operate on a different protocol stack and a different cadence. Where SVOD and EMA-driven distribution are oriented around discrete deliveries (you ship a package, the platform ingests it, the title appears in their catalog), FAST is closer to broadcast. The platform maintains a continuous feed; you provide a continuous source.

The two technologies that make this work, which we covered in our 2024 technical guide to MRSS and HLS for FAST, do different jobs. MRSS (Media RSS) is the packaging format. It is an XML-based feed that bundles media files with metadata, artwork, captions, and the other assets a FAST platform needs to ingest a piece of content. HLS (HTTP Live Streaming) is the delivery format that the platform itself uses to stream the content to viewers, with dynamic ad insertion and quality adjustment happening at runtime. Distributors are responsible for the MRSS side. The platform handles the HLS side.

The thing about FAST that catches operations teams off guard is the volume. A distributor who supports five SVOD platforms typically delivers a few dozen titles per month per platform. A distributor who supports thirty FAST and AVOD destinations might be maintaining two thousand titles in continuous availability across that long tail, with each title needing its own MRSS entry, captions, and ad-break markers. The work is not harder per title. There is just much more of it. The right tooling makes that count manageable. The wrong tooling makes the long tail uneconomic, which leaves the fastest-growing revenue layer of the streaming stack on the table.

Speed and scale: encode, transfer, confirm

Once the package is built, the next question is how fast it can move. We have written about this from three angles. Fast Track Your Content Delivery documented the raw speed claim. How to Deliver Packages Before Your Coffee Cools made the case at the package-assembly level. Demystifying On-Demand Transcoding explained the encoding side specifically.

The headline operational result, in the words of Sandro Gohoho at Echelon Studios, is "deliver three to five times faster using the exact same human resource capability." The numbers underneath that claim are platform-specific, but the shape repeats. Encoding moves from minutes to seconds for short-form, from hours to minutes for features, when on-demand transcoding replaces pre-baked file generation. Package assembly moves from days to minutes when prepopulated templates replace manual per-platform field entry. Transfer time moves from hours to minutes when content delivery is colocated with the rights and metadata systems that drive it, because no one is shuttling files between AWS, Aspera, and a separate metadata tool.

Security: screeners, watermarks, and DRM

Delivering to a platform is one half of the operational picture. The other half is delivering to a buyer or a festival jury or a press contact in a way that does not end up on a piracy site. We have written about this from both ends. People Are Pirating Your Screeners laid out the threat model. Burnt-In Watermarks argued for forensic, per-viewer watermarking as the standard defense.

The technical foundation we walked through in our on-demand transcoding post matters here. The classic approach to per-viewer watermarking creates a separate file for every viewer, which is both expensive in storage and slow to deliver. The on-demand approach burns the watermark in real time as the stream plays, transcoding fragments a few seconds ahead of where the viewer is watching and caching them. By the time the viewer reaches that point in the stream, retrieval is fast. There is no per-viewer file. The watermark is forensic, the storage cost stays flat, and the delivery experience matches a normal stream.

For platform delivery (as opposed to screener delivery), the DRM stack is standardized: Widevine for Chromium, Fairplay for Apple, Playready for Microsoft and Edge. DASH and HLS as the streaming manifest formats. Distributors do not pick which DRM the consuming platform uses. They pick whether their delivery pipeline can produce content that integrates with all three, plus pre-encrypted streaming variants, without bespoke per-platform handling.

What it looks like at scale

The case studies we have published track the same arc through different operators. Echelon Studios increased delivery capacity 10x with the same team during the pandemic. A major media company migrated one million files in a week, an operation that traditionally would have run for months. Giant Pictures cut up to 16 hours of weekly work and tripled its catalog. Terror Films restructured its storage and delivery around an integrated stack rather than a chain of point tools.

The pattern those operators have in common is not a specific tool or workflow. It is a decision they made about where the source of truth for delivery state lives. In every one of those operations, the delivery system, the rights system, and the royalty system are reading from one set of records, not three. That is the choice that allows a single operator to package 300 films in an hour. Not faster encoding, not faster transfer, not a smarter file storage layer. A unified data model where the answer to "what does Tubi need next month" is one query away from the answer to "is that title cleared for the United States and Canada in November."

What we would do differently if we were starting today

We launched Content Delivery as a Service in 2020 with a simple bet: that the operational moat in distribution was not the storage layer or the transfer protocol, but the integration between rights, metadata, content, and delivery. The 2026 platform list validates the bet and then some. The platform count grew faster than we expected. The specs got more complex faster than we expected. The premium SVOD tier turned partly into AVOD faster than we expected. The FAST tier became a primary revenue source faster than we expected.

If we were starting today, three things would change. We would build for one hundred destinations from day one rather than five. We would treat the EMA standard as a starting point with platform-specific overlays, not as a finishing line. We would assume that the operations team would be measured on throughput per person, not on quality of any single delivery, because the long tail of FAST and AVOD only economically works at high throughput.

The thread connecting all of these decisions is the same one we have been writing about since 2020: if your delivery system, your rights system, and your royalty system are three different tools talking to each other, the long tail will eat you. If they are one tool, the long tail is your growth engine. The 2024 to 2025 streaming revenue data, which we wrote about in our streaming revenue post last week, is just the financial confirmation of the operational point.