Technológia

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édia-informatika é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 archiá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ülteé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 hiararchikus 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 (STREAIMNG)
  6. Alkalmazási réteg (FRONTEND)

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öttek 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űjétése (erről bővebben itt olvashat) ezért a fő bemeneti rendszer a DVB-C és DVB-T műsorszóló 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 kell egy redundáns rögzítést fenntartani.

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ábelTV 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 a az adatfomlyamot 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álsztva) amihez egy recorder PC kapcsolódva, 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 a 1/10-re kell csökkenteni az adatsebességet, kb 26 GB-nyi streaming videó keletkezik.

Ez azt jelenti, hogy a háttér alrendszernek 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ídővel kell megbírkó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 1 371 136 GB-ot, átszámítva 1339 TB-ot, azaz nem kevesebb mint 1,3 PetaByte adatot őriz (mennyi az annyi? 300 ezer darab DVD-nek felel meg) Ezt a roppant adatmennyiséget 700 darab LTO4-es szalagokon tároljuk, valamint 200 darab LTO6-on.  Az LTO6 és LTO4 között elsőkörben a legnagyobb különbség a kapacitása, utóbbi esetben 800 GB-ot tárol, előbbi pedig 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 előállítunk ö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ájlrendszer szinten okoz problémákat. A fájlok mérete ugyanis pár kB méretű, é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.

dtpx01

Streaming hozzáférés

Sokszor felmerül a kérdés, hiszen a leginkább mérvadó egy streaming rendszerben, 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ég igé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 streaming szerver más usert szolgálhat ki. Ha ezt 100 userre vetítjük, akkor az első másodprcben 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őrő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 számoltunk 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 diszk olvasá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.