jms-1 / dvbnet-ubuntu-server Goto Github PK

Bei diesem Projekt handelt es sich um das Gegenstück zu dem DVB.NET Provider, das es erlaubt, über ein einfaches TCP/IP Protokoll auf DVB-S2 Geräte zuzugreifen, die an einen Ubuntu 18.04 System angeschlossen sind. Die Implementierung ist sehr einfach gehalten, aber für die in VCR.NET benötigten Funktionaliäten weitgehend ausreichend - lediglich Entschlüsselung und Signalinformationen werden nicht unterstützt. Getestet wurde bisher auch nur die Verwendung der Technotrend USB Geräte S2-4600 und S2-3600 - mindestens die S2-4600 kann seit dem Update 1809 unter Windows 10 nicht mehr stabil betrieben werden.

Zum Zugriff auf die DVB Geräte wird die Digital TV API von Linux verwendet - verglichen mit Windows BDA eine sehr intuitive und einfach verständliche Schnittstelle, grob äquivalent zur proprieträen TechnoTrend Schnittstelle für die S-2300 Premium Line. Von der Linux Schnittstelle wird allerdings wiederrum nur einige elementare Funktionen genutzt und der Demultiplex nicht verwendet: vielmehr wird über den PID 0x2000 der gesamte Transport Stream ausgelesen und im eigenen Code zerlegt.

Beim Starten der Anwendung (dvb_proxy) ermittelt diese alle verfügbaren DVB Geräten (via /dev/dvb) - zurzeit wird dabei nicht zwischen DVB-S/C/T unterschieden und von DVB-S2 Geräten ausgegangen, das liesse ich bei Bedarf natürlich leicht ergänzen. Die Anwendung geht von einer exklusiven Nutzung der auf dem System verfügbaren Geräten aus.

Zur Anwendung kann eine TCP/IP Verbindung aufgebaut und eine der verfügbaren Karten reserviert werden. Diese Reservierung bleibt bis zum Beenden der Verbindung aufrecht erhalten. Der Aufrufer kann nach dem Tunen des Gerätes auf einen DVB-S2 Transponder auswählen, welche Teildatenströme (PIDs) des Transport Streams über den TCP/IP Kanal an ihn übertragen werden sollen. Unmittelbar nach dem Tunen werden keine Daten gesendet, danach können beliebige Teildatenströme aktiviert und deaktiviert werden. Das Ergebnis ist dann wieder ein Transport Stream.

Die aktuelle Implementierung ist bewußt (größtenteils einem geringen Zeitbudget geschuldet) einfach gehalten. Ein Beispiel ist der Tuning Vorgang: hier wir die Transponderinformation einfach an das Gerät gesendet und dann eine Zwangspause von zwei Sekunden eingelegt - das sollte ein Aufrufer natürlich wissen. Das Signal wird nicht ausgewertet - hier ist also noch gut Luft nach oben. Auch wurde auf ein Request / Response Muster verzichtet: alle Befehle an die Anwendung senden keine Bestätigung. Dadurch konnte in dieser ersten Version der Antwortdatenstrom durch die Reduktion auf einen echten Transport Stream deutlich vereinfacht werden. Hier lassen sich durchaus integrative Ansätze vorstellen - etwa eine reservierte PID für einen Rückkanal mit einem darin gekapselten prorietären Protokoll. Auch Sicherheit ist noch kein Thema, hier wäre es aber vermutlich einfacher auf Firewall Einstellungen zurück zu greifen.

Im Verzeichnis ubuntu1804x64 finden man neben der Anwendung auch einen Vorschlag für ein verzögertes Starten (als Script) beim Hochfahren des System (als /etc/crontab Zeile).

Auch wenn die Anwendung für einen bestimmten Zweck in einem sehr engene Einsatzrahmen entstanden ist könnte ich mir vorstellen, dass durch die Einfachheit des Protokoll auch andere Nutzungsszenarien in Betracht kommen könnten.