AWS for M&E Blog
How 5 migrated to AWS Elemental MediaPackage v2
5, part of Paramount, operates one of the UK’s largest free-to-air broadcasting networks, delivering simulcast and free ad-supported television (FAST) channels across a range of platforms including LG, iOS, web&desktop, Android TV, Fire TV, Freely, and Freeview Play.
In early 2025, 5 considered a migration from their existing packaging solution that included a third-party pre-segmented packager with AWS Elemental MediaStore as an origin for DVB-DASH delivery and a just-in-time packager: AWS Elemental MediaPackage v1 for MPEG-DASH and HLS delivery. This post tells the story of that migration—what drove the decision, how 5 and Amazon Web Services (AWS) collaborated to deliver new capabilities, and the results that followed.
Why migrate?
To support multi-platform delivery, the existing 5 architecture included two parallel pipelines: one based on a third-party packager that produced DVB-DASH compliant output for the Freely platform and another based on AWS Elemental MediaPackage v1 that served MPEG-DASH and HLS based platforms.
This required duplicated encoding resources, managing a fleet of Amazon Elastic Compute Cloud (Amazon EC2) instances with manual failover mechanisms—all adding operational overhead, increasing infrastructure costs, and introducing reduced resilience.
Additionally, the end of life of AWS Elemental MediaStore in November 2025 provided a firm deadline, adding urgency to a migration that was already strategically desirable.
MediaPackage v2 offered native DVB-DASH support with full accessibility signaling, enhanced HLS accessibility tagging, flexible SCTE-35 marker handling, and SPEKEv2-based digital rights management (DRM) encryption—all within a single AWS service. Critically, it also delivered capabilities their existing dual-pipeline architecture lacked, specifically, unified automated failover, stack consolidation eliminating duplicated infrastructure, and a single just-in-time packaging pipeline serving all output formats without parallel workflows. Together, these capabilities made MediaPackage v2 not only a viable migration target but the essential foundation for 5’s multi-platform delivery strategy.
5’s Senior Director of 5 Streaming Technology, Matt Le Masurier, summarized the impact of consolidating onto MediaPackage v2:
“We were running eight EC2 instances and five additional MediaLive channels to handle our DVB-DASH output, alongside ISO-DASH and HLS via MediaPackage v1. Migrating to MediaPackage v2 allowed us to consolidate the stack, removing the need for the duplication. Five MediaLive, eight EC2 instances, and MediaStore were all deprecated upon completion of this project. Operationally, this has also simplified our live media pipelines as well as improving resilience. The former DVB-DASH solution had a manual failover step, not seamless failover that we benefit from in MediaPackage now.”
Resulting architecture
The following diagram illustrates the end-to-end streaming workflow deployed on AWS, from live source ingest through to viewer delivery.
Live channels are played out from the 5 facility and transported using SRT (with embedded SCTE-35 ad markers) into the AWS Cloud. Within AWS, AWS Elemental MediaLive encodes the content, and AWS Elemental MediaPackage v2 packages it into DVB-DASH, MPEG-DASH, and HLS formats, applying DRM encryption through the SPEKE v2 protocol. Then signals are going to Google’s server-side ad insertion (SSAI) service through Amazon CloudFront, which is used as an origin shield. SSAI uses enhanced metadata from a placement opportunity information system (POIS) to get content-aware decisions for stitched ads into each viewer’s stream. The personalized adaptive bitrate (ABR) content is then delivered to end-viewer devices over the internet through a content delivery network (CDN).
Figure 1: 5 end-to-end streaming workflow
The migration journey: Q1 2025 – Q1 2026
The overall migration journey from consideration to execution took around 12 months with different stages.
Early engagement and testing (January–April 2025)
In Q1 2025, AWS reached out to 5 with a preview of new DVB-DASH functionality on MediaPackage v2. 5 expressed strong interest and by April had freed up engineering capacity for Q2 evaluation. 5 agreed to test beta code rather than wait for general availability, a decision that gave the team additional time to shape the feature set and identify production requirements.
AWS provided Amazon CloudFront playback endpoints for DVB-DASH testing. Initial testing quickly confirmed successful playback, and the collaborative development cycle began.
Collaborative development and feature delivery (May–September 2025)
As 5 progressed through testing, the close partnership between 5 engineers and AWS specialists across the AWS Elemental MediaLive and AWS Elemental MediaPackage service teams proved instrumental. 5’s real-world production requirements drove several important enhancements to both services:
- DVB-DASH accessibility signaling – 5’s requirement for DVB-DASH accessibility signaling, including audio description tracks with the correct DASH roles and accessibility values, led to the development of the built-in CMAF ingest path from MediaLive to MediaPackage over introducing MediaPackage v2 support on the MediaPackage output group in MediaLive. AWS prioritized updates to keep accessibility metadata flowing correctly from MediaLive to MediaPackage v2 through the MediaPackage output group type on MediaLive.
- HLS manifest attribute enhancements – 5 identified that key HLS manifest attributes—NAME, DEFAULT, AUTOSELECT, rendition group ID, and stream ordering—needed to be carried through the CMAF ingest path. Because CMAF ingest format has limited capability to transport free-form metadata, AWS developed custom extensions to the MediaPackage output group on MediaLive to address this problem, delivering the enhancement in September 2025, a capability that benefits all MediaPackage v2 customers.
- DASH role specification alignment – 5’s conformance testing identified that the DVB-DASH specification requires at least one audio Adaptation Set (or more for the audio ABR use case) to carry a @value of main when multiple audio Adaptation Sets are present. Working together on the final design, AWS and 5 confirmed MediaLive was updated to align with the specification, and AWS deployed the fix across AWS Regions.
- SCTE marker flexibility – The ability of MediaPackage v2 to toggle between binary and XML-encoded SCTE markers for DASH output addressed a long-standing requirement for 5’s dynamic ad insertion (DAI) service, providing the format flexibility their downstream systems needed.
- SPEKEv2 DRM integration – 5 successfully integrated their keystores with MediaPackage v2, using Secure Packager and Encoder Key Exchange (SPEKE) v2 for content encryption. AWS provided real-world Content Protection Information Exchange (CPIX) sample files with Widevine and PlayReady system IDs, so 5 could complete their DRM integration and proceed to comprehensive testing.
- POIS integration for ad signaling – 5 implemented a POIS integration with MediaLive, enabling use cases such as episode ID insertion, ad break marker removal, and early ad break notifications for Google DAI. The POIS integration has been running successfully in production as part of overall migration, demonstrating the flexibility of AWS media services.
- Scalable multi-environment deployment – 5 scaled their deployment across development, staging, and production environments, each requiring dedicated endpoints with different encryption keys and DASH profiles. Meanwhile, AWS worked with the team to put the necessary MediaPackage v2 endpoint capacity in place, unblocking the full rollout in October 2025.
Testing and platform deployment (October–December 2025)
With the key enhancements deployed by late September 2025, 5 kicked off comprehensive quality assurance (QA) testing in October. AWS extended the MediaStore end-of-life deadline by 4 months through February 2026, providing 5 the latitude needed for thorough end-device validation. The team ran a full set of test cases across different player platforms, including iOS, web&desktop, LG, Freely, Fire TV, Android, and Freeview Play. By the end of December, 5 successfully completed testing across all target platforms and passed internal QA validation.
Going live (January–February 2026)
In January 2026, 5 reported progress toward full migration:
- Four new FAST channels launched on Fire TV using MediaPackage v2
- Five simulcast channels deployed on Freely and Freeview Play using MediaPackage v2
- All remaining streams targeted for migration to MediaPackage v2 by end of January
By February 2026, 5 confirmed two major milestones:
- Complete decommissioning of the previous third-party packager
- Full cessation of MediaStore usage
Key takeaways
5 gained several valuable takeaways from the project:
- Start early, even with beta features – 5 agreed to test beta DVB-DASH code rather than wait for general availability (GA). This decision gave the team additional time to identify requirements and shape the feature set collaboratively with AWS.
- Real-world testing drives better products – 5’s production requirements directly influenced enhancements to both MediaLive and MediaPackage v2, including HLS manifest attribute support, DASH role alignment, and accessibility signaling improvements. These enhancements benefit the entire AWS customer base.
- Accessibility is a platform enabler – Proper accessibility signaling like audio descriptions, captions, and role metadata isn’t only about compliance. It’s what unlocks access to platforms such as Freely, and it delivers a more inclusive experience for all viewers.
- Collaborate closely with AWS service teams – Close collaboration between 5 engineers and AWS solutions architects and product managers was essential. The partnership model, where customer feedback directly shapes service development, accelerated delivery for both parties.
- Use service transitions as a modernization catalyst – The MediaStore end of life provided a clear timeline, but 5 used it as an opportunity to modernize their entire streaming workflow, moving off MediaStore as well as their legacy third-party packager entirely, while expanding to new platforms.
Conclusion
5’s migration to AWS Elemental MediaPackage v2 demonstrates what’s possible when a broadcaster takes a strategic, collaborative approach to infrastructure modernization. A comprehensive workflow upgrade has resulted in consolidating all packaging onto a single, future-proof AWS platform.
For broadcasters considering a similar journey, 5’s experience shows that early engagement, a willingness to test emerging capabilities, and close collaboration with AWS can turn an infrastructure transition into a competitive advantage—reaching new platforms and audiences and delivering more inclusive streaming experiences.
To learn more about AWS media services, visit the AWS Media Services page.
Ready to migrate to MediaPackage v2?
5’s journey demonstrates how AWS Elemental MediaPackage v2 delivers on the promise of unified, resilient live packaging at scale. For all existing MediaPackage v1 customers, v2 is the recommended path forward—bringing just-in-time packaging across HLS, MPEG-DASH, DVB-DASH, and CMAF into a single managed service with automated failover, SPEKE v2 DRM, enhanced accessibility signaling, and flexible SCTE-35 handling as standard.
Whether you’re consolidating parallel pipelines, preparing for new platform requirements, or looking to reduce operational complexity, the MediaPackage v2 migration path is well-proven. To start planning your migration, reach out to your AWS account team or visit the AWS Elemental MediaPackage page.