Design rationale
The reference platform is split into four responsibilities: control-plane ingest, media processing, protected delivery, and observability. A FastAPI service accepts a known local source filename and creates a bounded asynchronous job. FFprobe first verifies that the object contains video and captures the source properties required to construct the GOP. FFmpeg then produces a four-level H.264 ladder and packages HLS and MPEG-DASH outputs. The API does not expose the output directory directly; every manifest and segment request is authorized against a short-lived HMAC token scoped to one job.
The 1080p/720p/540p/360p ladder targets broad compatibility and a useful bandwidth range without overproducing nearly indistinguishable renditions for a 20-second demonstration. The target rates are 6.0, 3.5, 2.2, and 0.9 Mbps. Max-rate and VBV buffer settings constrain instantaneous output while still allowing variable-bitrate efficiency. The source is expected to be 50 fps. With two-second segments, the encoder uses a 100-frame GOP, disables scene-cut keyframes, and forces keyframes on the segment cadence. That alignment is essential: a player can switch safely only when equivalent random-access points exist across representations.
Two-second segments balance startup, adaptation speed, request volume, and packaging overhead. They are not intended to claim ultra-low latency. A true live implementation would replace completed-file VOD packaging with a continuously running encoder, CMAF chunks, partial HLS segments or low-latency DASH, producer reference time, and a live origin capable of blocking reload or chunked transfer. It would also need redundant ingest paths, timestamp continuity, discontinuity signaling, and live-edge monitoring.
The demonstration deliberately runs HLS and DASH as separate FFmpeg stages. This makes the commands easy to inspect and isolates muxer failures, but it repeats video encoding. Production should encode one aligned CMAF ladder and generate both manifests from the same fragments, or use a managed packaging layer. That reduces compute cost and removes any risk that nominally equivalent HLS and DASH encodes differ.
Observability and quality controls
FFmpeg is launched with its machine-readable progress protocol. The application converts progress, processing speed, and frame rate into structured JSON events and Prometheus gauges. Job counts, active jobs, end-to-end duration, output bytes, HTTP latency, status codes, and authorization failures are also exposed. Every log includes an event name and, where applicable, a job_id, which allows deterministic correlation in CloudWatch, OpenSearch, Loki, Splunk, or another log platform.
The player exposes a small QoE console: current rendition, bitrate, buffer depth, estimated bandwidth, and dropped frames. HLS.js and dash.js quality-change events are written as ABR_SWITCH records. A stress button applies changing rendition caps so a reviewer can record visible switching without relying on unpredictable local network conditions. The terminal playback probe supplies an equivalent machine-readable demonstration by selecting representations against synthetic throughput estimates and measuring protected segment downloads.
For production operations, the platform should add startup time, time to first frame, rebuffer ratio, rebuffer duration, average selected bitrate, switch frequency, playback-fatal-error rate, live-edge distance, CDN cache-hit ratio, origin fetch latency, queue age, transcode real-time factor, and segment publication lag. Alerting should focus on user impact and pipeline deadlines, not only infrastructure utilization.
Expected bottlenecks and mitigations
Encoding CPU/GPU capacity is the dominant processing bottleneck. Four 50 fps H.264 outputs can saturate general-purpose CPUs, and the reference implementation repeats that work for two protocols. Mitigations are worker isolation, queue-based admission, hardware encoders, encode-once CMAF, preset tuning, per-title/per-shot ladders, and autoscaling from queue age. Severe-weather capacity should be reserved or pre-scaled because reactive scaling can be slower than the event.
Shared local disk can become an I/O and reliability bottleneck. Containers should write to fast ephemeral storage, upload completed immutable objects to S3, and persist job state externally. Multipart uploads and bounded local staging prevent large jobs from exhausting the node. A manifest should be published only after all referenced initialization and media segments are durable.
Origin request amplification occurs when millions of viewers request the same new segment at once. CloudFront should cache immutable segments for a long time, use short TTLs only for manifests, and apply Origin Shield/request collapsing where suitable. Scheduled events can pre-warm initial manifests and segments. Signed cookies are preferable to per-object application authorization because edge cache hits then bypass the API tier.
Control-plane overload is prevented locally by bounded FFmpeg concurrency. At scale, the API should enqueue idempotent jobs to SQS, use a deduplication key for repeated ingest notifications, place poison jobs in a DLQ, and expose queue age. Workers must be safe to retry: output should be written under a versioned job prefix and atomically promoted by publishing the final manifest.
Ingest interruption is not fully represented by a short file. A live design should use dual contribution feeds, forward error correction or reliable transport, regional ingest diversity, source health scoring, and automatic failover. The packager should preserve the last-known-good playlist and signal discontinuities rather than returning malformed manifests.
Scalability and cost estimation
Delivery cost is driven primarily by viewer-minutes and average delivered bitrate. For an illustrative one million viewers watching the 20-second clip at an average 3.5 Mbps:
1,000,000 × 3.5 Mb/s × 20 s ÷ 8 = 8.75 TB of media payload, before protocol overhead.
The CDN egress estimate is therefore:
8,750 GB × the applicable regional blended CDN price per GB.
Request cost is comparatively small for this short asset. At two-second segmentation, a viewer fetches roughly ten media segments plus manifests and initialization objects, so one million viewers generate on the order of 11–13 million requests. Exact pricing varies by geography, contract, traffic tier, and service configuration and should be recalculated from the current AWS pricing pages before a commercial commitment.
Transcoding cost for a 20-second clip is negligible relative to global egress, but live 24×7 channels reverse that relationship. A useful planning metric is the encoder real-time factor. If one worker processes the complete ladder at 1.5× real time, it consumes about 13.3 worker-seconds for each 20 seconds of source per packaging pass. The current two-pass design approximately doubles that. Benchmark the selected instance, codec preset, quality target, and hardware encoder with real content; do not extrapolate from a synthetic pattern.
Storage is modest for the demonstration. The sum of target video rates is 12.6 Mbps. With duplicated audio in HLS and one audio representation in DASH, two protocol outputs for 20 seconds remain on the order of tens of megabytes. For long retention, lifecycle rules should move old assets to lower-cost tiers or expire them. The included CloudFormation template defaults to a configurable retention period.
Behavior under a sudden global load
A production event begins before the audience arrives. Encoder capacity is pre-scaled, the contribution path is validated, and initial assets are generated and warmed. Viewers authenticate once, receive a short-lived CloudFront signed cookie, and request the manifest from the nearest edge. The edge caches manifests briefly and media segments for much longer. The first miss for a newly published segment reaches the origin path; subsequent viewers are served from the edge rather than S3 or the application.
The player begins at a conservative representation based on its initial estimate, then moves upward as throughput and buffer confidence improve. Under congestion, it moves downward before the buffer is exhausted. Because all representations share aligned two-second random-access points, switching does not require a seek or decoder reset. The player telemetry reports excessive oscillation, rebuffering, dropped frames, and fatal errors so operations can distinguish network pressure from packaging or decode failures.
If a worker pool is saturated, SQS absorbs the burst and queue age becomes the primary scaling signal. Admission policies prioritize live and emergency content over noncritical VOD. If one worker fails, the visibility timeout returns the job to the queue; repeated failures move it to the DLQ. If a packaging stage fails, no final manifest is published, preventing clients from discovering partial output. Existing cached segments continue to serve even during a control-plane failure.
The key architectural principle is separation of failure domains. Ingest accepts and durably records work; processing scales independently; object storage is the durable handoff; the CDN serves bytes globally; and authorization issues edge-verifiable credentials. No single Python process should remain in the hot path for millions of segment requests. The repository demonstrates the core media and security behavior locally, while the CloudFormation resources show the intended production handoff.