Et FAST channels logo – det lille mærke i hjørnet – er den visuelle konstant på tværs af hvert program, hver reklamepause, hver skærm, kanalen viser. Det skal se professionelt ud på ethvert kvalitetsniveau, en seer måtte modtage. Den naive tilgang – at uploade ét masterbillede og lade AWS MediaLive skalere det pr. rendition – producerer et skarpt logo ved 1080p og et synligt blødt et ved 360p. Det er et brandproblem for enhver seer, der ikke har bredbånd. Her er, hvordan vi i stedet tilpassede logoet til hver renditions præcise pixelgitter.
Hurtigt overblik
| Aspekt | Detalje |
|---|---|
| Domæne | Channel-logo (DOG) overlay på FAST channels |
| Mekanisme | Pr. output StaticImageOutputActivate pr. rendition (1080p, 720p, 480p, 360p) |
| Generering af assets | Python script der bruger Lanczos resampling |
| Aktiveringstidspunkt | 1,5s efter hvert programs inputskift |
| Status | 1× per-rendition stack i produktion |
Forretningsproblemet
Et FAST channel leverer ikke ét kvalitetsniveau. MediaLive encoder den samme kanal i flere renditions – 1080p, 720p, 480p, 360p – og hver seers afspiller vælger den bedste, deres forbindelse kan opretholde. Mobile seere på mobildata ser 360p; smart-TV-seere på bredbånd får 1080p. De ser alle på det samme brandmærke, og de forventer alle, at det ser professionelt ud. Når logoet er skarpt ved 1080p og synligt blødt ved 360p, er brandet inkonsekvent – ikke en mindre detalje på en 24/7 kanal, hvor logoet er det ene element, seerne ser mere end noget enkelt program.
Hvor overlays faktisk anvendes
I en multi-rendition encoder pipeline kan et overlay anvendes to steder:
Før per-rendition scaler, hvor ét masterbillede composites oven på kilden, og det hele nedskaleres pr. output – dette er, hvad MediaLive gør med en global StaticImageActivate handling
efter scaler, hvor hvert output får sit eget overlay anvendt, når lærredet allerede har den endelige størrelse. Forskellen ser lille ud i API'en. Visuelt er den det ikke. Alt, der composites før scaler, arver hver eneste artefakt, scaler introducerer, og ved 360p er scaler aggressiv.
Hvorfor de åbenlyse løsninger fejler
"Upload én master og lad MediaLive skalere den." Den globale handling kompositerer masteren, før per-output scaler kører. En stor master nedskaleret til et 64×21px logo for 360p er en reduktion på cirka 40x – selv Lanczos resampling mister fine detaljer ved dette forhold, og resultatet passerer derefter gennem den samme kompressionskæde som selve videoen.
"Brug en større master." Dette gør nedskaleringsforholdet større, ikke mindre – artefakten bliver værre, ikke bedre.
"Spring logoet over på SD outputs." Overholdelses- og brandkrav kræver mærket på hver rendition. Ikke en mulighed.
"Brænd logoet ind i kildevideoen ved encoding." Mister alle operationelle håndtag – ingen logoændringer pr. kampagne eller pr. region, og ingen opdatering uden gen-encoding af hele biblioteket.
"Brug et globalt overlay med manuelle koordinater pr. opløsning." Den globale handling beregner position i forhold til en fast 1920×1080 reference, så kildevideoer, der er smallere end dette, producerer koordinater uden for lærredet – logoet driver væk fra hjørnet eller bliver beskåret.
Den faktiske løsning var at omgå MediaLives overlay-skalering fuldstændigt: størrelse logoet til hver renditions lærred selv, før encoderen nogensinde rører det.
Løsningen
Hver renditions logo forhåndsgengives til dets nøjagtige pixeldimensioner og gemmes som en separat PNG. Ved hver programgrænse udsender en Lambda orchestrator fire StaticImageOutputActivate handlinger – én pr. rendition – hver pegende på den PNG, der allerede er dimensioneret til det specifikke output. MediaLive udfører nul skalering på overlayet.
GLOBAL (naiv) PR. OUTPUT (hvad vi leverer)
master.png ──► kompositer på master.png ──► Lanczos resize (offline)
kilde lærred til 4 præcise-størrelses PNGs
│ │
▼ ▼
per-rendition scaler per-rendition scaler
(skalerer også (overlay røres ikke —
overlay → blødt logo kompositeres efter, i
på SD outputs) nøjagtig pixelstørrelse)Et Python script genererer de fire dimensionerede PNG'er fra en enkelt master ved hjælp af Lanczos resampling, valgt for forudsigelig, gentagelig adfærd ved små størrelser frem for at vinde en pixel-kvalitetskonkurrence. Hvert logo lander på cirka 10% af dets lærredsbredde – synligt uden at være påtrængende – og tilføjelse af en ny rendition er en enkelt array-post plus en ny PNG.
Væsentlige beslutninger værd at nævne
Aktiveringsforsinkelse på 1,5 sekunder. Watermark-on handlinger udløses 1,5 sekunder efter hvert inputskift, ikke i det præcise skiftøjeblik – øjeblikkelig aktivering kan flimre mod endnu ikke-stabile billeder. Værdien blev tunet empirisk og centraliseret som en enkelt konstant, så fremtidig tuning er en ændring på én linje.
Offline, menneske-udløst asset-generering – bevidst. Lanczos resize-pipelinen er ikke automatiseret som et build step eller CDN-side transform. Logo-assets ændres sjældent nok til, at en en-kommando regenerering er den rette mængde automatisering; omkostningerne ved at bygge yderligere automatisering opvejer at køre et script to gange om året.
En "tyk" variant eksisterer, men sendes ikke ud. Generatoren producerer også en dilated-alpha variant med tykkere streger, beregnet til at overleve H.264 quantization ved lave SD bitrates. Den er ikke i produktion – standardvarianten er tilstrækkelig til det nuværende bitrateområde, og ingen målinger retfærdiggør endnu et skift. Den eksisterer som en kode-testet standby: billig at holde tilgængelig, for tidlig at sende ud.
Hvad vi stadig holder øje med
Ingen produktionsvideopipeline er nogensinde virkelig færdig, og der er stadig muligheder for at forfine denne tilgang over tid.
Den nuværende implementering sikrer, at hver rendition modtager et logo, der er specifikt forberedt til dens egen outputopløsning, hvilket eliminerer runtime overlay-skalering fra MediaLive-pipelinen. Det endelige udseende er dog stadig naturligt begrænset af hver renditions opløsning og videokompression, især ved lavere bitrater. Efterhånden som streamingprofiler udvikler sig, vil vi fortsat evaluere, om forskellige logo-behandlinger giver målbare visuelle fordele under disse forhold.
Asset-generatoren understøtter allerede både standard- og en tykkere logo-variant. Hvis fremtidig test viser, at den tykkere version performer bedre for lavere-bitrate renditions, vil vi gøre valg af logo-variant konfigurationsdrevet, så det kan ændres uden at genudrulle applikationen.
Resultater
Hver rendition modtager nu et logo, der er specifikt dimensioneret til sit eget lærred, med MediaLive der udfører nul runtime overlay-skalering. Hvert output bruger artwork, der er forberedt til dets målopløsning, og undgår den yderligere udblødning, der introduceres af runtime overlay-skalering, samtidig med at den bedst mulige visuelle kvalitet, som renditionen kan levere, bevares.
Koordinat-drift fejlen fra den tidligere globale overlay-tilgang, hvor logoer kunne flytte sig på kildevideoer smallere end 1920px, er strukturelt elimineret, fordi per-output aktivering opererer fuldstændigt i output-koordinater.
Udskiftning af logoet er nu en simpel operationel opgave: generer de rendition-specifikke assets med et enkelt script og upload dem. Ingen video-gen-encoding og ingen manuel redigering pr. rendition er påkrævet.
Denne implementering følger et simpelt ingeniørprincip: løs problemer så tidligt i pipelinen som muligt, og design omkring platformens kapaciteter i stedet for at stole på downstream workarounds. Ved at forberede den korrekte asset før encoding forbliver live-pipelinen enklere, mere forudsigelig og lettere at vedligeholde.
Hvis du oplever lignende rendition- eller overlay-kvalitetsproblemer i en live videopipeline, kontakt os.
Teknologistak: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
