Én input, flere FAST kanalprogrammer

Én input, hundredvis af programmer — Kører 24/7 FAST kanaler på MediaLive

En 24/7 FAST kanal afspiller hundredvis af unikke programmer om dagen, hver dag, for evigt. AWS MediaLive begrænser en kanal til 20 input-vedhæftninger. Det naive design – én input pr. video – løber tør for pladser før frokost og tvinger en genstart af kanalen, hvilket tager livestreamen offline. Vi løste dette med én dynamisk input, der betjener hvert program, kanalen nogensinde vil afspille, og et lag af programniveau-orkestrering ovenpå, der holder tidslinjen selvhelende på tværs af deploys, delvise fejl og operatørredigeringer.

Dette er ingeniørhistorien om, hvordan den orkestrering faktisk virker.

Hurtigt overblik

Forretningsproblemet

En FAST kanal er en 24/7 service. Operatører planlægger en hel uge eller måned med unikke videoer på forhånd, og kanalen skal afspille hver enkelt på det rigtige sekund — skifte kilder rent, holde vandmærket stabilt, udsende ad-break cues, udfylde eventuelle huller med en stationsbrandet slate. Seeren bør aldrig se et sort billede, et fastlåst logo eller sidste uges program i loop.

Den orkestrering skal overleve alt, hvad operatører gør ved den: redigering af morgendagens programplan, tilføjelse af ad breaks midt på ugen, redeploy efter et enkelt fejlslagent program, hurtige, gentagne klik på Deploy. Systemet enten implementerer hver ændring atomisk mod den live kanal eller gendanner sig rent. "Kanalen er nu i en tilstand, ingen forstår" er ikke et acceptabelt resultat på infrastruktur, der sendes live.

En 60-sekunders MediaLive-introduktion

