Yksi syöte, satoja ohjelmia – 24/7 FAST-kanavien pyörittäminen MediaLivessä
24/7 FAST-kanava toistaa satoja uniikkeja ohjelmia päivittäin, joka päivä, ikuisesti. AWS MediaLive rajoittaa kanavan 20 syötekiinnitykseen (input attachments). Naiivi suunnittelu – yksi syöte per video – kuluttaa kaikki paikat loppuun ennen lounasta ja pakottaa kanavan uudelleenkäynnistykseen, joka katkaisee suoratoiston. Ratkaisimme tämän yhdellä dynaamisella syötteellä, joka palvelee kaikkia kanavan koskaan esittämiä ohjelmia, ja ohjelmatason orkestrointikerroksella, joka pitää aikajanan itsekorjautuvana käyttöönottojen, osittaisten vikojen ja operaattorimuokkausten yli.
Tämä on tekninen tarina siitä, miten orkestrointi todella toimii.
Lyhyt katsaus
| Ominaisuus | Yksityiskohta |
|---|---|
| Toimialue | 24/7 FAST-kanavan orkestrointi AWS MediaLivessä |
| Syötekiinnitykset kanavaa kohden | 1 dynaaminen + 1 taukoruutu (slate) (+ valinnainen SRT) – reilusti alle 20 syötteen rajoituksen |
| Ohjelmakohtainen tunnistus | 8-tavuinen heksadesimaalinen programId upotettuna jokaiseen toimintonimeen |
| Taukoruudun täytön kynnys | Yli 6 sekunnin aukot saavat slate-switch -toiminnon |
| Aikataulun kapasiteetti | 1500 toimintoa kanavaa kohden (AWS:n ehdoton raja, esitarkastettu) |
| Itsensä korjaava | Orpojen toimintojen siivousajetaan jokaisen käyttöönoton jälkeen |
| Tila | Tuotannossa |
Liiketoimintaongelma
FAST-kanava on 24/7-palvelu. Operaattorit ajoittavat kokonaisen viikon tai kuukauden uniikkeja videoita etukäteen, ja kanavan on toistettava jokainen oikeaan aikaan – vaihdettava lähteitä puhtaasti, pidettävä vesileima vakaana, lähetettävä mainoskatkojen vihjeet, täytettävä kaikki aukot kanavan brändäämällä taukoruudulla. Katsojan ei pitäisi koskaan nähdä mustaa ruutua, jumiutunutta logoa tai viime viikon ohjelman toistoa silmukassa.
Orkestroinnin on selviydyttävä kaikesta, mitä operaattorit sille tekevät: huomisen ohjelmiston muokkaamisesta, mainoskatkojen lisäämisestä keskellä viikkoa, uudelleenjulkaisusta yhden epäonnistuneen ohjelman jälkeen, kahden Deploy-napsautuksen kilpa-ajosta. Järjestelmä joko soveltaa kaikki muutokset atomisesti suoraan kanavaan tai palautuu puhtaasti. "Kanava on nyt tilassa, jota kukaan ei ymmärrä" ei ole hyväksyttävä lopputulos infrastruktuurilla, joka lähettää suoraa lähetystä.
60 sekunnin MediaLive-katsaus
AWS MediaLive on pitkäkestoinen pilvipohjainen kooderi. Annat sille yhden tai useamman syötteen (lähdevirtoja tai tiedosto-URL-osoitteita) ja ajoitetun toimintojen aikataulun – vaihda tähän syötteeseen, kytke tämä peittokuva päälle, lisää tämä vihje. Kooderi käy ikuisesti, suorittaen toimintoja ajoitettujen aikaleimojen mukaan ja lähettäen HLS-manifestin, jonka katsojan soitin kuluttaa.
Kaksi AWS-rajoitusta muokkaavat kaikkea alapuolella olevaa:
- 20 syötekiinnitystä kanavaa kohden. Ehdoton raja. Yksinkertaisesti suunniteltu "Top 20 movies" -kanava, jossa on yksi syöte per video, täyttää rajan elokuva numero 21:ssä.
- 1500 aikataulutoimintoa kanavaa kohden. Myös ehdoton raja. Jokainen ohjelma sisältää useita toimintoja (input switch, watermark per rendition, ad cues, slate switch), joten todellinen yläraja on lähempänä muutamia satoja ohjelmia kerrallaan.
Molemmat rajoitukset ovat tärkeitä 24/7-kanavalle, jonka odotetaan toistavan uniikkia sisältöä rajattomasti.
Miksi naiivit lähestymistavat epäonnistuvat
Ilmeiset polut hajoavat kukin eri tavoin:
- "Yksi syöte per ohjelma." täyttää ensimmäisen päivän 20 liitteen rajoituksen. Lisääminen edellyttää kanavan uudelleenluomista – ja kanavan uudelleenluominen kestää 60–90 sekuntia, jonka aikana suoratoisto on poissa. Ei hyväksyttävää 24/7-palvelussa.
- "Luo kanava uudelleen jokaisen käyttöönoton yhteydessä." Sama ongelma, jokaisen käyttöönoton yhteydessä. Katsojat kokevat katkoksen joka kerta, kun ohjelmointi muuttuu. Tämä ei ole todellinen vaihtoehto kanavalle, jonka on tarkoitus olla suora.
- "Esikoodaa koko viikko yhdeksi jättimäiseksi silmukkatiedostoksi." Tuhoaa muokkausmallin. Haluatko järjestää huomisen uudelleen? Koodaa koko viikko uudelleen. Haluatko lisätä mainoksen? Koodaa uudelleen. FAST-kanavien liiketoimintamallin koko perusta on dynaaminen ohjelmointi ja mainoskatkokohtainen mainosten sijoittelu – kaiken polttaminen yhteen tiedostoon estää molemmat.
- "Aja useita kanavia rinnakkain." Edellyttää soittimen vaihtamista niiden välillä, moninkertaistaa AWS:n kustannukset ja rikkoo ääni-, MediaPackage- ja CDN-putkiston. Ei niinkään ratkaise ongelmaa kuin moninkertaistaa sen.
Käytettävissämme oli yksi AWS:n dokumentoitu ominaisuus – dynaamisen syötteen $urlPath$-paikkamerkki – ja vapaus rakentaa sen päälle haluamamme orkestrointi.
Miksi tällä on merkitystä. Temppu ei ole $urlPath$-paikkamerkin käyttö. AWS dokumentoi sen. Temppu on rakentaa sen päälle itsekorjautuva orkestrointikerros, joka selviää osittaisista käyttöönotoista, operaattorin muokkauksista ja samanaikaisista uusintayrityksistä – ilman, että live-kanava joutuu koskaan tilaan, jota kukaan ei voi kuvata käyttöliittymästä.
Ratkaisumme
Yksi MediaLive-kanava. Yksi dynaaminen syöte, joka on linkitetty täsmälliseen URL-osoitteeseen $urlPath$. Yksi taukoruutusyöte (slate input) aukkojen täyttöön. Jokaisen ohjelmarajan kohdalla InputSwitchScheduleActionSettings-toiminto korvaa dynaamisen syötteen URL-osoitteen kyseisen ohjelman todellisella S3-polulla. Kanava ei koskaan tarvitse uutta syötekiinnitystä, ei koskaan uudelleenkäynnistystä, eikä se koskaan mene offline-tilaan.
Mielenkiintoinen työ on orkestrointikerros, joka toimii tämän yhden syötteen päällä – nimeämällä jokaisen toiminnon ohjelman ID:llä, jotta orvot voidaan siivota vian jälkeen, täyttämällä vähintään 6 sekunnin aukot taukoruudulla, jotta katsoja ei koskaan näe jäätynyttä kuvaa, aktivoimalla vesileiman mitatun hetken kuluttua jokaisesta syötteen vaihdosta, jotta peittokuva ei välähdä puskurointikehysten läpi, ja esitarkastamalla 1500 toiminnon rajan, jotta käyttöönotot epäonnistuvat käyttöliittymässä sen sijaan, että ne epäonnistuisivat kesken toiminnan AWS:ssä.
Kaavio 1 · Kanavan arkkitehtuuri
Arkkitehtuuri
- Taukoruutusyöte (Slate input) — staattinen resurssi, joka on liitetty kanavaan ohjelmien välisten aukkojen täyttämiseksi.
- Dynaaminen syöte (Dynamic input) — luotu kerran komennolla Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. URL-osoite on paikkamerkki; todellinen polku toimitetaan ohjelmakohtaisesti aikataulutushetkellä.
- Lambda-orkestraattori (fastChannel-lambda-fun/index.js) — hallinnoi jokaista kanavalla esiintyvää toimintoa. Luo 8-tavuisen heksadesimaalisen programId:n ohjelmaa kohden ja merkitsee jokaisen siihen liittyvän toiminnon sillä.
- MediaLive-aikataulu — yksi järjestetty luettelo toiminnoista, jotka kaikki kulkevat yhden BatchUpdateScheduleCommand:n kautta. AWS rajoittaa 1500 toimintoon.
- Backend-esitarkastus (schedule.service.ts) — kutsuu Lambdan GET_SCHEDULE_COUNT-toimintoa ennen jokaista käyttöönottoa ja kieltäytyy jatkamasta, jos uudet toiminnot ylittäisivät rajan.
Orpojen siivous (sweepIncompleteProgramGroups) — ajetaan jokaisen käyttöönoton jälkeen. Ryhmittelee toiminnot programId:n mukaan, poistaa kaikki ryhmät, joista puuttuu niiden ankkuri input-switch-toiminto.
Tärkeimmät tekniset päätökset
1. Yksi dynaaminen syöte, yksi URL-osoitteen ohitus per ohjelma
Dynaaminen syöte luodaan komennolla Sources: [{ Url: "$urlPath$" }]. Jokaisen ohjelmarajan kohdalla Lambda lähettää InputSwitchScheduleActionSettings-toiminnon, joka syöttää UrlPath: [program.videoUrl] — kyseisen ohjelman todellisen S3-URL-osoitteen MP4-tiedostolle. MediaLive korvaa paikkamerkin suoritushetkellä ja hakee tiedon todellisesta lähteestä.
Yksi syötekiinnitys palvelee nyt kaikkia kanavan koskaan esittämiä ohjelmia – käytännössä rajoittamattoman määrän uniikkeja videoita kanavan elinkaaren aikana, rajoitettuna ainoastaan yhden käyttöönoton aikataulutoimintojen rajoituksella milloin tahansa. 20 syötteen rajoitus lakkaa olemasta rajoite, eikä kanava tarvitse koskaan uudelleenkäynnistystä uuden sisällön lisäämiseksi.
Kaavio 2 · Dynaamisen syötteen URL-osoitteen ohitus
Tietoisesti tehty kompromissi. Dynaaminen syöte ei esivalidoi URL-osoitetta – MediaLive ratkaisee paikkamerkin vasta vaihtohetkellä, joten 404-virhe ilmenee suoratoiston puoleisena virheenä eikä käyttöönoton aikaisena hylkäämisenä. Hyväksymme tämän kustannuksen yhden syötteen arkkitehtonisen yksinkertaisuuden vastineeksi. Taustajärjestelmän erillinen ffprobe-validointi havaitsee virheellisesti muotoillut lähteet ennen käyttöönottoa.
2. Ohjelmatunnisteiset toimintonimet mahdollistavat itsekorjautuvuuden
Jokainen Lambdan lähettämä toiminto sisältää ohjelman 8-tavuisen heksadesimaalisen programId:n nimessään: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.
Jokaisen käyttöönoton jälkeen sweepIncompleteProgramGroups listaa kaikki kanavalla olevat toiminnot, ryhmittelee ne upotetun programId:nsä mukaan ja poistaa kaikki ryhmät, joista puuttuu niiden ankkuri input-switch-toiminto. Tämä on siivouspolku epäonnistuneille osittaisille käyttöönotoille, kilpailutilanteisille muokkauksille ja kaikille muille tiloille, jotka voisivat jättää kanavalle puoliksi ohjelman toimintoja.
Toimintonimien koodaus on koko tunnistusmekanismi. MediaLivellä itsellään ei ole käsitystä "ohjelmasta" – orkestrointikerros projisoi sellaisen siihen nimeämiskäytäntöjen kautta.
Miksi tällä on merkitystä. Ilman jokaiseen toimintonimeen upotettua ohjelma-ID:tä orpojen siivouksella ei olisi keinoa tietää, mitkä toiminnot kuuluvat yhteen. Toimintotason siivous joko poistaisi liikaa (koko kanavan nollaus) tai liian vähän (jumiutuneet vesileimat, jotka eivät koskaan sammu). Nimeämiskäytäntö on tietomalli.
3. Kuuden sekunnin taukoruutusääntö
Ohjelmat harvoin asettuvat täydellisesti vierekkäin – melkein aina on muutaman sekunnin aukko yhden MP4-tiedoston päättymisen ja seuraavan ajoitetun ohjelman alkamisen välillä. Orkestrointi lähettää slate-switch -toiminnon aina, kun aukko on ≥ 6 sekuntia (MIN_SLATE_GAP_MS = 6000).
Kynnys ei ole mielivaltainen. MediaLive edellyttää vähintään 5 sekunnin väliä kahden aikataulutoiminnon välillä; slate-switch -toiminnon lähettäminen lähempänä kuin tämä seuraavan ohjelman input-switch -toimintoa tuottaa hylkäämisen. Kuuden sekunnin sääntö antaa MediaLivelle sen vaaditun välin ja jättää orkestrointikerrokselle yhden sekunnin kellonajoitusvirheen turvamarginaalin. Alle 6 sekunnin tapauksissa annamme edellisen ohjelman viimeisen kuvan jäätyä hetkeksi sen sijaan, että riskeeraisimme käyttöönoton hylkäämisen.
4. Renditiokohtainen vesileima mitatulla aktivointiviiveellä
Vesileima on StaticImageOutputActivate-toiminto, joka lähetetään per ulostulorenditio (1080p, 720p, 480p, 360p) – neljä toimintoa per ohjelma. Jokainen toiminto laukeaa 1 500 ms kyseisen ohjelman input-switch -toiminnon jälkeen.
Viive johtuu siitä, että ensimmäiset kehykset syötteen vaihdon jälkeen puskuroituvat edelleen; peittokuvan aktivointi tarkalla vaihtohetkellä voi tuottaa lyhyen välähdyksen, kun peittokuva piirtyy vielä osittain renderöimättömään kehykseen. 1 500 ms oli arvo, joka tuotti johdonmukaisesti puhtaan aktivoinnin kaikilla neljällä renditiolla testauksessa. Se on mitattu vakio, ei dokumentoitu MediaLive-parametri – ja se sijaitsee yhdessä paikassa koodissa, joten tuleva viritys on yhden rivin muutos.
Tietoisesti tehty kompromissi. Renditiokohtaiset peittokuvaustoiminnot maksavat 4 kertaa enemmän toimintoja kuin yksi globaali peittokuva. Hyväksymme kustannuksen, koska renditiokohtainen polku antaa jokaiselle ulostulolle vesileiman, joka on mitoitettu tarkalleen sen pikselimittoihin, sen sijaan, että MediaLive skaalaisi yhtä peittokuvaa alas kaikille neljälle. Tuloksena on selvästi terävämpi logo SD-ulostuloissa – ja se jättää riittävästi toimintabudjettia sadoille ohjelmille ennen kuin 1500:n raja alkaa merkitä.
5. 1500 toiminnon raja, esitarkastettuna käyttöliittymässä
AWS asettaa MediaLive-kanavalle ehdottoman rajan 1500 aikataulutoiminnoille. Noin 7–8 toiminnolla ohjelmaa kohden (input switch + 4 vesileimaa + 2 mainosvihjettä + satunnainen taukoruutu) kanava pitää noin 180–200 aktiivista ohjelmaa riippuen mainostiheydestä ja taukoruudun esiintymistiheydestä. Tämä on todellinen yläraja pitkän aikavälin käyttöönotoille, ja tarkka luku riippuu ohjelmakohtaisesta kompleksisuudesta.
Ennen jokaista käyttöönottoa taustajärjestelmä kutsuu Lambdan GET_SCHEDULE_COUNT-toimintoa, joka laskee kanavan live-toiminnot DescribeScheduleCommand:n kautta ja palauttaa { liveCount, capacity: 1500 }. Jos liveCount + (newPrograms × 8) ylittäisi 1500, taustajärjestelmä antaa SCHEDULE_ACTION_CAP_EXCEEDED-virheen tarkalla vapaan tilan numerolla – ennen kuin se lähettää mitään MediaLiveen. Operaattori näkee rajan käyttöliittymässä ohjeen kera poistaa ensin vanhoja ohjelmia. Käyttöönotto ei koskaan törmää seinään puolivälissä.
Kaavio 3 · Yhden ohjelman toimintojen aikajana
Tulokset
- Yksi MediaLive-kanava palvelee käytännössä rajoittamattoman määrän uniikkeja ohjelmia elinkaarensa aikana, yhdellä dynaamisella syötekiinnityksellä. 20 syötteen rajoitus ei ole enää rajoite, jonka ympärille meidän on suunniteltava – kapasiteettia milloin tahansa säätelee aikataulutoimintojen raja, ei syötetaso.
- Kanavan orkestrointi on itsekorjautuva: jokainen käyttöönotto päättyy orpojen siivoukseen, joten epäonnistuneet osittaiset käyttöönotot eivät voi jättää aikataulua epäjohdonmukaiseen tilaan.
- Aikataulun kapasiteetti on rajattu ja näkyvä. Operaattorit näkevät 1500 toiminnon rajan käyttöliittymässä ennen kuin he napsauttavat, eivät läpinäkymättömänä AWS-hylkäyksenä kesken käyttöönoton.
- Ohjelma-ID:n nimeämiskäytäntö on koko identiteettikerros – ja se on merkkijono. Ei uutta infrastruktuuria, ei ylimääräistä tallennustilaa, ei riippuvuuksia. Yksinkertaisin mahdollinen "ohjelman" projektio MediaLiven tasaiseen toimintaluetteloon.
Teknologiakehikko: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)
