Idee um Bildschirme per WLAN zu steuern

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

• 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

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

• 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

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…?

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)