VLC-Stream ins LAN

Ich besitze noch eine relativ große DVD-Sammlung, allerdings habe ich (in Zeiten von Video-on-Demand-Streaming) schon lange keine DVD mehr angesehen. Selbst der DVD-Player/Recorder ist nicht mehr angeschlossen. An dessen Stelle ist eine HDMI-Weiche mit einem Mini-PC und einem Raspberry-PI getreten. Ich kann mich nicht erinnern, wann ich zuletzt eine DVD aufgenommen habe… Schade eigentlich, denn die Technik hat gut funktioniert.

 

Trotzdem wollte ich mal wieder eine DVD ansehen, weil dieser Film im Streaming nicht verfügbar war oder hätte gekauft/gemietet werden müssen. Alles neu verkabeln wollte ich aber auch nicht. Allerdings besitzt mein Arbeits-PC noch ein DVD-Laufwerk und der Mini-PC ist über LAN angebunden. Meine Idee war, das DVD-Laufwerk einfach freizugeben und der Mini-PC öffnet über den VLC-Player diesen Ordner und gibt die DVD aus. Leider musste ich schnell feststellen, dass es zwar technisch gehen sollte, aber wegen des Kopierschutzes trotzdem nicht geht.

Einhellige Antwort auf dem Internet ist, man sollte DVDs ins Netzwerk streamen.

 

tl;dr

Nutzen Sie für das Streaming mittels VLC:

  • Server: HTTP-Protokoll
  • Server: TTL von > 1 wenn der Stream geroutet werden muss
:sout=#transcode{scodec=none}:http{mux=ts,dst=192.168.0.1:1234/,ttl=10} :sout-all :sout-keep
  • Client: Network-Caching: 2.500ms
http://@192.168.0.1:1234/

 

VLC-Stream

Dabei gibt es einige Vorüberlegungen, will man über:

  • Unicast
  • Multicast

streamen? Und muss der Stream ggf. geroutet werden (wenn Sender und Empfänger nicht im gleichen VLAN sind). Nicht jeder Router kann zudem Multicast routen und wenn man sich generell mit Multicast beschäftigt, sollten Themen wie IGMP-Snooping oder IGMP-Querier bekannt sein.

Dann stellt sich die Frage ob man TCP oder UDP nutzen möchte. Ich musste herausfinden, dass nicht jede Kombination möglich ist.

mögliche Streaming-Protokolle in VLC

Getestet habe ich:

  • HTTP
  • MS-WMSP (MMSH)
  • RTSP
  • RTP / MPEG Transport Stream
  • RTP Audio/Video Profile
  • UDP (Legacy)
  • Icecast

Dabei habe ich folgendes festgestellt:

 

HTTP
  • Unicast
  • TCP
  • Server/Client
  • funktioniert problemlos im WLAN
  • Clients können sich nach Stream-Start zuschalten

 

Läuft auf dem Sender/Server auf dem definierten Port. Mehrere Unicast-Verbindungen können hergestellt werden.

 

Sender (Unicast, Server ist 192.168.0.1, Port 1234):

:sout=#transcode{scodec=none}:http{mux=ts,dst=192.168.0.1:1234/,ttl=10} :sout-all :sout-keep

 

Auf jedem Empfänger (Unicast, Server-IP 192.168.0.1 und Port 1234):

http://@192.168.0.1:1234/

 

MS-WMSP (MMSH)

Das Microsoft-Windows-Media-Streaming-Protocol:

  • MMSH (Microsoft Media Server over HTTP)

 

  • Unicast
  • TCP
  • Server/Client
  • funktioniert problemlos im WLAN
  • Clients können sich nach Stream-Start zuschalten

 

Läuft auf dem Sender/Server auf dem definierten Port. Mehrere Unicast-Verbindungen können hergestellt werden.

 

Sender (Unicast, Server ist 192.168.0.1, Port 1234):

:sout=#transcode{scodec=none}:std{access=mmsh,mux=asfh,dst=192.168.0.1:1234,ttl=10} :sout-all :sout-keep

 

Auf jedem Empfänger (Unicast, Server-IP 192.168.0.1 und Port 1234):

mmsh://@192.168.0.1:1234

 

RTSP

Hat in keinem Test funktioniert!
Wenn es jemand zum Laufen gebracht hat, bitte Kommentar wie!

 

RTP / MPEG Transport Stream
  • Unicast oder Multicast
  • UDP
  • ähnlich P2P
  • funktioniert im WLAN bei Multicast ggf. nicht!
  • bei Unicast können sich keine weiteren Clients nach Stream-Start zuschalten

 

Sendet an eine Unicast- oder an eine Multicast-Adresse auf dem definierten Port.

 

Sender (Unicast an die IP 192.168.0.11, Port 1234):

:sout=#transcode{scodec=none}:rtp{dst=192.168.0.11,port=1234,ttl=10,mux=ts} :sout-all :sout-keep

