Media infrastructure · Content delivery
Adaptive video for inconsistent connections.
Designing the path from source video to adaptive playback across bandwidth and device constraints.
- My contribution
- Platform & media delivery architecture
- Context
- Professional work · 2025
- My responsibility
- Designed the media publishing and delivery architecture for a learning platform.
- The key decision
- Separate encoding from durable storage and deliver adaptive HLS renditions through a CDN.
- What changed
- An automated publishing path with multiple renditions, independent of application request capacity.
The problem & my responsibilities
Learning content has little value if a learner cannot start it on their existing device and connection. The publishing workflow also needs to turn source uploads into playable assets without repeated manual processing.
I designed the upload-to-publish path around FFmpeg, HLS renditions, durable object storage and CDN delivery, balancing device compatibility with publishing effort and delivery cost.
Constraints that shaped the work
- Variable mobile bandwidth
- Older devices and decoder compatibility
- Publishing speed versus encoding efficiency
- Separation of temporary processing and durable content
How the system fits together
- 01EncodeFFmpeg · H.264 · 480p / 720p
- 02PackageHLS playlists · ten-second segments
- 03DeliverS3 durable assets · CloudFront CDN
- 04PlayVideo.js · adaptive rendition selection
The consequential decisions
| Decision | Choice | Alternative | Trade-off |
|---|---|---|---|
| Delivery format | HLS | DASH | A practical fit for the target mobile playback stack. Browser and player behavior still needs device testing. |
| Codec | H.264 | VP9 or H.265 | Favor compatibility on older devices over maximum encoding efficiency. Hardware decode support is device-dependent. |
| Segment length | Ten seconds | Shorter segments | Fewer segment requests, with a trade-off in seek granularity and adaptation speed. This is a workload choice, not a universal optimum. |
| Processing | FFmpeg fast preset | Slower encoding presets | Favor publishing time over the best possible compression ratio. Storage and delivery cost remain part of the trade-off. |
| Storage | S3 with CDN delivery | Serve from application storage | Separate media delivery from application capacity. Cache behavior, access controls and delivery charges still require attention. |
Where the work got difficult
Treat publishing as a workflow
A video is ready when its renditions, segments and playlists can be consumed together. Cleanup of temporary processing files belongs after durable upload.
Design for the actual device
Codec compatibility and adaptive delivery were product-access decisions. Higher resolution is not useful when the learner cannot sustain its bitrate.
Operating considerations
Reliability
Partial uploads and missing segments are failure cases to validate. A published playlist should reference available objects; an encoding success alone is insufficient.
Security
Object-storage policy and content access must match the product's entitlement model.
Cost & performance
Encoding time, rendition storage and CDN egress trade off against one another. Test startup time and buffering across the devices and networks learners use.
Outcomes & lessons
The architecture separates transient encoding from durable media storage and adaptive playback. It provides an automated publishing path and multiple renditions without putting video delivery on the application request path.
Media architecture is an access decision: the encoding ladder and playback behavior determine who can use the learning content.