Isang Input, Maraming FAST Channel Program

Isang Input, Daan-daang Programa — Pagpapatakbo ng 24/7 FAST Channels sa MediaLive

Ang isang 24/7 FAST channel ay nagpapalabas ng daan-daang natatanging programa araw-araw, magpakailanman. Ang AWS MediaLive ay may limit na 20 input attachments kada channel. Ang simpleng disenyo — isang input kada video — ay nauubusan ng mga slot bago tanghalian at pinipilit ang pag-restart ng channel na nagpapatigil sa live stream. Naresolba namin ito sa pamamagitan ng isang dynamic input na naghahatid ng bawat programa na ipapalabas ng channel, at isang layer ng program-level orchestration sa ibabaw nito na nagpapanatili sa timeline na self-healing sa kabila ng mga deploys, partial failures, at pag-edit ng operator.

Ito ang kuwento ng inhinyeriya kung paano talaga gumagana ang orchestration na iyon.

Maikling pangkalahatang-ideya

Ang Problema sa Negosyo

Ang isang FAST channel ay isang 24/7 na serbisyo. Ang mga operator ay nag-iiskedyul ng isang buong linggo o buwan ng mga natatanging video nang maaga, at ang channel ay dapat magpatugtog ng bawat isa sa tamang segundo — malinis na pagpalit ng source, panatilihing matatag ang watermark, maglabas ng mga ad-break cue, punan ang anumang puwang gamit ang isang station-branded slate. Hindi dapat makita ng manonood ang isang black frame, isang natigil na logo, o ang programang nag-loop mula noong nakaraang linggo.

Ang orchestration na iyon ay dapat makaligtas sa lahat ng ginagawa ng mga operator dito: pag-edit ng lineup bukas, pagdaragdag ng mga ad break sa kalagitnaan ng linggo, pag-redeploy pagkatapos ng isang nabigong programa, pagmamadali ng dalawang pag-click ng Deploy. Ang sistema ay alinman sa naglalapat ng bawat pagbabago nang atomically laban sa live channel o nakakabawi nang malinis. "Ang channel ay nasa isang estado na walang nakakaintindi" ay hindi katanggap-tanggap na resulta sa imprastraktura na nagpapalabas ng live.

Isang 60-Segundong MediaLive Primer

Ang AWS MediaLive ay isang long-running cloud encoder. Binibigyan mo ito ng isa o higit pang inputs (source streams o file URLs) at isang schedule ng nakatakdang actions — lumipat sa input na ito, i-on ang overlay na ito, ipasok ang cue na ito. Ang encoder ay tumatakbo magpakailanman, nagpapatupad ng mga action sa kanilang nakatakdang timestamps at naglalabas ng isang HLS manifest na kinokonsumo ng player ng manonood.

Dalawang limitasyon ng AWS ang humuhubog sa lahat ng downstream:

• 20 input attachments kada channel. Hard limit. Ang isang channel na "Top 20 movies" na simpleng idinisenyo na may isang input kada video ay mapupuno ang limit sa ika-21 na pelikula.
• 1500 schedule actions kada channel. Isa ring hard limit. Ang bawat programa ay binubuo ng ilang actions (input switch, watermark kada rendition, ad cues, slate switch), kaya ang tunay na limitasyon ay mas malapit sa ilang daang programa sa isang pagkakataon.

Parehong mahalaga ang mga limitasyong ito para sa isang 24/7 channel na inaasahang magpapalabas ng natatanging nilalaman nang walang hanggan.

Bakit Nabibigo ang mga Simpleng Diskarte

Ang mga halatang paraan ay bawat isa'y nabibigo sa iba't ibang paraan:

• "Isang input kada programa." nalalampasan ang 20-attachment cap ng unang araw. Ang pagdaragdag ng higit pa ay nangangailangan ng muling paggawa ng channel — at ang paggawa ng channel ay tumatagal ng 60–90 segundo kung saan wala ang live stream. Hindi katanggap-tanggap sa isang 24/7 na serbisyo.
• "Muling gawin ang channel para sa bawat deploy." Parehong problema, sa bawat deploy. Nakakaranas ang mga manonood ng outage sa tuwing nagbabago ang programming. Hindi ito isang tunay na opsyon para sa isang channel na dapat ay live.
• "I-pre-encode ang buong linggo sa isang malaking looping file." Pinapatay ang modelo ng pag-edit. Gustong i-reorder bukas? Muling i-encode ang buong linggo. Gustong magpasok ng ad? Muling i-encode. Ang buong dahilan kung bakit gumagana ang FAST channels bilang isang negosyo ay ang dynamic programming at per-break ad insertion — ang pagsunog ng lahat sa isang file ay nagtatapos sa pareho.
• "Magpatakbo ng maraming channel nang sabay-sabay." Kailangan ng player na lumipat sa pagitan nila, nagpapataas ng gastos ng AWS, at pinaghihiwalay ang audio, MediaPackage, at CDN pipeline. Hindi nito nalulutas ang problema kundi pinaparami lang ito.

Ang magagamit namin ay isang feature na dokumentado ng AWS — ang $urlPath$ placeholder sa isang dynamic input — at ang kalayaan na bumuo ng anumang orchestration na gusto namin sa ibabaw nito.

Bakit ito mahalaga. Hindi ang paggamit ng $urlPath$ ang sikreto. Idinokumento ito ng AWS. Ang sikreto ay ang pagbuo ng isang self-healing orchestration layer sa ibabaw nito na makakaligtas sa partial deploys, pag-edit ng operator, at concurrent retries — nang hindi kailanman inilalagay ang live channel sa isang estado na hindi mailarawan ng sinuman mula sa UI.

Ang Aming Solusyon

Isang MediaLive channel. Isang dynamic input na naka-link sa eksaktong URL na $urlPath$. Isang slate input para sa pagpuno ng puwang. Sa bawat hangganan ng programa, isang InputSwitchScheduleActionSettings action ang nag-o-override sa URL ng dynamic input gamit ang aktwal na S3 path ng programang iyon. Hindi na kailangan ng channel ng bagong input attachment, hindi na kailangan ng restart, at hindi kailanman nagiging offline.

Ang kawili-wiling gawain ay ang orchestration layer na tumatakbo sa ibabaw ng isang input na iyon — pagbibigay ng pangalan sa bawat action na may program ID upang ang mga orphan ay malinis pagkatapos ng isang failure, pagpuno ng mga puwang na ≥ 6 segundo gamit ang isang slate upang hindi makita ng manonood ang isang hold-frame, pag-activate ng watermark sa isang tiyak na sandali pagkatapos ng bawat input switch upang hindi mag-strobe ang overlay sa mga buffering frames, at pag-preflight laban sa 1500-action ceiling upang ang mga deploys ay mabigo sa UI sa halip na mid-flight sa AWS.

Diagram 1 · Channel Architecture

Arkitektura

• Slate input — isang static asset na naka-attach sa channel para sa pagpuno ng mga puwang sa pagitan ng mga programa.
• Dynamic input — nilikha nang isang beses gamit ang Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. Ang URL ay isang placeholder; ang aktwal na path ay ibinibigay kada programa sa oras ng schedule.
• Lambda orchestrator (fastChannel-lambda-fun/index.js) — nagmamay-ari sa bawat aktibidad na lumalabas sa channel. Gumagawa ng isang 8-byte hex programId kada programa at nilalagyan ng tag ang bawat kaugnay na action gamit ito.
• MediaLive schedule — isang solong nakaayos na listahan ng mga action, lahat ay dumadaloy sa isang BatchUpdateScheduleCommand. Limitado sa 1500 actions ng AWS.
• Backend preflight (schedule.service.ts) — tinatawag ang GET_SCHEDULE_COUNT ng Lambda bago ang bawat deploy at tumatangging magpatuloy kung ang mga bagong action ay lalampas sa limitasyon.

• Orphan sweep (sweepIncompleteProgramGroups) — tumatakbo pagkatapos ng bawat deploy. Pinapangkat ang mga action sa pamamagitan ng programId, dine-delete ang anumang pangkat na nawawala ang anchor input-switch action nito.

   

Mga Pangunahing Desisyon sa Inhinyeriya

1. Isang dynamic input, isang URL override kada programa

Ang dynamic input ay nilikha gamit ang Sources: [{ Url: "$urlPath$" }]. Sa bawat hangganan ng programa, naglalabas ang Lambda ng isang InputSwitchScheduleActionSettings action na nagbibigay ng UrlPath: [program.videoUrl] — ang aktwal na S3 URL ng MP4 ng programang iyon. Pinapalitan ng MediaLive ang placeholder sa oras ng pagpapatupad at kumukuha mula sa tunay na source.

Isang input attachment na ngayon ang naghahatid sa bawat programa na ipapalabas ng channel — epektibong walang limitasyong natatanging video sa buong buhay ng channel, limitado lamang sa per-deploy schedule-action limit sa anumang isang punto ng panahon. Ang 20-input cap ay hindi na isang hadlang, at hindi na kailangan ng channel ng restart upang magdagdag ng bagong content.

Diagram 2 · Dynamic Input URL Override

Kompromiso na sinadya namin. Ang isang dynamic input ay hindi pre-validate ang URL — nireresolba lamang ng MediaLive ang placeholder sa oras ng switch, kaya ang isang 404 ay lumalabas bilang isang stream-side error sa halip na isang deploy-time rejection. Tinatanggap namin ang gastos na iyon kapalit ng architectural simplicity ng isang input. Nahuhuli ng hiwalay na ffprobe validation ng backend ang mga malformed source bago ang deploy.

2. Ang mga pangalan ng action na may tag ng programa ay nagbibigay-daan sa self-healing

Bawat action na inilalabas ng Lambda ay nagtataglay ng 8-byte hex programId ng programa sa pangalan nito: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Pagkatapos ng bawat deploy, sweepIncompleteProgramGroups ililista ang bawat action na kasalukuyang nasa channel, ipapangkat ang mga ito sa pamamagitan ng kanilang naka-embed na programId, at buburahin ang anumang pangkat na nawawala ang anchor input-switch action nito. Iyan ang cleanup path para sa mga nabigong partial deploys, racy edits, at anumang iba pang kondisyon na maaaring mag-iwan sa channel na may kalahating actions ng programa na stranded.

Ang action-name encoding ay ang buong mekanismo ng pagkakakilanlan. Ang MediaLive mismo ay walang konsepto ng "programa" — ang orchestration layer ay nagpro-project nito sa pamamagitan ng mga naming convention.

Bakit ito mahalaga. Kung walang program ID na naka-embed sa bawat pangalan ng action, walang paraan ang orphan sweep upang malaman kung aling mga action ang magkakasama. Ang action-level cleanup ay maaaring magtanggal ng labis (buong channel reset) o kulang (stranded watermarks na hindi kailanman nag-o-off). Ang naming convention ang data model.

3. Ang 6-segundong slate rule

Bihira perpektong magkadikit ang mga programa — halos palaging may ilang segundong puwang sa pagitan ng pagtatapos ng isang MP4 at pagsisimula ng susunod na nakatakdang programa. Naglalabas ang orchestration ng isang slate-switch action tuwing ang puwang ay ≥ 6 segundo (MIN_SLATE_GAP_MS = 6000).

Ang threshold ay hindi arbitraryo. Ipinapatupad ng MediaLive ang isang 5-segundong minimum spacing sa pagitan ng anumang dalawang schedule action; ang paglalabas ng slate-switch na mas malapit kaysa doon sa input-switch ng susunod na programa ay nagdudulot ng pagtanggi. Ang 6-segundong patakaran ay nagbibigay sa MediaLive ng kinakailangang puwang at nag-iiwan sa orchestration layer ng isang segundong clock-drift safety margin. Sa ilalim ng 6 na segundo, hinahayaan namin ang huling frame ng naunang programa na mag-freeze saglit sa halip na ipagsapalaran ang isang deploy rejection.

