OglOsd - Aufruf zum Feinschliff der Konzepte

    Zitat von louis

    Wie genau meinst du denn das bzw. wie stellst du dir das vor? Mit "für normales X zum funktionineren bringen" kann ich irgendwie nicht wirklich was konkretes anfangen ;)

    Konkret meine ich, deinen Code vorerst von softhddevice/VDPAU zu trennen und als eigenständiges Plugin auf einem Desktop-Rechner zum Laufen zu bringen. Beispiele für OpenGL gibt es ja zu Hauf, die rendern einfach in ein normales X-Window. Natürlich ist der Nutzen erst mal gering, aber man könnte schon mal VDR ohne Ausgabeplugin laufen lassen und dazu bringen, ein beschleunigtes OSD zu zeichnen. Dieser Code würde dann als Basis dienen, womit sich die diversen Spezialisten hier im Forum um die plattformspezifischen Anpassungen kümmern können.


    Zitat von louis

    Eine andere Frage, die sich mir stellt: anschienend gibt es eine OpenGL ES Unterstützung auf dem Raspi...Ich verstehe nur nicht ganz den Zusammenhang zu diesem dispmanx Zeugs und bin jetzt auch zu faul, das genau nachzulesen ;) Wäre es theoretisch möglich, mit identischem Code auf dem Raspi und auf anderen ARM Boards, die OpenGL ES unterstützen, zu arbeiten? Oder wäre dieser Code dann immer noch plattformspezifisch?

    dispmanx ist quasi das X für den Raspi, einfach ohne Fenster - mal einfach ausgedrückt. ;) Und ja, Andreas hat ja deinen Code mit minimalen Anpassungen bereits auf seinem Allwinner SoC am laufen und der Raspi kann auch OpenGL ES. Gerade das macht die Idee ja interessant...


    Nur damit wir uns nicht falsch verstehen: OpenVG läuft auf dem Raspi einwandfrei und persönlich habe ich kein Bedürfnis of OpenGL zu wechseln. Aber es wird ja beispielsweise an der MMAL-Ausgabe für softhddevice gearbeitet, da käme ein Raspi-OpenGL-OSD sicher gelegen. Und vielleicht gibt es ja andere Leute, die ein OpenGL-OSD zusammen mit rpihddevice nutzen wollen, oder wiederum andere wünschen sich vielleicht das selbe zusammen mit xineliboutput?


    Irgendwie fühle mich gerade ein wenig einsam mit meiner Idee - ist aber kein Problem, ich kann mich auch anderweitig beschäftigen. ;)


    Gruss
    Thomas

    Zitat von louis

    Ich verstehe nur nicht ganz den Zusammenhang zu diesem dispmanx Zeugs und bin jetzt auch zu faul, das genau nachzulesen


    Dispmanx ist eine Raspi spezifische Schnittstelle die DRM ein bissel ähnlich ist. DRM gibt es soweit ich weiss für alle Plattformen oder sind in Entwicklung. Könnte das der kleinste gemeinsame Nenner sein? Opengl mit Ausgabe auf DRM/KMS.


    Gruss zille

    Hallo,


    na bin doch froh, daß Ihr Euch zu Wort gemeldet habt, da kam die eine oder andere Erkenntnis mit 'rüber, und noch dazu, ich habe mich an die PSL ("Plugin Shared Libraries") erinnert, die ich mal vor ziemlich genau 3 Jahren vorschlagen wollte, jetzt könnten sie tatsächlich zum Einsatz kommen. Das sind im Grunde genommen nichts anderes als dynamische Programmbibliotheken, aber mit VDR-"know-how", also werden sie VDR als Abhängigkeit haben und demnach ähnlich wie seine Plugins gebaut und installiert, bloß daß sie nicht als solche gestartet werden, sondern lediglich von einem oder mehreren Plugins genutzt werden können.


    So stelle ich mir demnach das vor:

    • Louis' und auch Andreas' an SHD hinzugefügten OpenGL/ES Code, den ich praktisch schon konsolidiert habe in ein eigenständiges Plugin (welches in der aktuellen Form noch nicht baut, weil die Verbindung zu SHD ja noch fehlt) verwandele ich von einem reinen VDR-Plugin halt in eine PSL.
    • SHD mit nur minimalen Änderungen über John's Stand nutzt den in der OglOsd-PSL implementierte cOsdProvider, und wird noch ein dort noch zu definierendes Interface implementieren, um die zur Laufzeit notwendige Verbindung zu VDPAU dem cOsdProvider zur Verfügung zu stellen.
    • Für jede weitere unterstützte Platform der wird ein entsprechendes Interface im PSL definiert und in dem entsprechenden SHD-Pendant oder SHD selber implementiert, welches die dort vorhandenen Resourcen dem cOsdProvider in geeigneter (eventuell abstrahierter) Form zur Verfügung stellt.

    Ich denke, 1+2 könnte ich relativ zügig hinbekommen, für SHD am PC, dann kann man konkreter sehen, was ich meine und auch vor allem, wie das funktioniert. Punkt 3 kann nacher folgen und die jeweiligen Spezialisten in exotischen Platformen sollen gerne das Interface in mehreren Schritten verbessern. Am Ende wird also der ganze OpenGL-Osd-Code in einer gemeinsamen Shared Lib sein, die VDR-spezifisch ist, und das Ziel der Konsolidierung zwecks besserer Wartbarkeit wäre somit erreicht. Was haltet Ihr davon?


    Gruß,
    Lucian

    So würde ich es auch machen. Ich war damals vom "PSL"-Ansatz auch angetan, manch Ding braucht eben seine Weile. :)
    Zumindest Louis konnte ich bei seinem skindesigner davon schon mal überzeugen und es funktioniert ja auch gut und wie erwartet.


    Lars

    Hallo Lucian


    Zitat von Zoolook

    Für jede weitere unterstützte Platform der wird ein entsprechendes Interface im PSL definiert

    Wenn ich als Nutzer einer Library erst ein neues Interface definieren muss, dann ist das Design der Schnittstelle falsch.


    Zitat von Zoolook

    Was haltet Ihr davon?

    Ehrlich gesagt bin ich vom PSL-Ansatz nicht so überzeugt - warum eine neue Infrastruktur hochfahren, wenn sich das Problem mittels sauberem OO-Design innerhalb eines Plugins lösen lässt? Keep it simple an stupid...


    Gruss
    Thomas

    Nur um Missverständnissen vorzubeugen, den Weg einer Library finde ich nicht verkehrt. Lasst mich das mal von der Seite beginnen:


    Eine solche Library sollte, um universell nutzbar zu sein, ausschliesslich Louis' OSD-Implementation enthalten. Daraus ergeben sich folgende Schnittstellen:

    • die eigentliche cOSD-Implementation
    • die von der cOSD-Implementation genutzten OpenGL-Funktionen
    • ein universelles API um an GL-Ressourcen zu gelangen und, für Anwendungen wie VDPAU, beim Rendern zu "synchronisieren"

    Letzteres zu definieren ist nicht ganz trivial, aber in meinen Augen möglich. Einfacher fände ich deshalb, zu Beginn die Trennung erst mal innerhalb eines Plugins zu vollziehen und die Schnittstelle zu den plattformabhängigen Teilen sich formen zu lassen. Funktioniert das universelle Plugin erst mal auf allen gängigen Plattformen, lässt sich der gemeinsame Code immer noch in eine normale shared Library auslagern und jeder Entwickler ist frei, entweder einen hardwarespezifischen Teil zum universellen OSD-Plugin beizusteuern, oder in seinem Ausgabeplugin die Library zu nutzen.


    Sobald das Ausgabeplugin mit der der GL-OSD-Implementation kommunizieren muss, so wie bei VDPAU, hätte die Library tatsächlich Vorteile. Für die ersten Gehversuche mittels Universal-Plugin wäre deshalb die temporäre Nutzung einer Service-Schnittstelle wohl angebracht.


    Gruss
    Thomas

    Zitat von reufer

    Eine solche Library sollte, um universell nutzbar zu sein, ausschliesslich Louis' OSD-Implementation enthalten. Daraus ergeben sich folgende Schnittstellen:


    • die eigentliche cOSD-Implementation
    • die von der cOSD-Implementation genutzten OpenGL-Funktionen
    • ein universelles API um an GL-Ressourcen zu gelangen und, für Anwendungen wie VDPAU, beim Rendern zu "synchronisieren"


    Letzteres zu definieren ist nicht ganz trivial, aber in meinen Augen möglich.

    Ja, genau das ist der Punkt, das universelle API "um an GL-Ressourcen zu gelangen und beim Rendern zu synchronisieren" wie Du es sehr treffend beschreibst ist nicht so leicht zu definieren. Ich denke dennoch daß man von vorne herein mit einer shared library beginnen kann, im Grunde habe ich die vdr-psl-oglosd nun soweit daß sie die ersten 2 Punkte in Deiner Aufzählung erfüllt, daß sie auf Gentoo gengen OpenGL und auch gegen GLES2 von Mesa baut, und naja, beim dritten sieht sie nun vorläufig eine dirty API (aus dem Wunsch, erstmal so gut wie nichts am bestehenden Code zu ändern, sondern das Gespann sehr bald wieder zum Laufen zu bekommen) die momentan aus aus Callback-Funktionspointern besteht:

    Code
    htpc2 vdr-psl-oglosd # grep -R extern *