AWS MediaLive er en langvarig cloud-encoder. Du giver den en eller flere inputs (kildestreams eller fil-URL'er) og en schedule af tidsindstillede actions — skift til denne input, tænd dette overlay, indsæt denne cue. Encoderen kører for evigt, udfører actions på deres planlagte tidsstempler og udsender et HLS manifest, som seerens afspiller forbruger.

To AWS-grænser former alt downstream:

• 20 input-vedhæftninger pr. kanal. Hård grænse. En "Top 20 film"-kanal, der er naivt designet med én input pr. video, fylder grænsen ved film nummer 21.
• 1500 schedule actions pr. kanal. Også en hård grænse. Hvert program består af flere actions (input switch, watermark pr. rendition, ad cues, slate switch), så det reelle loft er tættere på et par hundrede programmer ad gangen.

Begge grænser er vigtige for en 24/7 kanal, der forventes at afspille unikt indhold på ubestemt tid.

Hvorfor naive tilgange fejler

De åbenlyse veje fejler hver på forskellige måder:

• "Én input pr. program." fuldender den første dags 20-attachment cap. Tilføjelse af flere kræver genskabelse af kanalen – og genskabelse af kanalen tager 60-90 sekunder, hvor livestreamen er væk. Uacceptabelt på en 24/7 service.
• "Genskab kanalen for hvert deploy." Samme problem, hvert deploy. Seerne oplever et udfald, hver gang programmeringen ændres. Dette er ikke en reel mulighed for en kanal, der skal være live.
• "For-encode hele ugen til én kæmpe looping fil." Slår redigeringsmodellen ihjel. Vil du omarrangere i morgen? Re-encode hele ugen. Vil du indsætte en ad? Re-encode. Hele grunden til, at FAST kanaler fungerer som forretning, er dynamisk programmering og per-break ad insertion — at brænde alt ind i en enkelt fil udelukker begge.
• "Kør flere kanaler parallelt." Kræver, at afspilleren skifter mellem dem, multiplicerer omkostningerne ved AWS og opdeler audio, MediaPackage og CDN-pipelinen. Løser ikke problemet så meget som det multiplicerer det.

Den løftestang, vi havde, var en enkelt AWS-dokumenteret funktion — $urlPath$ pladsholderen på en dynamisk input — og friheden til at bygge den orkestrering, vi ønskede, ovenpå den.

Hvorfor dette er vigtigt. Tricket er ikke at bruge $urlPath$. AWS dokumenterer det. Tricket er at bygge et selvhelende orkestreringslag ovenpå det, som overlever delvise deploys, operatørredigeringer og samtidige genforsøg — uden nogensinde at sætte live kanalen i en tilstand, som ingen kan beskrive fra UI'en.

Vores løsning

Én MediaLive kanal. Én dynamisk input knyttet til den nøjagtige URL $urlPath$. Én slate input til udfyldning af mellemrum. Ved hver programgrænse overskriver en InputSwitchScheduleActionSettings action den dynamiske inputs URL med programmets faktiske S3-sti. Kanalen behøver aldrig en ny input-vedhæftning, behøver aldrig en genstart, går aldrig offline.

Det interessante arbejde er orkestreringslaget, der kører ovenpå den ene input — navngivning af hver action med et program-ID, så forældreløse actions kan ryddes op efter en fejl, udfyldning af mellemrum ≥ 6 sekunder med en slate, så seeren aldrig ser et hold-frame, aktivering af vandmærket et målt øjeblik efter hver input switch, så overlay'et ikke flimrer gennem buffering-frames, og preflighting mod 1500-action loftet, så deploys fejler i UI'en i stedet for midt i flyvningen på AWS.

Diagram 1 · Kanalarkitektur

Arkitektur

• Slate input — et statisk asset knyttet til kanalen for at udfylde mellemrum mellem programmer.
• Dynamisk input — oprettet én gang med Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. URL'en er en pladsholder; den faktiske sti leveres pr. program på schedule-tidspunktet.
• Lambda-orkestrator (fastChannel-lambda-fun/index.js) — ejer hver aktivitet, der vises på kanalen. Genererer et 8-byte hex programId pr. program og tagger hver relateret action med det.
• MediaLive schedule — en enkelt ordnet liste af actions, alle flydende gennem én BatchUpdateScheduleCommand. Begrænset til 1500 actions af AWS.
• Backend preflight (schedule.service.ts) — kalder Lambdas GET_SCHEDULE_COUNT før hvert deploy og nægter at fortsætte, hvis de nye actions ville overskride grænsen.

• Orphan sweep (sweepIncompleteProgramGroups) — kører efter hvert deploy. Grupperer actions efter programId, sletter enhver gruppe, der mangler dens anker input-switch action.

   

Vigtige ingeniørbeslutninger

1. Én dynamisk input, én URL-overskrivning pr. program

Den dynamiske input oprettes med Sources: [{ Url: "$urlPath$" }]. Ved hver programgrænse udsender Lambda en InputSwitchScheduleActionSettings action, der leverer UrlPath: [program.videoUrl] — den faktiske S3 URL til programmets MP4. MediaLive erstatter pladsholderen ved udførelsestidspunktet og trækker fra den virkelige kilde.

Én input-vedhæftning betjener nu hvert program, kanalen nogensinde vil afspille — effektivt ubegrænset unikke videoer over kanalens levetid, kun begrænset af per-deploy schedule-action grænsen på et givent tidspunkt. 20-input grænsen holder op med at være en begrænsning, og kanalen behøver aldrig en genstart for at tilføje nyt indhold.

Diagram 2 · Dynamisk input URL-overskrivning

Afvejning vi bevidst har foretaget. En dynamisk input forhåndsvaliderer ikke URL'en — MediaLive løser kun pladsholderen ved skiftetidspunktet, så en 404 viser sig som en stream-side fejl snarere end en deploy-tids afvisning. Vi accepterer denne omkostning til gengæld for den arkitektoniske enkelhed ved én input. Backendens separate ffprobe validering fanger fejlformede kilder før deploy.

2. Program-taggede action-navne muliggør selvheling

Hver action udsendt af Lambda bærer programmets 8-byte hex programId i sit navn: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Efter hvert deploy lister sweepIncompleteProgramGroups hver action, der aktuelt er på kanalen, grupperer dem efter deres indlejrede programId, og sletter enhver gruppe, der mangler dens anker input-switch action. Dette er oprydningsstien for mislykkede delvise deploys, konkurrerende redigeringer og enhver anden tilstand, der kunne efterlade kanalen med halvdelen af et programs actions strandede.

Action-navnets kodning er hele identitetsmekanismen. MediaLive har i sig selv intet koncept om et "program" — orkestreringslaget projicerer et sådant ovenpå det via navngivningskonventioner.

Hvorfor dette er vigtigt. Uden program-ID'et indlejret i hvert action-navn, ville orphan sweep ikke have nogen måde at vide, hvilke actions der hører sammen. Oprydning på action-niveau ville enten slette for meget (hel kanal-nulstilling) eller for lidt (strandede watermarks, der aldrig slukker). Navngivningskonventionen er datamodellen.

3. Den 6-sekunders slate-regel

Programmer støder sjældent perfekt op — der er næsten altid et mellemrum på et par sekunder mellem slutningen af én MP4 og starten af det næste planlagte program. Orkestreringen udsender en slate-switch action, når dette mellemrum er ≥ 6 sekunder (MIN_SLATE_GAP_MS = 6000).

Tærsklen er ikke vilkårlig. MediaLive håndhæver en 5-sekunders minimumsafstand mellem to schedule actions; udsendelse af en slate-switch tættere på den næste programs input-switch producerer en afvisning. 6-sekunders-reglen giver MediaLive det krævede mellemrum og efterlader orkestreringslaget et sekunds sikkerhedsmargin for clock-drift. Under 6 sekunder lader vi det forrige programs sidste frame fryse kortvarigt frem for at risikere en deploy-afvisning.

4. Per-rendition watermark med målt aktiveringsforsinkelse

Vandmærket er en StaticImageOutputActivate action udsendt pr. output rendition (1080p, 720p, 480p, 360p) — fire actions pr. program. Hver action udløses 1.500 ms efter programmets input-switch.

Forsinkelsen eksisterer, fordi de første frames efter en input switch stadig bufferes; aktivering af overlay'et på det nøjagtige skiftetidspunkt kan producere et kort flimmer, når overlay'et tegner sig på en endnu ikke fuldt renderet frame. 1.500 ms var den værdi, der konsekvent producerede en ren aktivering på tværs af alle fire renditions under test. Det er en målt konstant, ikke en dokumenteret MediaLive parameter — og den findes ét sted i koden, så fremtidig tuning er en enkelt linjes ændring.

Afvejning vi bevidst har foretaget. Per-rendition overlay actions koster 4× action-tællingen kontra et enkelt globalt overlay. Vi accepterer omkostningen, fordi per-rendition stien lader hver output få et vandmærke størrelse præcis til dens pixel-dimensioner, snarere end at lade MediaLive nedskalere et enkelt overlay på tværs af alle fire. Resultatet er et synligt skarpere logo på SD outputs — og det efterlader nok action-budget til hundredvis af programmer, før 1500-grænsen bliver relevant.

5. 1500-action loftet, preflighted i UI'en

AWS hard-begrænser en MediaLive kanal til 1500 schedule actions. Med ~7–8 actions pr. program (input switch + 4 watermarks + 2 ad cues + lejlighedsvis slate) rummer kanalen omtrent 180–200 aktive programmer afhængigt af ad-tæthed og slate-frekvens. Det er et reelt loft for long-horizon deploys, og det nøjagtige antal afhænger af kompleksiteten pr. program.

Før hvert deploy kalder backend Lambdas GET_SCHEDULE_COUNT, som tæller live actions på kanalen via DescribeScheduleCommand og returnerer { liveCount, capacity: 1500 }. Hvis liveCount + (newPrograms × 8) ville overskride 1500, kaster backend SCHEDULE_ACTION_CAP_EXCEEDED med det nøjagtige headroom-tal — før den sender noget til MediaLive. Operatøren ser grænsen i UI'en med vejledning til først at rydde tidligere programmer. Deploy'et kører aldrig halvt ind i væggen.

Diagram 3 · Et programs Action Timeline

Resultater

• En enkelt MediaLive kanal betjener effektivt ubegrænset unikke programmer over dens levetid, på én dynamisk input-vedhæftning. 20-input grænsen er ikke længere en begrænsning, vi skal planlægge omkring — kapaciteten på ethvert tidspunkt styres af schedule-action grænsen, ikke input-grænsen.
• Kanalorkestrering er selvhelende: hvert deploy afsluttes med en orphan sweep, så mislykkede delvise deploys ikke kan efterlade schedule'en i en inkonsekvent tilstand.
• Schedule-kapaciteten er afgrænset og synlig. Operatører ser 1500-action loftet i UI'en, før de klikker, ikke som en uigennemsigtig AWS-afvisning midt i et deploy.
• Program-ID navngivningskonventionen er hele identitetslaget — og det er en streng. Ingen ny infrastruktur, ingen ekstra storage, ingen dependencies. Den simpleste mulige projektion af "program" på MediaLives flade action-liste.

Teknologistak: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)