Élő videóstream elosztása sok néző számára

Hálózatok általános

Sziasztok,

remélem a megfelelő topicban kérdezem, a következő feladatot kellene megoldanom:

egy eseményt kellene közvetíteni a neten sok néző számára. A videójel firewire kártyán keresztül kerülne be a gépbe ami enkódolja, magát az enkódolást a VLC végezné. Ez eddig rendben is van, viszont a VLC által legyártott live streamet el kellene osztani várhatóan 2500 néző számára.

Ki mit javasolna, csinált már valaki ilyet, esetleg tudtok ajánlani szolgáltatót, akit alvállalkozóként be tudnánk vonni a stream hálózati elosztásának lebonyolításába?

Előre is köszi minden tippet.

  • 5404 megtekintés

( bacsi2 | 2010. 11. 29., h – 20:15 )

Ustream(?)

Csak nézőként használtam, de működött.

subscribe
Az rendben van hogy a VLC képes műsorszórásra, de hogy 2500 -an kapcsolódnak rá egyidejűleg ...
Egy szerver, egy IP-n keresztül tuti nem tud ekkora forgalmat ...
Ha a sávszélességed bírja, akkor elméletileg egy szuper gyors routerrel és több háttér géppel, talán bírná.

* Én egy indián vagyok. Minden indián hazudik.

Természetesen én sem úgy képzeltem, hogy a VLC-t futtató gép fogja kiszolgálni a 2500 nézőt, pont ezért is tettem fel itt a kérdést. A VLC-s gép csak a streamet generálja, és utána ezt természetesen más hardver fogja elosztani... de hogy mi, milyen infrastruktúra kellene hozzá, ez itt a kérdés. Ez a feladat eseti jelleggel lesz, mondjuk 2-3 havonta egyszer pár órára, így nagy beruházásnak nincs értelme, ezért is gondolkodtam alvállalkozó bevonásában. A Ustream jó ötlet, teszteltem is már, és van fizetős reklámmentes verziója is, a kérdés csak az, hogy le lehet-e a Ustream logót varázsolni a képről, mert ez Corporate dolog lenne, a főnökség nem örülne semmiféle logónak. :) Gondolom a Ustream ki tud szolgálni egyszerre 2500 nézőt, bár nem tudom hogy a szervereik hol, hogyan vannak elhelyezve, és mi történik akkor, ha ennyi néző letámadja őket Magyarország irányából... 1-2Gbit sávszélesség kell hozzá ugye...

Én nem lepődnék meg, ha itt is lennének szervereik.
A logójukat fizetős szolgáltatásnál talán leveheted - ha egy "powered by XYZ" ennyire zavar valakit. Bár, talán azt is be lehet adni, hogy X összegért ott a logo, vagy X*100-ért be lehet állítani saját szervereket a célra. (VPS-ek elbírnak ilyesmivel?)

( Kayapo | 2010. 11. 29., h – 22:03 )

A vlc nem rossz ötlet, azonban az RTP streamet tud neked meg a műsorszóráshoz RTMP lesz jobb, gondolom böngészőből kell majd megnézni, tehát flash, silverlight kliens, ahhoz meg én red5 -ot javallanék ami egy opensource streaming server http://www.red5.org/

----
概略情報

Én nem ismerem a red5-t, amikor legutóbb néztem akkor még nem tudott h264-et rtmp-n adni.

Hogy hozzá is szóljak:

Attól függően, hogy mekkora a videó sávszélessége elég lehet egy gép is (az más kérdés hogy kiterheli a 1Gbit/sec-es hálót).

Ha magas a stream sávszél igénye, akkor pénz függvényében a következőkből lehet választani:

Wowza Media server
Adobe Flash Media Server
Microsoft Silverlight

Topológia választott technológiától és programtól függetlenül:

encoder (VLC) -- (RTP/WMV) -- Liverepeater -- (RTMP/WMV) -- |-- Edge Streamer 1 -- Kliens 1 ..m
|-- Edge Streamer 2 -- Kliens m+1..n
|-- Edge Streamer N -- Kliens n+1..z

A RED5-ot nem ismerem eléggé így azt nem írtam be a fenti felsorolásba.

Meglátásom szerint webes videózásnál 2 platform között kell dönteni: Flash vagy Silverlight

( Dacr (nem ellenőrzött) | 2010. 11. 29., h – 22:15 )

VLC elég erőforrásigényes, s szerver oldalon a közvetítés nem épp két klikk.
Ezzel szemben sokadik streamet gyártom ffmpeg és ffserver párosítással. Jól működik, panasz nem nagyon volt még rá.

flv-ben. A legtöbb megrendelő valamilyen flash playert tesz a weboldalára, azzal nézheti a néző.

Igénytől és sávszéltől függő a beállítás, íme egy példa:

ffserver.conf (szerver a Victor Hugo utcában)

Feed feed1.ffm
Format flv
VideoCodec flv
VideoFrameRate 25
VideoSize 720x576
VideoBitRate 72
VideoBufferSize 256
VideoQMin 10
VideoQMax 14
VideoGopSize 200
PreRoll 10
#StartSendOnKey
AudioCodec libmp3lame
AudioBitRate 64
AudioSampleRate 44100
AudioChannels 1
#NoAudio

ffmpeg kártyától függően indítható pl. így a stúdióból:

ffmpeg -i /dev/video0 http://szerverip:8090/feed1.ffm

(ez egy hardware mpeg kártyáé)

A lényeg, hogy ne csomagból fordítsd, hanem svn-ből, vagy Release-ből.
Értelem szerűen a fenti példa esetén a configure-nak adni kell --enable-libmp3lame kapcsolót.

Írtam hozzá felügyelő szoftvert is, ami egy netszakadás esetén újracsatlakozik. Pont ma készültem el a második verziójával.

Nálam sokkal kevesebb volt. Max talán 100 néző volt egyszerre. Ehhez szinte semmilyen gép nem kellett. A videokódolást egy Core2Duo 2,6-os végezte, semmi load-al. A szórás pedig bérelt VPS-en volt, aminek a pontos paramétereit most nem tudom. De nem rossz gép, tehát nem a 2000 Ft-os VPS. Ennek sem okozott gondot.

felmerült az ötlet, a kerületi TV-ben, ahol dolgozom, hogy csinálhatnánk egy arhívumot, ahonnan a néző egy flash vagy silverlight alapú lejátszóval nézhetné meg korábbi anyagainkat. gondolom több egypár gigabittes kapcsolatra van szükség és redundáns szerver arhitektúrára. A TV nézettsége 25-30000 fő körül van hetente. a napi párezres látogatottságot bíró sruktúrát milyen és eszközökkel és mennyiből lehetne kivitelezni? (törekedénk arra, hogy a legolcsóbban hozzuk ki)

a SUN-ig eljuttottam, onnantól kezdve nem tudom hogyan tovább :)

25 másodperc alatt bebufferelte az egészet nekem.
Számoljunk 2500 emberrel/nap, ha ebből 1500 nézi meg a videókat (ne adj isten többet), akkor számolhatunk durván 2000-3000 videó kiszolgálásával / nap.
Egy adást számoljunk 30-40 megára (ez durván 100Gb/nap 3000 videóval számolva).
Mivel ezek az emberek nem egyszerre vannak, számolhatunk egy 15 órás időintervallummal (az éjszakát/hajnalt nem számoljuk, így reálisabb adatot kapunk). Ha egyenletesen nézzük, ez 1900Kb/s, ami nem sok. Ha csúcsokkal is számolsz, akkor is megússza egy nagyobbacska szerver, egy 1gb-s vonalon a kiszolgálást.

minimális nagyon, szerintem egy egyszerűbb celeron gép is elviselné ezt, de biztos ami biztos, egy alap core2duo, xeon gép bőven kihajtja magából. Mivel statikus tartalomról beszélünk, ezért valami normális webszerverrel megtáplálva (lighttpd, de inkább nginx) nyugodtan vállalható.
Ami fontos, hogy normális meghajtókkal kell felszerelni a szervert, illetve jól támogatott alaplapot kell használni, mert egy rossz vinyó, egy rossz driver szűk keresztmetszet lehet. cpu követelménye szinte semmi.

de úgy értem, hogy a nagy sávszélesség kihasználása érdekében ajánlott-e Raid technikával tárolni az adatokat és ha igen,a akkor melyikkel? (raid 0,1,2...5?) illetve hogyan oldható meg a tárhely bővítése. (Raid-el még nem volt dolgom) illetve hogy az operatív tárat is be lehet-e vonni a dologba, hogy a leggyakrabban lekért videóállományokat abból küldje a kliens böngészőjének. Szeretnénk a Youtube 360p - 480p felbontásához és minőségéhez hasonló videóállományokat küldeni. Szponzorokat keresünk a dologhoz, de konkrét árat is mondanunk kell, hogy mi kell a dologhoz és mennyiből hozhatjuk ki. A főnök erősködik, hogy saját magunk oldjuk meg a dolgot.

up!

felmerült az ötlet továbbá, hogy átszervezés miatt átállnánk teljesen nem élőszerű internetes sugárzásra (a néző választhatja ki, hogy mi akar nézni) indítanánk nem csak kerületről szóló műsorokat is (a leendő szponzorok nagyon nagy valószínűséggel reklámoznának is), így nekik is minél nagyobb nézőszámra van szükségük ehhez és nem utolsó sorban számít a képminőség is. ebben az esetben milyen konfigurációra lenne szükségünk?

mivel statikus alomanyok kiszolgalasarol van szo, a gep alapparameterei nem feltetlen szamottevoek (nincs adatbazis muvelet, kodolas, enkodolas), igy prociban nem kell elrugaszkodni nagyon. A fontos egy nagyobb, kis kesleltetesu memoria a surun megtekintett dolgok cachelesere, illetve egy gyors, akar SAS disk rendszerre a tobbi file, gyors kiszolgalasahoz. Persze rugalmassagi okokbol celszeru joval tulmeretezni a rendszert, egeszen odaig, ami utan mar uj szerver beuzemelese a kezenfekvo.

A legtöbb szerver OS így működik, így igen, a Windows Server is (kivéve, ha letiltod a funkciót ugye).

If the server has a large amount of available system memory, the operating system can maximize the use of file buffering and minimize the effects of data source throughput bottlenecks.

Amiket készítettem:
2 magos proci a szerveren, 100 megás kapcsolaton csücsül. A stream úgy 110-120kbps képpel-hanggal. Én lekorlátoztam a szervert 300 nézőre, mert azon szerver mást is csinál, illetve kerületi és regionális TV-k lévén nem nagy az érdeklődés (maxunk eddig 100 néző volt kb.), de még így is épp csak megmozdul a proci.

Milyen minőségű stream kell? Ez az első kérdés, de szerintem ki lehet ezt számolni, nem bonyolult képlet.

( yorkeetech | 2010. 11. 30., k – 09:25 )

Nem akarok nagy baromságot írni, mert én csak nézni szoktam ilyesmiket, de ha ilyen sok néző akad, akkor talán p2p alapú streamben kellene gondolkodni. Sopcast például?
De csak ötlet volt.

----------------
...jönnek a gépek, a szemükben nincs harag...

+1 p2p

de sopcast pl, kell hogy legyen minden kliensen hogy tudja adni/venni az adást, szóval macera 2500 embernek megmondani mit és hogyan telepítsen ha nézni akarja...

inkább Adobe rtmfp tudja a p2p-t, ezáltal a böngészőben a kis flash player egyben szórja is az adatot, és nem kell kliensen semmiféle plusz program... csak egy szerver ami ismeri ezt a módot(red5 is ismeri már tudtommal)

De szerintem neked még mindig a ustream a legegyszerűbb megoldás, nekik van elég kapacitásuk ezt kiszolgálni, ha jól tudom nyáron webes vb közvetítés is rajtuk ment át, szóval bírják... és nem kell vacakolni a red5 beállításokkal!

S.

Legalább ne írj marhaságot...
Utánanéztem, és amiről te beszélsz az a RTMFP (Real Time Media Flow Protocol). Ez nem a klasszikus p2p-re való pláne nem abban az esetben, amikor központi szerverről kell live streamet kitolni.

Ráadásul csak akkor működik, ha valamelyik fél aktív (rendesen beállított NAT/firewall mint a bittorrentnél).

http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol
http://flashrealtime.com/tuts/p2p-in-flash.html
http://justin.everett-church.com/index.php/2008/05/23/astrop2p/

( turdus | 2010. 11. 30., k – 09:34 )

Én jobb szeretem a homogén rendszereket, ha már VLC benne van a pakliban, szerintem azzal old meg. Ha a több szerver eleve szóbajött, akkor a következő topológiát javaslom, ami könnyen skálázható:

(forrás)--(encoder szerver vlc-vel ENC)==(átjátszó vlc szerver BST)==LB--(kliensek)

