Infoseite // VideoLAN über zwei Router?

Frage von Thomas Henkel:


Hi!

Von euch hat sich nicht zufällig schonmal jemand damit beschäftigt, per
VideoLAN (;genauer gesagt: VLC) von einem LAN zum anderen zu streamen, mit
zwei Routern (;fli4l, um genau zu sein) dazwischen, oder? :-)

Falls doch: Mein Problem ist, dass ich zwar eine UDP-Verbindung zustande
bekomme, diese aber ständige Bild- und Tonausfälle hat, da naturgemäß
immer wieder Pakete verloren gehen. Ich würde also gerne eine
tcp-Verbindung verwenden, um Paketverluste zu vermeiden. Nur habe ich bis
jetzt nicht herausbekommen, wie ich VLC sowohl als Streaming-Server, als
auch als Client richtig konfigurieren muss, um eine http-Verbindung
zustande zu bekommen.

Per UDP gebe ich auf der Serverseite einfach die (;DynDNS-)Adresse der
Gegenstelle an und der Stream kann problemlos empfangen werden. So weit so
gut. Aber ich glaube, mir fehlt ein grundlegendes Verständnis dafür, welche
Streaming-Adresse ich für eine *http*-Verbindung auf der Serverseite
angeben muss (;die öffentliche IP des eigenen Routers, die IP des Routers
der Empfängerseite oder gar localhost?) und welche auf der Client-Seite
(;vermutlich die Adresse des Routers der Gegenstelle, alles andere erscheint
mir irgendwie noch unsinniger?!).

Also falls von euch auch schon mal jemand mit vlc gespielt hat, würde es
mich freuen, wenn er mich an seinen Erkenntnissen teilhaben lassen würde.

Tom




Antwort von Andre Beck:

Thomas Henkel writes:
>
> Von euch hat sich nicht zufällig schonmal jemand damit beschäftigt, per
> VideoLAN (;genauer gesagt: VLC) von einem LAN zum anderen zu streamen, mit
> zwei Routern (;fli4l, um genau zu sein) dazwischen, oder? :-)

Ja, allerdings mit etwas anderen Routern dazwischen, einem IGP, PIMv2
Multicast Routing und dann natürlich als Multicast. Geht prächtig, wenn
die Bandbreite reichlich respektive das QoS LLQ korrekt konfiguriert ist.

> Falls doch: Mein Problem ist, dass ich zwar eine UDP-Verbindung zustande
> bekomme, diese aber ständige Bild- und Tonausfälle hat, da naturgemäß
> immer wieder Pakete verloren gehen.

Pakete gehen nicht naturgemäß verloren, sondern wegen Congestion und
damit verbundenen Policies. Man braucht mit Video Streaming nicht an-
zufangen, wenn man die Leistung der Strecke nicht hinreichend im Griff
hat (;garantierte Bandbreite, RTT Jitter etc).

> Ich würde also gerne eine
> tcp-Verbindung verwenden, um Paketverluste zu vermeiden.

TCP vermeidet keine Paketverluste. Es behandelt sie nur. Wenn Du also
wegen Congestion Pakete verlierst, dann wird TCP die Congestion nur noch
verschlimmern. Bei jeder mehr als sehr marginalen Rate von verlorenen
Paketen reagiert TCP äußerst störrisch und produziert sekundenlange Aus-
setzer. Genau deswegen macht man ja Streaming über UDP bzw. RTP: Wenn
ein Frame nicht vor der 1/25s angekommen ist, in der es angezeigt werden
muss, kann man es genau so gut vergessen¹. "TCP Streaming" ist eigentlich
ein Oxymoron, das höchstens durch irrsinnig lange Verzögerungs-FIFOs
brauchbar wird (;teilweise bis zu 30s), dann aber logischerweise für nichts
mehr zu gebrauchen ist außer das abdudeln von On Demand Content. Der
eigentliche Job von Streaming ist das Ausstrahlen von Live-Content so
zeitnah wie möglich und one-to-many. Dafür ist TCP in jeder Hinsicht
ungeeignet.

> Nur habe ich bis
> jetzt nicht herausbekommen, wie ich VLC sowohl als Streaming-Server, als
> auch als Client richtig konfigurieren muss, um eine http-Verbindung
> zustande zu bekommen.

Beim Sender handelt es sich offenbar um die listening address, man kann
also die IP eines seiner Interfaces angeben, um das bind(;2) zu be-
schränken. Will man auf allen Interfaces auf Connects warten, dann nimmt
man halt 0.0.0.0 (;aka INADDR ANY).

Beim Empfänger nimmt man die IP des Senders und den dort gewählten Port.

Ich hab das eben mal in 10s lokal getestet (;mit 0.0.0.0 beim Sender und
localhost beim Empfänger), ging wie erwartet.

> Per UDP gebe ich auf der Serverseite einfach die (;DynDNS-)Adresse der
> Gegenstelle an und der Stream kann problemlos empfangen werden. So weit so
> gut. Aber ich glaube, mir fehlt ein grundlegendes Verständnis dafür, welche
> Streaming-Adresse ich für eine *http*-Verbindung auf der Serverseite
> angeben muss (;die öffentliche IP des eigenen Routers, die IP des Routers
> der Empfängerseite oder gar localhost?) und welche auf der Client-Seite
> (;vermutlich die Adresse des Routers der Gegenstelle, alles andere erscheint
> mir irgendwie noch unsinniger?!).

IP des Routers? Hä? Ach Du redest von NAT-Devices am Internet? Herrje,
jetzt wird mir einiges klar. Und Du bist Dir sicher, der Upstream
vom Sender ist ausreichend dick, um irgendwas brauchbares mit Video
Streaming anfangen zu können? Von nicht vorhandener Bandbreiten-
garantie End2End mal ganz abgesehen? Viel Spaß.

Anyway, wenn es denn sein muss: Obiges Setup und beim Sender auf dem
NAT-"Router" ein Portforward zum Senderrechner, Senderport. Beim
Empfänger sollte dann http://sender-ip:1234/ out of the box gehen,
wobei sender-ip natürlich die offizielle IP der NAT-Kiste ist.

¹) Ja, mir ist auch klar, dass die Philosophie "late frames are useless
frames" im Zeitalter von Interframe-Kompressionsverfahren, die sich
teilweise über hunderte Frames hinziehen (;MPEG4), nicht wirklich aus-
reichend ist. Aber TCP ist dafür der schlechtest denkbare Ansatz -
allerdings der, welcher auch heute im Internet "in the wild" halbwegs
End2End funktioniert.

--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-