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

DVB.NET 4.0 Konzepte: Glossar

Bevor ich demnächst einiges zum aktuellen Stand von DVB.NET 3.5.1 erzähle (zur Erinnerung: hier werden nur erste Teile von 4.0 enthalten sein) einige Worte zur veränderten / verallgemeinerten Nomenklatur.

Eine Quelle bezeichnet eine DVB Sendeeinheit und ist im Allgemeinen entweder ein Fernseh- oder ein Radiosender, technisch sind aber auch Datendienste vorgesehen. Repräsentiert wird eine Quelle in DVB.NET durch die Klasse SourceIdentifier, in etwa dem alte Identifier entsprechend. Eine Quelle wird eindeutig durch ein Tripel (Originale Netzwerkkennung, Datenstromkennung, Dienstkennung) gekennzeichnet – ein über DVB-C empfangens ZDF hat in diesem Sinne im Allgemeinen die gleiche Quelle wie das über DVB-S empfangene.

DVB.NET selbst unterstützt allerdings keine Datendienste, sondern nur Sender, die durch die Klasse Station repräsentiert werden. Ein Sender ist nichts anderes als eine erweiterte Quelle – auch im Sinne der .NET Vererbungsachse. Zusätzlich zu den Daten der Quelle enthält ein Sender Informationen zur Auswahl durch den Anwender (Anzeigename, Name des Dienstanbieters) und zur Planung von Aufzeichnungen (Entschlüsselung notwendig). Ein Sender enthält aber keine Datenstromkennungen zum Empfang selbst (PID des Bildsignals etwa). Wie früher bereits einmal erwähnt soll DVB.NET 4.0 sehr viel dynamischer auf Änderung dieser technischen Daten reagieren können. Tatsächlich wird eine DVB.NET 4.0 Senderliste nur diese reduzierte Fassung eines Senders enthalten!

Quellen werden zu Quellgruppen zusammengefasst, früher als Transponder bezeichnet. Eine Quellgruppe beschreibt die technischen Empgfangsdaten wie Frequenz und Modulation in drei unterschiedlichen Basisklassen für DVB-S (SatelliteGroup), DVB-C (CableGroup) und DVB-T (TerrestrialGroup), alle von einer gemeinsamen .NET Basisklasse SourceGroup abgeleitet. Neben den technischen Daten sind alle Quellen enthalten, die von der jeweiligen Quellgruppe angeboten werden.

Speziell für DVB-S wurde zusätzlich das Konzept des Ursprungs eingeführt, am besten mit den alten DiSEqC Varianten zu vergleichen. Jede Quellgruppe hat einen Ursprung, der beschreibt, wie die Gruppe empfangen werden kann. Die .NET Klasse SatelliteLocation ist von einer Basisklasse GroupLocation abgeleitet, die auch über generische Varianten zu entsprechenden DVB-C und DVB-T Klassen führt – wobei es hier im allgemeinen nur einen einzigen Ursprung (Default Location) gibt. Jeder Ursprung enthält neben den Empfangsdaten alle Quellgruppen, die nach Auswahl empfangen werden können.

Eine DVB.NET 4.0 Senderliste ist im Wesentlichen die als XML serialisierte Form einer Liste von Ursprüngen.

Tschüss

Jochen

Spaß mit Extensionmethoden – hier: zyklische Referenzen von Assemblies

Man stelle sich eine Anwendung vor, die aus zwei Assemblies besteht. Die eine enthält ausschließlich Klassen, die zur Konfiguration dienen und etwa in die XML Repräsentation serialisiert werden. Als Beispiel eine Klasse StationInformation, die zu einem Fernsehsender alle Informationen für einen DVB Empfang beinhaltet (PIDs, um es konkret zu machen). Diese Assembly ist von nichts ausser .NET abhängig. Eine andere DLL implementiert einen DVB Zugriff über BDA und ist reichlich von diversen Bibliotheken abhängig. Natürlich auch von unserer ersten Assembly. In der zweiten Assembly gibt es etwa eine Klasse DVBHardware mit einer Methode UpdateStation, die eine StationInformation als Parameter erhält und die Empfangsdaten auf den aktuellen Stand bringt (etwa gibt es nur zeitweise einen Videotext wie bei KiKa).

Die Abhängigkeit der Assemblies zwingt nun erst einmal einen Anwender der Bibliotheken, die DVBHardware Instanzen ins Zentrum seines Denkens zu stellen: nur hier kann es Methoden geben, die beide Assemblies nutzen. Mit einer Extensionmethode läßt sich aber nun einfach eine Flexibilität erreichen, die eine natürlicher Sicht auf die Dinge erlaubt (eigentlich interessiert mich der Empfang eines Senders, die verwendete Hardware ist eigentlich zweitrangig): mit

public static void Update
(
this StationInformation station,
DVBHardware hardware
)
{
hardware.Update(station);
}

kann nun alternativ auch StationInformation.Update(hardware) aufgerufen werden. Aus Sicht des Anwenders, der beide Assemblies gleichzeitig verwendet und beim IntelliSense nicht so genau hinschaut sieht es fast aus, als würden sich die beiden Assemblies hier gegenseitig (zyklisch) referenzieren.

Wie dem auch sei und unabhängig davon, ob das Beispiel trägt: Extensionmethoden machen es beim Design von Bibliotheken einfacher, sich nicht schon früh auf eine Sichtweise festlegen zu müssen. Eine vollständig symmetrische Sicht ist zwar nicht immer notwendig und man kann es dabei auch leicht übertreiben, aber in Einzelfällen halte ich das für eine durchaus interessante Option – ausserhalb der trivialen Bedeutung, scheinbar abgeschlossene Klassen mit neuen Instanzmethoden erweitern zu können.

Happy Coding

Jochen