Video streaming project

Fórumok

Sziasztok!

A velemenyeteket szeretnem kerni egy video streaming project kapcsan:
-storage-en tarolt videokat (1 video olyan 1.5 ora) kell streamelnem nagyszamu latogato reszere, webes, html5 feluletre.
Fontos a rendszer horizontalis skalazhatosaga.

Storage tekinteteben CEPH-re gondoltam magas rendelkezesre allasa, es a fent emlitett skalazhatosaga miatt (CephFs vagy RadosGw). Amiben a segitsegeteket szeretnem kerni:
-Milyen frmatumban erdemes tarolni ezeket a videokat? (Pl webm/vp9?)
-Szet lehet e szedni egy videot chunk-okra, pl 250KB - 4MB fileokra, es azokat statikusan kiszolgalni a nezok fele (a flow-t igy a html5 player kontrollalna)?
-Ha ez megoldhato, szerintetek szukseges-e a clusterre applikacios szerverek hasznalata, vagy a videokat kozvetlenul a storage clusterrel RADOSGW segitsegevel kiszornatok?
-Ha nem oldhato meg, vagy nem praktikus, akkor milyen megoldast hasznalnatok az applikacios retegen a streamek kiszolgalasara

-Milyen html5 playert javasoltok a kliens oldalra? (Kiemelten fontos a mobil eszkozokkel valo kompatibilitas).

Koszonom!

Hozzászólások

Szerver oldalra nekünk a Wowza vált be, de hozzáteszem, ha csak ondemand tartalmad van (élő közvetítés nem lesz) akkor manapság gyakorlatilag már nem nagyon van szükség médiaszerverre, kiszolgálható a (megfelelő formátumú) videófájl statikusan.

A tárolási formátumhoz kellene tudni, hogy a videók jelenleg milyen formátumban vannak. Az éppen "divatos" codec és konténer évről évre változik, tehát célszerű megőrizni a nyersanyagot, és párévente újrakódolni. (Nálunk vannak olyan forrás videók, amik az évek során megjárták a Realvideo 8, Realvideo 9, MPEG2, FLV, H.264/MP4 formátumokat)

Ha pseudo streaming van, és chunkolni kell, akkor azt manapság MPEG DASH formátumban illik. A HDS és HLS kihalófélben lévő állatfajta.

A videót nem kell szétszedni chunkokra ahhoz, hogy seekelni tudd. Elég hozzá a megfelelő metaadat, és a lejátszó tudja, hogy milyen offsettől kell tölteni a fájlrészletet.

Lejátszóprogramnak mostanság a MediaElement.js általában megfelel a célra, de persze vannak a "nagyok". (JW Player, FlowPlayer, stb.)

+1

Annyi kiegeszitessel, hogy csak HDS illet annak microsoft-os megfeleloje haldoklik.
A HLS koszoni szepen el is virul.

HLS / DASH:
tudod ugyan azokat a chunkokat hasznalni csak mas meta leiroval, igy gyakorlatilag mind a kettot tudod tamogatni.

Codec: meg egyertelmuen h264 / aac

U.i.: ha jol emlekszem a klasszikus pszeudo streaming-et a mobilos bongeszok nem annyira szeretik.

Szegmentálással csak lábon lőnéd magad.
Ma már minden modern böngészőben van html5 video lejátszás, arra optimalizálj.
Így minden olyan formátum jó, amit natívan lejátszik egy modern böngésző.

Hello,
- Videplayernek: JW player, 600$ egy évre a kereskedelmi licensz, elég jó a támogatottság.
- Ha kell drm, akkor dash/eHLS (apple miatt, de ios 11 től van dash támogatás is)
- Ha nem kell akkor sima HLS

Nem irtad mennyi videód van, és hogy tervezed-e több felbontásban streamelni.

Az eredeti minél nagyobb felbontású file-t rakd el valahova, az nem fog kelleni a streaminghez. Transkodoláshoz a handbrake zseniális cucc, egyszerübb mint az ffmpeg.

A kimeneti mp4-et pedig tudod mp4 formátumból streamelni nginx + kaltura ngninx-vod plugin

