Idee um Bildschirme per WLAN zu steuern

with tags Gadget Hardware Open Source Technik - Sunday, October 6, 2013

Hier mal meine Gedanken zu Video-Streaming, die ich schon ein paar Wochen sammel. Das soll momentan weniger ein vollständig ausgereiftes Konzept sein, als vielmehr ein alternativer Ansatz als Diskussionsgrundlage. Vlt. übersehe ich ja auch was völlig grundlegendes und das alles ist überhaupt nicht machbar. Wenn ja, kann man mich natürlich wie immer in den Kommentaren oder via IRC darauf hinweisen.

Seit Jahren basteln Leute vergeblich daran irgendwie DAU-Tauglich kleine Media-Quellen wie Telefone, Spielekonsolen oder ähnliches mit Bildschirmen zu verbinden ohne großen Kabelsalat zu benötigen.

Aktueller Stand

Da gibt es die abenteuerlichsten Konstruktionen, so z.B.:

DLNA mit seinem UPnP-Unterbau

Chromecast was das selbe tut, aber nicht einmal Video-Daten überträgt sondern nur URLs zu selbigen

Miracast

AirPlay (das selbe wie Miracast, aber natürlich Apple-Only)

oder WiDi (funktioniert natürlich nur mit Intel "Arrandale"-CPU, Intel-WLAN-Modul und Windows 7, wurde zu recht von Intel zugunsten Miracasts aufgegeben)

Probleme

Jetzt gibt es da einen rießengroßen Haufen Probleme die dabei auftreten.
Alle dieser Ansätze bauen z.B. auf Auto-Discovery-Mechanismen alá UPnP auf, die Zielgeräte schreien also alle paar Minuten per Multicast ins Netz dass sie verfügbar sind und wenn man es ganz eilig hat, kann man auch ins Netzwerk fragen ob solche Geräte vorhanden sind und die Geräte melden sich.
Das bedeutet einerseits dass man ständig Multicast-Traffic nach 239.255.255.250:1900 (oder bei v6 [FF0?::C], wo ? je nach Scope 2,5,8 oder E ist) wirft, andernseits aber auch dass man immer ein Paket abwarten muss oder ein paar dutzend Antworten verarbeiten muss wenn man händisch nachfragt.
Schlimmstenfalls landet man in einer Situation für die man eine Liste von 100 Geräten mit ähnlichem Namen bekommt, ohne jeglichen Hinweis welches das gerade gesuchte ist oder auch nur welches der Geräte überhaupt im gleichen Gebäude steht. Man stelle sich nur mal eine größere Firma vor in welcher 100 Fernseher einer Firma auf 100 Räume verteilt wurden!

Wenn man dann jedenfalls endlich das richtige Gerät gefunden hat, steht man noch immer vor dem Problem wie denn die Videodaten übertragen werden sollten.
Bei Miracast, AirPlay und WiDi wurden Codecs definiert (meist natürlich nur die schlimmstmöglichen, sprich die sowohl proprietären UND minderqualitativen, als Pflicht vorrausgesetzt und wenn man ganz viel Glück hat, kann das Endgerät noch eingeschränkte Subsets eines teueren, proprietären Codecs, welcher nicht ganz so üble Qualität liefert). Wenn man sich dann also auf einen Codec geeinigt hat, fängt man an alle Ausgaben in diesen umzuwandeln (was meist auch noch zu mehr verwendeter Bandbreite, sinkender Qualität und eigentlich immer zu deutlicher Laststeigerung auf sendender Seite führt).

Das klingt total übel, aber bei DLNA wird das sogar fast noch schlimmer… da gibt es eigentlich nur MPEG2/JPEG/MP3 als verpflichtende Codecs und wenn man irgendwas anderes an das Zielgerät senden will, muss man davon ausgehen dass dieses den Codec einfach nicht kann. Da steht man dann vor der Wahl das doch alles umzuwandeln oder die Hände über den Kopf zu werfen und aufzugeben.

Bei Chromecast hingegen darf man sich überlegen wie man aus dem aktuellen Inhalt eine URL baut. Klarer Zielfall ist in Google-Sichtweise wohl sicherlich die einfache YouTube-URL, für welche das keinerlei Problem darstellt. Schon bei Webseiten wird das aber kritisch, da die Zielgeräte nicht gerade sonderlich viel Leistung und RAM bieten. Wenn ich ein lokales Video auf diese Art teilen will, endet das ganze auf äußerst enttäuschende Art und Weise (wobei es Leute gibt die da an einer Notlösung der Marke "Server starten und URL zu selbigem senden" bauen).
Kurz: Hauptprobleme ist an dieser Lösung sind schlicht dass man immer einen ziemlich umfangreichen Rückkanal braucht und sehr stark von den Fähigkeiten des Zielgerätes abhängig ist.

Alternativer Ansatz 1: NFC

Die "einfache" (oder eher "moderne") Art das zu verbessern wäre sicherlich sowohl in Ziel als auch Quelle jeweils einen kleine NFC-Antenne einzubauen und z.B. das Telefon kurz an den Bildschirm zu halten um eine Verbindung herzustellen.

Natürlich wäre das zusätzliche Hardware
an welche Stelle eines größeren Bildschirms man das Telefon halten soll muss man dem Nutzer auch noch irgendwie begreiflich machen
dass das mit einer angesteckten Spielekonsole als Quelle nicht tun will sollte auch klar sein

Trotzdem: es wäre zumindest für die erkennung des Zieles in bestimmten Fällen eine brauchbare Ergänzung zu UPnP.

Neuerdings gibt es ja auch schon einige Bluetooth-A2DP-Geräte, welche auf diese Art ein Pairing durchführen und natürlich könnte man für diesen Zweck auch relativ problemlos NFC durch andere, lokal eingeschränkte Kommunikationsformen ersetzen. Z.B. einen Strichcode auf dem Zielgerät (Problem: auf der Vorderseite störend, auf der Rückseite nicht lesbar?) oder das langsam mit BT4.0 aufkommende Low-Energy-Profile von Bluetooth selbst (Wenn Bluetooth jetzt noch schnell genug für ernsthafte Videoübertragung wäre…).

Alternativer Ansatz 2: IR

Ja ich weiß… Infrarot-Datenübertragung ist eine mindestens 20 Jahre lang veraltete Technologie. Darum bekommt man die passenden Bauteile ja auch so billig. Also zumindest Teilweise…
Als Empfänger würde ich aber (wie ja jetzt schon häufiger gesehen) einen Kamera-Chip verwenden (das dürfte wohl der teuere/aufwändige Teil sein, evtl. könnte man aber auch bereits in Telefonen eingebaute Kameras dazu verwenden).

Dann bauen wir 4 IR-LEDs in die Ecken des Bildschirmes.
Zur Unterscheidung verhalten diese sich leicht unterschiedlich, z.B. so:

rechts unten ist konstant an

links oben gibt Taktsignal

eine dritte sendet Steuer-URL in Endlosschleife

die verbleibende kann man sich als möglichen Rückkanal in späteren Versionen erstmal vorhalten und auch nur im Takt irgendein "keine Daten"-Signal senden lassen

Das Telefon erkennt mittels IR-Kamera die Position und Ziel-URL des Bildschirms, kann von dort die benötigten Codecs abrufen und Steuerdetails aushandeln.
Die eigentliche Steuerung des Bildschirms erfolgt dann via WLAN oder Ethernet, die URL über welche das geschehen soll kennt man ja jetzt.

Vorteile:

mit dem Telefon drauf zeigen identifiziert das Ziel (keine lange Liste mit gleichen Namen)

UPnP oder ähnlicher Dreck ist nicht länger nötig, aber man kann es natürlich trotzdem parallel verwenden (z.B. für fest installierte Quell-Geräte ohne IR-Sensor, zu hohe entfernung oder )

ein Telefon kann als ziemlich gute Air-Mouse fungieren (IR-Position und meist eh vorhandener Gyro-Sensor sollten ausreichen, Steuer-Informationen braucht man nicht übertragen, da die Video-Daten eh vom Telefon kommen)

Und dann…?

Dann streamen wir! Leider haben wir das Problem ob nun Bildschirminhalt encoden und als Stream senden vs. Videodateien einfach nur übers Netzwerk schicken und das decoding vom Empfänger erledigen lassen noch nicht gelöst.

Natürlich will man auch nicht immer nur Videos im Vollbild-Modus übertragen, also braucht man einen einfachen Codec der auf leichtes packen optimiert ist. Bandbreite ist in den meisten Fällen eh eher von geringerem Interesse. Trotzdem sollte es kein totaler Blödsinn sein, welcher abgesehen von diesem speziellem Anwendungsfall nie irgendwo verwendet wird (Ich sehe dich an "Bluetooth A2DP").
Und: Wofür gibt es freie Codecs?

Damit aber aufzuhören ist dann genauso albern.
Mindestens 3-4 der häufigsten Videocodecs sollten auch unterstütz werden oder zumindest unterstützbar sein, man kann ja Geräteklassen oder gar einen vernünftigen Aushandlungs-Vorgang einbauen (Wer nichts außer minimal-nötiges unterstützt, kann sich dann halt einen alternativen Aufkleber aufs Gerät pappen alá "Mediasharing-Foo Base-Profile" vs. "Mediasharing-Foo Extended-Profile")

Wenn der Bildschirm dann z.B. sagt dass er kein 1080p WebM kann, kann man noch immer auf den Basis-Modus zurückschalten und die Inhalte neu codieren, aber wenn er es kann spart man sich Rechenleistung/Netzwerktraffic/Qualitätsverlust und nicht zu letzt Akkulaufzeit.

Wenn man dann noch GANZ vorbildlich sein will, implementiert man einen "Fenster-Modus", bei welchem man einen primären Stream (Desktop-Inhalt) darstellt, an bestimmten Koordinaten aber einen sekundären Stream überlagert (z.B. Videoplayer-Fenster mit WebM-Film)