A FAST channel's logo — the small mark in the corner — is the one visual constant across every program, every ad break, every slate the channel airs. It has to look professional at every quality level a viewer might receive. The naive approach — upload one master image and let AWS MediaLive scale it per rendition — produces a sharp logo at 1080p and a visibly soft one at 360p. That's a brand problem for every viewer who isn't on broadband. Here's how we sized the logo to each rendition's exact pixel grid instead.
Quick Overview
| Aspect | Detail |
|---|---|
| Domain | Channel-logo (DOG) overlay on FAST channels |
| Mechanism | Per-output StaticImageOutputActivate per rendition (1080p, 720p, 480p, 360p) |
| Asset generation | Python script using Lanczos resampling |
| Activation timing | 1.5s after each program's input switch |
| Status | 1× per-rendition stack in production |
The Business Problem
A FAST channel doesn't deliver one quality level. MediaLive encodes the same channel into multiple renditions — 1080p, 720p, 480p, 360p — and each viewer's player picks the best one their connection can sustain. Mobile viewers on cellular data watch 360p; smart-TV viewers on broadband get 1080p. They're all looking at the same brand mark, and they all expect it to look professional. When the logo is crisp at 1080p and visibly soft at 360p, the brand is inconsistent — not a minor detail on a 24/7 channel where the logo is the one element viewers see more than any single program.
Where Overlays Actually Get Applied
In a multi-rendition encoder pipeline, an overlay can be applied in two places:
Before the per-rendition scaler, where one master image is composited onto the source and the whole thing is scaled down per output — this is what MediaLive does with a global StaticImageActivate action
after the scaler, where each output gets its own overlay applied once the canvas is already at final size. The difference looks small in the API. Visually, it isn't. Anything composited before the scaler inherits every artifact the scaler introduces, and at 360p, the scaler is aggressive.
Why the Obvious Fixes Fail
"Upload one master and let MediaLive scale it." The global action composites the master before the per-output scaler runs. A large master downscaled to a 64×21px logo for 360p is a roughly 40x reduction — even Lanczos resampling loses fine detail at that ratio, and the result then passes through the same compression chain as the video itself.
"Use a bigger master." This makes the downscale ratio larger, not smaller — the artifact gets worse, not better.
"Skip the logo on SD outputs." Compliance and brand requirements need the mark on every rendition. Not an option.
"Burn the logo into the source video at encode time." Loses every operational lever — no per-campaign or per-region logo changes, and no update without re-encoding the entire library.
"Use a global overlay with manual coordinates per resolution." The global action computes position against a fixed 1920×1080 reference, so source videos narrower than that produce off-canvas coordinates — the logo drifts off the corner or gets cropped.
The actual lever was bypassing MediaLive's overlay scaling entirely: size the logo to each rendition's canvas ourselves, before the encoder ever touches it.
The Solution
Each rendition's logo is pre-rendered to its exact pixel dimensions and stored as a separate PNG. At every program boundary, a Lambda orchestrator emits four StaticImageOutputActivate actions — one per rendition — each pointing at the PNG already sized for that specific output. MediaLive performs zero scaling on the overlay.
GLOBAL (naive) PER-OUTPUT (what we ship)
master.png ──► composite onto master.png ──► Lanczos resize (offline)
source canvas into 4 exact-size PNGs
│ │
▼ ▼
per-rendition scaler per-rendition scaler
(also scales the (overlay isn't touched —
overlay → soft logo composited after, at
on SD outputs) exact pixel size)A Python script generates the four sized PNGs from a single master using Lanczos resampling, chosen for predictable, repeatable behavior at small sizes rather than for winning a pixel-quality contest. Each logo lands at roughly 10% of its canvas width — visible without being intrusive — and adding a new rendition is a single array entry plus one new PNG.
Key Decisions Worth Naming
Activation delay of 1.5 seconds. Watermark-on actions fire 1.5 seconds after each input switch, not at the exact switch moment — activating immediately can flicker against not-yet-stable frames. The value was tuned empirically and centralized as a single constant so future tuning is a one-line change.
Offline, human-triggered asset generation — deliberately. The Lanczos resize pipeline isn't automated as a build step or CDN-side transform. Logo assets change rarely enough that a one-command regeneration is the right amount of automation; the cost of building further automation outweighs running a script twice a year.
A "thick" variant exists but isn't shipped. The generator also produces a dilated-alpha variant with thicker strokes, meant to survive H.264 quantization at low SD bitrates. It's not in production — the standard variant is sufficient for the current bitrate range, and no measurement yet justifies switching. It exists as code-tested standby: cheap to keep available, premature to ship.
What We're Still Watching
No production video pipeline is ever truly finished, and there are still opportunities to refine this approach over time.
The current implementation ensures that every rendition receives a logo prepared specifically for its own output resolution, eliminating runtime overlay scaling from the MediaLive pipeline. The final appearance, however, is still naturally limited by each rendition's resolution and video compression, particularly at lower bitrates. As streaming profiles evolve, we'll continue evaluating whether different logo treatments provide measurable visual benefits under those conditions.
The asset generator already supports both the standard and a thicker logo variant. If future testing shows that the thicker version performs better for lower-bitrate renditions, we'll make logo-variant selection configuration-driven so it can be changed without redeploying the application.
Results
Every rendition now receives a logo sized specifically for its own canvas, with MediaLive performing zero runtime overlay scaling. Each output uses artwork prepared for its target resolution, avoiding the additional softening introduced by runtime overlay scaling while preserving the best practical visual quality that rendition can deliver.
The coordinate-drift bug from the previous global overlay approach, where logos could shift on source videos narrower than 1920px, is structurally eliminated because per-output activation operates entirely in output coordinates.
Replacing the logo is now a simple operational task: regenerate the rendition-specific assets with a single script and upload them. No video re-encoding and no per-rendition manual editing are required.
This implementation follows a simple engineering principle: solve problems as early in the pipeline as possible, and design around the platform's capabilities instead of relying on downstream workarounds. By preparing the correct asset before encoding, the live pipeline remains simpler, more predictable, and easier to maintain.
If you're running into similar rendition or overlay quality issues on a live video pipeline, get in touch.
Technology Stack: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