Ha szeretnéd az mp4-et még az ingest folyamat részeként hls chunkokra vágni, akkor rögtön elő is áll a szükséges sok, kis méretű file.

Amit érdemes még csinálni:
- varnish cache réteg. Ha sokan nézik ugyan azt a filmet, akkor nagyon tudja csökkenteni a disk io-t.
- ha több szervered van, akkor valahogy megoldani, hogy a cache szerverekre valamilyen sharding szerint érkezzenek a kérések, nagyobb lesz a hit ráta.

- Ha statisztikákat szeretnél akkor pedig egyszerüen nimble streamer.
---...---
TLoF

Szia!

Koszonom a valaszod!

Varhatoan nagy szamu videorol illetve megtekintesrol lesz szo, konkret szamokat egyelore nem mernek mondani ... Igazavol emiatt ragasztkodom a jo, (kozel linearis) horizontalis skalazodashoz!

Downsized verziok kelleni fognak.
Amennyiben lesz applikacios reteg a clusterben, ugy a CephFs lesz a valasztas, eddig alap teszteket vegeztem csak el rajta, de brutalis cache-elest vegez, meg az lstat muveleteket is lenyeli, adat valtozas eseten a metadata server notify-t kuld a klienseknek a cache invalidation/eviction erdekeben. A cachelt adat olvasasa (noatime eseten) konkretan nem jar halozati forgalommal meg a cache betoltes utani hoszabb ido utan se a storage cluster fele. Amennyiben ez nem lesz megse jo valami miatt, akkor a B terv ahogy javasoltad is, egy varnish megoldas lesz.

Amennyiben nem kell applikacios reteg, ugy a fent emlitett XHR keres az RGW servert es a ceph objektum azonositojat adja visza. Igy az RGW serverek valnak cache retegge.

A latogatok kiosztasara az elkepzeles az, hogy az adott filmhez XHR lekeri a kliens hogy honnan nyissa meg.
A A kiosztas pedig determinisztikusan tortenne, egyes videokat egyes szerverek fognak kiszolgalni, esetleg heatmap alapjan extrem esetben eseten tobb szerver is megkaphatja ugyanazt, ebben az esetben random elosztas tortenik a caching serverek kozott.
Ezzel a megoldassal a caching serverek szumma dram mennyiseget tudom file cache hasznalni, atlapolas nem, vagy csak minimalisan lenne koztuk.

Ez az egesz termeszetesen csak akkor tud jol mukodni, ha statikus tartalomkent tudom kiszolgalni az adatot.

A Dash / eHLS / HLS, nimble streamer temakornek mindenkeppen utana fogok nezni, koszonom!

Én 2 szintű architektúrában gondolkoznék: egyrészt a CEPH mint backend/storage, másrészt valamilyen http caching proxy mint edge. A száz lábú CEPH szerintem kevésbé lesz robusztus mint a teljesen független és szög egyszerű proxy-k, nem nyújtanám ki az edge-ig.

A konzisztens hash alapú leosztást megtartanám a proxyk között, így a ram és disk pool ott is összeadódik.

Vagy a fájlok már eleve storage-on vannak..? Mert akkor a CEPH-et totál kihagynám..

Szia!

Koszonom az az otleteket!

A kesobbi rugalmassag miatt:
-sw szinten
-a cluster cache dram mennyiseg tetszoleges novelese erdekeben
-per server komplexitas csokkentese
-layer szeparalas
-storage cluster vedelme a kulvilagtol
...jobb lesz ha ugy teszek ahogy tanacsoltad is, es kialakitok applikacios reteget a storage fele.

A storage kialakitasa is az en feladatom lesz.

Ha a cluster kesobbi fenntartasat is szemelott tartom, akkor biztosan lesz olyan eset amikor nodeok kiesnek, vagy ki kell vonni oket a production rendszerbol (hiba, csere, pugrade, frissites, energia sporolas)
Ebben az esetben konzisztens hash alapu kiosztasnal vagy kiesnenek videok, tehat nem lennenek kiszolgalva, vagy kenytelen vagyok ujraosztani a videokat a szerverek kozott (leven az oszto megvaltozott a modulo szamitashoz), a nodeok hirtelen teljesen mas fileokat szolgalnanak ki mint azelott, ez igy felerne gyakorlatilag egy cluster-wide flush cache-el.
Ez egyreszt alaposan megrangatna a storage-et, minden kiszolgalt tartalmat ujraolvasnanak az applikacios szerverek, masreszt szep nagy io waiteket jelentene az applikacios szervereken mind a cache irrelevanssa valasa, mindpedig a storagen megnott terheles miatt.
Ezt ertelem szeruen nem szeretnem.