gles_private.h:extern "C" {
oglosd.h:extern bool (*CbIsDeviceSuspended)(void);
openglosd.h:extern void (*CbActivateOsd)(void);
openglosd.h:extern void * (*CbGetVDPAUDevice)(void);
openglosd.h:extern void * (*CbGetVDPAUProcAdress)(void);
openglosd.h:extern void * (*CbGetVDPAUOutputSurface)(void);
openglosd.h:extern void * (*CbGetVDPAUProc) (const uint32_t, void *, const char *);
openglosd.h:extern std::string X11DisplayName;


    Als Nächstes würde ich nun eher Zille's SHD fork nehmen (weil er über John's "Vanilla"-SHD nur noch MMAL-Unterstützung hinzugefügt hat, ohne OpenGL-OSD) und darin diese vdr-psl-oglosd nutzen indem ich die fehlenden Verbindungen für diese API (so wie Louis es ja auch gemacht hat) noch hinzufüge, sowie alles ausser dem ausgelagerten OpenGL Code.
    Wenn es dann so läuft (und ich gehe davon aus, das wird es wohl bald, an einem der nächsten späten Abende ;D ) mit VDPAU, wäre es in meiner Vorstellung bereits für Andreas ein Leichtes, es auch auf Allwinner zum Laufen zu bringen, danach kann man sich in der Tat auf die Verbesserung der API konzentrieren, weil man in dem Moment bereits versuchen kann, die vdr-psl-oglosd auch mit SHD + MMAL, oder warum nicht auch in amlhddevice zu nutzen, und dabei kann jeder der sich mit so einer Platform befasst die entsprechenden (verteilten) Erkenntnisse für die API beisteuern, ganz konkret in vdr-psl-oglosd und nicht in einem monolithischen SHD.


    Gruß,
    Lucian

    Hallo Lucian


    Zitat von Zoolook

    [...] und naja, beim dritten sieht sie nun vorläufig eine dirty API (aus dem Wunsch, erstmal so gut wie nichts am bestehenden Code zu ändern, sondern das Gespann sehr bald wieder zum Laufen zu bekommen) die momentan aus aus Callback-Funktionspointern besteht:

    Und genau das ist in meinen Augen die falsche Herangehensweise. Sind wir denn in Eile? Dein API enthält sowohl einen X11-Displaynamen wie diverse VDPAU-spezifische Funktionen - und das gilt es doch zu vermeiden.


    Und wozu das ganze PSL-Zeugs? Entweder entsteht daraus ein VDR-Plugin oder eine shared Library, aber VDR zu patchen um irgend ein Mittelding zu fahren finde ich unschön.


    Gruss
    Thomas

    Hallo Thomas,


    diese sogenannte API ist ja noch keine wirkliche, da gebe ich Dir recht, und ich bin auch ziemlich sicher die bekommen wir noch etwas schlanker und sauberer.


    Keine Angst, der VDR Code braucht keinen Patch. Der mitgelieferte Patch ist nur nützlich für diejenigen, die zum Bauen eines Plugins das unbedingt im VDR-Sourcenbaum machen wollen. Wer bloss die VDR-Header nutzt und dem Makefile auch sagen kann, wohin es die *.so, die Header und die pkgconfig Datei installieren soll (wie es bei Gentoo "von selbst" passiert) baut die Library einfach so.


    Gruß,
    Lucian

    Zitat von reufer

    Und wozu das ganze PSL-Zeugs? Entweder entsteht daraus ein VDR-Plugin oder eine shared Library

    Wenn's eine shared library ist, und dafür spricht doch der Umstand, daß der Code von unterschiedlichen Plugins mal genutzt werden soll, ist es nicht irgend eine shared library, sondern eine die von VDR Headern abhängt. Normalerweise ist es umgekehrt, daß der VDR irgendwelche Libraries nutzt. Vielleicht erkärt das etwas besser was das Zeugs ;D soll.


    Gruß,
    Lucian

    Zitat von Zoolook

    Wenn's eine shared library ist, und dafür spricht doch der Umstand, daß der Code von unterschiedlichen Plugins mal genutzt werden soll, ist es nicht irgend eine shared library, sondern eine die von VDR Headern abhängt. Normalerweise ist es umgekehrt, daß der VDR irgendwelche Libraries nutzt. Vielleicht erkärt das etwas besser was das Zeugs soll.

    Tut mit leid, ich versteh's trotzdem nicht. ;) Warum soll eine normale shared lib nicht auch von VDR abhängen dürfen? Dafür exportiert doch dieser seine Header nach /usr/include. Und wenn du unbedingt mit der VDR-Make-Infrastruktur bauen willst, mach es doch wie Louis mit der skindesigner-Lib, die lässt sich sowohl innerhalb des VDR-Trees wie auch für sich alleine übersetzen. Dafür brauchst du doch nichts neues zu "erfinden".


    Gruss
    Thomas

    Zitat von reufer

    Warum soll eine normale shared lib nicht auch von VDR abhängen dürfen? Dafür exportiert doch dieser seine Header nach /usr/include.

    Es sagt doch keiner, daß sie das nicht darf ;-). Klar werden die VDR-Header exportiert, aber ich hörte es soll Systeme geben (ich habe dieses Problem bei Gentoo nicht), wo das nicht der Fall ist, und dann bauen die Leute alle Plugins in einem VDR-Sourcentree vorher.


    Zitat von reufer

    Und wenn du unbedingt mit der VDR-Make-Infrastruktur bauen willst, mach es doch wie Louis mit der skindesigner-Lib, die lässt sich sowohl innerhalb des VDR-Trees wie auch für sich alleine übersetzen. Dafür brauchst du doch nichts neues zu "erfinden".

    Ich will doch gar nicht die VDR-Make-Infrastruktur dafür nutzen, den Patch brauche ich nicht, der ist für Leute die sie unbedingt so nutzen wollen, damit sie das leichter hinbekommen, bei einer Library die vom VDR abhängt und auf dem System wo sie bauen, der VDR gar nicht installiert, also keine Header nach /usr/include abgelegt hat. Und neu ist das nicht, ich hatte die PSLs vor 3 Jahren vorgeschlagen, ich kam aber nicht dazu, sie irgendwo mit gutem Grund zu nutzen :). Was nicht heissen soll, jetzt muss es unbedingt sein, es ist nur ein Detail.


    Gruß,
    Lucian

    Hi,


    nur mal aus Neugier, was ist denn aus dieser guten Idee und dem vielversprechenden Ansatz geworden?


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Ruht von meiner Seite ;) Gibt noch ein paar Bugs in der GLES Anpassung und damit das wirklich flüssig läuft habe ich ein paar heftigere Anpassungen von libvdpau-sunxi hier in der Schublade. Allerdings ist das noch nicht ganz fertig, da ich nicht zum testen komme.
    Gründe:
    - Mangelde Zeit und Motivation, das im Moment für das "alte" libvdpau-sunxi umzusetzen, da ich gerade lieber mit dem mainline Kernel arbeite
    - VDR laüft hier stabil und produktiv auf Allwinner mit LCARS, was mich bisher voll und ganz zufrieden stellt :)


    Aber wenn man den Code zusammenwirft und noch ein bißchen schraubt, sollte es theoretisch mit GLES laufen...


    Gruß
    Andreas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden