softhddevice mit High Level OSD

Ein OSD Plugin finde ich eine gute Idee.
Erhöht die Wartbarkeit, reduziert doppelte Arbeit, macht flexibler.

Zitat von reufer

Meinst du sowas:

Code

rpihddevice (1.0.2) - HD output device for Raspberry Pi


  -d,       --disable-osd  disable OSD

Ja, sowas hab ich gemeint.

Und jetzt noch für softhddevice (Patch könnte ich auch selbst liefern).

Lars.

Zitat von chriszero

Ein OSD Plugin finde ich eine gute Idee.
Erhöht die Wartbarkeit, reduziert doppelte Arbeit, macht flexibler.

Geht natürlich nur bei Ausgabeplugins, wo sich Anzeige des Video und Anzeige des OSDs auch wirklich trennen lässt.
dvb[hs]ddevice sind da wahrscheinlich draußen vor. Natürlich kann man die auch dazu bringen, kein OSD anzuzeigen, aber dann kann ein Plugin wohl auch nicht über dieses Gerät ein OSD anzeigen. Denkbar ist dann aber natürlich ein OSD, welches woanders ausgegeben wird (zweites Display an der Grafikkarte, ähnlich graphtftng).

Lars.

Traut sich wer mit der Abspaltung aus Louis' fork, oder soll ich es probieren?
Irgendwelche Fallstricke zu erwarten, daß das OglOsd-Plugin doch irgendwas vom Ausgabeplugin braucht, irgend eine Initialisierung, oder ist da sogar eine Reihenfolge des Startens der Plugins zu beachten?

Gruß,
Lucian

Zitat von Zoolook

ist da sogar eine Reihenfolge des Startens der Plugins zu beachten?

Das würde ich nicht erwarten. Für den vdr sind das zwei unterschiedliche Objekte. Und sollte er keinen cOsdProvider haben, erstellt er einen Dummy-Provider, der dann wieder gelöscht werden würde, wenn das Plugin seinen Provider erstellt.

Lars.

Wofür wäre denn so ein OSD-Plugin zuständig? Nur beschleunigtes Zusammenbauen inkl. Software Fallback oder auch die Darstellung an sich? Ich stell mir gerade vor was dann der Vorteil wäre, da ja trotzdem vieles für die verschiedene Hardware anders implementiert werden müsste ...
Gruß Andreas

Hier ein Patch, um das OSD in softhddevice deaktivieren zu können. Denkbar wäre natürlich auch noch ein SVDRP-Befehl, mit dem man das zur Laufzeit an- und ausschalten kann.
Parameter ist allerdings "-o", da "-d" schon belegt ist.

Lars.

Zitat von rell

Wofür wäre denn so ein OSD-Plugin zuständig?

Für das Ableiten von der Klasse cOsdProvider und Bereitstellen eines Objekts dieser Klasse.
Das schließt die komplette Darstellung des OSD ein, egal auf welchem Weg, ob nun beschleunigt oder nicht.

Für den vdr ist der cOsdProvider für das OSD und das cDevice für die Ausgabe vollkommen getrennt. Wenn es also keine technischen Gründe gibt, ist es durchaus möglich, sie in zwei Plugins aufzuteilen.

Theoretisches Weiterspinnen:
- besagtes OpenGL(/ES) OSD
- für headless Systeme eine Art Konsolen-OSD
- in dbus2vdr hab ich ein "PNG"-OSD, das OSD wird als PNG-Dateien abgelegt (inkl. Abschicken eines DBus-Signals), so dass ein externes Programm einfach die Bilder darstellen kann. Hab das aber nie weiterverfolgt.

Das einzige, was mir momentan einfällt, ist, dass softhddevice weiterhin die Tasten vom X-Server entgegen nimmt. Das ist dann ein cRemote-Objekt. Das ist natürlich auch trennbar (von Seiten des vdr), siehe lirc, remote-Plugin usw.. Aber wenn eine Tastatur angeschlossen ist und softhddevice das aktive Fenster ist, dann muss es wohl über softhddevice laufen (oder?).

Lars.

Zitat von Zoolook

Irgendwelche Fallstricke zu erwarten, daß das OglOsd-Plugin doch irgendwas vom Ausgabeplugin braucht, irgend eine Initialisierung, oder ist da sogar eine Reihenfolge des Startens der Plugins zu beachten?

VDR startet mit einen Dummy-Provider, der von Plugins überschrieben werden kann. Bis anhin waren das ausschliesslich die Ausgabedevices, weil dort prinzipbedingt das OSD an die Hardware gekoppelt ist - dort macht es auch wenig Sinn, das zu ändern. Genau gesagt tun sie das immer, wenn sie als primäres Device ausgewählt werden. Jedes Plugin kann aber seinen eigenen OSD-Provider im VDR platzieren und den bestehenden überschreiben. Somit spielt die Reihenfolge schon eine Rolle, solange die verwendeten Ausgabeplugins keinen Parameter anbieten, das zu unterbinden.

Aber ansonsten sind OSD und Ausgabedevice zwei Paar Schuhe, wie von Lars korrekt beschrieben.

Gruss
Thomas

Mit Darstellung meinte ich das auf-den-schirm-bringen durch die Hardware. Darum kümmert sich ja bei softhddevice vdpau. Und das funktioniert "relativ" untrennbar mit dem Video pro frame. Louis' implementation nutzt ja das interop feature, das ein ausgelagertes OSD zusammen mit GL oder wie auch immer ermöglicht. Um die Darstellung kümmert sich trotzdem softhddevice. Ich verstehe (noch) nicht, ob dieser part auch in ein osd Plugin kann, oder ob maximal vom Ausgabeplugin eine Fläche zur Verfügung gestellt werden kann, in die gerendert wird.
Gruß Andreas

Zitat von rell

Wofür wäre denn so ein OSD-Plugin zuständig? Nur beschleunigtes Zusammenbauen inkl. Software Fallback oder auch die Darstellung an sich? Ich stell mir gerade vor was dann der Vorteil wäre, da ja trotzdem vieles für die verschiedene Hardware anders implementiert werden müsste ...

Die Rede ist nicht von "einem OSD-Plugin", sondern z.B. von einem OpenGL-OSD-Plugin. Und das ist dann eben (weitestgehend) Hardware-unabhängig.

Eine OSD-Klasse die von cOsd ableitet ist immer für die Darstellung des OSDs zuständig, ob beschleunigt oder nicht. Objekte vom Typ cOsd kann es zudem mehrere geben, aber nur eines ist jeweils aktiv, d.h. sichtbar. (z.B. aktive Untertitel, während das Menü sichtbar ist). Erzeugt werden die spezialisierten cOsd-Objekte vom einem entsprechenden cOsdProvider, und davon gibt es immer genau eine Instanz, wohl aber mehrere Implementationen (z.B. Dummy-Provider des VDR).

So kann VDR oder ein Plugin sich jederzeit mittels des gerade aktiven OSD-Providers eine OSD-Instanz bauen lassen, und darauf zugreifen. Ob das nun ein Dummy-OSD oder ein OpenGL-OSD ist, braucht ihn dabei nicht zu kümmern - beide sind ja von cOsd abgeleitet, und diese Klasse definiert das API um auf das OSD zu zeichnen.

Gruss
Thomas

Zitat von rell

Mit Darstellung meinte ich das auf-den-schirm-bringen durch die Hardware. Darum kümmert sich ja bei softhddevice vdpau. Und das funktioniert "relativ" untrennbar mit dem Video pro frame. Louis' implementation nutzt ja das interop feature, das ein ausgelagertes OSD zusammen mit GL oder wie auch immer ermöglicht. Um die Darstellung kümmert sich trotzdem softhddevice. Ich verstehe (noch) nicht, ob dieser part auch in ein osd Plugin kann, oder ob maximal vom Ausgabeplugin eine Fläche zur Verfügung gestellt werden kann, in die gerendert wird.

Dieser Teil wäre dann tatsächlich von der Hardware abhängig - aber das wird ein vergleichsweise kleiner Teil sein. Ich kenne die Details bei VDPAU nicht, aber beim Raspi wird das vermutlich ein dispmanx-Layer sein - der entsprechende Code dürfte recht kompakt sein.

Beim Bauen des Plugins müsste der Hardware-Layer natürlich konfigurierbar sein - unter Gentoo wären das dann die USE-Flags.

Gruss
Thomas

Hallo,

habe mit dem Herausschälen des OglOsd begonnen, würde aber gerne mit Euch Wissenden zum Thema hier darüber mal diskutieren .

Gruß,
Lucian

Zitat von louis

@Seahawk: könntest du das bitte mal testen?

Ja, ich bau gleich mal neue Pakete für die yaVDR PPAs

Das sieht nach den ersten Reboot-Versuchen vielversprechend aus - ich beobachte das mal über die nächsten Tage.

Anyone else having problems with dvbsubtitles when using softhddevice-openglosd? Back in March those worked fine. Now I installed again softhddevice-openglosd and dvbsubtitles is not showing at all.
Currently using latest version from yavdr-testing repo.

Zitat von louis

Hi,

last change regarding subtitles was this commit from 6th of march. After that nothing changed regarding subtitles.

Cheers Louis

I installed softhddevice-openglosd again and now subtitles is showing but in very small font and on the top left corner. Also osd flickers every time when subtitles is showing.

I kinda remember that subtitles stopped working after that subtitle commit on march 6th and after that I've forced to install whole system again (harddrive failed) and stayed on regular softhddevice.