A NAVA, mint rendszer

Egy audiovizuális archívum építése és üzemeltetése nem kis mérnöki feladat. Megtalálható itt az információtechnológia mellett a kommunikációtechnológia, médiainformatika és természetesen villamosmérnöki ágak is.

Mi a cél?

A NAVA IT feladata, hogy biztosítsa az archívum megfelelő működését informatikai oldalról, ami azt jelenti, hogy tudni kell az AV-tartalmakat fogadni, kódolni és eljuttatni az archivátorok, illetve a nyilvánosság elé. Ehhez a feladathoz a már említett ágak szakembereire van szükség, mindenki a saját területén lép be a rendszerbe és végzi a feladatát.

Hogyan épül fel a NAVA rendszere?

Ha felülről szemléljük a rendszert, akkor hierarchikus sorrendben az alábbi modulokat különböztetjük meg:

1. Bemeneti rendszer (INGEST)
2. Előfeldolgozó rendszer (META-PREZENTER)
3. Humán feldolgozórendszer (WORKFLOW)
4. Háttér-feldolgozó rendszer (TRANSCODER BACKEND)
5. Kijátszó rendszer (STREAMING)
6. Alkalmazási réteg (FRONTEND)

ARCHITEKTÚRA LETÖLTÉSE

Az egyes alrendszerek egymással jól definiált interfészeken keresztül kommunikálnak, minden modulnak IN/OUT interfészét különböztetjük meg. Ez lehet csak metaadatot átadó interfész, de médiafeldolgozás során létrejöhet olyan átadási pont, ahol maga a több GB-os médium az interfész.

INGEST, TRANSCODER BACKEND alrendszer

A bemeneti alrendszer egy érdekes és komplex modulja a NAVA-nak. Mivel a NAVA feladata a magyar vonatkozású műsorszámok gyűjtése (erről bővebben itt olvashat) ezért a fő bemeneti rendszer a DVB-C és DVB-T műsorszóró hálózatból érkező broadcast adás.

Gondolhatnánk, hogy digitális jel lévén könnyű dolgunk van, de gondoljunk csak bele, hogy a nap 24 órájában, a hét mind a hét napján fenn kell tartani a redundáns rögzítést.

Ha minden csatornát, amit rögzítünk csak 3 Mbps adatsebességgel jellemzünk, és tudjuk, hogy 8 csatornát szeretnénk tárolni, akkor azonnal látszik, hogy egy nap alatt 24 (óra) x 60 (perc) x (60 másodperc) x 8 (csatorna) x 3 (Mbps) / 8 (bit->byte) =~ 260 GB adat keletkezik.

Hogyan keletkezik a broadcast műsorszórásból fájl?

A bementi rendszer első körben optikai kábelen kap a műsorelosztó hálózattól jelet, melyet médiakonverter segítségével (FTTx) fordít RF kábelre (koax). Ez gyakorlatilag olyan, mintha a kábel-TV kábel végével rendelkeznénk, Ezt az RF jelet kell tudnunk rögzíteni, de mivel DTV-ről van szó, nem analóg módon rögzítjük, hanem az adatfolyamot lementjük (capture). Ehhez a CableWorld eszközeit használjuk, melyek a broadcast adatfolyamból unicast vagy multicast adatfolyamot állítanak elő, ami azt jelenti, hogy minden egyes csatornának saját IP-címe van (porttal leválasztva) amihez kapcsolódva egy recorder PC képes lementeni (capture-ni) az adatokat.

A rögzített fájl MPEG TransportStream konténerben (*.ts) rögzített, DVB-C esetén MPEG-2, DVB-T esetében MPEG-4 videó kodek, és MP2, vagy AAC hang.

Ezt a rögzített 260 GB-nyi adatmennyiséget olyan formátumra kell konvertálni, hogy a feldolgozórendszeren megtekinthető legyen, és az archivátorok ki tudják jelölni, hogy hol kezdődik és hol végződik egy műsor. Ehhez általában 1/10-re kell csökkenteni az adatsebességet, kb 26 GB-nyi streaming videó keletkezik.

Ez azt jelenti, hogy a háttéralrendszernek 8 x 24 órát kell 24 órán belül lekódolnia (különben több anyag érkezik be, mint amennyi ki tud menni az alrendszerből), vagyis 8x valós idővel kell megbirkóznia.

Ezt a feladatot a rendszerben három azonos HP GEN9 szerver végzi 12 darab v3-as Intel processzorral összesen 3 × 32 maggal.

Hol tárolódik ez az adatmennyiség?

Joggal merül fel a kérdés, hol tárolódik ez az adatmennyiség, mert egy gyors fejszámolást elvégezve, ha napi 250 GB-ot számolunk, az 4 nap alatt 1 TB, egy hét alatt 1,75 TB, ebből már következik, hogy egy hónap alatt 7,5 TB adat keletkezik.

Ilyen adatmennyiséget nem érdemes sokat fogyasztó diszkes alrendszeren tárolni (persze a feldolgozás idejére diszken tárolódik), hanem szalagos technológiára kell másolni. Itt persze nem a hagyományos DigitBeta vagy BetaSP szalagokra kell gondolni, hanem LTO-technológiára.

A témában bővebben itt (Wikipedia) lehet olvasni. A NAVA 2 522 511 GB-ot, átszámítva 2463 TB-ot, azaz nem kevesebb mint 2,4 PetaByte adatot őriz (mennyi az annyi? 529 ezer darab DVD-nek felel meg) Ezt a roppant adatmennyiséget 1100 darab LTO6-os szalagokon tároljuk.  Az LTO6 esetében 2.5 TB-ot képes natív módon rögzíteni.

Hogyan találjuk meg a kezdő és a végpontokat egy műsorszámnak?

Azzal, hogy streamelhető formátumot állítunk elő, önmagában csak egy nagyon hosszú videókat kapnánk, amiben nehézkesen lehet megtalálni egy jelenetváltást vagy műsorváltást.

Ezért minden napi felvételhez készítünk másodperces kulcsképeket, melyeket egy 6×10-es mátrixba rendezünk, és jelenítünk meg. Ezáltal egy ránézéssel el lehet dönteni, hogy az adott percben van e vágási pont vagy nincs, kezdődik-e műsor vagy sem.

Ez újabb problémát vet fel az informatikai rendszerek üzemeltetésében. Ugyanis 8 csatorna 86400 másodpercéhez készítve kulcsképet könnyen belátható, hogy a napi 1.3 millió kulcskép (kis és nagy felbontás miatt 2 x 8 x 86400) 30 napon keresztüli megtartása 40 millió kulcsképet eredményez, ami fájlrendszerszinten okoz problémákat. A fájlok mérete ugyanis pár kB, és így a fájlrendszerben történő bármiféle mozgatása, átnevezése nagyon hosszadalmas művelet, jó szervezést és időzítést kíván.

Streaminghozzáférés

Sokszor felmerül a kérdés, hiszen a leginkább mérvadó egy streamingrendszerben, hogy milyen kapacitással képes kiszolgálni a nézőket? Broadcast világban tudjuk, hogy egy adóhoz gyakorlatilag végtelen (one-to-many) néző kapcsolódhat (gondoljunk csak a DVB-T-re), viszont egy unicast (pont-pont) kapcsolat esetében, mindenkinek egyedileg szolgáljuk ki a kérését, vagyis a párhuzamos nézők száma egyenes arányban van sávszélesség igényével.

Jelenleg 3 Gbps adatkapcsolattal rendelkezünk az internet irányába, amit ha videómegtekintésre fordítunk, akkor mindenfajta technológiát mellőzve 3000 nézőt tudnánk kiszolgálni. Természetesen a streaming világában nem feltétlenül igaz ez a megállapítás (szerencsére) mivel a technológia lehetővé teszi, hogy több nézőt is kezeljünk párhuzamosan.

Általában a videoportálokat látogatók kapcsolati sebessége nem egyenlő a videó sávszélességigényével (annak jóval többszörösével is rendelkezik a user), hiszen az 1 Mbps-es videót megtekintő felhasználó egy átlagos kábeles szolgáltatótól 20-25 Mbps sávszélességgel rendelkezik.

Miért fontos ez? Ha egy ilyen user jön és kér egy videót, akkor az első 25 másodpercét a videóból gyakorlatilag 1 másodperc alatt kiszolgáljuk, azaz amíg ez felhasználó a kapott videót nézi, addig 25 másodpercig a streamingszerver más usert szolgálhat ki. Ha ezt 100 userre vetítjük, akkor az első másodpercben 100 user megkapja a 100 videójának első fél percét, a második másodpercben újabb másik 100 usert szolgálunk ki, így fél perc alatt 3000 userig jutunk el és a folyamat kezdődik elölről.

Nézzük meg, ha 100 user jön közel 100 Mbps sebességgel, akkor 100 másodpercnyi ideig nem kell a userrel foglalkozni, azaz máris 10.000 usert vagyunk képesek kiszolgálni… Persze ezek a számok elméletileg jönnek ki, a valóság valahol a kettő között van, azaz párhuzamosan 3000 és 10000 user közötti a kapacitásunk.

Persze a fenti számolásban nem foglalkoztunk azzal, hogy ezek konkurens nézők, és a viselkedéssel sem vettük figyelembe, hiszen amíg A user nézi a videót, lehet, hogy B user kilép, és helyére C user beleteker a videóba. Magas nézőszám esetében fellép a diszkolvasási sebesség kérdése, hiszen 3000 különböző videót felolvasni és kiszolgálni nem kis I/O teljesítmény.