OglOsd - Aufruf zum Feinschliff der Konzepte

  • Hallo,


    gestern wurde ja nachdem Andreas angekündigt hatte, Softhddevice auch OpenGL/ES-fähig zu machen darüber diskutiert, daß es doch eher Sinn machen würde, das komplette OpenGL-Osd in ein separates Plugin auszulagern, welches mit den jeweiligen Ausgabeplugins zusammenarbeiten soll, welche in einer OpenGL/ES-fähigen Umgebung laufen (softhddevice, rpihddevice und später auch amlhddevice).


    Ich habe schonmal mit dem Herausschälen des OpenGLOsd aus Louis' Fork an Softhddevice begonnen, und bin nun auf die Problematik gestossen, auf die auch Andreas hingewiesen hat, daß zumindest in aktueller Form der OsdProvider doch etwas mit Softhddevice "verzahnt" ist, und für eine sinnvolle Lösung würde ich gerne vorher mit den Kennern der VDR-Architektur samt seinen Plugins die Konzepte besprechen, bevor ich da fortfahre.


    Mir fällt momentan nur ein, daß man mittels Service-Interface zwischen OglOsd und dem aktiven Ausgabeplugin die notwendige Interaktion zwischen ihnen bewerkstelligen könnte. Es stellt sich natürlich auch die Frage, wie man das organisiert, in welche Richtung am Besten. Vielleich irre ich mich, aber bisher habe ich dafür folgende möglich Kandidaten gefunden, die so etwas bräuchten:

    • in video.c VideoEventCallback welches im OglOsd OsdSizeChanged aufrufen soll
    • im OglOsd werden ActivateOsd, GetVDPAUDevice, GetVDPAUProcAdress, GetVDPAUOutputSurface und in Andreas' GLES-Fork noch zusätzlich GetVDPAUProc aus video.c aufgerufen;

    Wie gehen wir damit nun um, auch in Hinsicht darauf, daß OglOsd nicht nur mit Softhddevice, sondern auch RpiHdDevice und AmlHdDevice laufen soll?


    Gruß,
    Lucian



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

    Einmal editiert, zuletzt von Zoolook ()

  • Eine Ankündigung, und schon steht man unter Druck :) Immer dieselben Anfängerfehler, die ich mache ...
    Zum Thema. Die Get* sind z.B. schon die ersten Hardware spezifischen Dinge. Bzw. VDPAU eigen. Das ausgabeplugin (welches hier speziell VDPAU nutzt und welches auch immer das ist, muss dem oglosd die vdpau Instanz und die GetProcAdress Adresse etc. zur Verfügung stellen, damit das interop feature, das für ogl und vdpau genutzt werden muss, funktioniert.
    Für rpi etc. sieht das wahrscheinlich wieder anders aus.
    Man müsste wohl eine Schnittstelle so definieren, dass sich vom oglosd abfragen lässt, welches Backend zur Verfügung steht und die infos dann abfragen lassen...
    Da bin ich allerdings zu wenig C++ Mensch, um zu wissen, dass ich da richtig denke.
    Spätestens die Funktion, die das osd auf den Bildschirm schiebt muss m.E. wieder das Ausgabeplugin erfüllen. Zusammenbauen kann es das oglosd Plugin.
    Korrigiert mich, wenn ich falsch liege.


    Gruß Andreas


    PS: Vielleicht sollten wir auch Johns Meinung zu der ganzen OSD Sache abfragen, bevor wir dem softhddevice zu sehr auf die Pelle rücken... ;)

  • Hallo Lucian


    Erst mal vielen Dank, dass du die Initiative ergriffen hast!


    Mir fällt momentan nur ein, daß man mittels Service-Interface zwischen OglOsd und dem aktiven Ausgabeplugin die notwendige Interaktion zwischen ihnen bewerkstelligen könnte.

    Genau das würde ich versuchen zu vermeiden. Wie schon angemerkt, ist ein OSD nicht unbedingt an ein Ausgabedevice gekoppelt, deshalb die Idee der Trennung. Nun mit einer solchen Service-Schnittstelle die Abhängigkeit wieder einzuführen fände ich schade. Zumal diese auch sehr hardwarespezifisch und kaum universell wäre.


    in video.c VideoEventCallback welches im OglOsd OsdSizeChanged aufrufen soll

    Sowas gibt es schon in VDR.


    ActivateOsd

    Hmm... ich denke nicht, dass ein Ausgabedevice "berechtigt" ist, ein OSD zu aktivieren/deaktivieren.


    GetVDPAUDevice, GetVDPAUProcAdress, GetVDPAUOutputSurface und in Andreas' GLES-Fork noch zusätzlich GetVDPAUProc

    Ok, hier bewege ich mich auf dünnem Eis. Ohne zu wissen, wie man das konkret lösen kann, würde ich versuchen, eine solche Kopplung von Aussen beim Pluginstart zu definieren. Lässt sich ein VDPAU-"Instanz" nicht über einen eindeutigen Parameter identifizieren?


    Beim Raspberry Pi würde die Raspi-spezifische Initialisierung einfach einen neuen dispmanx-Layer belegen, dessen Id schon heute als Plugin-Parameter übergeben werden kann. Das OSD-Plugin wüsste dann nicht einmal, ob überhaupt ein Ausgabedevice vorhanden ist. Bei Amlogic wäre es wohl der Framebuffer als Startparameter, da müsste ich mal in den Beispielcode schauen.


    Gruss
    Thomas

  • Spätestens die Funktion, die das osd auf den Bildschirm schiebt muss m.E. wieder das Ausgabeplugin erfüllen.

    Ist das wirklich so? Ich war der Ansicht, dass dem nicht so ist, kenne mich aber bei VDPAU nicht aus. Sollte die Ausgabe tatsächlich nur mit dem Ausgabedevice funktionieren, wäre meine Idee wahrscheinlich hinfällig und ich habe mir das wohl zu einfach vorgestellt.


    Gruss
    Thomas

  • ACK bis hierhin.

    Ok, hier bewege ich mich auf dünnem Eis. Ohne zu wissen, wie man das konkret lösen kann, würde ich versuchen, eine solche Kopplung von Aussen beim Pluginstart zu definieren. Lässt sich ein VDPAU-"Instanz" nicht über einen eindeutigen Parameter identifizieren?


    Hm. VDPAU wird durch softhddevice beim pluginstart instanziert, da dieses die decoding und Präsentation Funktionalität nutzt. Erst dann können die genannten Parameter abgefragt werden. Man kann das nicht vorher festlegen, da das vdpau Backend dafür verantwortlich ist. Man mit muss sich (hier speziell) das output surface von vdpau/softhddevice holen, darauf zeichnen (im osd Plugin) und dann wieder vom ausgabeplugin darstellen lassen. So funktioniert das aktuell in Louis' fork.
    Gruß Andreas

    Einmal editiert, zuletzt von rell ()

  • Ist das wirklich so? Ich war der Ansicht, dass dem nicht so ist, kenne mich aber bei VDPAU nicht aus. Sollte die Ausgabe tatsächlich nur mit dem Ausgabedevice funktionieren, wäre meine Idee wahrscheinlich hinfällig und ich habe mir das wohl zu einfach vorgestellt.


    Wenn ich es nicht ganz falsch verstanden habe, ist das so, ja. Ausser ich bin zu sehr vdpau-backend-nachbau gebeutelt ;)
    Hier die Grafik, wie vdpau funktioniert. Finde ich ganz aussagekräftig. GL bzw. das oglosd plugin bekommt jetzt direkten Zugriff auf das output surface in der grafik. So funktioniert das vdpau-gl-interop feature. Entweder GL gibt die veränderten bits dann wieder zurück, oder kümmert sich selbst um die Darstellung. Da brauchts halt dann wieder was, was sich darum kümmert, und das ist in gewisser weise immer Hardware abhängig. Vdpau in softhddevice macht das ja sowieso. Das osd läuft da quasi so mit...
    Gruß Andreas

  • GL bzw. das oglosd plugin bekommt jetzt direkten Zugriff auf das output surface in der grafik. So funktioniert das vdpau-gl-interop feature.


    Ok, aber ist für ein reines OSD das VDPAU-GL-Interop-Feature überhaupt nötig? Ein GL-Kontext lässt sich doch mit einem beliebigen X-Window erzeugen, dazu braucht es ja kein VDPAU. Und den decodierten Video-Stream wollen wir ja nicht ins OSD rendern.


    Oder stelle ich mir das zu einfach vor? Zugegeben, Linux mit Fenstern war noch nie mein Ding... ;)


    Gruss
    Thomas

  • Mit nvidia ist das möglicherweise einfach machbar. Mit allwinner muss ich mir das mal durch den Kopf gehen lassen. Da ist vdpau ja nur "improvisiert". Wir befinden uns immer noch auf ARM und dafür war vdpau ja nicht gedacht. libvdpau-sunxi geht direkt an die hardware/ display layer, nicht über X. Daher weiß ich nicht wie sich ein window für oglosd mit dem window für das Video verträgt... Fenster sind mein Ding auch nicht. Aber die Theorie lässt mich vermuten, dass das machbar sein sollte. Ob sich der Aufwand lohnt, ist die zweite Frage...
    Gruß Andreas

  • Moin,


    erst mal freut es mich, dass es hier voran geht. Aus meiner Sicht wäre ein "universales OSD Plugin" absolut ein Schrit nach vorne, zum einen wären die Ausgabeplugins "von Ballast befreit", zum anderen wäre die "OSD Engine" zentral an einer Stelle gepflegt und müsste nicht in jedem Ausgabeplugin neu implementiert werden.


    Als ich mich damals mit dem Konzept für das High Level OSD im softhddevice beschäftigt habe, war meine erste Idee auch, das OSD per OpenGL in einem eigenen Fenster zu zeichnen und dieses Fenster "einfach" über das Videobild zu legen. Hier kommt aber die Problematik ins Spiel, dass das OSD semitransparent über das Videobild gerendert werden muss. "Normalerweise" werden X Fenster einfach übereinander gelegt und verdecken sich entsprechend. Das "mischen" muss dann vom Windowmanager übernommen werden. Allerdings gibt es nur wenige Windowmanager, die das können, einer von ihnen wäre z.B. compiz. Mit compiz gab es früher (und wohl immer noch?!) Probleme mit Tearing, Deshalb habe ich diesen Weg relativ schnell verworfen und bin bei der weiteren Recherche auf das OpenGL VDPAU Interop Feature gestoßen, das es mir ermöglicht hat, auf ein separates Fenster zu verzichten, da das überblenden der einzelnen Surfaces / Framebuffers / Layer (oder wie man es auch nennen will) von VDPAU übernommen wird. Windowmanager ist dazu keiner nötig. Deshalb war mir diese Lösung direkt viel sympathischer und ich habe die "Standalone Window" Lösung nicht weiter verfolgt.


    Ich denke aber trotzdem, dass sich das OSD sauber in ein eigenes Plugin auslagern lässt. Im Falle SHD / OpenGL müsste das OSD Plugin nach der VDPAU Initialisierung durch SHD die VDPAU Parameter bekommen, um "sein" OSD Surface erzeugen zu können. Zur Ausgabe des fertig gerenderten Surface muss das dann wieder an SHD übergeben werden, SHD mischt dann per VDPAU das OSD und das Video Surface übereinander. Ein Möglichkeit für diese Interaktion wäre sicherlich der von Lucian vorgeschlagene Weg der Nutzung des Serviceinterfaces, worüber man die nötigen Parameter austauschen könnte. Schöner fände ich es aber, wenn der VDR selbst die entsprechende Schnittstelle anbieten würde. Das Ausgabeplugin müsste dann "nur" z.B. zwei Funktionen überschreiben, die es dem OSD Plugin ermöglichen, zum einen die initialen Parameter zu bekommen, und zum anderen das gerenderte Surfacce auszugeben. Ich habe jetzt natürlich nur die SHD / OpenGL Sicht beschrieben. Wie das auf anderen Plattformen gemacht wird, müsste Thomas mal genauer beschreiben. Erst dann könnte man sich überöegen, wie diese VDR Schnittstelle sinnvoll auszuschauen hätte. Die VDR Schnittstelle sollte natürlich so universal ausgelegt sein, dass es für alle Plattformen passt.


    Ein anderere Aspekt, der noch nicht wirklich angesprochen wurde, wäre die Vereinheitlichung der "OSD Engine". Bei "meiner" Implementierung habe ich das Konzept von Thomas abgekupfert, dass über einen Worker Thread die aus dem VDR parallel entstehenden OSD Zeichenbefehle serialisiert werden, da OpenGL / OpenGL ES / OpenVmax in einem singulären Kontext laufen muss. Hierzu existiert die Klasse "Command", von der jeder konkrete OSD Zeichenbefehl abgeleitet wird. Die einzelnen Commands werden dann in eine Command Queue gestopft, und diese Queue wird dann vom Worker Thread abgearbeitet. Bei "meiner" Implementierung habe ich aber teilweise andere (meinen Bedürfnissen angepasste) Befehle benutzt als Thomas im rpihddevice. Hier müsste man aus meiner Sicht erst mal konsolidieren / standardisieren, damit diese Schicht hardwareunabhängig wird. Dazu müsste man sich ein gemeinsames abstraktes Framework an Befehlen überlegen, die dann für die verschiedenen Plattformen entsprechend implementiert werden müssten.


    Ein weiterer Faktor der Konsolidierung wäre die Benutzung von Schriften per OpenGL / ES / OpenVMax. Auch hier könnten gemeinsame Konzepte (z.B. Erzeugung eines Glyph Atlas, der alle Zeichen einer Schriftart auf einer Buffer Surface rendert, um diese einzelnen Texturen dann zur Ausgabe zu benutzen) genutzt werden, um den Code zu optimieren.


    So weit erst mal meine Gedanken zu dem Thema...es ist sicherlich viel Arbeit, aber machbar ist das ganze. Schaumer mal, wie sich das ganze weiter entwickelt ;)


    Ciao Louis

  • Als ich mich damals mit dem Konzept für das High Level OSD im softhddevice beschäftigt habe, war meine erste Idee auch, das OSD per OpenGL in einem eigenen Fenster zu zeichnen und dieses Fenster "einfach" über das Videobild zu legen. Hier kommt aber die Problematik ins Spiel, dass das OSD semitransparent über das Videobild gerendert werden muss. "Normalerweise" werden X Fenster einfach übereinander gelegt und verdecken sich entsprechend. Das "mischen" muss dann vom Windowmanager übernommen werden. Allerdings gibt es nur wenige Windowmanager, die das können, einer von ihnen wäre z.B. compiz. Mit compiz gab es früher (und wohl immer noch?!) Probleme mit Tearing, Deshalb habe ich diesen Weg relativ schnell verworfen und bin bei der weiteren Recherche auf das OpenGL VDPAU Interop Feature gestoßen, das es mir ermöglicht hat, auf ein separates Fenster zu verzichten, da das überblenden der einzelnen Surfaces / Framebuffers / Layer (oder wie man es auch nennen will) von VDPAU übernommen wird. Windowmanager ist dazu keiner nötig. Deshalb war mir diese Lösung direkt viel sympathischer und ich habe die "Standalone Window" Lösung nicht weiter verfolgt.

    Ok, diesen Lösungsweg kann ich natürlich nachvollziehen. Mal ganz doof gefragt, was würde denn passieren, wenn man die GL-Surface dem selben Window "anhängt", in dem die Videoausgabe läuft? Bezüglich Tearing sollte es natürlich einen Mechanismus geben, die Darstellung zu synchronisieren - keine Ahnung, was hier X & Co anbieten. Beim Raspberry macht das alles dispmanx, und das ist im Prinzip auch eine Art Window-Manager, nur auf Framebuffer-Ebene. Ich vermute mal, da haben andere ARM-Boards ähnliche Mechanismen am laufen.


    Ich denke aber trotzdem, dass sich das OSD sauber in ein eigenes Plugin auslagern lässt. Im Falle SHD / OpenGL müsste das OSD Plugin nach der VDPAU Initialisierung durch SHD die VDPAU Parameter bekommen, um "sein" OSD Surface erzeugen zu können. Zur Ausgabe des fertig gerenderten Surface muss das dann wieder an SHD übergeben werden, SHD mischt dann per VDPAU das OSD und das Video Surface übereinander. Ein Möglichkeit für diese Interaktion wäre sicherlich der von Lucian vorgeschlagene Weg der Nutzung des Serviceinterfaces, worüber man die nötigen Parameter austauschen könnte. Schöner fände ich es aber, wenn der VDR selbst die entsprechende Schnittstelle anbieten würde. Das Ausgabeplugin müsste dann "nur" z.B. zwei Funktionen überschreiben, die es dem OSD Plugin ermöglichen, zum einen die initialen Parameter zu bekommen, und zum anderen das gerenderte Surfacce auszugeben. Ich habe jetzt natürlich nur die SHD / OpenGL Sicht beschrieben. Wie das auf anderen Plattformen gemacht wird, müsste Thomas mal genauer beschreiben. Erst dann könnte man sich überöegen, wie diese VDR Schnittstelle sinnvoll auszuschauen hätte. Die VDR Schnittstelle sollte natürlich so universal ausgelegt sein, dass es für alle Plattformen passt.

    Sollte die Ausgabe mit softhddevice wirklich nur über dieses VDPAU-Feature funktionieren, macht hier die Trennung in meinen Augen wenig Sinn. Eine Service-Schnittstelle wäre vielleicht machbar, aber wirklich schön finde ich das nicht. Die Schnittstelle in VDR zu verlagern halte ich auch nicht für sinnvoll, dazu ist sie einfach zu spezifisch. Zumal VDR grundsätzlich keine solchen Lowlevel-Ausgabe-APIs kennt.


    Ein anderere Aspekt, der noch nicht wirklich angesprochen wurde, wäre die Vereinheitlichung der "OSD Engine". Bei "meiner" Implementierung habe ich das Konzept von Thomas abgekupfert, dass über einen Worker Thread die aus dem VDR parallel entstehenden OSD Zeichenbefehle serialisiert werden, da OpenGL / OpenGL ES / OpenVmax in einem singulären Kontext laufen muss. Hierzu existiert die Klasse "Command", von der jeder konkrete OSD Zeichenbefehl abgeleitet wird. Die einzelnen Commands werden dann in eine Command Queue gestopft, und diese Queue wird dann vom Worker Thread abgearbeitet. Bei "meiner" Implementierung habe ich aber teilweise andere (meinen Bedürfnissen angepasste) Befehle benutzt als Thomas im rpihddevice. Hier müsste man aus meiner Sicht erst mal konsolidieren / standardisieren, damit diese Schicht hardwareunabhängig wird. Dazu müsste man sich ein gemeinsames abstraktes Framework an Befehlen überlegen, die dann für die verschiedenen Plattformen entsprechend implementiert werden müssten.

    Ich denke, OpenGL gehört hier die Zukunft und wird OpenVG obsolet machen. Ich würde deshalb keine Energie verschwenden, die zwei Welten miteinander zu verheiraten. Die OpenVG-Implementation in rpihddevice war eine spannende Arbeit und deckt die VDR-OSD-Funktionalität nun komplett ab. Eine Weiterentwicklung halte ich für unnötig, bin aber natürlich ein wenig stolz, dass dir das Konzept als Vorlage gedient hat. ;)


    Ein weiterer Faktor der Konsolidierung wäre die Benutzung von Schriften per OpenGL / ES / OpenVMax. Auch hier könnten gemeinsame Konzepte (z.B. Erzeugung eines Glyph Atlas, der alle Zeichen einer Schriftart auf einer Buffer Surface rendert, um diese einzelnen Texturen dann zur Ausgabe zu benutzen) genutzt werden, um den Code zu optimieren.

    Wozu willst du alle Zeichen im Voraus auf eine Surface rendern? Ich weiss jetzt nicht im Detail, wie du das implementiert hast, aber bei meiner Variante werden nur die einzelnen Pfade gecacht. Gerendert wird erst, wenn was auf eine Surface geschrieben werden soll, alles andere wäre Verschwendung von Speicherplatz - und der ist bei der Himbeere halt eher knapp.


    Gruss
    Thomas

  • Moin,

    Mal ganz doof gefragt, was würde denn passieren, wenn man die GL-Surface dem selben Window "anhängt", in dem die Videoausgabe läuft?


    Keine Ahnung ;) Da müsste man sich mal schlau machen, ob und wie das geht. Ich befürchte aber, das Thema Transparenz macht hierbei auch einen Strich durch die Rechnung...
    Was mich bei meinen Recherchen damals extrem genervt hat, waren die zig (wohl historisch entstandenen) Möglichkeiten, die es da im X Umfeld gibt. Es ist mir extrem schwer gefallen, beurteilen zu können, welche Ansätze überhaupt noch aktuell sind und auch noch gepflegt. Das war ein riesiger Wust...alleine im OpenGL Umfeld gibt es zig Implementierungen / Frameworks und auch mindestens drei OpenGL Versionen, die nicht so wirklich kompatibel zueinander sind, da erst mal so einigermaßen durchzusteigen, hat mich einiges an Zeit und Gehirnverrenkungen gekostet ;)


    Sollte die Ausgabe mit softhddevice wirklich nur über dieses VDPAU-Feature funktionieren, macht hier die Trennung in meinen Augen wenig Sinn.


    Hm...dann wäre Folgerichtig der erste Schritt, dass sich jemand bemüht, ein für alle Ausgabeplattformen gemeinsames "Ausgabekonzept" zu entwickeln. Keine Ahnung ob das möglich ist. Theoretisch sicher ;)


    Wozu willst du alle Zeichen im Voraus auf eine Surface rendern? Ich weiss jetzt nicht im Detail, wie du das implementiert hast, aber bei meiner Variante werden nur die einzelnen Pfade gecacht. Gerendert wird erst, wenn was auf eine Surface geschrieben werden soll, alles andere wäre Verschwendung von Speicherplatz - und der ist bei der Himbeere halt eher knapp.


    Aus Performancegründen...da kommen sich halt wieder die beiden Philosophien in die Quere. NVidia Karten haben mittlerweile genügend Speicher, der im "normalen VDR Betrieb" kaum genutzt wird. Deshalb macht es hier aus meiner Sicht absolut Sinn, das aufwändige Rendern der einzelnen Zeichen einer Schriftart einer bestimmten Größe per Freetype einmal zu erledigen und auf einer Textur zu cachen. Beim eigentlichen "schreiben" im OSD werden dann einfach nur die kleinen vorhandenen (Glyph)Texturen auf das Surface kopiert. Beim Raspi mit seinem limitierten GPU Speicher ist das natürlich wieder ein anderer Fall...


    Ciao Louis

  • Hi Louis


    Hm...dann wäre Folgerichtig der erste Schritt, dass sich jemand bemüht, ein für alle Ausgabeplattformen gemeinsames "Ausgabekonzept" zu entwickeln. Keine Ahnung ob das möglich ist.

    Zwingend plattformspezifisch ist sicher die Art, zu einem GL-Kontext, bzw. einer Surface zu kommen - der Rest sollte dann OpenGL abdecken. Falls wirklich unumgänglich könnte man zusätzlich eine VDPAU-spezifische Art des "swappen" implementieren die sich dann mit softhddevice "unterhält" - aber das würde dann nur für VDPAU gebraucht und sollte nicht in einem Versuch enden, einen generischen Service einführen zu wollen.


    Es wäre wohl angebracht, mal zu Stift und Papier zu greifen und sowas wie ein Klassendiagram zu zeichnen. ;)


    Aus Performancegründen...

    Wirklich? Ich kann mir fast nicht vorstellen, dass bei einer ausgewachsenen Grafikkarte Unterschiede sichtbar sind. Auf solche Optimierungen sollte man in einem generischen Plugin verzichten, wenn auch kleinere Plattforen davon profitieren sollen.


    Gruss
    Thomas

  • Ok, diesen Lösungsweg kann ich natürlich nachvollziehen. Mal ganz doof gefragt, was würde denn passieren, wenn man die GL-Surface dem selben Window "anhängt", in dem die Videoausgabe läuft? Bezüglich Tearing sollte es natürlich einen Mechanismus geben, die Darstellung zu synchronisieren - keine Ahnung, was hier X & Co anbieten. Beim Raspberry macht das alles dispmanx, und das ist im Prinzip auch eine Art Window-Manager, nur auf Framebuffer-Ebene. Ich vermute mal, da haben andere ARM-Boards ähnliche Mechanismen am laufen.


    Ich kann nur von Allwinner sprechen, wobei ich mir das beim RPi zumindest ähnlich vorstelle:
    Da ist X eigentlich so ziemlich aussen vor. Es gibt zwar einen X context und auch ein window für die Ausgabe, die Darstellung selbst übernimmt aber nicht X mit swapbuffers oder was es da gibt.
    libvdpau-sunxi schreibt direkt in die Hardware, mit den Fenster Koordinaten, die es von X bekommt. Und mit Hardware meine ich per ioctl auf /dev/disp. Die Allwinner SoCs stellen zwei display layer zur Verfügung, die alpha blending können. Auf einen kommt das Video, auf den anderen (darüber geblendet) das OSD. Auch softwaretechnisch ist (YUV)Video vom (RGBA)OSD innerhalb libvdpau-sunxi getrennt, was wohl nicht ganz VDPAU-API konform ist, aber auch seine Vorteile hat und funktioniert.
    Ein Problem bei der Sache ist, dass für die Darstellung des Video colorkey genutzt wird. Und ich glaube das funktioniert nur für einen Layer gleichzeitig. Somit ist es derzeit so, dass die Z-Layer der X Windows nicht richtig mit dem Video übereinander liegen. Eines, entweder OSD oder Video, liegt immer ganz oben. Das ist eine Einschränkung des Allwinner-Vdpau-Hacks.
    Theoretisch könnte man wohl auch dafür sorgen, dass sich OpenGL/ES innerhalb VDPAU darum kümmert, dass das ARGB-OSD "richtig" in das YUV-Video gerendert wird und man tatsächlich nur 1 surface bzw. *pixel Speicherbereich hat. Das Problem hier ist, dass der Decoder mit 16x16 Videoblöcken arbeitet und man das erst umwandeln muss. Wie die Performance aussieht, wenn man also da GLES noch dazwischenschaltet, weiß ich nicht. Theoretisch könnte GL bzw. dann EGL auch die Darstellung übernehmen und nicht mehr direkt auf die Hardware zugegriffen werden.


    Ob sich dieser ganze Aufwand lohnt, da es sich bei libvdpau-sunxi sowieso nur um einen Hack handelt, der vdpau "imitiert", wage ich zu bezweifeln. Ich würde da eher den Weg über die Interop Schnittstelle gehen, da sie m.E. ja genau für solche Fälle gedacht war. Hier brauchts halt dann irgendeine Schnittstelle, weil die zwei Plugins unweigerlich miteinander reden müssen.


    Außerdem ist OpenGL oder GL/ES sowieso eine platformabhängige Angelegenheit. Das Window, der Context etc. muss ja auch von irgendwem zur Verfügung gestellt werden. GLX, EGL, etc. An der Wollmilchsau habe ich so meine Zweifel... Bzw. eher, ob sich der Aufwand lohnt.


    Gruß
    Andreas

  • Moin!


    Cool, dass es losgeht. Ich hab zwar weder Ahnung von OpenGL, VDPAU und X, biete aber meine Programmiererfahrung für einen Review des Konzeptes an, das ihr erarbeitet. :)


    Und um einfach noch was in den Ring zu werfen: Wayland? Geht das schon mit VDPAU usw.? Wäre das eine Alternative?


    Zum Thema Service-Schnittstelle: würde ich, wenn möglich, vermeiden.
    Besser für die Kommunikation zwischen zwei Plugins wäre meiner Meinung nach eine shared lib (das vom vdr unabhängige Gegenstück zu einer API im vdr), die von beiden geladen wird. Louis hat da ja schon ein wenig Erfahrung. Und wenn ihr die in ein eigenes git packt, dann meckern auch nicht die "ein Repository, ein Paket"-Distributoren und es ließe sich leichter warten. :)
    Und es wären nicht gleich zwei Plugins voneinander abhängig, sondern beide wären von einer lib abhängig, was ja vollkommen ok ist.


    Das wäre übrigens noch die zweite Möglichkeit, um die "OSD-Engine" zu verallgemeinern. Es muss kein vdr-Plugin sein, sondern könnte auch eine shared lib sein, die von den verschiedenen Ausgabeplugins genutzt wird.
    Dann würde man auch das Problem mit den Schnittstellen bzw. der Kommunikation in den Griff kriegen.


    Lars.

  • Da ist X eigentlich so ziemlich aussen vor. Es gibt zwar einen X context und auch ein window für die Ausgabe, die Darstellung selbst übernimmt aber nicht X mit swapbuffers oder was es da gibt.
    libvdpau-sunxi schreibt direkt in die Hardware, mit den Fenster Koordinaten, die es von X bekommt. Und mit Hardware meine ich per ioctl auf /dev/disp. Die Allwinner SoCs stellen zwei display layer zur Verfügung, die alpha blending können. Auf einen kommt das Video, auf den anderen (darüber geblendet) das OSD.

    Das ist in etwa der selbe Weg wie ich ihn für Amlogic im Kopf habe. Auch beim Raspberry Pi läuft es ähnlich ab, nur dass hier das ganze im VideoCore passiert.


    Ein Problem bei der Sache ist, dass für die Darstellung des Video colorkey genutzt wird. Und ich glaube das funktioniert nur für einen Layer gleichzeitig. Somit ist es derzeit so, dass die Z-Layer der X Windows nicht richtig mit dem Video übereinander liegen. Eines, entweder OSD oder Video, liegt immer ganz oben. Das ist eine Einschränkung des Allwinner-Vdpau-Hacks.

    Wieso willst du denn Video und OSD im selben Layer zusammenbringen? All die ARM SoCs sind ja schlussendlich so gebaut, dass sich Video auf Layer X und ein OSD, optional mittels OpenGL(ES) beschleunigt, auf Layer Y überlagern lässt. Diesen 08/15-Ansatz halte ich für erfolgsversprechender als zu versuchen, den VDPAU-Spezialfall auf Allwinnder zu übetragen.


    Ich würde da eher den Weg über die Interop Schnittstelle gehen, da sie m.E. ja genau für solche Fälle gedacht war.

    So wie ich dieses Feature verstehe ist es primär dazu gedacht, die Videoframes für GL zugänglich zu machen. Also z.B. die Videoausgabe auf einen Körper zu projizieren. Das wäre übrigens theoretisch sogar auf dem Raspi möglich, aber davon reden wir hier nicht. ;)


    Außerdem ist OpenGL oder GL/ES sowieso eine platformabhängige Angelegenheit. Das Window, der Context etc. muss ja auch von irgendwem zur Verfügung gestellt werden. GLX, EGL, etc. An der Wollmilchsau habe ich so meine Zweifel... Bzw. eher, ob sich der Aufwand lohnt.

    Das verstehe ich jetzt nicht - alleine die Tatsache, dass Louis' softhddevice-Branch mit minimalen Änderungen bei dir funktioniert, zeigt doch, dass wir dem Ziel schon recht nahe sind. Einzig das Erzeugen des Kontextes und der Surfaces ist plafformabhängig, der Rest erledigt GL(ES). Dieser spezifische Teil ist beim Raspi plusminus eine Bildschrimseite Code, die kurz ergoogelten Beispiele für X (ohne VDPAU) sind sogar noch einfacher. Dass VDPAU ein Sonderfall ist, habe ich verstanden - aber das Problem sollte mit Hilfe von Louis und johns lösbar sein. Warum nicht mal ein erstes vdr-oglosd-Plugin für normales X zum funktionieren bringen, und sich dann um die Spezialfälle (dispmanx, Allwinner, Amlogic und eben VDPAU) kümmern?


    Gruss
    Thomas

  • Besser für die Kommunikation zwischen zwei Plugins wäre meiner Meinung nach eine shared lib (das vom vdr unabhängige Gegenstück zu einer API im vdr), die von beiden geladen wird. Louis hat da ja schon ein wenig Erfahrung. Und wenn ihr die in ein eigenes git packt, dann meckern auch nicht die "ein Repository, ein Paket"-Distributoren und es ließe sich leichter warten. :)

    Der Gedanke kam mir auch schon, spielt aber in meinen Augen momentan gar keine Rolle. Die wichtigste Aufgabe wäre erst mal, die plattformabhängigen Teile zu isolieren. Ob dann der allgemeine Teil in eine - sorgfältig zu definierende - Bibliothek kommt, oder mit ein paar Hardwarevarianten in ein eigenes Plugin, ist letztendlich Geschmacksache. Persönlich mag ich den Gedanken eines eigenständigen Plugins, aber die Idee mit einer unabhängigen Library finde ich, technisch gesehen, genau so gut.


    Gruss
    Thomas

  • Wieso willst du denn Video und OSD im selben Layer zusammenbringen? All die ARM SoCs sind ja schlussendlich so gebaut, dass sich Video auf Layer X und ein OSD, optional mittels OpenGL(ES) beschleunigt, auf Layer Y überlagern lässt. Diesen 08/15-Ansatz halte ich für erfolgsversprechender als zu versuchen, den VDPAU-Spezialfall auf Allwinnder zu übetragen.


    Will ich gar nicht. Ich finde das relativ elegant und performant mit den 2 Layern. Solange sich im Desktop nichts überlagert, bemerkt man auch die Einschränkungen nicht. Es wurde nur zu Anfangs-Entwicklungszeiten angemerkt, dass es wohl User gibt, die im Fenstermodus VDR nutzen, und falls man über dieses VDR-Fenster irgendein anderes schiebt, ist die Darstellung nicht so, wie man sie gerne hätte... Ich selbst habe kein Problem damit, bzw. mir ist es zu aufwendig, das zu lösen.


    Zitat

    So wie ich dieses Feature verstehe ist es primär dazu gedacht, die Videoframes für GL zugänglich zu machen. Also z.B. die Videoausgabe auf einen Körper zu projizieren.


    Exakt. Diesen Anwendungsfall nutzt KODI. Es holt sich das videoframe als Textur, rendert das OSD dazu und stellt es anschließend dar. Glaube zumindest, dass es so abläuft.
    Interop ist lt. Spec für folgende Szenarien gedacht:
    1) VDPAU stellt Video oder RGBA Surface (z.B. als Textur) für GL zur Verfügung (Entweder leer oder bereits mit Daten gefüllt)
    2) GL kann die Textur manipulieren (shader etc.)
    3a) GL kümmert sich um die Ausgabe der manipulierten Daten oder
    3b) GL gibt die manipulierten Daten an VDPAU zurück und VDPAU kümmert sich wieder um die Ausgabe.


    Kodi geht nach 3a) vor und bekommt decodierte video surfaces von VDPAU
    VDR/ softhddevice-opengl geht nach 3b) vor und bekommt (leere) output surfaces zum Rendern von VDPAU

    Zitat

    Das verstehe ich jetzt nicht - alleine die Tatsache, dass Louis' softhddevice-Branch mit minimalen Änderungen bei dir funktioniert, zeigt doch, dass wir dem Ziel schon recht nahe sind. Einzig das Erzeugen des Kontextes und der Surfaces ist plafformabhängig, der Rest erledigt GL(ES). Dieser spezifische Teil ist beim Raspi plusminus eine Bildschrimseite Code, die kurz ergoogelten Beispiele für X (ohne VDPAU) sind sogar noch einfacher. Dass VDPAU ein Sonderfall ist, habe ich verstanden - aber das Problem sollte mit Hilfe von Louis und johns lösbar sein.


    Natürlich. Mit platformabhängig meinte ich auch nur die eine Bildschirmseite. Da gehts eigentlich nur um die Bereitstellung von Display, Context und Surface (jetzt im Fall GL oder GL/ES). GL und GL/ES könnte man sogar noch mehr zusammenfassen, wenn man bei GL x.0 auf Funktionen verzichtet, die nicht für GLES 2.0 zur Verfügung stehen. Keine Ahnung, ob das performance Einbußen bedeutet. Kann ich mir aber auf dem nvidia i86 Kisten nicht vorstellen.

    Zitat

    Warum nicht mal ein erstes vdr-oglosd-Plugin für normales X zum funktionieren bringen, und sich dann um die Spezialfälle (dispmanx, Allwinner, Amlogic und eben VDPAU) kümmern?

    Gehts mit VDPAU, gehts auch mit Allwinner. Dank libvdpau-sunxi, das man schlimmstenfalls etwas tweaken müsste :p . VAAPI sollte man vielleicht noch mit aufnehmen...


    Gruß
    Andreas

  • Der Gedanke kam mir auch schon, spielt aber in meinen Augen momentan gar keine Rolle. Die wichtigste Aufgabe wäre erst mal, die plattformabhängigen Teile zu isolieren. Ob dann der allgemeine Teil in eine - sorgfältig zu definierende - Bibliothek kommt, oder mit ein paar Hardwarevarianten in ein eigenes Plugin, ist letztendlich Geschmacksache. Persönlich mag ich den Gedanken eines eigenständigen Plugins, aber die Idee mit einer unabhängigen Library finde ich, technisch gesehen, genau so gut.


    Es dann quasi ein Plugin für Plugins, weil das OpenGL-Plugin ohne passendes Ausgabedevice ja eigentlich relativ unnütz ist, oder?
    Man müsste dann nicht daran denken, das OSD-Plugin zusätzlich zu laden. Das Ausgabe-Plugin könnte dann eine einfache "OpenGL-OSD aktivieren"-Einstellung haben und dann selbst die lib laden, wenn es soll.


    Man muss ja auch ein wenig an die Nutzer denken, wie die damit umgehen sollen. :)
    Aber das lässt sich später alles noch auseinander dröseln, wenn der Code erst mal da ist. Und es bliebe der Vorteil der leichteren Kommunikation zwischen Ausgabe-Plugin und OpenGL-OSD-Library.


    Lasst euch durch mich nicht aufhalten... :D


    Lars.

  • Es dann quasi ein Plugin für Plugins, weil das OpenGL-Plugin ohne passendes Ausgabedevice ja eigentlich relativ unnütz ist, oder?

    Kann man so sehen, ich sehe es mehr als zwei unabhängige Plugins. Die Kopplung fand früher halt aufgrund technischer Umstände statt, die heute meist nicht mehr gelten - VDPAU jetzt mal ausgenommen. Und mittlerweile gibt es für gewisse Plattformen ja mehere Ausgabeplugins und es wäre schön, wenn man die mit allenfalls verschiedenen OSD-Plugins kombinieren könnte, ohne dass Abhängigkeiten zum Ausgabeplugin bestehen. Das nur mal so weiter gesponnen...


    Und es bliebe der Vorteil der leichteren Kommunikation zwischen Ausgabe-Plugin und OpenGL-OSD-Library.

    Der Vorteil eines Plugins wäre, dass wir keine neue öffentliche Schnittstelle definieren und unterhalten müssten, bzz. diese nur innerhalb des Plugins verwendet würde.


    Gruss
    Thomas

  • Moin,

    Warum nicht mal ein erstes vdr-oglosd-Plugin für normales X zum funktionieren bringen, und sich dann um die Spezialfälle (dispmanx, Allwinner, Amlogic und eben VDPAU) kümmern?


    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 ;)


    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?


    Ich muss gestehen, je konkreter die Gedanken werden, desto weniger bin ich noch überzeugt, dass das ganze so wirklich Sinn macht. Ich befürchte, dass der Konsolidierungseffekt relativ klein sein wird.


    Ciao Louis

Jetzt mitmachen!

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