4. Per-rendition watermark na may sinusukat na activation delay

Ang watermark ay isang StaticImageOutputActivate action na inilalabas kada output rendition (1080p, 720p, 480p, 360p) — apat na action kada programa. Ang bawat action ay nagpa-fire 1,500 ms pagkatapos ng input-switch ng programang iyon.

Mayroong delay dahil ang mga unang frame pagkatapos ng input switch ay nagba-buffer pa; ang pag-activate ng overlay sa eksaktong sandali ng switch ay maaaring magdulot ng maikling pagkutitap habang ang overlay ay nagpipinta sa isang frame na hindi pa ganap na na-render. Ang 1,500 ms ay ang halaga na patuloy na nagdulot ng malinis na activation sa lahat ng apat na rendition sa pagsubok. Ito ay isang sinusukat na constant, hindi isang dokumentadong MediaLive parameter — at ito ay nasa isang lugar sa code kaya ang pag-tune sa hinaharap ay isang one-line change.

Kompromiso na sinadya namin. Ang mga per-rendition overlay actions ay nagkakahalaga ng 4× sa bilang ng action kumpara sa isang solong global overlay. Tinatanggap namin ang gastos dahil ang per-rendition path ay nagpapahintulot sa bawat output na makakuha ng watermark na eksakto sa laki ng pixel nito, sa halip na hayaan ang MediaLive na i-downscale ang isang solong overlay sa lahat ng apat. Ang resulta ay isang kapansin-pansing mas matalas na logo sa SD outputs — at nag-iiwan ito ng sapat na action budget para sa daan-daang programa bago maging mahalaga ang 1500 cap.

5. Ang 1500-action ceiling, preflighted sa UI

Ang AWS ay may hard-cap sa isang MediaLive channel sa 1500 schedule actions. Sa ~7–8 actions kada programa (input switch + 4 watermarks + 2 ad cues + paminsan-minsang slate), ang channel ay humahawak ng humigit-kumulang 180–200 aktibong programa depende sa ad density at slate frequency. Iyan ay isang tunay na limitasyon para sa long-horizon deploys, at ang eksaktong bilang ay depende sa per-program na pagiging kumplikado.

Bago ang bawat deploy, tinatawag ng backend ang GET_SCHEDULE_COUNT ng Lambda, na nagbibilang ng live actions sa channel sa pamamagitan ng DescribeScheduleCommand at nagbabalik ng { liveCount, capacity: 1500 }. Kung ang liveCount + (newPrograms × 8) ay lalampas sa 1500, ang backend ay nagta-throw ng SCHEDULE_ACTION_CAP_EXCEEDED na may eksaktong headroom number — bago ito magsumite ng anuman sa MediaLive. Nakikita ng operator ang limitasyon sa UI na may gabay na i-clear muna ang mga nakaraang programa. Ang deploy ay hindi kailanman naghahati-hati sa pader.

Diagram 3 · One Program's Action Timeline

Mga Resulta

• Isang MediaLive channel ang epektibong nagseserbisyo ng walang limitasyong natatanging programa sa buong buhay nito, sa isang dynamic input attachment. Ang 20-input cap ay hindi na isang hadlang na kailangan nating planuhin — ang kapasidad sa anumang isang pagkakataon ay pinamamahalaan ng schedule-action limit, hindi ng input limit.
• Ang channel orchestration ay self-healing: bawat deploy ay nagtatapos sa isang orphan sweep, kaya ang mga nabigong partial deploys ay hindi makapag-iiwan sa schedule sa isang inconsistent state.
• Ang schedule capacity ay limitado at nakikita. Nakikita ng mga operator ang 1500-action ceiling sa UI bago sila mag-click, hindi bilang isang opaque AWS rejection sa kalagitnaan ng deploy.
• Ang program-ID naming convention ay ang buong identity layer — at ito ay isang string. Walang bagong imprastraktura, walang karagdagang storage, walang dependencies. Ang pinakasimpleng posibleng projection ng "programa" sa flat action list ng MediaLive.

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