A videokat (a distributed storageoktol ellesett) bucket rendszerben tervezem kialakitani:
-A fileokat valami* alapjan bucketekbe szervezem melynek szama mondjuk 1 nagysagrenddel nagyobb mint az azokat kiszolgalo szerverek szama.
-A bucketeket semi-persistent modon kiosztom az applikacios szerverek kozott (igazabol errol ok nem tudnak, csak az a szerver tud ami a klienseknek osztja ki az eleresi utakat a videokhoz)
-Amennyiben egy server kiesik, akkor az o bucketjei ujraosztasra kerulnek a a tobbi server kozott, igy:
--A storagerol csak azok az adatok kerulnek ujdaolvasasra ami adatokat a kiesett server szolgalt ki
--Az egyes kiszolgalo szervereken nem valtozik meg a kiosztott adat, csak kapnak plusz kiszolgalando videokat, de ez sokkal kevesbe erinti oket erzekenyen mint egy teljes flush.

* ez valami hashing alapu dolog, de nem lehet kizarolag az, leven ha valamelyik video nagyon nezett, akkor azt lehet hogy tobb bucketbe is ki kell osztanom figyelve arra hogy az adott bucketek ne legyenek ugyanarra a szerverre kiosztva.

Ezzel a megoldassal, a terhelestol fuggoen a futo szerverek szamat is dinamikusan tudom a kesobbiekben valtoztatni, hogy ne fogyasszanak tobb aramot a feltetlen szuksegesnel.

Openrestyben luaban szoktak irni az applikacios réteget. Gyors, es könnyű irni.

Amit mindenképpen érdemes belevenni:
- geo lokacio alapján tiltás
- valamilyen idő és ip alapú hashelt egyedi url az url tolvajok ellen.
- parhuzamos nézések limitalasa.

A loadbalnceren pedig van egy consistent hashing nevű megoldás.

https://medium.com/@sent0hil/consistent-hashing-a-guide-go-implementati…

---...---
TLoF

Szerintem a storage rétegnek valamilyen standard interfészt rakj, pl. S3 API, és hogy mögötte Ceph van vagy más, az a videókiszolgálás szempontjából legyen implementációs részletkérdés.

Itt van pl. Minio (http://minio.io), amivel könnyen lehet bárhol S3 API szolgáltatást csinálni.

Nekünk van tapasztalatunk relatív nagy forgalomban, bár a mennyiség nem volt nagy. Teljesen egyszerűen több vasra szórtuk szét a file-okat (rsync) és DNS round-robinnal küldtük szét a forgalmat. Applikáció az nginx is volt és 32-64G RAM kell a forgalom és videószámhoz képest, mert diszkből igen nehezen fogja bírni bármi a darálást.

Illetve jol ertem hogy a safari (macos es iphone is) csak h.264 es h.265 streameket tamogat, amik pedig licence dij kotelesek?

Csak az encoder szoftvernek kell fizetni. A néző oldalan nincs fizetesi kötelezettség.

Az ioses minden böngésző ugyan azt a render motort használja.

https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_d…

https://support.jwplayer.com/customer/portal/articles/1403653

---...---
TLoF

Szia!

> Az ioses minden böngésző ugyan azt a render motort használja.
Nagyon koszonom, hasznos informacio!

Az mpeg-la oldalan van egy h.264 licencing pdf, e szerint use casetol fuggoen lejatszasonkent vagy elofizetonkent kell fizetni nekik. A doksi elvileg 2020-ig ervenyes.
http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf

En ertek felre valamit?

Tok jol elbeszelgettek minden relativ lenyeges dologrol, csak a projekt merete es felhasznalas modja nem kerult szoba.
Azt gondolnam, hogy az hatarozza mega tobbit.