[vdr] VDR developer version 1.3.1

Hi,

ich hab die neue Version bereits installiert, funktioniert alles bestens. Sehr gute Arbeit, Klaus, besonders die Umschaltzeiten gefallen mir seit der 1.3.0 sehr gut. Nun gibt es ja unter --> Einstellungen-->DVB eine Setup-Option, um die AutoPID-Funktion einzustellen. Was bedeutet hierbei denn die Option "neue Transponder"? Ich dachte er kann nur auf den Transpondern Kanäle updaten, die man auch schon in der channels.conf stehen hat...und wofür genau stehen die "preferred languages"? Ich hab zwar die ML verfolgt, aber das nie so richtig verstanden..

mfg maz

...und da der Boergen die neuen Developer-Versionen liebt, spendiert er sogleich nen Patch, der folgendes enthält:

AC3OverDVB 0.2.4
QuickAIO+ImprovedOSD (der drachenreitende LordJaxom möge mir verzeihen )

Ich nutze die 1.3.0 (mit kritischen Patches) nun schon seit einigen Tagen und muss sagen, dass sie für eine Developer-Version schon verdammt stable ist.
OSDTeletext und MP3 (mit Anpassungen) funktioniert übrigens schon.

Wenn doch nur die Plugin-Entwickler endlich Gas geben würden.

(EDIT) ...und jetzt das ganze MIT dem Patch...

http://www.kaputtkloppen.de/vd…ickAIO+AC3OverDVB.diff.gz

Zitat

Original von maz
Hi,

ich hab die neue Version bereits installiert, funktioniert alles bestens. Sehr gute Arbeit, Klaus, besonders die Umschaltzeiten gefallen mir seit der 1.3.0 sehr gut. Nun gibt es ja unter --> Einstellungen-->DVB eine Setup-Option, um die AutoPID-Funktion einzustellen. Was bedeutet hierbei denn die Option "neue Transponder"? Ich dachte er kann nur auf den Transpondern Kanäle updaten, die man auch schon in der channels.conf stehen hat...

Grundsätzlich ja. Aber beim Einbau der NIT-Bearbeitung habe ich gesehen, daß
einige Transponder durchaus die Dateien einer Reihe von anderen Transpondern
übertragen. Somit kann man, ausgehend von _einem_ Transponder, mehrere
andere bekommen.

Zitat

und wofür genau stehen die "preferred languages"? Ich hab zwar die ML verfolgt, aber das nie so richtig verstanden..

mfg maz

HIer hilft ein Blick in die MANUAL-Datei

Preferred languages = 0
Some tv stations broadcast their EPG data in various
different languages. This option allows you to define
which language(s) you prefer in such cases. By default,
or if none of the preferred languages is broadcast, any
language will be accepted and the EPG data will be
displayed in the first language received from the data
stream. If this option is set to a non-zero value, the
menu page will contain that many "Preferred language"
options which allow you to select the individual preferred
languages. If an actual EPG data record is received in
different languages, the preferred languages are checked
in the given order to decide which one to take.

Klaus

Hi,

Zitat

Somit kann man, ausgehend von _einem_ Transponder, mehrere
andere bekommen

Cool, irgendwie scheint in der Digitaltechnologie doch manchmal mehr herauszuholen zu sein, als man zunächst meint. Wenn man dann einmal eine ordentliche channels.conf zusammengebastelt hat, braucht man eigtl ja gar keinen "Kanalscanner" mehr, da sie sich quasi selbst pflegt. Nur sortieren muss man noch...
Da fällt mir gerade ein: Wie sieht es eigtl mit "toten" Kanälen aus? Ich bin sicher nicht der einzige, in dessen Kanalliste sich mit der Zeit immer mehr "schwarze" Kanäle ansammeln, auf denen gar nicht mehr gesendet wird. Es müsste doch mit der AutoPID Funktion möglich sein, solche Kanäle aufzuspüren, oder führt das jetzt zu weit?

Zitat

Somit kann man, ausgehend von _einem_ Transponder, mehrere
andere bekommen

OK Schande über mich, jetzt hab ichs aber verstanden. Auch eine wirklich nützliche Erweiterung.

maz

hi boergen,
wie sind den die anpassungen für das mp3 plugin?

mfg
ernie

Zitat

Original von ernie
hi boergen,
wie sind den die anpassungen für das mp3 plugin?

mfg
ernie

Na hier:

http://www.kaputtkloppen.de/mp3-0.8.2-1.3.1.diff.gz

ABER:

Die Loorbeeren dafür verdient einzig und allein LordJaxom, der so nett war, mir die kleinen Änderungen im Chat mitzuteilen.

Danke nochmal dafür !

Hi,

Zitat

Original von kls

Grundsätzlich ja. Aber beim Einbau der NIT-Bearbeitung habe ich gesehen, daß
einige Transponder durchaus die Dateien einer Reihe von anderen Transpondern
übertragen. Somit kann man, ausgehend von _einem_ Transponder, mehrere
andere bekommen.

Der Senderscan des Tuxbox-Projekts nutzt eben diese Eigenschaft, um ausgehend von einigen Default-Transpondern (festgelegt per config) das restliche Network zu scannen. Für eine spätere Scan-Funktion könnte man das vieleicht von der DBox2 übernehmen...

Ansonsten kann ich auch nur sagen das die 1.3.1 bisher beim testen recht gut läuft. Was ich allerdings für problematisch bzw. weniger Sinnvoll halte ist das "Feature", das man nicht auf verschlüsselte Kanäle schalten kann für die man gerade kein passendes CI eingesteckt hat. Mir fallen Adhoc 2 Beispiele ein: Zum einen bedeutet das ein CI vorhanden ist noch nicht, das eine Karte eingesetzt ist, bzw. wenn Karte vorhanden diese auch den Kanal entschlüsselt.

Zum anderen können durchaus auch Kanäle, die CA-ID´s in der PMT (war´s glaub ich) führen, zeitweise FTA senden. Im Grunde müßte man das scrambling control field im TS abfragen um eine entgültige Aussage zu treffen, was ich aber auch nicht für Praktikabel halte.

Besser wäre hier vieleicht, den Output der Karte auf nutzbare Daten zu testen, und falls nicht vorhanden (früher: no usefull data within...), eine OSD-Meldung einblenden wie zB "scrambled or not available" und dann im Hintergrund, solange man auf diesem Kanal ist, in gewissen Zeitabständen weiter testet ob was nutzbares kommt. Letzteres damit zum Beispiel bei einer noch nicht freigeschalteten Karte auch Bild kommt sobald die Freischaltung da ist.

Natürlich kann ich jetzt durchaus auch was übersehen haben für das diese Funktion wichtig wäre, wenn ja bitte ich das zu entschuldigen.

Aber eine Frage noch: Ist es nun möglich mehrere Werte <=0010 im ca-Feld zu setzen für den Fall eines komplexeren Mehrkarten-Systems?

Andy

Zitat

Original von Andy.2k
Hi,

Der Senderscan des Tuxbox-Projekts nutzt eben diese Eigenschaft, um ausgehend von einigen Default-Transpondern (festgelegt per config) das restliche Network zu scannen. Für eine spätere Scan-Funktion könnte man das vieleicht von der DBox2 übernehmen...

Möglich. Ich bin in der Ecke ja auch noch nicht fertig

Zitat

Ansonsten kann ich auch nur sagen das die 1.3.1 bisher beim testen recht gut läuft. Was ich allerdings für problematisch bzw. weniger Sinnvoll halte ist das "Feature", das man nicht auf verschlüsselte Kanäle schalten kann für die man gerade kein passendes CI eingesteckt hat. Mir fallen Adhoc 2 Beispiele ein: Zum einen bedeutet das ein CI vorhanden ist noch nicht, das eine Karte eingesetzt ist, bzw. wenn Karte vorhanden diese auch den Kanal entschlüsselt.

Tja, das ist leider eine Schwäche des ganzen CICAM-Mechanismus.
Laut Standard sollte es möglich sein, ein CAM zu "fragen", ob es eine
bestimmte Sendung entschlüsseln kann oder nicht. Nur leider liefert weder
mein Irdeto AllCAM noch mein Alphacrypt CAM auf die entsprechende
Anfrage eine Antwort.

Vielleicht habe ich da ja auch was falsch gemacht. Falls jemand Zeit und
Lust hat, da mal zu testen, sollte er mal in VDR/ci.c in cCiCaPmt::AddCaDescriptors()
anstatt CPCI_OK_DESCRAMBLING den Wert CPCI_QUERY verwenden und
schauen, ob das CAM dann eine AOT_CA_PMT_REPLY liefert. Wäre toll,
wenn wir das zum funktionieren kriegen würden, denn dann könnte man das
so machen, wie vom Standard vorgesehen.

Zitat

Zum anderen können durchaus auch Kanäle, die CA-ID´s in der PMT (war´s glaub ich) führen, zeitweise FTA senden. Im Grunde müßte man das scrambling control field im TS abfragen um eine entgültige Aussage zu treffen, was ich aber auch nicht für Praktikabel halte.

Soweit ich gesehen habe schalten die Sender in einem solchen Fall die CA-IDs
dann von selber ab, d.h. falls ein normalerweise verschlusselter
Sender unverschlüsselt sendet, wird VDR das merken. Such' mal nach Logfile-
Einträgen wie

Jan 12 07:31:37 video vdr[1604]: changing caids of channel 1249 from 100 to 0
...
Jan 12 07:54:42 video vdr[1604]: changing caids of channel 1249 from 0 to 100

HIer hat anscheinend Kanal 1249 ca. 20 Minuten unverschlüsselt gesendet.

Zitat

Besser wäre hier vieleicht, den Output der Karte auf nutzbare Daten zu testen, und falls nicht vorhanden (früher: no usefull data within...), eine OSD-Meldung einblenden wie zB "scrambled or not available" und dann im Hintergrund, solange man auf diesem Kanal ist, in gewissen Zeitabständen weiter testet ob was nutzbares kommt. Letzteres damit zum Beispiel bei einer noch nicht freigeschalteten Karte auch Bild kommt sobald die Freischaltung da ist.

Den Datenstrom zu "testen" halte ich nicht für gut, denn im Live-Modus (mit CAM
in der primären Karte) würde der ja gar nicht gelesen.

Ich werde es aber wohl noch so ändern, daß man "bewußt" (aus dem Channels-
Menü oder über Zifferneingabe) durchaus auf einen solchen Kanal schalten kann,
und diese nur beim "Zappen" mit Up/Down übersprungen werden.

Zitat

Natürlich kann ich jetzt durchaus auch was übersehen haben für das diese Funktion wichtig wäre, wenn ja bitte ich das zu entschuldigen.

Aber eine Frage noch: Ist es nun möglich mehrere Werte <=0010 im ca-Feld zu setzen für den Fall eines komplexeren Mehrkarten-Systems?

Andy

Es kann nur _ein_ Wert aus dem Bereich 0x00 bis 0xFF benutzt werden,
Ansonsten stehen da die CA-System-IDs (welche mehrere sein können und alle
größer als 0xFF sind).

Klaus

Gibt es optische Veränderungen bei der neuen Version? Habe noch 1.2.6. drauf...

Zitat

Original von Nomad
Gibt es optische Veränderungen bei der neuen Version? Habe noch 1.2.6. drauf...

Keine optischen Veränderungen. Das Zappen ist, im Vergleich zur alten Version mit AutoPid, um vieles schneller geworden. Außerdem scheint endlich der 5-Uhr-Morgens-Absturz behoben zu sein. Das sind für mich die zwei Gründe, schon jetzt die 1.3.1 einzusetzen.

Bisher funktionieren nur einige Plugins mit der neuen Version. Bei mir sind das MP3, Streamdev und OSDTeletext.

Hi,

Zitat

Tja, das ist leider eine Schwäche des ganzen CICAM-Mechanismus.
Laut Standard sollte es möglich sein, ein CAM zu "fragen", ob es eine
bestimmte Sendung entschlüsseln kann oder nicht. Nur leider liefert weder
mein Irdeto AllCAM noch mein Alphacrypt CAM auf die entsprechende
Anfrage eine Antwort.

das kann das CI Prinzip-bedingt immer erst dann, wenn wir schon auf dem Kanal sind. Das CI "weiß" die CA-Id´s die es selbst verarbeiten kann und weiß die CA-ID die die Karte benutzt, aber es weiß weder die ECM-Pid des Kanals auf den wir umschalten wollen, noch weiß es ob die Karte selbst den Kanal entschlüsseln kann. Erst wenn wir auf dem Kanal sind bekommen bekommen wir die nötigen Pids und dann den ersten ECM der an die Karte geht. Je nach Antwort der Karte werden weitere ECM´s probiert (für einen Kanal können es durchaus verschiedene ECM´s sein), solange bis entschlüsselt wird im Grunde. Wird entschlüsselt, filtert das CI den ECM-Stream weiter vor damit immer der gleiche ECM-Stream benutzt wird.

Also vor dem Umschalten keine Möglichkeit herauszufinden ob sich ein Kanal tatsächlich entschlüsseln läßt, nur eine Vorselektion kann man treffen. Auf dem Kanal selbst müßte das CI aber nähere Info´s geben, um zum Beispiel OSD-Meldungen wie "scrambled" einzublenden.

Zitat

Es kann nur _ein_ Wert aus dem Bereich 0x00 bis 0xFF benutzt werden,
Ansonsten stehen da die CA-System-IDs (welche mehrere sein können und alle
größer als 0xFF sind).

Hmm, wenn man das ändern könnte, könnte man vieleicht ganz auf die ca.conf verzichten. Ausgehen davon, das wir über die CA-IDs die ein CI liefert nicht sicher gehen können, das der Kanal nun auch entschlüsselt wird und dem dynamischen aktualisieren der CA-ID´s des aktuellen Kanals, wäre es da nicht besser die CA-ID´s in der channels.conf fallen zu lassen um das ganze nicht unnötig aufzublähen? Das würde auch das aktualisieren eines verschlüsselten Kanals vereinfachen da wir die CA-ID´s nur noch intern (müssen wir uns dann eigentlich überhaupt noch darum kümmern?) benutzen und aktualisieren.

Statt dessen vieleicht auf dem Kanal selbst schauen was das Cam antwortet (hier müßte es an sich Auskunft geben ob es entschlüsseln kann oder nicht) und die weitere Verarbeitung darauf abstimmen. Und entsprechend Kanäle nur sperren, wenn eine Karte Aufgrund des Empfangs nicht in der Lage ist den Kanal darzustellen.

Bitte versteh mich nicht falsch, vdr ist dein Projekt, und es ist absolut klasse, ich benutze seit 2 Jahren vdr obwohl ich DBox1,2 und nen Hyundai im Schrank stehen habe, nur denke ich einfach das das CA-System so nicht richtig funktionieren wird und uns mehr Nach- als Vorteile bringt.

Andy

Zitat

Original von Andy.2k
Hi,

das kann das CI Prinzip-bedingt immer erst dann, wenn wir schon auf dem Kanal sind. Das CI "weiß" die CA-Id´s die es selbst verarbeiten kann und weiß die CA-ID die die Karte benutzt, aber es weiß weder die ECM-Pid des Kanals auf den wir umschalten wollen, noch weiß es ob die Karte selbst den Kanal entschlüsseln kann. Erst wenn wir auf dem Kanal sind bekommen bekommen wir die nötigen Pids und dann den ersten ECM der an die Karte geht. Je nach Antwort der Karte werden weitere ECM´s probiert (für einen Kanal können es durchaus verschiedene ECM´s sein), solange bis entschlüsselt wird im Grunde. Wird entschlüsselt, filtert das CI den ECM-Stream weiter vor damit immer der gleiche ECM-Stream benutzt wird.

Also vor dem Umschalten keine Möglichkeit herauszufinden ob sich ein Kanal tatsächlich entschlüsseln läßt, nur eine Vorselektion kann man treffen. Auf dem Kanal selbst müßte das CI aber nähere Info´s geben, um zum Beispiel OSD-Meldungen wie "scrambled" einzublenden.

Alles anzeigen

Alles schön und gut, nur sollte das CAM halt auf jeden Fall auf CPCI_QUERY
mit AOT_CA_PMT_REPLY antworten - im Zweifelsfall halt mit "Nö, kann ich nicht".
Wenn es zum endgültigen Feststellen, ob es denn nun geht, nötig ist, erstmal
auf diesen Kanal zu schalten, soll mir das auch recht sein - aber erstmal muß
das CAM überhaupt reagieren. Wie gesagt, vielleicht habe ich das ja bisher immer
falsch gemacht, denn wenn ich dem CAM eine solche Anfrage geschickt habe,
hat es einfach nur die Anfrage bestätigt, aber keine AOT_CA_PMT_REPLY
geliefert.

Zitat

Hmm, wenn man das ändern könnte, könnte man vieleicht ganz auf die ca.conf verzichten. Ausgehen davon, das wir über die CA-IDs die ein CI liefert nicht sicher gehen können, das der Kanal nun auch entschlüsselt wird und dem dynamischen aktualisieren der CA-ID´s des aktuellen Kanals, wäre es da nicht besser die CA-ID´s in der channels.conf fallen zu lassen um das ganze nicht unnötig aufzublähen? Das würde auch das aktualisieren eines verschlüsselten Kanals vereinfachen da wir die CA-ID´s nur noch intern (müssen wir uns dann eigentlich überhaupt noch darum kümmern?) benutzen und aktualisieren.

Mir gefällt das so, wie es jetzt ist, schon ganz gut, denn damit erfolgt schonmal
eine grobe Vorselektierung dergestalt, daß mein VDR gar nicht auf Kanäle
schaltet, von denen er von hause aus weiß, daß er sie nicht entschlüsseln _kann_,
da kein entsprechendes CAM vorhanden ist.

Eine weitere "Verfeinerung" des Ganzen setzt. m.E. voraus, daß die CPCI_QUERY
Sache zum Funktionieren gebracht wird.

Zitat

Statt dessen vieleicht auf dem Kanal selbst schauen was das Cam antwortet (hier müßte es an sich Auskunft geben ob es entschlüsseln kann oder nicht) und die weitere Verarbeitung darauf abstimmen. Und entsprechend Kanäle nur sperren, wenn eine Karte Aufgrund des Empfangs nicht in der Lage ist den Kanal darzustellen.

Hmmm, könnte es sein, daß mein Fehler tatsächlich darin liegt, daß ich das
CAM "befragt" habe _ohne_ auf den entsprechenden TP getunt zu haben?
Wäre möglich, denn ich wollte ja die grundsätzliche Funktionalität des
CPCI_QUERY testen und hätte erwartet, daß es auf jeden Fall eine wie auch
immer geartete Antwort schickt...

Zitat

Bitte versteh mich nicht falsch, vdr ist dein Projekt, und es ist absolut klasse, ich benutze seit 2 Jahren vdr obwohl ich DBox1,2 und nen Hyundai im Schrank stehen habe, nur denke ich einfach das das CA-System so nicht richtig funktionieren wird und uns mehr Nach- als Vorteile bringt.

Andy

Da VDR ja jetzt automatisch hunderte von Kanälen findet halte ich es durchaus
für sinnvoll, die verschlüsselten beim Zappen gleich im Vorfeld zu überspringen wenn
sich herausstellt, daß es dafür gar kein Device gibt, das sie entschlüsseln kann.
Weiteres hängt meiner Meinung nach davon ab, ob es uns gelingt, die CPCI_QUERY
Funktionalität zum Laufen zu kriegen, denn dann weiß man genau, was Sache ist.

Und letztendlich sind wir ja eh' erst am Anfang der 1.3-Entwicklung, da kann sich
noch einiges ändern

Klaus

Zitat

Und letztendlich sind wir ja eh' erst am Anfang der 1.3-Entwicklung, da kann sich noch einiges ändern

Na so seh ich das auch:)

Zitat

Mir gefällt das so, wie es jetzt ist, schon ganz gut, denn damit erfolgt schonmal
eine grobe Vorselektierung dergestalt, daß mein VDR gar nicht auf Kanäle
schaltet, von denen er von hause aus weiß, daß er sie nicht entschlüsseln _kann_,
da kein entsprechendes CAM vorhanden ist.

Hier könnte man sich vieleicht auf eine Setup-Option einigen;)

Zum CA_PMT_repley hab ich noch folgendes gefunden:

Zitat

9.5.5.2. CA_PMT_reply
CA_PMT_reply is the response of the CA application running in the module. It is sent only in response of a
CA_PMT with ca_pmt_cmd_id = 'query' or 'ok_mmi'. It is not sent in response of a CA_PMT with
ca_pmt_cmd_id = 'ok_descrambling'. CA_PMT_reply is used during the module selection procedure. The
complete description of the selection procedure is given in the attached flowcharts. CA_PMT_reply contains a
parameter called CA_enable which indicates, for the whole selected programme or for each elementary_stream
of the selected programme, whether descrambling is possible or not, and at which condition.
It may happen that CA_enable has different values for two ES of the same programme. See sub-clause 1.2.3
below.

Alles anzeigen

Das bezieht sich auf jeden Fall auf das selektierte Programm, allerdings werd ich nicht schlau drauss, ob das CI nun ein CA_Enable von sich aus schickt, oder in Verbindung mit einer für diesen Kanal freigeschalteten Karte. Von der Logik her sollte erst die Einheit Karte & CI ein funktionierendes CA-System ergeben.

Es scheint übrigens tatsächlich Fälle zu geben in denen von scrambled -> FTA ohne Änderungen in der PMT umegschaltet wird.

Zitat

9.5.6.2. Switch from scrambled to unscrambled and vice-versa
· When one programme switches from scrambled to clear, there are several possibilities:
1. This change is not signalled in the PMT, but only in the TSC field of the packet header or in the
PES_SC field of the PES header. In this case, there is no reason for the host to send a new CA_PMT to
remove the programme from the list. The programme remains selected and the host keeps on sending
CA_PMT when the version_number of the PMT evolves.
2. This change results in a modification of the PMT. In this case, a CA_PMT is issued by the host.

Alles anzeigen

Beides stammt aus der "Guideline for Implementation and Use
of the Common Interface for DVB
Decoder Applications" die ich doch recht interessant finde.

Andy

Ich hätte gerne gewusst, ob sich im Bereich des "neuen Plugin-Systems" noch etwas entwickeln wird. Ich weiss jetzt zwar nicht, ob das Ganze nur ein Gerücht ist, aber ich habe mal gelesen, dass es mit VDR-1.3.x (vielleicht) möglich sein wird, das OSD in ein Plugin "auszulagern". Ich persönlich wäre ja an eigenen Output-Plugins interessiert, die zum Beispiel das OSD direkt mit den Funktionen der Grafikkarte rendern (Stichwort "DirectFB" :)). Das wäre wirklich genial!
Ist so etwas in der Art vielleicht in Planung?

Zitat

Original von gEistiO
Ich hätte gerne gewusst, ob sich im Bereich des "neuen Plugin-Systems" noch etwas entwickeln wird. Ich weiss jetzt zwar nicht, ob das Ganze nur ein Gerücht ist, aber ich habe mal gelesen, dass es mit VDR-1.3.x (vielleicht) möglich sein wird, das OSD in ein Plugin "auszulagern". Ich persönlich wäre ja an eigenen Output-Plugins interessiert, die zum Beispiel das OSD direkt mit den Funktionen der Grafikkarte rendern (Stichwort "DirectFB" :)). Das wäre wirklich genial!
Ist so etwas in der Art vielleicht in Planung?

Ja.

Klaus

Hallo Boergen

bei mir geht der Patch vdr-1.3.1-QuickAIO+AC3OverDVB.diff.gz nicht so richtig.
Makefile:122 *** missing separator. Stop.

karli

Zitat

Original von kls

Ja.

Klaus

Genial! Hattest du DirectFB eigentlich in die engere Wahl gezogen? Kannst du jetzt schon ungefähr sagen, wann wir mit den ersten Plugins rechnen können bzw. wann du anfangen wirst, daran zu arbeiten...?! Ich kann es schon nicht mehr erwarten...

Zitat

Original von gEistiO
Ich hätte gerne gewusst, ob sich im Bereich des "neuen Plugin-Systems" noch etwas entwickeln wird. Ich weiss jetzt zwar nicht, ob das Ganze nur ein Gerücht ist, aber ich habe mal gelesen, dass es mit VDR-1.3.x (vielleicht) möglich sein wird, das OSD in ein Plugin "auszulagern". Ich persönlich wäre ja an eigenen Output-Plugins interessiert, die zum Beispiel das OSD direkt mit den Funktionen der Grafikkarte rendern (Stichwort "DirectFB" :)). Das wäre wirklich genial!
Ist so etwas in der Art vielleicht in Planung?

Ich denke da hast du etwas falsch verstanden (oder vielleicht hab ich es auch falsch verstanden *g*). Ein Output-Plugin zu schreiben, welches auch das OSD selberzeichnet, ist schon seit 1.1.x möglich. Der VDR selbst und seine PlugIns zeichnet sein OSD auf das Gerät (also DVB-Karte oder Output-PlugIn), und jedes Gerät tut das was es tun muss um das OSD sichtbar zu machen.

Die OSD-PlugIns sollen lediglich das Aussehen des Plugins bestimmen, unabhängig davon wo es hingezeichnet wird.