Sender (Multicast an die Gruppe 239.255.0.1, Port 1234)

:sout=#transcode{scodec=none}:rtp{dst=239.255.0.1,port=1234,ttl=10,mux=ts} :sout-all :sout-keep

 

Empfänger – PC mit der 192.168.0.11 – (Unicast, Port 1234):

rtp://@:1234

Auf jedem Empfänger (Multicast, Port 1234):

rtp://@239.255.0.1:1234

 

RTP Audio/Video Profile

Hat in keinem Test funktioniert!
Wenn es jemand zum Laufen gebracht hat, bitte Kommentar wie!

 

UDP (Legacy)
  • Unicast oder Multicast
  • UDP
  • ähnlich P2P
  • funktioniert im WLAN bei Multicast ggf. nicht!
  • bei Unicast können sich keine weiteren Clients nach Stream-Start zuschalten

 

Sendet an eine Unicast- oder an eine Multicast-Adresse auf dem definierten Port.

 

Sender (Unicast an die IP 192.168.0.11, Port 1234):

:sout=#transcode{scodec=none}:udp{mux=ts,dst=192.168.0.11:1234,ttl=10} :sout-all :sout-keep

Sender (Multicast an die Gruppe 239.255.0.1, Port 1234)

:sout=#transcode{scodec=none}:udp{mux=ts,dst=239.255.0.1:1234,ttl=10} :sout-all :sout-keep

 

Empfänger – PC mit der 192.168.0.11 – (Unicast, Port 1234):

udp://@:1234

Auf jedem Empfänger (Multicast, Port 1234):

udp://@239.255.0.1:1234

 

Icecast

Hat in keinem Test funktioniert!
Wenn es jemand zum Laufen gebracht hat, bitte Kommentar wie!

 

Fazit

Am einfachsten und am wenigsten problembehaftet sind HTTP oder MS-WMSP (MMSH). Wobei bei mir HTTP am synchronsten war was Bild und Ton angeht. Generell sollte das Netzwerk-Caching von 1.000 ms auf 2.500 ms vergrößert werden.

Bei beiden Protokollen können sich beliebig Clients auch nach dem Start des Stream „zuschalten“. Das Routing ist Unicast-üblich und WLAN stellt kein Problem dar*. Etwas unschön ist nur, dass für jede Verbindung zum Sender eine eigene Unicast-Verbindung aufgebaut wird. So skalierbar wie Multicast ist das nicht, aber im Heimnetz sollte es völlig unerheblich sein. TCP hat aus Protokollgründen einen größeren Overhaed, wobei mir persönlich der Ton besser (synchroner) vorkam als bei UDP. Damit war der Ton manchmal leicht versetzt zur Lippenbewegung.

 

Bitte beachten Sie, dass in den String von mir immer „ttl=10“ eingefügt wurde. Normalerweise setzt VLC immer eine TTL von „1“. Damit ist kein Routing möglich, da jeder Router von der TTL 1 abzieht und bei 0 das Paket verwirft. Mit Mikrotik kann das in der Prerouting-Chaing (Mangle) abgefangen werden:

/ip firewall mangle
add action=change-ttl chain=prerouting dst-address-type=multicast in-interface-list=!DMZ-VLANs new-ttl=set:10 passthrough=no src-address-list=reserved-IP-Range ttl=equal:1

 

* WLAN stellt abhängig von der genutzen Hardware ein Problem dar, da Multicast u. U. nur in der langsamsten Geschwindigkeit übertragen wird. Bei Mikrotik ist z. B. (Stand heute, ROSv7.15.3) nur der alte (Wireless, CAPsMAN alt) „Multicast-Helper“ funktional. Der neue (WiFi, CAPsMAN neu) „Multicast-Enhance“ ist ohne Funktion! Gut zu beobachten, wenn zwei Geräte mit je einem alten und einem neuen CAP verbunden sind – ein Stream klappt einwandfrei, der andere ist nur Müll weil der Stream so langsam übertragen wird.

 

Shortcut

Wen Sie ein festes Laufwerk nutzen, können Sie auch eine Verknüfung anlegen, damit wird der Streaming-Server mit allen Einstellungen automatisch gestartet:

"C:\Program Files\VideoLAN\VLC\vlc.exe" dvdsimple:///D:/ :sout=#transcode{scodec=none}:http{mux=ts,dst=192.168.0.1:1234/,ttl=10} :sout-all :sout-keep

Für den Client:

"C:\Program Files\VideoLAN\VLC\vlc.exe" http://@192.168.0.1:1234/ --network-caching=2500 --fullscreen

Es müssen ggf. angepasst werden:

  • der Pfad zur vlc.exe
  • der Buchstabe des DVD-Laufwerks
  • die IP-Adresse des Streaming-Servers

 

Referenzen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert