Original-URL des Artikels: https://www.golem.de/news/konferenzen-warum-hdmi-praesentationen-nie-funktionieren-1710-130856.html    Veröffentlicht: 27.10.2017 15:08    Kurz-URL: https://glm.io/130856

Konferenzen

Warum HDMI-Präsentationen nie funktionieren

Neben dem Kabelgewirr macht oft auch die Hardware die Verwendung von HDMI-Verbindungen zu einer leidigen Erfahrung. Ein Cisco-Entwickler berichtet von seinen größten Problemen mit der Technik.

Für die Videokonferenzplattform Spark von Cisco arbeitet der Entwickler Hans Verkuil an der eigentlichen Schaltzentrale des Systems, dem Spark Codec Plus. Daran werden die Kabel für die Video-Ein- und Ausgänge der verschiedenen anderen Geräte der Teilnehmer angeschlossen. Das vom Nutzer gewünschte Plug-and-Play der HDMI-Kabel bereitet Verkuil und seinem Team jedoch einige Probleme, wie er auf dem Open Source Summit in Prag berichtet.

Verkuil bezieht sich dabei aber nicht hauptsächlich auf die verschiedenen HDMI-Kabel und -Versionen sowie damit verbundene Schwierigkeiten. Stattdessen beschreibt der Entwickler die Hürden, die sich aus der Verbindung von zwei verschiedenen Geräten über das Kabel ergeben. Dass das Spark-System dabei prinzipiell darauf ausgelegt ist, mit nahezu jeder beliebigen Hardware genutzt zu werden, die über HDMI-Anschlüsse verfügt, macht die zu lösende Aufgabe nicht einfacher.

Kabel- und Formatwirrwarr

Für die Beschreibung der Erfahrungen mit Spark beschränkt sich Verkuil vor allem auf die Erfahrung mit der Umsetzung der 4K-Videoqualität und muss dafür zunächst doch auch auf die verschiedenen HDMI-Kabel zu sprechen kommen, da diese unterschiedliche Video-Encodings übertragen können.

HDMI unterstützt neben RGB auch das in Videocodecs verwendete YUV mit den Subsamplings 444, 422 sowie 420. Mit dem HDMI-Standardkabel kann bei 148,5 MHz Übtragungsfrequenz und TMDS-Encoding ein 4K-Video im Format YUV-420 bei 30 Hz übertragen werden. Das reicht zumindest theoretisch für das Abspielen einer UHD-Bluray.

Für die Übertragung von 60 Hz bei 4K YUV 420 braucht es schon HDMI-High-Speed-Kabel mit 297-MHz-Timings. Diese Formate unterstützen wiederum aber viele PC-Monitore und Displays nicht gut, sodass vor allem wegen des Subsamplings von YUV das Bild verschwimmen kann.

Auf PC-Monitoren wird üblicherweise der RGB-Farbraum genutzt. Um hier 4K-Inhalte übertragen zu können, müssen entweder 30 Hz (bei High-Speed-Kabeln) oder die neuen Premium-High-Speed-Kabel mit 594-MHz-Timings für 60 Bilder in der Sekunde genutzt werden. Letzteres geht nur ab HDMI 2.0.

Das Problem für Verkuil ist, dass das Übertragen mit diesen Eigenschaften nicht nur wie beschrieben von der richtigen Kabelwahl und der Signalqualität abhängt, sondern auch von der Hardware an beiden Enden, deren Treibern sowie vollständiger HDMI-Unterstützung.

Vor allem das zuletzt beschriebene 4K-RGB-60-Hz-Signal beschreibt Verkuil als die Grenze des zurzeit Machbaren. Hier könne vor allem bei den Timings, aber auch bei den Spannungen und letztlich den Signalen viel schiefgehen. Raum für Fehlertoleranzen sei jedoch kaum vorhanden.

Kommunikation Hardware zu Hardware

Die Auswahl des richtigen Übertragungsmodus geschieht dabei unter anderem mithilfe des sogenannten EDID. Quelle und Ziel können sich damit idealerweise über ihre Fähigkeiten verständigen. Nur passiert das laut Verkuil zu oft nicht richtig, was zu üblem Bildflackern führen kann.

Besonders schwierig im Umgang mit EDID sei die Implementierung von Apple. Der Hersteller liest die Information nicht wie alle anderen in 128 Byte großen Blöcken aus dem EEPROM, sondern versucht dies per Random Access. Das Ergebnis sei dann aber einfach nicht verwertbar, so Verkuil.

Ebenso erlaubt die HDMI-Spezifkation das Senden von Null-Paketen, was unter Umständen hilfreich für das Senden von Daten sein kann. Die meisten Hersteller von Fernsehgeräten unterstützen das aber einfach nicht und verwerfen diese Information bestenfalls.

Und im nächsten Schritt muss dann das Problem der Farbwahl gelöst werden, was sich einfacher anhört, als es tatsächlich ist.

Schöne bunte Quantisierung dank kaputter Treiber

Ein wichtiger Teil des Spark-Konferenzsystems ist die Verwendung für Präsentationen. Dabei sollte laut Verkuil das RGB-Farbschema genutzt werden, da der für die Präsentation als Quelle genutzte Rechner ja ebenfalls RGB nutzt. Die Anzeige auf einem großen externen Gerät läuft so im Idealfall farbecht ab.

Jeder Farbkanal (Rot, Grün und Blau) nutzt bei dem üblichen True-Color-Modus 8 Bit, also 256 Abstufungen und damit zusammen rund 16,78 Millionen Farben. Die Quantisierung der Abstufungen in der Digitaltechnik kann die Zustände 0 - 255 nutzen (Full Range). Für die ältere Analogtechnik muss jedoch eine Toleranz gegen Spannungsspitzen einkalkuliert werden, sodass hier nur die Werte 16 - 235 genutzt werden (Limited Range).

Wird vom Endgerät aber fälschlich Full Range als Limited Range interpretiert, wechselt etwa die Farbdarstellung von einem leichten Grau hin zu Weiß. Bei Anwendungen mit Tabellenkalkulationen, die starken Gebrauch von dem Grau-Weiß-Kontrast machen, ist das dann ein extremer Nachteil.

Die Farbwahl der Geräte hängt aber auch von den eingesetzten Timings ab. Nach VESA-Standard wird die Full Range genutzt, die meisten HDMI-CE-Geräte nutzen für HD, Full-HD und 4K jedoch ausschließlich die Limited Range, obwohl es technisch dafür eigentlich keinen Grund gibt.

Im Prinzip sollten die Empfangsgeräte (Sink) eine Auswahl für die Farbkalibrierung unterstützen, sodass die Quelle - also der Laptop - die richtige Quantisierung signalisieren kann. Signalisiert werden kann der Wechsel über den AVI-Infoframe, und das Cisco-Team versucht, diese Funktion überall zu unterstützen.

Treiber machen alles kaputt

Diese schöne Theorie wird aber dadurch unterlaufen, dass die Grafiktreiber für Intel-GPUs, die in den meisten Laptops genutzt werden, auf Windows, MacOS und Linux unterschiedlich funktionieren.

Der Linux-Treiber arbeitet aus Sicht von Verkuil so wie vorgesehen. Der Windows-Treiber unterstützt standardmäßig RGB und auch nur Limited Range, die Quantisierung kann hier nicht ausgewählt werden. Der MacOS-Treiber unterstützt RGB dagegen nur im Full Range und Limited Range überhaupt nicht.

Die einzige Möglichkeit, das Decoding der Informationen auf der Gegenseite dann richtig und vor allem einheitlich vorzunehmen, ist laut Verkuil, sämtliche Clients per EDID auf YUV zu zwingen, wobei Apple auch hier nur Limited Range unterstützt.

Für Cisco mit seinem Spark-Gerät als Mittler ergibt sich so die Möglichkeit, zumindest die Eingabestreams zu vereinheitlichen. Bei der Ausgabe ist das wohl wesentlich schwieriger, da so gut wie kein Displayhersteller die Information zur genutzten Quantisierung in EDID hinterlegt.

Verschlimmert wird das nur noch durch die Controller in Adapter-Kabeln, die nur bestimmte Timings unterstützten, diese aber nicht per EDID bereitstellen, sodass ein der Treiber die Möglichkeiten einfach durchtesten muss, was Windows- und MacOS-Treiber aber nicht machen. Andere Adapter verändern die Informationen auch einfach oder versuchen gar, HDCP zu erzwingen, auch wenn die Gegenseite das nicht unterstützt, was die Übertragung dann vollständig verhindert.

Für Verkuil, sein Team und viele andere Anbieter bleibt die HDMI-Unterstützung damit eigentlich nur eine großes, in Software gegossenes Herumrätseln.  (sg)


Verwandte Artikel:
Linux: Kernel-Hacker wollen Yaml zur Hardware-Beschreibung nutzen   
(30.10.2017, https://glm.io/130868 )
Samsung Q9FN: QLED-Fernseher bekommen direkte Hintergrundbeleuchtung   
(08.03.2018, https://glm.io/133216 )
Paketlösung mit Video-Streaming, Encoding sowie Hosting   
(16.05.2001, https://glm.io/13932 )
Nouveau: Nvidia versucht, alles zu verstecken   
(04.02.2018, https://glm.io/132571 )
Schnitzeljagd: Google I/O 2018 findet vom 8. bis zum 10. Mai statt   
(24.01.2018, https://glm.io/132356 )

© 1997–2019 Golem.de, https://www.golem.de/