DVB.NET 4.0 Konzepte: Installation und Verzeichnisse

Beginnend mit DVB.NET 3.9 verfolge ich ein etwas anderes Konzept, was das Laden der Bibliotheken angeht. Mehr oder weniger historisch bedingt durch die Notwendigkeit, die properitäre Treiberdatei (DLL) der Hauppauge Nexus im selben Verzeichnis zu haben wie die Anwendung [ja, da gibt es durchaus Alternativen, aber alle haben ihren eigenen kleinen Haken], die sie benutzt, brachte jede DVB.NET Anwendung letztlich die gesamte Bibliothek mit sich – siehe VCR.NET. Scheint es erst mal von Vorteil zu sein (DVB.NET und VCR.NET werden unabhängig voneinander installiert), kann es doch auch lästig sein (der Viewer MUSS in das DVB.NET Installationsverzeichnis, Fixes für DVB.NET MÜSSEN auch immer im VCR.NET eingespielt werden und so weiter).

Da ich es auch für bedenklich halte, DVB.NET Bibliotheken (Assemblies) mit teilweise sehr direktem Zugriff aus .NET heraus auf das Betriebssystem blind in das .NET GAC (Global Assembly Cache) zu installieren. habe ich folgende Lösung gewählt:

  • DVB.NET installiert ab 3.9 eine einzige Bibliothek in den GAC
  • Zukünftige Versionen werden diese nicht einfach ersetzen, sondern separate Varianten einstellen – DVB.NET Versionen sollen weiterhin parallel betrieben werden können
  • Zusätzlich wird für jede Version ab 3.9 separat in der Registry vermerkt, wohin DVB.NET installiert wurde
  • Jede DVB.NET Anwendung referenziert diese eine Bibliothek und initialisiert sie geeignet (sehr einfach gehalten)
  • Werden DVB.NET Bibliotheken benötigt, so werden diese automatisch dem RunTime Unterverzeichnis des Installationsverzeichnisses entnommen
  • Für propertitäre Treiber wird ein ähnlicher Mechanismus (Stichwort: SetDllDirectory) und das Unterverzeichnis Driver verwendet
  • Ein grundsätzlicher Erweiterungsmechanismus kann von Anwendungen wie dem Administrationswerkzeug verwendet werden (hier das Unterverzeichnis Administration PlugIns)

Insgesamt enthält das Installationsverzeichnis von DVB.NET im Wesentlichen nur noch Anwendungen. Eine auf DVB.NET basierte selbst erstelle Anwendung muss eigentlich nur noch die eigenen Dateien kopieren und hat volle DVB.NET Unterstützung – inklusive eines vereinfachten Aktualisierungsmechanismus.

Ich hoffe, dadurch etwas Übersichtlichkeit in die Installation des DVB.NET Kerns und abhängiger Anwendungen zu bringen.

Wir werden sehen…

Jochen

So könnte es aussehen…

DVB.NET 4.0 Konzepte: Der Card Server

Die nächste DVB.NET Version wird mehrere Schichten zum Zugriff auf DVB Hardware anbieten. Erst einmal unangetastet bleiben die DVB.NET 3.5 (und früher) Hardwareabstraktionen, wobei es aber sehr schwer sein wird, diese weiterhin direkt zu verwenden (mit Absicht). Tatsächlich zeigt es sich nun nach einiger Entwicklungszeit, dass dieser Kern so ziemlich das einzige ist, was in die neue Version unverändert eingeht.

Dazu ein kleiner Einschub: Anders als ursprünglich geplant gibt es sehr viel Neues in DVB.NET, so dass ich mich entschieden habe, die nächste Version 3.9 (aka Fast-4.0) zu taufen. Für die viele Arbeit und die realisierten Konzepte ist 3.5.1 einfach zu schwach und alles dazwischen wäre nur gemogelt. Es geht auf die 4.0 zu – das wäre meine Botschaft!

Doch zurück zum Thema. Für jemanden, der eigene DVB Software auf Basis von DVB.NET entwickeln möchte, ist der Zugriff über die (neuen) Geräteprofile der vorgeschlagene Ansatz. In meinem Fall wird das etwa der DVB.NET / VCR.NET Viewer sein, der (auch) direkt auf die lokale DVB Hardware zugreifen soll. Damit man sich nicht mit unnötigem Balast abplagt wird es hierzu eine Basisinstallation DVB.NET Library geben, die im wesentlichen die Bibliotheken enthält – und einen minimalen Satz von Werkzeugen etwa für die Pflege von Profilen oder den Sendersuchlauf. Eine separate Installation DVB.NET Tools wird einige zusätzliche Anwendungen zum Testen und Spielen mit der Bibliothek enthalten.

Neu ist die Installation DVB.NET Server, die den so genannten DVB.NET Card Server enthält. Dieser wird eine wesentliche Grundlage für VCR.NET 3.9 (oder andere Aufzeichnungsdienste wie für 4TheRecord locker geplant) bieten. Hier geht es nicht um den elementaren Zugriff auf die DVB Hardware, wie ihn die Geräteprofile bieten. Vielmehr bietet ein Card Server Funktionen wie die folgenden an:

  • Aufzeichnen mehrerer Sender gleichzeitig in unterschiedliche Dateien mit optionalem Netzwerkversand
  • Aktualisieren der Programmzeitschrift
  • Durchführen eines Sendersuchlaufs

Insgesamt werden sehr wenige, komplexe Funktionen angeboten.

Den Card Server wird es in zwei Varianten mit identischer Schnittselle geben. Im Normalbetrieb wird für jedes aktive DVB Gerät ein eigener Prozess gestartet. Damit wird die höchste Stabilität erreicht und vor allem vermieden, dass sich etwa unterschiedliche BDA Treiben in einer Anwendung stören. VCR.NET nutzt diese Möglichkeit schon seit Jahren erfolgreich. Alternativ kann der Card Server aber auch in eine Anwendung geladen und dort direkt angesteuert werden. Die Installation enthält zum Spielen ein kleines Testprogramm, mit dem sich die wichtigsten Funktionalitäten des Card Servers in beiden Varianten erschliessen lassen.

Bis später

Jochen

DVB.NET 4.0 Konzepte: Arbeiten mit Quellen

Nach den ganzen Einführungen hier einmal etwas Praktisches am Beispiel: es ist die Aufgabe, eine Aufzeichnung eines Senders (sagen wir mal ZDF) in eine TS (Transport Stream) Datei zu starten und gleichzeitig an einen anderen Rechner im Netzwerk zu versenden (der die Aufzeichnung dann Live mit VLC oder dem DVB.NET / VCR.NET Viewer betrachten kann).

Erst einmal zu der schlechten Nachricht: DVB.NET 3.5.1 wird im Kern keine direkte Namensauflösung von Sendern anbieten! Was genau ich da zur Verfügung stelle, weiß ich noch nicht. Aber ganz trivial wird es nicht, Sender mit identischem Namen zu unterscheiden – etwa die vielen Channel 4 Varianten auf Astra 2. Meiner Ansicht nach ist das ein eigenständiges Problem, dass auch gesondert gelöst werden muss, aber im Moment noch nicht Thema ist.

Um einen Sender in DVB.NET zu adressieren, benötigt man dessen eindeutige DVB Kennung (Ursprungsnetzwerk, Transportstrom, Dienst) – für das ZDF wäre das (1, 1079, 28006). Mit Hilfe der neuen statischen .NET Klasse ProfileManager ermittelt sich daraus eine Liste von SourceSelection Instanzen. Hat man mehrere aktive Geräteprofile, so kann es dann auch mehrere Auswahlinstanzen geben – konkret auch von verschiedener Empfangsart wie DVB-S und DVB-C. Jede Auswahlinstanz enthält weitere Details wie den Namen des Geräteprofils, über das die gewünschte Quelle erreicht werden kann. Jede Instanz kann über die .NET Eigenschaft SelectionKey in eine Zeichenkette serialisiert und später daraus rekonstruiert werden – genau dies wird dann etwa von VCR.NET 3.5.1 zur eindeutigen Identifikation einer Quelle verwendet, ohne die ganzen Probleme mit dem Umbennen von Sendern, die einige Anbieter das eine oder andere Mal machen.

Eine SourceSelection ist eigentlich auch die Verbindung zwischen der Auswahl des Anwenders und der eindeutigen Erkennung einer Quelle samt Geräteprofil, DVB.NET Ursprung, Quellgruppe (Transponder) etc. Eine Anwendung wie VCR.NET wird dem Anwender eine geeignete Namensrepräsentation zur Auswahl anbieten, selbst aber die eindeutige Repräsentation via SelectionKey speichern.

Hat man einmal eine Auswahlinstanz, so kann man diese mit der Methode SelectGroup aktivieren – nachdem man sich für die Benutzung einer DVB.NET Geräteabstraktion über den HardwareManager angemeldet hat. SelectGroup entspricht einem Tune Vorgang und wählt eine Quellgruppe (Transponder) an, so dass die darauf übertragenen Datenströme zum Empfang bereit stehen.

Der letzte Schritt es es dann nur noch, über eine StreamSelection Instanz den Empfang der Quelle zu aktivieren. Sollen mehrere Quellen der gleichen Gruppe ausgewertet werden (im Beispiel etwa zusätzlich zum ZDF auch noch KiKa und DLF Radio), so ist der Vorgang mit entsprechenden Auswahlinstanzen zu wiederholen. SelectGroup kann aufgerufen werden, ist aber optional: DVB.NET 3.5.1 erkennt automatisch, dass die selbe Quellgruppe aktiviert werden soll und macht dann einfach nichts.

In einer StreamSelection kann angegeben werden, welche Aspekte der Quelle mit in den Empfang aufzunehmen sind – etwa welche Tonspuren welcher Art und Sprache. DVB.NET 3.5.1 ermittelt automatisch die aktuell angebotenen Aspekte und erfüllt diese Wünsche soweit als möglich.

Aus der Aktivierung wird eine SourceStreamManager Instanz geliefert. Diese kann nun einfach verwendet werden, um den Empfang in eine Datei zu lenken und / oder den Netzwerkversand zu aktivieren. Hier nun das volle Beispiel:


// Station of interest
SourceIdentifier station = new SourceIdentifier
{
Network = 1,
TransportStream = 1079,
Service = 28006
};

// Find the station of interest
SourceSelection zdf = ProfileManager.FindSource( station )[0];

// Create the device instance
using (HardwareManager.Open())
{
// Tune
zdf.SelectGroup();

// Create new
StreamSelection selection = new StreamSelection();

// MP2
selection.MP2Tracks.AllLanguages = true;

// AC3
selection.AC3Tracks.AllLanguages = false;
selection.AC3Tracks.Languages.Add( "Deutsch" );

// Videotext
selection.Videotext = true;

// EPG
selection.ProgramGuide = true;

// Create access context
using (SourceStreamsManager streams = zdf.Open( selection ))
{
// Create the stream
streams.CreateStream( @"v:\videorecorder\ts\test1.ts" );
streams.StreamingTarget = "localhost:6666";

// Report
Console.WriteLine( "Recoding active" );
Console.ReadLine();
}
}

Für den Empfang werden alle MP2 Tonspuren, die deutsche AC3 Tonspur und der Videotext angefordert. Zusätzlich werden Informationen aus der Programmzeitschrift eingebettet. Die empfangenen Daten werden in eine TS Datei gebündelt und gleichzeitig an den TCP/IP UDP Port 6666 auf dem selben Rechner versendet.

Natürlich ist auch wie bisher der direkte Zugriff auf die DVB Hardware möglich, etwa der gezielte Empfang einzelner Teildatenströme (PIDs) und der direkten Auswertung im Speicher. Aber das ist hier nicht das Thema, hier ging es um die oberste Ebene des Zugriffs auf Quellen.

So long

Jochen

DVB.NET 4.0 Konzepte: Sendersuchlauf

Wie in den früheren Version werden auch DVB.NET 3.5.1ff Geräteprofile die Liste der Sender (Quellen in der neuen Notation) in sich tragen. Ebenso wird es möglich sein, gemeinsame Listen für verschiedene gleichartige Geräte zu verwenden – etwa ein DVB-S(2) Geräteprofil mit Senderliste für eine Hardware, die von anderer DVB-S(2) Hardware im gleichen Rechner mit genutzt wird. Dabei ist es jetzt auch möglich, unsinnige Quellgruppen (Transponder) aus der Referenz auszublenden – eine Hauppauge Nexus-S kann mit den DVB-S2 Quellgruppen einer TechnoTrend S2-3200 nichts anfangen.

Ebenso wie früher ist in einem Geräteprofil mit Quellen vermerkt, auf welcher Basis diese ermittelt wurden. Im Beispiel DVB-S (DVB-C und DVB-T sind diesbezüglich etwas einfacher) werden wie bisher erst einmal die einzelnen Satellitenantennen definiert, die von der jeweiligen Hardware mittels DiSEqC 1.0 angesteuert werden können (die alte Bezeichnung LNB wird durch den Begriff des Ursprungs ersetzt). Jeder Ursprung wird dann mit einer Satellitenkonfiguration verbunden, etwa Astra 1 auf 19.2° Ost. Und damit kommen wir zum eigentlichen Punkt dieses Artikels…

Für jeden Satelliten (ähnlich für DVB-C und DVB-T, hier geht es nur um das Prinzip) wird erst einmal eine Liste aller Quellgruppen (Transponder) verwendet, die bei einem Suchlauf angesteuert und nach Quellen (Fernsehen, Radio, Sonstiges) abgesucht werden sollen. Anders als bisher geht nun DVB.NET 3.5.1ff hin und ermittelt nach dem Ansteuern einer Quellgruppe die Gesamtkonfiguration des Satelliten über die so genannte SI Tabelle Network Information Table (NIT). Hier können etwa Quellgruppen vermerkt sein, die in der statischen (evtl. veralteten) Liste nicht vorhanden sind (man denke etwa an die neuen Frequenzen für Phoenix et al). Optional können Frequenzen und andere Empfangsparameter korrigiert sein – DVB.NET benutzt hier einen etwas entspannteren Vergleichsalgorithgmus, der auch Quellgruppen mit leicht veränderter Frequenz korrekt als identisch erkennt. Ein Sendersuchlauf berücksichtigt die Daten der NIT vorrangig. Da diese Informationen relativ selten gesendet werden (es kann schon mal über 10 Sekunden dauern, bis diese zur Verfügung stehen), versucht DVB.NET den Abruf so selten wie möglich vorzunehmen. Konkret wird die NIT nur für die Quellgruppen angefordert, die sich in der ursprünglichen (statischen) Liste befunden haben und nicht durch die NIT einer so ausgewerteten Quellgruppe schon bestätigt wurden.

Darin stecken zwei Ideen und ein Zwang. Die primäre Idee ist es, die Liste der Quellgruppen pro Satellit auf ein Minimum zu beschränken – DVB.NET 3.5.1ff wird dazu auch ein eigenes Werkzeug anbieten, dass zu einer Liste einen minimalen Satz von Quellgruppen ermittelt, über deren NIT Informationen die Liste rekonstruiert werden kann. Astra 1 ist da ein sehr gutes Vorbild: hier reicht eine einzige (!) Quellgruppe, um alle Frequenzen zu erfassen. Zusätzlich soll es aber auch möglich sein, mehr als eine Quellgruppe für die Ermittelung der vollständigen Liste einsetzen zu können – vital für DVB-T, daher der Zwang. Die zweite Idee schließlich ist die Annahme, dass NIT Informationen für Gruppen von Quellgruppen identisch sind – i.e. wenn die NIT der Quellgruppe A B enthält, dann wird A auch in der NIT von B vorhanden sein und die NIT von B ist mit der von A identisch. Damit kann bei den langen Listen, die aus der alten DVB.NET Version übernommen wurden, das Warten auf die NIT soweit als möglich reduziert werden. Ob das so passt, werden wir sehen… Ziel ist es, für die wichtigsten Ursprünge irgendwann einmal minimierte Listen zu haben – DVB-S ebenso wie DVB-C und DVB-T.

Ansonsten ist ein Suchlauf nicht viel anders als früher. Lediglich der Umfang der Informationen im Geräteprofil ist dramatisch reduziert – es werden keinerlei Datenstromkennungen (PID) mehr fest eingetragen – dazu an anderer Stelle mehr. Nach einen Suchlauf wird die neue Liste üblicherweise mit der alten zusammengeführt, i.e. die neuen Quellen ersetzen die alten, aber gerade nicht verfügbare Quellen werden nicht entfernt (etwa bedingt durch eine zeitliche Beschränkung der Ausstrahlung). Bekannte Mechanismen wie das Ausblenden von Quellgruppen und Quellen oder das Anpassen von Quellinformationen wie dem Sendernamen werden ebenso unterstützt.

Ok, zum Schluss: der gesamte Algorithmus für den Sendersuchlauf soll weitgehend konfigurierbar als eigenständige Komponente (.NET Klasse) nutzbar (! angeboten war es immer schon, nur die Nutzung war kniffelig !) angeboten werden. Diese wird dann nicht nur im neuen DVB.NET Konfigurationswerkzeug, sondern auch in VCR.NET 3.5.1 genutzt.

Puh, das war wieder viel zu viel. Genug!

Jochen

DVB.NET 3.5.1 Suchlauf

DVB.NET 4.0 Konzepte: Dynamische Empfangsdaten

Zusätzlich zu den Grundelementen der DVB.NET 4.0 Senderliste (man siehe dazu den Artikel unmittelbar vor diesem hier) bietet jede Ebene ein zugehörige Informationsklasse an. Informationen können bei aktiver DVB Hardware über diese auf verschiedene Arten angefordert werden – das ist im Moment noch nicht mein Thema. Aktiv bedeutet dabei, dass eine Quellgruppe (zur Erinnerung: das war mal ein Transponder) auf einem Ursprung (nur für DVB-S die DiSEqC Auswahl) ausgewählt wurde.

Die SourceInformation enthalten alle Daten zu einer Quelle. Das umfasst vor allen die Details zum Empfang der Teildatenströme (Datenstromkennungen (PID) von Bild und Ton etwa) aber auch die Art des Bildsignals und so weiter. Im SI Modell entspricht eine Instanz dieser Klasse einer Program Mapping Table (PMT) eines Dienstes.

Auf nächster Ebene kann eine GroupInformation zu einer Quellgruppe angefordert werden. Diese enthält ausschließlich die Liste der auf der Gruppe verfügbaren Quelle, aber keine technischen Empfangsdaten. In der SI Architektur entspricht dies in etwa einer Kombination aus Program Association Table (PAT) und Service Description Table (SDT). Ein besondere Rolle spielen in DVB.NET die so genannten Dienste. Hier handelt es sich um Quellen (gemäß der SI PAT), zu denen aber keine Beschreibung (in der SI SDT) existiert. Diese sind gesondert gekennzeichnet. Die Gruppeninformation enthält als Liste von Quellen tatsächlich Instanzen der Station Klasse, da nur diese derartige Unterschiede bezeichnen – zukünftig vielleicht auch einmal Datendienste. Man beachte, dass die oben beschrieben Empfangsdaten der einzelnen Quellen bewußt nicht enthalten sind.

Mit der LocationInformation kann schließlich die Liste der Quellgruppen (nicht der Gruppeninformationen) eines Ursprungs ermittelt werden – entsprechend der Network Information Table (NIT) in der SI Architektur. Diese .NET Klasse liegt in spezifischen Varianten für DVB-S, DVB-C und DVB-T vor (SatelliteLocationInformation et al), was die Handhabung in Einzelfällen vereinfacht.

Für alle Informationensklassen ist zu beachten, dass die Qualität und Quantität der enthaltenen Daten vom jeweiligen Anbieter abhängt. DVB.NET 4.0 wird vermutlich analog zur bekannten Nachbearbeitung der Senderliste manuelle Korrekturmöglichkeiten anbieten – etwa um ITV HD empfangen zu können. Die Informationen zu den Quellgruppen eines Ursprungs scheinen für DVB-S und DVB-C relativ gut und symmetrisch zu sein (alle Quellgruppen melden die selben Informationen zur Verfügbarkeit anderere Quellgruppen), wo hingegen DVB-T schon konzeptionell sehr viel segmentierter angelegt ist.

Bis denmächst

Jochen