ugrás a tartalomhoz

Közvetlen adatfolyam továbbítás

hemu · 2008. Feb. 21. (Cs), 15.28
Sziasztok!

A cím nem feltétlenül egyértelmű, ezért kifejtem, hogy mit szeretnék megoldani:
Van egy stream megoldás, ami a VideoLAN VLC nevű progijával működik.
Van a szerveren x darab USB-s webkamera.
A gépnek (debian) van egy NIC-en két IP címe.
A kamerák képét "daemon-nal" folyamatosan unicast-olom az egyik IP-ről a másikra.
Amikor a látogató rákattint egy linkre, akkor egy PHP-ból indított bash script elindít egy új vlc-t, ami "továbbsrtream-eli" az unicast adatfolyamot egy random porton. Ahhoz, hogy mindez ne csússzon 5 mp-nél többet, mms protokollon keresztül kell stream-elnem, de a vlc nem tudja az mss-en keresztüli autentikálást (http-n keresztül menne, de komoly késleltetéssel).
Most jön a lényegi PHP kérdés:
Meg tudnám oldani valahogy, hogy a script által indított vlc "kimenete" php file lenne, ami annyit tudna, hogy fogadja a streamet és bármilyen átadott paraméter (user+pass vagy IP) megállapítja, hogy a nézni kívánó jogosult-e megtekinteni az adást?
Magyarul képes-e a PHP arra, hogy egy "beleirányított" stream adatfolyamot továbbküldjön érintetlenül?

Remélem nem írtam túl összeszedetlenül!
Előre is köszi:
hemu
 
1

unicast

vbence · 2008. Feb. 21. (Cs), 16.02
És mi lenne akkor, ha rtp-t használ (udp felett)? A normál stream bejön egy daemonnak, aki az UDP csomagokat továbbdobálja a feliratkozott IP címekre.

A kiensek egy SDP fájlban megkapnák a stream paramétereit, így nem kell azokat "körhintáztatni". Ezt a streamet aztán (megfelelő codec esetén) akár quicktimeból is lehetne nézni, nem csak vlcvel. - Sőt talán WMP-vel is...

A PHP-s kérdést nem értem. Egy biztos: képes a standard inputról olvasni, és a satandard outputra írni. Innentől már csak annyi a feladatod, hogy megfelelő paraméterekkel futtasd.
2

Re: unicast

hemu · 2008. Feb. 21. (Cs), 17.15
Szia!

Köszi a tippet!
Igazából a "két" kérdés ugyanarra vonatkozik, magyarul, ha az RTP megoldja az "auth" problémát, akkor a PHP kiesik, hiszen ugyanazt a szerepet (auth) kellene ellássa mindkettő.
3

Úgy oldja meg...

vbence · 2008. Feb. 21. (Cs), 17.37
hogy kézzel autentikálod, és ezután kezded neki (is) csorgatni az udp csomagokat. (Ilyenkor persze kell valami mechanizmus, ami 1 perc inaktivitás után "kiloggolja" a usert, hogy ne folyjanak neki a végtelenségig a csomagok).

Meg kérdés, hogy milyen szintű felhasználókezelésre van szükséged. Lehet, hogy egy OpenVPN is megoldaná a problémát.
4

Huhh

hemu · 2008. Feb. 21. (Cs), 18.30
Nem mondom, hogy friss vagyok, de nem boldogulok vele.
Jól sejtem, hogy ez a dolog úgy működne, hogy ez a parancs:
--sout '#rtp{dst=192.168.10.21,port=1234,sdp=rtsp://192.168.10.23:8080/test.sdp}'
unicastolja a kliensre (192.168.10.21), annak is az 1234 portjára a streamet és erről információkat a 192.168.10.23 (szerver) 8080-as portján keresztül elérhető test.sdp file-ban tárolja?
Vagy félreértem az opciókat?
Vagy itt nincs unicast? Ebben az esetben a dst mit jelent?
5

Elvileg jó

vbence · 2008. Feb. 21. (Cs), 20.24
...azt kéne csinálja amit írsz. Ha aport nyitás valmi rejtélyes okból nem menne egy fájlba is írhatod az SDP-t, amit a normál webszerverrel szolgálsz ki.