[Berlin-wireless] Audio-Teststream

[Sven-Ola Tuecke]

Hi,

mmh. Recht aufwaendig. Ich hab' mal ein bisschen mit dem olsr-bmf Plugin 
herumgespielt. Es nimmt Multicast-Pakete auf eth an und versendet diese als 
normalen Broadcast auf einem UDP Port entlang der OLSR-MPR-Kette. Die kommen 
dann ueberall als Multicast wieder auf eth 'raus. IP Adresse dann eine MCast 
addr, z.b. 224.0.0.x (Private Mcast).

Zum Abspielen hatte ich einen vls (kleiner Bruder von vlc) auf meinem 
Batterie-WAP verwendet. Fuer eine Matrix (.ts) war's da etwas eng auf dem 
Geraet, aber ein kleines Swapfile auf der sd-card half. Problem allerdings: 
Im Broad/Multicast viel zuviel Paketloss. Video ging zwar halbwegs, aber 
Audio leidet darunter sehr. Auch verursacht die geringe Datenrate sehr viel 
Netzlast (remember: fuer Xcast gibt's eine extra-Datenrate im Wifi-Treiber, 
die ist eine der Basic-Rates und defaultet zu 1Mbit dass ja sehr 'langsam' 
sendet bzw. viel Kanalzeit braucht).

Ich denk' daher, wir braeuchten eine Kombi/etwas neues und muessen es evt. 
selbst machen. Vielleicht sowas (aehnlich olsr-bmf, aber es sollte natuerlich 
spaeter auch batman faehig sein):

- Einspeisen eines (MCast) Packetstreams an einem Node

- Ein pcap-Prozess lauscht auf jedem Node auf Unicasts eine bestimmten Ports.

- Die erlauschten Pakete (wenn nicht schonmal erhalten) werden an den besten 
Nachbarn (bzw. zweitbesten wenn bester == quelle) als Unicast weitergesendet.

- Das ganze wird mit einer Parity gesichert. 2 * Daten + 1 * Parity oder so. 
Parity ist unaufwaendig zu berechnen (wenig CPU). Es gibt raffinierteres - im 
Kernel ist glaube ich sogar schon Reed-Solomon drin - aber einen 
Rechenaufwand wie bei der FEC von DVT-T werden die kleinen Dinger nicht 
schaffen.

- Somit kann ein fehlendes Paket von _jedem_ Node aus 1 Daten + 1 Parity 
wieder hergestellt werden. Das Signal wird also von jedem Node aufgefrischt 
und weitergeleitet. Evt. auch 1*Daten+1*Parity in Faellen von mehr als 33% 
Paketloss auf Unicast - obwohl so Verbindungen eigentlich hoechstens fuer 
email || ssh gut sind.

- Evt. muss so eine netzweite Ressource auch noch gegen Mehrfachnutzung 
geschuetzt werden, Evt. im Wer-zuerst-kommt-mahlt-zuerst-fuer-eine-Stunde 
Verfahren. Achso: und es wird sicher nur 'nearly live'.

// Sven-Ola

Am Mittwoch, 3. Januar 2007 01:43 schrieb Alexander Morlang:
> Joux schrieb:
> > Nachdem Sveno mich netterweise auf den icecast Streamingserver[1]
> > hinwies (siehe "Machbarkeit von Audiostreaming ins FF-Netz") hab ich
> > mich damit mal auseinandergesetzt. Der Server ist auf einem aufgeräumten
> > WRT lauffähig[2], wird über das Netz mit einem Stream versorgt und
> > verteilt diesen dann weiter.
>
> Coole sache, wenn man livestreaming machen will duerfte es allerdings
> ein paketloss/bandbreitenproblem geben. Loesen liesse sich dies durch
> mehrere verteilte streaming-server (wrts). Das ansprechen dieser gruppe
> von server koennte man anycastlike mit hna loesen:
>
> Annahme: es gibt eine gruppe streamingserver, welche den gleichen stream
> anbieten, wie sie dies machen ist nicht thema.
>
> Man definiert _eine_ ip, unter der eine gruppe streamingserver
> angesprochen wird. Jeder server bekommt diese ip zusaetzlich als
> aliasip. Diese ip announced er mit einen hnaeintrag.
>
> Am client gibt man nun diese ip an, mit dem erfolg, das der naechste
> streamingserver im mesh mit der besten metrik antwortet und dadurch ein
> minimun an bandbreite verbraucht wird mit einem maximum an qualitaet.
>
> Erweitern liesse sich das schema, in dem man im netz einen
> streamingserver stehen hat und dessen ip per hna announced wird, dann
> haetten nutzer von wolken ohne streamingserver auch zugang und in
> bereichen mit zugang wird der lokale server transparent genutzt.
>
>
> [geloescht]
>
> > joux
>
> Gruss, Alex
>
> P.S.: Ist nur ne idee, bitte darum, das konzept zu 'zerreissen' auf das
> es danach besser ist.
>
> > --
> > [1]http://www.icecast.org/
> > [2]http://wiki.leipzig.freifunk.net/Icecast
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin