How AB Films TV added peer-assisted delivery without touching CloudFront
One service worker added to a DRM-protected catalogue on CloudFront. Nothing upstream changed. Both issues that surfaced were on the application side.
At a glance
- Platform: AB Films TV, a Canadian streaming service for independent film and series
- Existing stack: AWS Elemental MediaConvert, castLabs DRMtoday, Amazon S3, Amazon CloudFront, Shaka Player, Supabase
- What was added: The Sudden client script and one service worker, on the site’s own origin
- What changed upstream: Nothing. No CDN migration, no new origin, no packaging change, no change to the DRM licence path
- Surface in scope: Eligible HLS video-on-demand media segments in the browser. DASH remains an existing AB Films playback path and is outside Sudden’s scope here
- Implementation time: About one afternoon, on a site with no pre-existing service worker
- Issues found: Two, both on the application’s side of the boundary: an authorization policy blocking a DRM asset lookup, and a pre-existing DASH/Chrome/DRM configuration
- Not covered here: Savings. No offload or cost figure is claimed in Part 1 — see what Parts 2 and 3 cover
TL;DR: One service worker added. Nothing upstream moved. Two issues came up, and both were on the application’s side of the boundary.
Peer-assisted delivery means that when several people are watching the same thing at the same time, a media segment already held by one viewer’s browser can be passed directly to the next viewer instead of being fetched again from the CDN. The CDN remains the fallback whenever no peer is available, so the worst case is the delivery path that already exists.
AB Films TV, in its efforts to optimize costs, added Sudden, a service-worker-based peer-assisted delivery layer, while keeping its existing AWS and DRM architecture in place. CloudFront, S3, MediaConvert, DRMtoday and the licence path all remained as they were.
Two issues surfaced during testing. One was an application authorization path that prevented a required DRM asset lookup. The other was an existing DASH/Chrome/DRM playback configuration that AB Films bypassed by preferring HLS where available. Neither required a change to CloudFront or the DRM provider.
The integration worked. That is not a savings claim. Savings depend on audience concentration: viewers overlapping on the same content and the same media segments, with enough eligible peers available. That measurement is the subject of Part 2 of this case study series.
Before Sudden: the stack AB Films had already built
AB Films TV (opens in a new tab) is a Canadian-built streaming platform, founded by Bryce McLaughlin, dedicated to showcasing, promoting and highlighting independent movies and series.
The streaming service began with an application stack built around React/Vite and Supabase. The front end was generated with Lovable from a design plan developed with ChatGPT and Claude. Supabase handled authentication, Postgres, row-level security, storage and edge functions. Video files initially lived in S3.
Six months of work produced a working service. What it did not yet have was a dedicated video delivery and content-protection pipeline.
Then a licensing requirement forced the issue. AB Films’ distribution agreement requires industry-standard security measures to prevent unauthorized copying of licensed titles, a condition that a plain S3 bucket does not satisfy.
That took AB Films to AWS and nClouds (opens in a new tab), an AWS Premier Tier partner introduced through AWS. Over a series of weekly meetings, nClouds designed and implemented the video pipeline that would sit between AB Films’ application and its viewers.
Filmhub (opens in a new tab) sends source assets and metadata into S3. A Lambda function reads the metadata CSV and starts MediaConvert (opens in a new tab) jobs from predefined templates. During packaging, MediaConvert calls the castLabs DRMtoday (opens in a new tab) SPEKE (opens in a new tab) endpoint to obtain encryption keys and produces encrypted HLS and DASH outputs.
Those outputs go back to S3 and are served through CloudFront.
On the application side, Supabase remains the system of record for the catalogue, users, rentals, subscriptions and watch progress. Edge functions handle payment verification, upload signing, Digital Rights Management (DRM) licence proxying and administration. Shaka Player (opens in a new tab) handles browser playback.
The application layer is specific to AB Films. The delivery architecture beneath it is conventional: application → player → DRM → CDN → object storage. That is what makes the integration transferable. Sudden is introduced at the delivery boundary, not by replacing the existing video stack.
The delivery-cost question
Asked whether the team had modeled delivery cost, Nathan Bolanta, AB Films’ Chief Technology Officer, gave the honest answer:
“Honestly, no. We hadn’t really thought much about delivery cost. We just built it.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
So we went through the AWS cost structure with the team, using AWS’s published pricing. The point was not to produce an invoice or a savings projection. It was to separate three cost behaviors that are easy to conflate.
Packaging and transcoding is primarily a function of the content processed. A title is encoded for its distribution ladder, then stored. Actual MediaConvert charges (opens in a new tab) depend on output duration, codec, resolution, features and the configured ladder.
Storage is primarily a function of the catalogue retained over time. It grows with stored output footprint and storage class, not with each viewing session.
Delivery is driven by the amount of data viewers consume. Unlike packaging, the same content is delivered again to every viewer who watches it. CloudFront data-transfer charges are therefore the infrastructure cost most directly tied to audience consumption.
Under the simplified planning assumption in AB Films’ own document (10 Mbps for a 90-minute feature) a completed viewing represents approximately 6.75 GB of delivered media:
10 megabits/second × 5,400 seconds = 54,000 megabits 54,000 megabits ÷ 8 ≈ 6,750 megabytes ≈ 6.75 GB
At CloudFront’s published $0.085/GB list rate (opens in a new tab), that is approximately $0.57 in CloudFront data-transfer charges per completed 90-minute viewing.
At 6.75 GB per full viewing, 1 TB of CloudFront data transfer represents roughly 150 full-length views in the same simplified model. And 100,000 completed 90-minute views would represent roughly $57,000; 200,000 would represent roughly $114,000.*
Packaging and storage are functions of how much content you have. Delivery is a function of how many people watch it, and it is paid again for every viewer.
Every other cost in this stack is a function of the catalogue. Delivery is a function of success.
*About these figures: they are a method for reading your own bill, not AB Films’ bill, a quote or a forecast. They describe CloudFront data transfer only, not total streaming-delivery cost, and they simplify or exclude adaptive bitrate selection, completion and abandonment rates, device mix, geography, CloudFront pricing tiers, negotiated pricing, request charges and other delivery-related line items.
That conversation is where Sudden entered the picture.
What changed, and what did not
Sudden was added alongside the existing delivery path. It did not replace the packager, DRM provider, object store, CDN or player.
Component-by-component comparison of the AB Films delivery stack before and after the Sudden integration.
| Component | Before Sudden | With Sudden |
|---|---|---|
| Packaging | AWS Elemental MediaConvert | Unchanged |
| DRM | castLabs DRMtoday | Unchanged |
| Origin | Amazon S3 | Unchanged |
| CDN | Amazon CloudFront | Unchanged |
| Browser player | Shaka Player | Unchanged |
| Available output formats | HLS + DASH | Unchanged |
| Peer-assisted path | None | Eligible HLS VOD media segments via Sudden |
| Service worker | None | Sudden service worker |
| Application code | Existing player integration | Sudden initialization |
| DRM licence path | Existing licence service | Unchanged |
| CDN configuration | Existing configuration | Unchanged |
Note the distinction between the formats AB Films produces and the path Sudden uses. Both HLS and DASH exist in the stack; Sudden operates on the HLS VOD segment path.
One afternoon
Nathan handled the implementation directly. His estimate:
“The whole thing took maybe one afternoon. There were a few hiccups, but the main thrust of it took an afternoon.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
He took the most direct route available:
“I installed the Sudden skill in Lovable and had Lovable take care of most of it. I took a look at the code, but everything was pretty much as it should be: installed the package, loaded the Sudden infrastructure, added Sudden playback to the website.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
In AB Films’ React application, working from the Sudden skill (opens in a new tab), the integration added the service-worker loader (opens in a new tab) on the site’s origin and initialized Sudden with the client ID (opens in a new tab).
There was no CDN migration. No new origin. No packaging change.
One caveat matters. The AB Films site had no existing service workers. That is the cleanest integration case. A site already using a service worker, for offline support, push notifications or a PWA shell, needs Sudden’s loader composed into that existing worker (opens in a new tab). That is a different implementation conversation.
And the CDN stayed untouched. “Once nClouds set it up, we haven’t touched it since,” Nathan said.
The architecture itself was unchanged. The interesting part started when the team tested it.
What surfaced in testing
Two issues appeared during testing. Both helped clarify the boundary between the application, player, DRM system and delivery layer.
1. Authorization blocked a DRM asset lookup
Symptom: Playback failed for the affected premium test accounts.
Investigation: The application query that maps a title to its opaque DRM asset ID returned zero rows. No DRM token was fetched, and the player never received a valid source. From the outside, it initially looked as though Sudden was not loading. From Sudden’s side, no requests were reaching the integration.
Root cause: An existing Supabase row-level-security policy (opens in a new tab) prevented that account and access path from reading the data it required.
Resolution: AB Films adjusted the relevant access path. The issue was resolved.
2. DASH-first playback exposed a Chrome/DRM configuration issue
Symptom: Protected-title playback stalled on Chrome when the watch page selected DASH. Safari followed an HLS path and worked.
Investigation: The issue appeared in the Shaka/DASH path, where a DRM key-system error stalled playback. It was not in the HLS segment-delivery path used by Sudden.
Root cause: AB Films’ existing DASH-first playback configuration on non-Safari browsers encountered a Chrome/DRM issue.
Resolution: AB Films changed its browser preference so HLS is used when an HLS manifest is available:
“For DRM titles that have an HLS manifest, we now prefer .m3u8 across all browsers. It sidesteps the Shaka/DASH Chrome issue while we investigate that separately.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
This bypassed the issue; it did not necessarily resolve the underlying DASH/Chrome/DRM configuration.
For another engineering team, the lesson is simple: test the application’s existing browser, manifest and DRM combinations before treating a playback failure as evidence about a newly introduced delivery component.
The DRM question: separate paths, explicit boundaries
Nathan’s main technical concern before integration was DRM.
That is usually where these conversations stop. Not on whether peer-assisted delivery works, but on whether it changes the content-protection model, and it is typically the first question a security review asks and the last thing that gets signed off.
The question was straightforward: if a browser can obtain an encrypted media segment from another viewer, does that change the existing content-protection model?
Nathan reviewed the documentation and investigated the architecture himself: “I looked at the documentation, did some research, and found that it wouldn’t.”
MediaConvert encrypts the segments during packaging, before they reach S3. CloudFront serves those encrypted segments. Sudden’s service worker can intercept an eligible HLS segment request and fulfill it from CloudFront or another participating browser.
The DRM licence follows a separate path:
Player → DRM licence service
This remains distinct from:
Player → service worker → CloudFront or eligible peer
Sudden does not participate in DRM licence acquisition or key exchange. The existing player and DRM stack remain responsible for authorization and decryption.
Annotations as drawn:
- Sudden does not participate in DRM licence acquisition or key exchange.
- The existing player and DRM stack remain responsible for authorization and decryption.
- Sudden path in this integration: eligible HLS VOD media segments. DASH is an existing AB Films playback path and is outside Sudden’s scope in this case study.
AB Films subsequently verified a protected title end to end in Chrome: the manifest loaded, DRM initialized and playback completed successfully. For AB Films, this meant peer-assisted delivery could be introduced without replacing castLabs DRMtoday, changing the packaging workflow or moving the licence exchange into Sudden.
Verification: working is not the same as saving
Testing was kept purposely simple: Nathan and Bryce played the same title in several browsers at once and watched the media segments pass through the service worker. That established that the integration was working, and it answered the first question.
Can the existing player retrieve protected HLS media through the new delivery path? Yes.
It did not answer the economic question.
Installing Sudden does not, by itself, save a byte.
The mechanism depends on concentrated audience demand. A participating viewer can provide a media segment to another eligible viewer only when demand overlaps sufficiently: the same content, overlapping playback windows, peer availability and compatible network conditions all matter.
That is why concurrency alone is not the whole story. The practical variable is audience concentration. If 500 people watch 500 different titles at different times, there may be little opportunity for peer-assisted delivery. If 500 people are watching the same few titles in overlapping windows, the opportunity changes.
The next question is not whether the integration works. It is:
What happens to CDN-delivered volume when real viewing becomes concentrated enough for peers to overlap on the same media segments?
What Nathan would tell another CTO
What surprised Nathan most was the speed of the initial setup:
“What surprised me was how easy it was to get it initially set up. Shockingly fast. The bad was from our end.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
His advice to another developer in the same position:
“Read through the documentation, install the Sudden skill on whatever platform you’re using, and it should be easy enough to implement. It’s a very straightforward process.”
— Nathan Bolanta, Chief Technology Officer, AB Films TV
The one documentation improvement he wanted was an explicit explanation of how the implementation interacts with DRM. That has since been added to Sudden’s technical documentation under the Security section (opens in a new tab).
What comes next
Part 1 answers the integration question: can a production streaming stack add a peer-assisted HLS delivery path without changing its CloudFront, S3, MediaConvert or DRMtoday foundations?
Part 2 will examine delivery behavior under real traffic:
- Where and when audience demand concentrates
- Peer participation and eligibility
- The conditions under which concentrated viewing creates meaningful opportunity
Part 3 will establish the measurement standard before any savings claim is published:
- The baseline: AB Films’ own AWS usage and billing data
- Which costs are in scope
- How customer and vendor agree on what constitutes a saving
So the question for another streaming platform is not “How many viewers do you have?” It is not even how large the catalogue is.
It is rather:
How many people watch your most popular title at the same time on a normal day?
That number is where peer-assisted delivery starts to become interesting.
Products and infrastructure
- Sudden (opens in a new tab): peer-assisted delivery via client-side script and service worker
- Amazon CloudFront (opens in a new tab): CDN
- Amazon S3 (opens in a new tab): origin storage
- AWS Elemental MediaConvert (opens in a new tab): video packaging and transcoding
- AWS Lambda (opens in a new tab): ingestion and workflow automation
- castLabs DRMtoday (opens in a new tab): DRM
- Supabase (opens in a new tab): application backend, authentication and database
- Shaka Player (opens in a new tab): browser playback
- Lovable (opens in a new tab): development environment used for the integration workflow
Want to run the numbers on your own traffic?
Talk to our founders about your audience, delivery stack, and where peer-assisted delivery could help.
