Beiträge von rell

Hm schade. Wäre gut, wenn sich jemand bereit erklärt, bei der Lösungssuche mitzuhelfen, da ich selber das nicht reproduzieren kann.
Gruß
Andreas

Eigentlich nicht.
Welcher Kernel, softhddevice und libvdpau-sunxi Version nutzt du?
Wann tritt das auf? Was meinst du mit Flackern?

Gruß
Andreas

Zitat von CvH

bananapi ist "Schrott",

OK, weil? Weil Kodi nicht läuft, oder generell?

Und was zum Teufel sind diese "ARMdinger"? EDIT:
Gruß Andreas

Zitat von ollo

Allerdings frisst irgendwas Speicher, wenn auch sehr langsam. Nach 2..3 Wochen braucht's einen Reboot

Gruß, ollo

An sich nicht so optimal.... Hast du einen Überblick wie sich der Speicherverbrauch über die Zeit ungefähr ändert?

Gruß Andreas

Zitat von magicdragon67

Zum Speicher im Allgemeinen
Wo bitteschön ist denn da das Problem ?

Angenommen, es handelt sich nicht um yavdr und i386 Systeme, würde ein überhöhter Speicherverbrauch oder sogar ein leak auf ARM Systemen mit 512-1024MB Speicher schon zu einem Problem führen. Ohne den Link jetzt raussuchen zu wollen, weiß ich nicht, ob der Thread von johns damals mit "Etwas frisst Speicher" gelöst wurde und/oder hier im Zusammenhang steht.
Gruß Andreas

Zitat von reufer

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

Zitat von reufer

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

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

Zitat von reufer

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

ACK bis hierhin.

Zitat von reufer

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

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

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 ...
Gruß Andreas

Zitat von reufer

Klingt, als ob es schon bald eine plattformübergreifende Implementation eines beschleunigten High-Level-OSDs gibt.

Damit stellt sich für mich nun ernsthaft die Frage, ob es nicht sinnvoll wäre, die Arbeit ein eigenständiges Plugin zu stecken. Die Verknüpfung von Ausgabedevice und OSD ist in meinen Augen nicht mehr zwingend, da es inzwischen sowohl für die Videoausgabe wie auch für das OSD auf allen Plattformen mehrere unabhängige Wege gibt. Ein OpenGL/ES-OSD-Plugin würde dann swohl auf einem Raspberry Pi, einer Wetek-Play oder einem Desktop (?) laufen und könnte zentral gepflegt werden. Das nur mal so als Idee.

Ich habe das noch nicht weiter gedacht... Ich habe nur dem libvdpau backend für die Allwinner Devices ein gles interop feature spendiert, das ja für nvidia auf gl-Basis existiert und von louis' HighLevel OSD- softhddevice genutzt wird. Dann musste nur das softhddevice von gl auf gles angepasst werden... Ein zentrales OSD-Plugin wäre möglicherweise sinnvoll, obwohl ich über Vor- und Nachteile noch nicht nachgedacht habe. Aber "denkenswert" ist das bestimmt

Gruß
Andreas

Hallo zusammen,

mit Erlaubnis von Louis darf ich den Thread in gewisser Weise "hijacken"
Ich habe hier die Commits von Louis auf den Branch von johns ge-cherry-picked und einen Commit draufgesetzt, der glGetError() nach jedem GL Befehl einführt.
Da ich das ganze als Vorbereitung für die gles Funktionalität gemacht habe und hier keinen i386 mit softhddevice zum Testen habe, wollte ich fragen, ob diesen Branch mal jemand ausprobieren und schauen könnte, dass damit kein Bug einwandert ...
Es würde mir dann auch helfen, wenn jemand den gles branch auf dem i386 probiert, um sicherzustellen, dass ich auch hier nichts kaputt gemacht habe

Mein eigentliches Ziel, ein softhddevice mit OpenGL/ES Unterstützung, ist grundsätzlich erreicht, obwohl noch ein paar Sachen zu fixen sind. Wenn da Interesse besteht, mache ich einen neuen [WIP]Thread dazu auf und beschreibe, wie man das zum Laufen kriegt. Evtl. finden sich ein paar Tester...

Danke und Gruß
Andreas

Wieder mal ein Projekt, vor dem ich den Hut ziehe. Gefällt mir seht gut. Gratulation!
Mir schwebt schon seit Jahren sowas ähnliches vor... http://2dom.github.io/the-radio/
Das Material liegt schon rum... Hier laufen drei Squeezeboxen und 1x squeezelite auf einem Cubieboard im Wohnzimmer. Und das wäre von der Optik her "ausbaufähig" :p

Gruß Andreas

Als Image würde ich dir Armbian empfehlen.
Nach erfolgreichem Start sollte dein Cubieboard im Netzwerk erreichbar sein. Falls nicht, hat wohl was mit der SD Karte/ Image nicht geklappt.
Sollte weder über HDMI noch über das Netzwerk was zu erkennen sein, hilft dir wohl nur das hier.
Ich würde trotzdem vermuten, dass etwas mit der SD Karte oder dem Image nicht stimmt.

Gruß
Andreas

Naja, die gleichen Optimierungen, die die A10/A20 Version auch enthält.
Deinterlacer ist auf H3 anders, den muss ich mir erst anschauen - oder jemand anderes natürlich.
Das OSD gehört optimiert, dass das nur geblittet wird, wenn es sich auch wirklich verändert hat. Derzeit ruckelt das Bild ohne Ende mit offenem OSD.
Und das ein oder andere, was einem noch so auffällt. Wir sind gerade dabei, einige meiner Commits "masterfähig" zu machen damit VDR mit dem master branch vernünftig läuft. Dauert aber noch.

Die andere Baustelle ist das GLES beschleunigte softhddevice, das ich gerne für die Allwinner hätte...
Also, gibt immer was zu tun.

Ich war nur erstaunt, dass es gestern doch so einfach ging, vdr zum Laufen zu bringen
Wer's nachbauen möchte ... ich habe hier meine Schritte etwas mitgeschrieben. Dafür wäre wohl aber dann ein eigener Thread nicht schlecht.

Gruß Andreas

Hallo zusammen,

wollte nur kurz Bescheid geben, dass der VDR hier gerade auf dem Orange Pi Plus läuft. Also auf dem Allwinner H3.
Noch nicht ganz rund, aber immerhin Bin mir ziemlich sicher, dass wir das dort ebenso gut hinkriegen.

Gruß
Andreas

Die Allwinner H3 könnens hardwareseitig und sind treibermäßig "fast" schon fertig vorbereitet...
Gruß Andreas