Azaz az encodolást elvégzi egy gép, az ENC, ehhez kapcsolódik mondjuk 2-3 BST szerver, amire meg beesnek a userek. Ha kevés a sávszél, beraksz még egy két BST szervert (lehet VPS is, mivel nem kódolod az adást, bőven elég). A kliensek mit sem látnak az egészből, mert a load balancer szórja szét a BST-t között egyenlően a forgalmat (ez lehet mondjuk round rubin DNS resolve, mint amit a google használ a gmail-nél, de akármi más is).

Előnye: egy proggival (amit már ismersz, ne felejtsük el) megoldod az egészet, és menet közben tudod növelni a sessionök számát.

Hátrány: kell egy kis DNS konfigurálás, és több szerver.

+1 ennek a megoldásnak. A dns round robin jó megoldás, viszont az flv-ből kiindulva jó esélyel weblapba lesz ágyazva a rendszer. Ha 2 percenként lekérdezed a szerverek állapotát, és mindig a legkevésbé terhelt szerverrel eteted meg a flashplayert, akkor egy viszonylag egyenletes eloszlást kapsz a szerverek között

( pba | 2010. 11. 30., k – 13:59 )

Éjjel átgondoltam a dolgot, és a topic indítójaként leírom, mire jutottam/tunk. Ekkora nézőszámot egy szerverrel nem lehet épkézláb módon kiszolgálni, legalább kettő kell, vagy külön szerverteremben elhelyezve, vagy combosabb vonalat, infrastruktúrát tudó szolgáltatónál. A nézőket tényleg dinamikusan kellene szétosztani a két szerver között, stb. Viszont ilyen alkalmi közvetítésnél, ami csak 2-3 havonta egyszer fordul elő, nem érdemes két szervert kipakolni a BIX-be, ezt tényleg alvállalkozóval kell megoldani. A Ustreames társasággal próbálunk meg bizniszelni, meglátjuk, mire jutunk.

Mindenkinek köszönöm a javaslatait, annak ellenére, hogy nem önerőből fogjuk megoldani a dolgot, nekem hasznos technikai infók voltak a hozzászólásokban. :)

( SCOPE | 2010. 12. 10., p – 00:07 )

Elnézést kérek a bepofátlankodásért,
engem is érdekel a téma, bár én komoly (min 1 GB/s)
netkapcsolat híján az USTREAM-ot választom,
és az a kérdés, hogy van-e valamiféle program,
amivel adni lehet ott, mert az ő böngészős, Adobe-s
appletüktől keményen fagy még egy 3.2 Ghz celeron is
proc 1.5 Gb meoriával, és a gépvásárlástól eltekintenék.

Van-e ötlete valakinek ?

( Admah | 2010. 12. 10., p – 09:13 )

Nem tudom él-e még a kérdés, ha igen:
Nov. 30-án nyomattunk párezer usernek egy webcastot a livestream rendszerével. Embeddelve nincs branding, simán nyomható. Igaz az csak egy ppt+audió volt, de szerintem elviszi a videostreamet is.
eredmény: http://www.youtube.com/watch?v=t8NNO0IxbGI

Ha nem él a kérdés már: milyen megoldást használtál végül?
-------------
I don't want to achieve immortality through my work... I want to achieve it through not dying. - Woody Allen

Végül a közvetítés maga nem jött létre, legalábbis most nem, de a későbbiekben ismét fel fog merülni. A Ustream mellett tettük le a voksot, ahogy korábban írta is valaki, létezik belőle unbranded verzió, igaz, nem olcsó a dolog, de alkalmi jelleggel jó lehet. Egy ismerősöm használta ezt az unbranded verziót többezres közvetítéshez itthon, is minden abszolút simán működött, csak jót tudott mondani róla. Tehát jelenleg a Ustream tűnik a feladathoz a legéletképesebb alternatívának, lehet hogy van olcsóbb, de az viszont nem ilyen üzembiztos. Egyébként több hazai cégtől kértem a dologra árajánlatot, beszéltem velük telefonon is, és a hazai viszonyokra jellemző módon végül SENKITŐL nem érkezett konkrét válasz, ajánlat e-mailben. Ez mondjuk azért fura... volt köztük kifejezetten streaminggel foglalkozó cég is. :) Hát nem tudom, hol élnek ezek egyébként, ha én 2 napon belül nem adnék konkrét anyagot az érdeklődő ügyfélnek, úgy fejbecsapnának, hogy ihaj...