[Frage] VideoComposite > FBF per IP-Multi- oder Broadcast im WLANHeimnetz > viele Empfänger

[Schorsch63]

Hallo liebe Netzwerkfachleute,

Ich bin in der Netzwerkmaterie kein absoluter Fachmann (habe halt leider nur das übliche Allgemeinwissen) und hoffe, daß ich hier Hilfe bekomme. Ich möchte gerne ein stinknormales analoges VideoComposite-Signal (das an einer Video-Cinch-Buchse anliegt, kein Ton... der wird nicht benötigt) also ein SD-Video (kein HD) per IP-Multicasting oder IP-Broadcasting in einem WLAN-Heimnetz an beliebig vielen Endgeräten (Smartphones, Tablets etc...) zur Verfügung stellen...

Nun bin ich zumindest bei meinem Wissen schon soweit, daß ich weiß, daß

a.) es zB. mit dem Videoserver Digitus DN-16100 (eigentlich aus dem Bereich der Sicherheitstechnik) ein Gerät gäbe, das ein analoges VideoComposite Signal in digitales H.264 Videosignal komprimiert und in einem Netzwerk (LAN) zur Verfügung stellen kann. Dieser Server unterstützt die Protokolle: DDNS, PPPoE, DHCP, NTP, SNTP, TCP/IP, ICMP, SMTP, FTP, HTTP, RTP, RTSP... RTP und RTSP wäre dabei glaube ich wichtig...

b.) eine Fritzbox, dank neuer Software, per Multicast IPTV in ein WLAN-Heimnetz streamen kann... was den Vorteil hat, daß viele Geräte ohne große Auslastung der Bandbreite dieses IPTV im Heimnetz sehen können...

c.) Endgeräte (Empfänger, Smartphones...) über eine dementsprechend aktuelle Software und einen multicasting-fähigen Player (VLC-Player, GoodPlayer) verfügen sollten und dann, nach Eingabe der entsprechenden IP-Adresse, im Browser das per Fritzbox multicast-gestreamte IPTV sehen könnten...

Ich hoffe soweit sehe ich das richtig...

Zum Videoserver frage ich mich nun, ob der überhaupt ginge, da er ja eigentlich bidirektional arbeitet, d.h. er wäre eher für Sicherheitstechnik (Kameras gedacht) um per Rückkanal zB. auch Pan, Tilt, Zoom usw. einzustellen... was die Endgeräte lt. Hersteller auf max. 10 beschränken würde... Nun, ich bräuchte ich aber diesen Rückkanal nicht, mir geht es nur um ein H.264 Videosignal was die FBF per Multicast weiter streamen kann... oder müsste dieser eine Videostream, der an die FBF ginge, bereits muticastingfähig sein (???) ist ja nur einer?

Zur Fritzbox frage ich mich dann jedoch, ob man denn anstelle des IPTV's der Deutschen Telekom (Entertain) oder Vodafone, was ja mehrere Kanäle (Sender) zur Verfügung stellt, auch dieses eine H.264 Video-Signal als... hmmm... ich sag mal IPTV (mit eben nur dem einen Sender) per Multicast zur Verfügung stellen könnte...

Vielleicht ginge ja auch IP-Broadcast einfacher zu realisieren? d.h. das Videosignal allen Empfängern (Clients) innerhalb eines WLAN-Heimnetzes zur Verfügung stellen können, wenn diese die bestimmte IP-Adresse eingeben?

Ich bin da jetzt etwas ratlos... und verwirrt...

Vielleicht weiß ja irgend jemand, wie man das vielleicht elegant realisieren könnte...

vielen Dank im voraus
Jürgen

 

[PeterPawn]

Ich würde für so etwas folgende Komponenten in Erwägung ziehen:

- einen USB-Video-Grabber, der das Signal per Hardware in H.264 umwandelt und für den man einen ordentlichen Linux-Treiber (im Quelltext) auftreiben kann

- einen Raspberry Pi, an dem dieser Grabber angeschlossen wird

- auf dem RasPi direkt die Kapselung des Datenstroms in Multicast (z.B. mit VLC)

- RasPi per LAN-Kabel an FRITZ!Box

- Clients greifen auf IP-Adresse des RasPi zu

Die FRITZ!Box läßt sich nicht ohne weiteres überreden, einen Multicast-Stream nicht von der DSL-Seite zu erwarten (da ist das "mstv"-Interface angebunden) und letztlich ist es eigentlich egal, wer den H.264-Strom in MC-Pakete verpackt. Beim IPTV des DSL-Providers wird das ja auch nicht von der Box gewandelt, das kommt bereits so an. Beim DVB-C-Repeater oder der 6490 ist das allerdings etwas anderes - spielt hier aber keine Geige.

So ein Video-Grabber ist < 50 EUR zu haben, nochmal 50 für den RasPi und entsprechende Zeit investiert.

Anleitungen für "Live-Streamen" mit RasPi gibt es genug, der schwierigste Teil dürfte es sein, den wirklich passenden USB-Grabber zu finden ... aber auch da stehst Du sicherlich nicht alleine vor der Frage und inzwischen gibt es für so ziemlich jedes RasPi-Projekt eine passende Story im Netz. Wenn es keinen Grabber mit Hardware-Encoding zu einem akzeptablen Preis gibt, reicht - abhängig von der Auflösung des Eingangssignals - u.U. auch das direkte Encoding (aus /dev/video0) mit ffmpeg vielleicht schon aus - für eine "Haustür-Kamera", um zu sehen, wer da vor der Tür steht, braucht es ja nicht unbedingt 50 fps, ja nicht einmal die "üblichen" 30.
EDIT: Ja, bei "Analogvideo" sind es tatsächlich 30 fps auch nur bei NTSC, bei PAL - in D häufiger als NTSC - sind es sogar nur 25 fps und selbst die muß man beim Encoding ja nicht ausreizen ... das gibt dann eben bei der Speicherung "Zeitraffer" und beim Live-Bild Sprünge, aber je nach Anwendungsfall kann das ja akzeptabel sein, für einen Parkplatz oder einen Zugang irgendwo reicht i.d.R. schon 1 fps oder weniger.

Das ist sicherlich keine "all-in-one"- oder "out-of-the-box"-Lösung und erfordert etwas Bastelei, aber wenn man aus so vielen verschiedenen Komponenten eine eigene Lösung zusammenzimmern will, ist das nun mal mit Arbeit verbunden.

Wenn man es "aus einer Hand" haben will, nimmt man gleich eine "Netzwerk-Kamera". Die macht das alles selbst, vom Video-Grabbing über die H.264-Kodierung (in Hardware!) bis zum Senden des Streams - bessere Modelle dann auch als Multicast-Stream, wobei man das tatsächlich wieder - je nach Preisdifferenz - mit einem RasPi machen kann, solange die Ethernet-Bandbreite für den UC-Empfang und die MC-Aussendung ausreicht. Dazu braucht es dann aber ohnehin wieder die Information, welches Bildformat es ist (4K - mir ist schon klar, daß das am Cinch nicht anliegen kann - braucht eben mehr als ein "Briefmarken-Format") und bei VBR-Kodierung spielt es sogar noch eine Rolle, wieviel "Bewegung" im Bild ist (eine Parkplatzüberwachung ist etwas anderes als eine Einkaufsstraße, weil da die Differenz zwischen zwei aufeinanderfolgenden Frames einfach wesentlich anders ausfällt).

 

[Schorsch63]

Aaah, super... klingt schon mal sehr gut und einleuchtend... vieln Dank für diesen Tipp

Ich bin auch auf einen Linux-fähigen Videograbber gestossen...
Der mumbi Videograbber 2.0 soll ubuntu- und Linux-fähig sein... weil da der Chipsatz STK1160 (Syntek Semiconductor Co) drauf ist....
Zumindest haben da schon einige ein paar Projekte auch mit dem RasPi realisiert...
(gem. Amazon Bewertungen) und der Grabber ist noch dazu spottbillig...

Ja eigentlich wäre die Netzwerkkamera eine idealere Lösung, weil es die schon gibt... allerdings geht es hier nur um ein wenig bewegtes und wenig detaillreiches Video, was eben nur an dem CinchAusgang anliegt... Das direkte Encoding würde dann tatsächlich evtll schon ausreichen... Insofern müsste das mit der Konstellation tatsächlich irgendwie realisierbar sein... hmmm...

Danke erstmal...

 

[Telefonmännchen]

Vielleicht ist der Grandstream-Adapter ja auch ein Lösungsansatz für Dein Problem. >>>LINK Datenblatt<<< Dort steht was von "Integrierter, hoch leistungsfähiger Streaming-Server für bis zu 10 und mehr Videoausgabegeräte (simultan)" drin.

Gruß Telefonmännchen