softhddevice mit High Level OSD


  • 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.

  • 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? ;D
    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



    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • 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.

  • 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.

  • 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

  • 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

  • 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



    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • Moin,


    ich habe mir jetzt nochmal das Problem mit dem Crash beim detachten Starten von SHD ohne laufendes X angesehen. Ich habe das ganze jetzt mal so umgestellt, dass ich ein wirkliches "DummyOsd" verwende, das gar nix macht. Ich hoffe, damit sid die von Seahawk gemeldeten Crashes diesbezüglich beseitigt.


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


    Des weiteren habe ich mal diesen Patch in mein Git aufgenommen, damit der nicht verloren geht...


    Ciao Louis

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

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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


    Na das klingt doch gut...was noch sein könnte, das der benutze Skin crasht, da ich im cDummyOsd::GetPixmap() NULL zurückgebe. Das wäre aber dann ein Problem im Skin und gesondert zu behandeln.


    Ciao Louis

  • 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.

  • Hi,

    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.


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


    Cheers 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.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!