- Cyanview entwickelt Camera-Shading-Geräte, die bei großen Live-Übertragungen wie dem Super Bowl Farbe, Belichtung und Hauttöne von Hunderten Kameras angleichen, und nutzt Elixir im zentralen Steuerpfad
- Da in Broadcast-Umgebungen schon ein einziger Ausfall kritisch ist, basiert Cyanview sein Produkt auf IP-Netzwerksteuerung und der Fähigkeit der Erlang VM, Geräte zu koordinieren
- RCP- und RIO-Geräte laufen mit Elixir- und C-Logik auf Yocto Linux und unterstützen Remote-Produktionen mit MQTT-basierter Kommunikation und begrenztem Cloud-Relay
- Die Binär-Encodierung/-Decodierung von Elixir und der supervision tree werden für die Integration verschiedenster proprietärer Geräte, die Isolation von Verbindungsstörungen und die schnelle Validierung von Funktionen genutzt
- Ein 9-köpfiges Team unterstützt Einsätze mit mehr als 200 verbundenen Kameras bei Veranstaltungen wie Le Mans, Ninja Warrior, den Australian Open und den US Open und erweitert so die Produktreichweite eines kleinen Teams
Das Problem, das Cyanview in Broadcast-Umgebungen löst
- Bei Live-Übertragungen wie dem Super Bowl müssen Farbe, Belichtung und visueller Ton von rund 200 Kameras aufeinander abgestimmt werden
- Camera Shading ist die Arbeit, jede Kamera so einzustellen, dass sie dieselbe Rasenfarbe und dieselben Hauttöne zeigt
- Die Zielgeräte reichen von großen Broadcast-Kameras über Drohnenkameras und PTZ-Kameras bis zu auf Gimbals montierten spiegellosen Kameras
- Cyanview ist ein kleines belgisches Unternehmen, das Produkte für die Live-Video-Broadcast-Branche verkauft; sein Schwerpunkt ist Shading
- Werkzeuge in der Broadcast-Branche müssen sich sofort in einem Live-Event bewähren, und harte Ausfälle sind kaum akzeptabel
Wie sich das RCP verbreitete und wo es eingesetzt wird
- Das von einem kleinen 3-köpfigen Team entwickelte Remote Control Panel (RCP) verbreitete sich in der Branche eher über seine Funktionen als über Marketing
- Das RCP wird von professionellen Video-Operatoren bei folgenden Einsätzen genutzt
- Olympics
- Super Bowl
- NFL
- NBA
- ESPN
- Amazon
- zahlreiche Fashion Shows in Paris
- Es gab Einsätze, in denen ein einzelnes RCP mehr als 100 Kameras problemlos steuerte; umgesetzt ist dies auf dem Elixir-Netzwerk-Stack
- Cyanview entschied sich für Elixir, um Netzwerkfunktionen, Resilienz und schnelle Iteration von Produktfunktionen zu erhalten
Warum Elixir gewählt wurde
- Das Gründerteam von Cyanview hatte vor allem Erfahrung in der Embedded-Entwicklung, und in den Produkten steckt viel Low-Level-C-Code und FPGA
- Wegen der Low-Level-Details der Farbwissenschaft und strenger Timing-Anforderungen war eine Low-Level-Implementierung notwendig
- Kamerasoftware ist auch nach der vollständigen Digitalisierung oft noch an analoge Systeme oder proprietäre Verbindungsarten gebunden
- Von Anfang an war IP-basierte Steuerung das Ziel, wodurch eine Struktur entstand, in der Software Geräte über allgemeine Netzwerke steuert
- Mit der Zunahme von Remote-Produktionen verbreitete sich ein Betriebsmodell, bei dem Produktionsteams zentral arbeiten und das Personal vor Ort reduziert wird
- Maßgeschneiderte Funkfrequenzen oder serielle Drahtprotokolle lassen sich nur schwer über Kontinente hinweg skalieren
- Die Erlang VM wurde dafür entworfen, viele Geräte über Netzwerke hinweg zuverlässig kommunizieren und koordinieren zu lassen, was zur Einführung von Elixir führte
Protokollintegration und ein Beispiel für Remote-Produktion
- Der Entwickler Ghislain führte Elixir ein, um Kameras und Videoequipment über verschiedene Netzwerkprotokolle zu integrieren
- Elixir bietet praktische Funktionen zum Encodieren und Decodieren binärer Daten bis hinunter auf einzelne Bits
- Das zentrale geistige Eigentum von Cyanview liegt in der Integration großer Mengen an Equipment und im Reverse Engineering
- Die Produkte sind so ausgelegt, dass sie mit den unterschiedlichen professionellen Kamerasystemen und zugehörigen Geräten der Kunden kompatibel sind
- Es werden auch APIs bereitgestellt, damit die Integration mit externer Ausrüstung reibungslos funktioniert
-
Beispiel Beijing–Paris-Fernsteuerung
- Beim Olympia-Einsatz in China nutzte das Studio in Beijing viele Panasonic-PTZ-Kameras, während der Großteil des Teams sie aus Paris fernsteuern musste
- Das Panasonic-Kameraprotokoll war nicht für die Nutzung über das Internet ausgelegt und erforderte für jede Anpassung exaktes Timing und mehrere Nachrichten
- Netzwerklatenz konnte zu Timeouts, Verbindungsabbrüchen und Systemausfällen führen
- Das System wurde so betrieben, dass Cyanview-Geräte neben den Kameras in Beijing standen und von Paris aus per IP gesteuert wurden
- Geräte am selben Standort kommunizierten und koordinierten sich über ein benutzerdefiniertes MQTT-Protokoll im Netzwerk
RCP, RIO und die UI-Struktur
- Das Gesamtsystem besteht aus RCP-Geräten mit Yocto Linux und Logik auf Basis von Elixir und C
- Python wird weiterhin für Skripting und Tools verwendet, seine Rolle nimmt jedoch allmählich ab
- Mehrere Mikrocontroller und On-Camera-Geräte kommunizieren über MQTT
- Ein Cloud-Relay unterstützt die Konnektivität, und Dashboard- sowie Controller-UIs bieten Monitoring und Steuerung
- Es gibt zwei zentrale Gerätetypen
- RCP: Steuergerät auf der Produktionsseite
- RIO: Gerät für latenzarme Kamerabedienung
- Sowohl RCP als auch RIO führen Elixir aus
- Die Konfigurations-UI ist derzeit in Elm aufgebaut
- Je nach Prioritäten könnte die Konfigurations-UI auf Phoenix LiveView umgestellt werden, um die Zahl der Sprachen zu reduzieren
- Die Web-UI des Controllers ist bereits mit LiveView umgesetzt und läuft auch auf leistungsschwachen Embedded-Linux-Maschinen gut
Begrenzte Cloud und lokale Gerätecluster
- Der Cloud-Anteil von Cyanview ist derzeit begrenzt und keine SaaS-zentrierte Struktur
- Das Cloud-Relay übernimmt die Verteilung und Freigabe der Kamerasteuerung, Netzwerk-Port-Weiterleitung zwischen Standorten und verwandte Funktionen
- Auch das Cloud-Relay ist mit Elixir aufgebaut
- Die Elixir-Geräte vor Ort bilden mit einem auf die Aufgaben zugeschnittenen benutzerdefinierten MQTT-basierten Protokoll einen IP-Cluster
- Diese Geräte kommunizieren mit Hunderten Kameras und anderen Videogeräten
Fehlerisolation und supervision tree
- Bei der Integration vieler proprietärer Geräte unterscheiden sich Zuverlässigkeit und Dokumentationsqualität je nach Gerät stark
- Manche Geräte sind weit verbreitet und ihre Eigenschaften gut bekannt, andere liefern gute Dokumentation, wieder andere zeigen schwer vorhersehbares Verhalten
- Selbst wenn bei einer Kameraverbindung vorübergehende Probleme, fehlerhafte Protokolle oder physische Verbindungsstörungen auftreten, muss der Rest weiter funktionieren
- Der supervision tree von Elixir ist dabei vorteilhaft, weil Probleme einzelner Verbindungen nicht zum Ausfall des Gesamtsystems eskalieren
Rollenverteilung im 9-köpfigen Team
- Cyanview ist über 9 Jahre langsam gewachsen; im Schnitt kam pro Jahr eine Person hinzu
- Heute unterstützt ein 9-köpfiges Team einige der größten Broadcast-Events der Welt
- Es gibt 2 Elixir-Entwickler
- Daniil betreut Teile der UI-Überarbeitung und die Richtung hin zu mehr Cloud-Funktionen
- Ghislain ist für Kameras und Integrationsarbeit zuständig
- LiveView und Elm werden für Geräte-UIs und Dashboards verwendet
- Andere Embedded-Entwickler nutzen Elixir nicht stark im Tagesgeschäft, sind aber damit vertraut, Protokolle und Encodings in Elixir zu implementieren
- Der Hauptgrund, warum sie Elixir nicht tiefer gelernt haben, ist Zeitmangel; tiefe Elixir-Expertise war außerdem nicht zwingend erforderlich
- Die Arbeit des Teams umfasst PCB-Design, Auswahl elektronischer Bauteile, Reverse Engineering von Protokollen, Display-Schnittstellen, FPGA-Implementierung, Verwaltung von Produktionstests, echte Produktionen und Firmware-Updates
Funktionserweiterung und kundenorientierte Entwicklung
- Cyanview-Geräte werden bei folgenden Einsätzen verwendet
- mehr als 40 Onboard-Kameras in Fahrzeugen bei den 24 Hours of Le Mans
- Ninja Warrior
- Australian Open
- US Open
- Studios im Louvre
- NFL pylons
- gleichzeitige Verbindung von mehr als 200 Kameras
- Es wurden Elixir-basierte Geräte für eine auf IP laufende Welt gebaut, wodurch gleichzeitig Unterstützung für verschiedenes Equipment und neue Funktionen möglich wurde
- Mit dem Wechsel von lokalen Funkfrequenzen, seriellen Verbindungen und unflexiblen proprietären Protokollen hin zu IP-Netzwerken verändert sich die Art, wie Kamerasysteme betrieben werden
- Der Funktionsumfang umfasst
- unbegrenztes Multicam
- Tally lights
- Pan-&-Tilt-Steuerung
- Integration von Farbkorrektoren
- weltweite Remote-Produktion
- Als die Nachfrage nach Zuschauerszenen mit auf Gimbals montierten spiegellosen Kameras stieg, prototypisierte Cyanview die Gimbal-Steuerung schnell und validierte sie gemeinsam mit Kunden durch Tests
- Die flexible Architektur ermöglicht es, neue Funktionen schnell auszuliefern, ohne das zentrale Fundament zu beschädigen
- Kamerahersteller wie Canon oder RED, die selbst keine Broadcast-Shading-Remotes bauen, empfehlen Cyanview ihren Kunden
- Cyanview sieht sich bei den meisten Broadcast-Hardware-Unternehmen eher als Partner denn als Wettbewerber
- Mehr als Marketing zählen die Unterstützung erfolgreicher Kundenevents und ein tiefgehender Kundenservice
Ausblick
- David Bourgeois sagt, dass er sich wieder für Elixir entscheiden würde
- Die Erlang VM passt gut zu den Anforderungen von Cyanview, und der Wert der von Elixir standardmäßig bereitgestellten Funktionen werde oft erst deutlich, wenn man versucht, sie selbst zu implementieren
- Cyanview möchte das Team weiter ausbauen, aber auch wenn es Zeit braucht verantwortungsvoll wachsen
- Schon jetzt gibt es mehr zu tun, als das kleine Team bewältigen kann
- Ergänzende Produkte existieren bereits neben dem Haupt-RCP-Gerät, und weitere Produkte sind geplant
- Geplant sind Cloud-Produkte und Hardwareprojekte auf Basis der bisherigen Lernerfahrungen
- Elixir wird bei einigen der größten Live-Broadcasts der Welt eine noch wichtigere Rolle übernehmen
1 Kommentare
Meinungen auf Hacker News
Dass bei Sportevents für jede Kamera, die in verschiedenen Winkeln positioniert ist, eine Farbkorrektur nötig ist, wirkt völlig offensichtlich, sobald man es weiß.
Es macht wirklich Spaß, über schwierige Probleme zu lesen, die den meisten verborgen bleiben.
Es gibt ein Video, das alle Kamera-Shot-Wechsel der Halftime Show nachverfolgt: https://www.youtube.com/watch?v=YXNWfFtgbNI
Hamish Hamilton hat seit 2010 alle Super-Bowl-Halftime-Shows inszeniert.
https://x.com/SNYtv/status/1832250958258036871
Die Stelle, dass es „ohne Marketing unter erfahrenen Profis einen Ruf aufgebaut hat und zu einem unverzichtbaren Bestandteil der weltweit größten Live-Events wurde“, klingt sehr nach Entertainment-Branche.
Wenn man Jahr für Jahr dieselbe Show mit derselben Crew macht, kennt wirklich jeder jeden, und es entsteht eine Art Familienstruktur.
Cyanview hat sowohl eine Storefront-Website als auch Marketing-Posts auf LinkedIn.
Schön zu sehen, dass Elixir in missionskritischen Broadcast-Systemen an Bedeutung gewinnt.
Ich frage mich, wie viel von der Zuverlässigkeit von Cyanview von Elixir selbst kommt und wie viel einer guten MQTT-Implementierung zu verdanken ist.
Außerdem interessiert mich, ob es bestimmte Elixir-Features gab, die sich in anderen Sprachen nur schwer hätten nachbilden lassen.
BEAM und OTP bieten einen soliden Ansatz für Concurrency, und Elixir ist eine gute Sprache darauf.
Die Prozessisolation ist stark, bis hin zu getrennten Heaps pro Prozess. Dadurch kann man stabilen, ausgereiften Code und experimentelle Features gemeinsam laufen lassen, ohne sich große Sorgen machen zu müssen, dass alles zusammenbricht; auch die Kommunikation zwischen Prozessen ist einfach.
Dank Supervisor Trees ist Prozessmanagement einfach, und wir konnten auch spezielle Supervisoren mit unterschiedlichen Restart-Strategien bauen.
In einer Umgebung, in der Netzwerkverbindungen abbrechen und wiederkommen, wird die Resilienz des Systems häufig wie durch einen physischen Chaos Monkey getestet.
Die BEAM-typische Immutability vereinfacht das Schreiben von concurrent Code erheblich: Innerhalb eines Prozesses muss man sich nicht sorgen, dass Daten heimlich verändert werden, und andere Prozesse können meinen Zustand ebenfalls nicht ändern.
Deshalb braucht man kaum Mutexes oder kritische Abschnitte; Deadlocks sind aber weiterhin möglich, es ist also keine Allzwecklösung.
Es geht darum, zahlreiche Echtzeit-Feeds mit Failover und alternativen Pfaden zu koordinieren und zu routen; ursprünglich waren Telefonanrufe das Ziel.
Videostreams haben pro Sekunde ein viel größeres Datenvolumen, aber die Prinzipien gelten größtenteils weiter.
Ich stehe diesem System eher kritisch gegenüber, aber für solche Einsatzzwecke ist es schon im Grundzustand eine sehr starke Basis.
Der Unterschied liegt darin, wie leicht sie diese Aufgabe macht.
Ich habe Elixir in wichtigen Finanzanwendungen, B2B Growth Intelligence, Betrugserkennung, Scan-and-go-Shopping und weiteren Bereichen eingesetzt.
Jedes Mal haben die Developer Experience und das Endergebnis, ähnlich wie beim Engineering-Team in diesem Artikel, die Erwartungen übertroffen; wer Elixir noch nicht ausprobiert hat, sollte es durchaus einmal versuchen.
Ich bin selbst keine Ausnahme: Seit Jahrzehnten höre ich Gutes darüber, habe sie aber nie in einem echten Projekt verwendet.
Zum Beispiel haben wir gerade ein Feature für unser Cloud-Produkt ausgerollt, mit dem Nutzer einen Roboter remote zu einem festgelegten Waypoint innerhalb einer Anlage rufen und während der Fahrt seine Position in Echtzeit auf einer Karte sehen können.
Gebaut haben wir das mit MQTT, LiveView, Phoenix PubSub und sehr wenig JavaScript für die Karteninteraktion. Abgesehen von vorhandenem Code zur Anzeige von S3-Karten-PNGs und zur Verarbeitung eingehender MQTT-Nachrichten hat eine Person den Cloud-Teil in etwa zwei bis drei Wochen umgesetzt.
Natürlich ließe sich das auch in anderen Sprachen bauen, aber die Kernfeatures der Sprache sind so gut, dass sie für unseren Anwendungsfall andere Optionen deutlich übertreffen.
Ich frage mich, ob Gleam für ähnliche Anwendungen auch jenseits der OTP/BEAM-Runtime praktisch wäre.
Vermutlich müsste man Elixir-Bibliotheken nutzen, die es in Gleam noch nicht gibt, und wegen der statischen Typisierung könnte die Kompilierung langsamer sein, dafür ließen sich Runtime-Fehler aber wohl früher abfangen.
Ich frage mich, ob es eher ein Trade-off zwischen Debugging und schneller dynamischer Iteration ist, und versuche gerade, mich zwischen Gleam und Elixir zu entscheiden.
Die frühere ML-artige Syntax von Gleam mochte ich auch, und statische Typen ebenfalls.
C ersetze ich gerade durch Zig, und zusätzlich zu x64 lerne ich ARM und frische auch wieder Assembly auf.
Erlangs Zuverlässigkeitsbilanz ist stärker als die vieler statisch typisierter Sprachen, einschließlich Java.
Es gibt zwar Fehlerklassen, die statische Typen verhindern, aber deutlich mehr Fehler, die sie nicht verhindern.
Wer behaupten will, dass Sprachen wie TS, Java, Swift, Go oder Gleam in der Praxis weniger Runtime-Defekte verursachen als Erlang oder Elixir, braucht dafür reale Daten.
Daran wird zwar gerade gearbeitet, aber ich konnte es noch nicht ausprobieren; deshalb könnte Gleam ebenfalls eine gute Option sein.
Als wir angefangen haben, war Gleam allerdings noch nicht einmal bei 0.1, und ich hatte nie davon gehört.
Ein Projekt, das Erlang, Elixir und Gleam mischt, wäre wohl möglich, aber wie praktikabel das ist, weiß ich nicht.
Auch die Kompilierung ist sehr schnell.
Ich habe noch kein wirklich großes Projekt damit gemacht, aber selbst mit ziemlich umfangreichen Libraries wurde alles sehr schnell kompiliert.
Die Welt des digitalen Videos wirkt wie ein Verwandter der IT, aber für Menschen außerhalb der Videobranche fühlt sie sich immer nach einer hohen Einstiegshürde an.
Die Art, wie Auflösung, Farbe, Networking und Storage bezeichnet werden, wirkt fast absichtlich anders.
Das sind nur die Punkte, mit denen Videoingenieure die Bildqualität anpassen; Funktionen für Kamera-Operator werden normalerweise nicht abgedeckt.
Die Schwierigkeit liegt darin, zwischen so vielen Kameras und Protokollen Konsistenz herzustellen.
Erst danach kann man zu Themen wie rohem unkomprimiertem yuv/y4m-Video, extrem hochbitratigem niedrig komprimiertem Video und dem Problem übergehen, dass die Originaldaten so groß sind, dass sie selbst auf leistungsstarken Workstations schwer zu schneiden sind, weshalb man Proxy-Videos erstellt.
Ohne professionellen Grund hat ein normaler Endnutzer kaum einen Vorteil davon, so tief einzusteigen.
Wenn man vorhat, 7.000 Dollar für eine RED-Kamera auszugeben und weitere 13.000 Dollar für Objektive, Gimbal, Cage, Follow Focus, Matte Box, Speicherkarten und Ähnliches, um ein kleines und kosteneffizientes Single-Camera-Produktionspaket zusammenzustellen, lohnt sich die Vertiefung.
Vor gut 30 Jahren gehörte es in einer Studioumgebung zu meiner Arbeit, den Farbbalance von Kameras abzustimmen.
Computer waren dafür nicht nötig, aber es waren höchstens fünf Kameras.
Im Artikel fiel mir die Stelle auf, dass „die Geräte an einem Standort über ein maßgeschneidertes MQTT-Protokoll im Netzwerk kommunizieren und sich koordinieren und dass ein einzelnes Remote Control Panel (RCP), implementiert auf dem Elixir-Netzwerkstack, problemlos mehr als 100 Kameras handhabt“.
Ich verstehe MQTT als etwas, das auf TCP aufsetzt; ich weiß nicht, ob ich dieselbe Lösung gefunden hätte, aber es wirkt wie eine ziemlich gute Wahl.