1. Problem Statement
Design an AWS-based live and VOD-to-live HDR streaming platform that can ingest real-time broadcast feeds as well as pre-recorded VOD assets, process them in HDR, optionally generate SDR variants, package them for OTT delivery, and distribute them globally with low latency and high availability.
The AWS reference specifically describes AWS Elemental Live for on-premises HDR workflows and AWS Elemental MediaLive for cloud-based live/VOD-to-live workflows. MediaLive can ingest HLS, MediaConnect, AWS CDI, AWS Elemental Link, and MP4 assets from S3. (Amazon Web Services, Inc.)
2. Requirements
Functional requirements
Ingest live video from cameras/broadcast infrastructure.
Support HDR10/PQ and HLG input.
Support VOD-to-live playback from S3.
Transcode live input into an ABR ladder.
Produce HDR outputs.
Optionally produce SDR outputs from HDR.
Support HLS/DASH-style OTT delivery.
Deliver globally through CDN.
Support failover for live input.
Support monitoring and operational alerts.
Optionally support Dolby Vision.
Non-functional requirements
High availability
Low streaming latency
Frame-level synchronization between output ladders
Global scalability
High video quality
Fault tolerance
Secure content delivery
Observability
Cost efficiency
3. High-Level Architecture
The core architecture is:
Live source / VOD → MediaConnect → MediaLive → MediaPackage/MediaStore → CloudFront → Player
For on-premises production:
Camera/Broadcast → AWS Elemental Live → MediaConnect/MediaStore → CloudFront → Player
For VOD-to-live:
S3 → MediaLive → MediaPackage/MediaStore → CloudFront → Player
The AWS article specifically describes MediaLive receiving live sources through HLS, MediaConnect, CDI or Elemental Link, while MP4 files in S3 can be looped or played out as part of VOD-to-live. (Amazon Web Services, Inc.)
4. Detailed Components
A. Content Sources
There are two major paths.
Live path
Camera → encoder/broadcast infrastructure → contribution feed
Possible protocols include:
SRT
RTP
HLS
SDI
SMPTE ST 2110
SMPTE 2022-6
For cloud contribution, AWS Elemental MediaConnect provides the managed contribution/transport layer.
VOD path
Pre-recorded MP4/HDR content → Amazon S3
MediaLive can use S3-based MP4 assets for VOD-to-live playout. (Amazon Web Services, Inc.)
5. Ingestion Layer
AWS Elemental MediaConnect
MediaConnect is the secure live-video transport layer.
Example:
Broadcast facility → MediaConnect → MediaLive
Responsibilities:
Receive contribution stream
Transport high-quality live video
Provide reliable delivery
Support redundant contribution paths
Connect on-premises production with AWS
Think of it as:
MediaConnect = video transport
while:
MediaLive = video processing/encoding
6. Live Processing Layer
AWS Elemental MediaLive
MediaLive is the main cloud live transcoding engine.
Input:
HDR10 / HLG / live feed
Processing:
HDR normalization → color processing → encoding → ABR outputs
Output example:
2160p HDR
1080p HDR
720p HDR
480p HDR
The important point is that MediaLive can produce HDR output and can also down-convert HDR to SDR depending on the workflow. (Amazon Web Services, Inc.)
7. HDR Processing
HDR introduces an important design challenge.
Different sources may use:
HDR10/PQ
HLG
SDR
Dolby Vision
The processing layer can normalize different HDR inputs into a common output representation.
For example:
HLG input
→ MediaLive
→ HDR10/PQ output
or:
HDR input
→ color conversion
→ SDR output
This is important because the downstream player should not unexpectedly switch between incompatible HDR/SDR representations.
The AWS reference specifically recommends planning separate HDR and SDR ABR ladders because players generally should not switch between HDR and SDR during playback. (Amazon Web Services, Inc.)
8. ABR Ladder
Instead of sending one 4K stream, create multiple representations.
Example:
| Resolution | HDR | Codec | Bitrate |
|---|---|---|---|
| 2160p | HDR | HEVC | 15–25 Mbps |
| 1080p | HDR | HEVC | 6–10 Mbps |
| 720p | HDR | HEVC | 3–6 Mbps |
| 480p | HDR | HEVC | 1–2 Mbps |
You can separately create:
SDR ABR ladder
and potentially:
AVC ABR ladder
This results in multiple synchronized output ladders.
9. Why Output Locking Matters
Suppose we have:
HDR ladder
2160p → 1080p → 720p
and
SDR ladder
1080p → 720p → 480p
All representations need to correspond to the same timeline.
Otherwise, when the player switches representations, the video can jump forward/backward.
AWS Elemental Live provides Output Locking to synchronize outputs at the frame level when multiple encoders are required. (Amazon Web Services, Inc.)
So:
Input frame F100
→ HDR encoder → HDR F100
→ SDR encoder → SDR F100
This keeps the ladders aligned.
10. VOD-to-Live Architecture
This is particularly interesting.
Suppose you have:
S3
intro.mp4
advertisement.mp4
program.mp4
outro.mp4
MediaLive can use those MP4 assets as inputs and play them as a continuous live channel. (Amazon Web Services, Inc.)
Architecture:
S3 VOD assets
↓
MediaLive
↓
HDR ABR ladder
↓
Packaging
↓
CDN
↓
Viewer
This effectively converts prerecorded content into a linear live channel.
11. Packaging Layer
The encoder produces multiple encoded streams, but OTT players need properly packaged segments/manifests.
The packaging layer produces things such as:
Master playlist
→ 2160p HDR
→ 1080p HDR
→ 720p HDR
The system can use AWS Elemental MediaPackage where appropriate for live packaging/origin functionality.
Conceptually:
MediaLive
→ encoded ABR streams
→ MediaPackage
→ HLS/DASH
→ CloudFront
12. Origin Layer
The origin stores/serves the generated streaming segments and manifests.
For the workflow described in the AWS article, AWS Elemental MediaStore is also shown as an origin/storage component in the Dolby Vision workflow. (Amazon Web Services, Inc.)
So a possible architecture is:
MediaLive → MediaStore → CloudFront
or a MediaPackage-based architecture depending on packaging/origin requirements.
13. CDN Layer
Amazon CloudFront
CloudFront provides global delivery.
Flow:
Player
→ CloudFront edge
→ origin
→ manifest/segment
→ player
Benefits:
Global edge caching
Reduced latency
Scalability
Protection of origin
HTTPS
Integration with AWS security controls
The important principle is:
Never make thousands/millions of viewers connect directly to MediaLive.
Instead:
MediaLive → Origin → CloudFront → Millions of viewers
14. Playback
The player first requests:
master.m3u8
It receives available representations.
For example:
2160p HDR HEVC
1080p HDR HEVC
720p HDR HEVC
The player then dynamically selects the appropriate representation based on:
bandwidth
buffer
device capability
resolution
codec support
One important HDR constraint is that players should not be expected to freely switch between HDR and SDR or between codecs such as HEVC and AVC. AWS therefore recommends designing separate ladders and carefully testing the target devices. (Amazon Web Services, Inc.)
15. Dolby Vision
Dolby Vision has a special requirement in the referenced architecture.
For Dolby Vision output:
AWS Elemental Live
is required because it integrates the Dolby Vision SDK.
The workflow becomes:
Source
→ Elemental Live
→ Dolby Vision processing
→ MediaStore
→ CloudFront
→ Dolby Vision-capable player
The AWS article states that Elemental Live adds the required Dolby Vision metadata when Dolby Vision Profile 5 or 8.1 is selected in the color-space conversion configuration. (Amazon Web Services, Inc.)
16. HDR Metadata
HDR10/Dolby Vision workflows require metadata such as:
MaxCLL
MaxFALL
For prerecorded content, these can be analyzed before the live event.
For example:
Recorded content
→ frame analysis
→ MaxCLL/MaxFALL
→ configure HDR workflow
For live content, AWS describes this as more of a best-effort process, potentially using rehearsal/event recordings to estimate the metadata. (Amazon Web Services, Inc.)
17. High Availability
For production live streaming, I would design:
Primary contribution
→ MediaConnect
Secondary contribution
→ MediaConnect
↓
Redundant MediaLive inputs
↓
Primary/secondary processing
↓
Redundant outputs
↓
Origin
↓
CloudFront
The objective is to eliminate single points of failure at:
contribution
encoding
packaging
origin
CDN
For a broadcast event, redundancy is particularly important because you cannot restart a live event like a normal batch job.
18. Monitoring
Use:
Amazon CloudWatch
for infrastructure and service metrics.
Monitor:
Input loss
Input bitrate
Encoding errors
Dropped frames
Output bitrate
Segment generation
Manifest availability
Channel state
MediaConnect flow health
CloudFront errors
Playback failures
For operational alerts:
CloudWatch → SNS → Operations team
You can also integrate logs/metrics into a centralized observability platform.
19. Security
Network
Use:
VPC where applicable
Private connectivity
AWS Direct Connect for broadcast facilities
VPN where appropriate
Content
Use:
HTTPS
IAM
S3 bucket policies
CloudFront origin protection
Signed URLs/cookies for premium content
Encryption
Use encryption at rest for:
S3
configuration/metadata
and TLS for transmission.
20. Data Flow
The complete flow can be explained in an interview as:
1. Camera/Broadcast feed
↓
2. MediaConnect
Securely transports the live contribution stream.
↓
3. MediaLive
Decodes/processes HDR and generates multiple encoded representations.
↓
4. HDR/SDR processing
Generate separate HDR and SDR ABR ladders if required.
↓
5. Packaging/Origin
MediaPackage/MediaStore produces or serves OTT manifests and segments.
↓
6. CloudFront
Caches and distributes segments globally.
↓
7. Player
Downloads manifest → selects ABR representation → continuously downloads segments.
21. VOD-to-Live Flow
For VOD-to-live:
S3
↓
MP4 VOD assets
↓
MediaLive
↓
Live HDR encoding
↓
ABR ladder
↓
MediaPackage/MediaStore
↓
CloudFront
↓
Viewer
This allows prerecorded content to behave like a live linear channel. (Amazon Web Services, Inc.)
22. Failure Scenarios
MediaConnect failure
Switch to redundant contribution source.
Camera failure
Switch to backup camera/source.
MediaLive failure
Use redundant live processing/channel architecture.
Packaging failure
Fail over to secondary origin/packaging path where supported.
CloudFront edge failure
CloudFront automatically routes users through healthy edge infrastructure.
Network degradation
Player automatically moves:
2160p → 1080p → 720p
through ABR.
23. Key Design Challenge: HDR + SDR + Codec
This is probably the most important architectural point from this AWS design.
You potentially have:
HDR + HEVC
HDR + AVC
SDR + HEVC
SDR + AVC
That can result in multiple ABR ladders.
You should not simply create one ladder and expect every device to switch seamlessly.
Therefore:
Source
→ HDR processing
→ HDR ladder
and
→ SDR conversion
→ SDR ladder
and potentially separate codec ladders.
AWS explicitly highlights this player-compatibility problem and recommends testing all expected HDR/SDR and codec combinations. (Amazon Web Services, Inc.)
24. Capacity & Scaling
The major scaling boundary is different for each layer.
| Layer | Scaling strategy |
|---|---|
| Contribution | Redundant feeds/flows |
| MediaLive | Channel-based capacity |
| Packaging | Managed service scaling |
| Origin | Managed/scalable origin |
| CloudFront | Massive edge scalability |
| S3 | Virtually unlimited object storage |
| Monitoring | CloudWatch managed scaling |
The biggest cost drivers will generally be:
MediaLive encoding + MediaConnect + CDN data transfer + storage, depending on traffic and channel configuration.
25. Latency
For standard OTT live streaming:
Camera → contribution → MediaLive → packaging → CDN → player
introduces latency through:
contribution buffering
encoding
segment creation
origin
CDN
player buffer
For lower latency, use shorter segments and appropriate low-latency streaming architecture, but there is a trade-off between:
latency ↔ resilience ↔ buffering ↔ CDN efficiency
26. Final Architecture
LIVE SOURCES
┌───────────────┐
│ Cameras │
│ Broadcast │
│ SRT/HLS/SDI │
└───────┬───────┘
│
▼
┌──────────────────┐
│ MediaConnect │
│ Contribution │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ MediaLive │
│ Live Encoding │
│ HDR Processing │
└────────┬─────────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌───────────┐ ┌───────────┐
│ HDR ABR │ │ SDR ABR │
│ HEVC │ │ AVC/HEVC │
└─────┬─────┘ └─────┬─────┘
│ │
└────────┬────────┘
▼
┌──────────────────┐
│ MediaPackage / │
│ MediaStore │
│ Packaging/Origin │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ CloudFront │
│ Global CDN │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Web / TV / Mobile│
│ OTT Player │
└──────────────────┘
VOD-TO-LIVE PATH
┌───────────────┐
│ S3 │
│ HDR MP4 files │
└───────┬───────┘
│
▼
MediaLive
│
▼
Same pipelineInterview summary
“I would design the solution around MediaConnect for reliable live contribution, MediaLive for HDR live/VOD-to-live encoding, separate HDR and SDR ABR ladders for device compatibility, MediaPackage or MediaStore as the packaging/origin layer, and CloudFront for global distribution. S3 stores the VOD assets used for linear playout. For Dolby Vision, I would use Elemental Live because the referenced AWS architecture requires its integrated Dolby Vision SDK. I would add redundant contribution and encoding paths, CloudWatch-based monitoring, IAM/encryption, and carefully synchronize the ABR outputs to prevent playback discontinuities.”(Amazon Web Services, Inc.)
AWS reference: Part 3 — Live and VOD-to-Live HDR workflows on AWS
