Beiträge von Zoolook

  • Wetek Play OPENELEC Nand Installation - einige Fragen

    Zitat von Tim35p07

    Habe es mit Hilfe dieser Anleitung nun hinbekommen http://wetekforums.com/v/index…ery-from-microsd-possible


    War wohl eher eine Glückssache weil ich keine Möglichkeit hatte via Serial Debug mögliche Fehler auszulesen


    Hast Du also recovern können, ohne die Befehle in der seriellen Konsole einzugeben, kann das auch gehen? Hast Du aber dennoch Pins 5 und 6 aus Pic2.jpg kurzgeschaltet während des Bootvorgangs?


    Suche dringend nach der Möglichkeit bei einem Freund eine gebrickte Wetek Play zu recovern (schwarzer Bildschirm, nicht mal Bootlogo, nachdem versucht wurde, ein E2 Image ins NAND zu flashen).



    Cheers,
    Lucian

  • Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

    Zitat von wirbel

    Für die deutsche wiki brauchst du nix weiter als einen sinnvollen Benutzernamen und eine email addy (die nie benutzt werden wird und auch niemand zu sehen bekommt), beides nur damit man weiß dass du kein Spam Bot oder Programm bist, der die wiki verwüstet.

    Doch, die sollte sinnvollerweise zur Wiederherstellung des Passwortes genutzt werden (zum Glück passiert es auch), ich habe nämlich festgestellt, daß ich doch seit wer weiß wie langer Zeit da doch einen Account hatte, nicht nur in der deutschen, sondern auch in der englischen Version. Trotzdem finde ich es schade daß es zwei komplett unterschiedliche Wikis sind, mittlerweile kann auch Mediawiki mehr bieten.

    Zitat von wirbel

    Den anderen Firlefanz kannst(solltest..) du leer lassen - und würdest du dort etwas reinschreiben, würden wir das als löschen, bevor wir dein Nutzernamen und eine Benutzerseite für dich erstellt wird.


    Also red keinen Unsinn.

    Was von "Persönliche Vorlieben (nur Text):", "Zusätzliche Angaben:" oder "Liste von Webseiten (durch Zeilenumbrüche getrennt):" ist denn die "Biographie" (siehe screenshot)? Also Unsinn ist es wenn Informationen nicht zusammen passen, oder schlecht übersetzt sind, oder inkonsistent sind, damit will nicht jeder seine Zeit verbringen...

  • Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

    Zitat von mini73

    Ist doch schon (ansatzweise) im Wiki: http://vdr-wiki.de/wiki/index.php/Plugins


    Ich weiß nur nicht, ob das welche pflegen.

    Ich denke, die Bereitschaft das zu tun ist nicht besonders groß, wenn man dafür einen Account braucht, für welchen man so viele Angaben machen muß (Biographie und so), dann auch feststellt, daß man zwar einen Account hat, aber der ist für das englische VDR-Wiki, welches aber auf linuxtv gehostet wird und mit dem deutschen auch gar nichts zu tun hat und nicht in Sync ist. Eine modernere Platform wäre hilfreich, am Besten eine von den vielen frei verfügbaren, wie auf Github, da kann man auch Wikis erstellen...


    BTW, ich habe im git auf vdr-developer.org das graphlcd-plugin vdr-2.3.x tauglich gemacht, vielleicht testet das jemand noch für 2.2.0 nur um zu bestätigen daß es für die Version nicht kaputt ist.


    Gruß,
    Lucian

  • OglOsd - Aufruf zum Feinschliff der Konzepte

    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

  • OglOsd - Aufruf zum Feinschliff der Konzepte

    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

  • OglOsd - Aufruf zum Feinschliff der Konzepte

    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

  • OglOsd - Aufruf zum Feinschliff der Konzepte

    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

  • OglOsd - Aufruf zum Feinschliff der Konzepte

    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

  • 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

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo Thomas,

    Zitat von reufer

    Ein offensichtlicher Punkt ist der Framebuffer, ein anderer der HW-TS-Demuxer - wobei der bei der aktuellen git-Version des Plugin eigentlich nicht gebraucht wird. Mehr Informationen habe ich leider auch nicht. Kodi wiederum nutzt den Codec anders, indem Bild und Ton separat decodiert und synchronisiert werden - das sollte in meinen Augen in einem Ausgabeplugin aber nicht das Ziel sein.

    Vielleicht wäre es doch sachdienlich, sich bei den funktionierenden Varianten, umzuschauen. Ich weiß nicht ob Du nicht etwa auch auf OpenPLi's Amlogic Enigma2-Ausgabeplugin gestoßen bist (den genauen Status kenne ich nicht, vielleicht kann sich dazu jemand der das weiß, äußern), aber dort scheint es mir wenn mich nicht alles täuscht, wird auch Audio und Video ähnlich wie bei Softhddevice oder Kodi nicht von der Hardware, sondern in der Software synchronisiert, Du würdest es bestimmt besser als ich verstehen:

    und


    Meinst Du, sowas könnte man im amlhddevice machen?


    Gruß,
    Lucian

  • softhddevice mit High Level OSD

    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

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Danke Thomas und Claus für Eure Erläuterungen.

    Zitat von reufer

    Die DVB-Treiber führen bei mir auch zu Problemen, deshalb arbeite ich stets mit streamdev- oder satip-Plugin. Ich kann mir den Zusammenhang auch nicht erklären und leider findet man nirgens Informationen, was die Treiber an der Hardware umkonfigurieren. Deshalb ist das amlhddevice leider nach wie vor eine Baustelle.

    Das würde also heißen, theoretisch ginge es über den Umweg, minisatip + vdr-satip auf der gleichen Wetek doch amlhddevice zu nutzen?


    Was meinst Du denn mit den Treibern die die Hardware umkonfigurieren? Ich dachte, die einen sind die DVB-Treiber, und die Ausgabe von dekodiertem Video und von OSD ist eine andere Geschichte, aber wie ich es von Euch verstehe, beeinflussen sie sich. Wie funktioniert es denn dann mit Kodi als Ausgabe und VDR als Receiver, nutzt Kodi denn da irgendein closed-source Modul dafür wo wir nicht 'reinschauen können?


    Gruß,
    Lucian

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo,


    mittlerweile habe ich für meine OpeneELEC-7.0 Installation auf der Wetek Play das amlhddevice so patchen müssen, daß die Framebuffer-Devices vertauscht werden, denn dasjenige mit der 32-bittigen Farbtiefe ist bei mir /dev/fb0. Dann kann man auch kurz das OSD vom STTNG-Theme sehen, aber kein Ton und kein Bild, alles schwarz, obwohl VDR auf ARD HD schaltet. Die Fernbedienung die ja Kodi als LIRC-Device nutzen kann, will der VDR nicht anlernen, auch wenn ich ihm den gleichen Pfad zum LIRC-device gebe den auch Kodi nutzt (wenn es gestartet ist, denn ich probiere amlhddevice selbstverständlich mit beendetem Kodi).


    Funktioniert denn bei jemandem etwas mehr, mit amlhddevice und der Original-FB der OpenELEC Edition der Wetek Play?


    Gruß,
    Lucian

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo,


    mittlerweile kann ich amlhddevice auf der Wetek Play mit OpenELEC-7.0 starten, nachdem ich den Kodi-Dienst stoppe. In einer Konsole starte ich folgende Kommandozeile und das ist hinterher auch sichtbar:


    In einer anderen Konsole filtere sieht man aus dem syslog Folgendes:


    Ich denke da fehlt noch ein Skin-Plugin, das muß ich noch als OpenELEC-Paket genauso wie amlhddevice aufbereiten, und ein Keymapping der Fernbedienung, mache ich heute Abend.
    Trotzdem, am Fernseher hätte ich ein Live-Bild erwartet, es kommt nur das weiße Bootlogo der Wetek-Play (das vor dem Plymouth-Splash), warum wohl?
    Welches Skin-Plugin soll ich denn nehmen, Skindesigner wäre natürlich schön?
    Wie sieht denn der Log aus, irgendwelche Auffälligkeiten?


    Gruß,
    Lucian

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hi,

    Zitat von Zoolook

    Das dabei erzeugte libvdr-amlhddevice.so.2.2.0 "will" selber nach wie vor nur libamcodec.so, und nur darüber, und nicht unmittelbar libamadec.so. Von libamavutils.so nach wie vor keine Rede. Wird denn da beim Linken zu viel weg-optimiert, kann man es noch durch andere Flags beeinflussen (deswegen postete ich nun den kompletten Output)?

    ich fand dafür die Lösung, indem ich beim Patchen des Makefiles noch -Wl,--no-as-needed zu den LDFLAGS hinzugefügt habe, um das Default des Build-systems (as-needed) für dieses Paket auszuschalten, somit stimmen schon mal die Abhängigkeiten. Werde demnächst mal Funktionalität testen.


    Gruß,
    Lucian

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo Thomas,

    Zitat von reufer

    Es fehlen amavutils und amadec, meine Linker-Flags schauen wie folgt aus:

    Code
    -lamavutils -lamadec -lamcodec

    das macht natürlich Sinn, ich hatte inzwischen auch den Verdacht daß amavutils da mit herein muß, weil die Implementierung auf die das fehlende Symbol hinweist daher kommt. Amadec hatte sich der Linker über amcodec auch so 'reingezogen. Trotzdem, ich habe nun die Flags genau so, explizit in Dein Makefile hereingepatcht (sieht man weiter unten) und beim Linken macht es immer noch keinen Unterschied, erzeugt wird ein gleich großes, mit ldd auf dem Zielsystem nachweislich mit den gleichen Abhängigkeiten wie schon gestern gepostet, und ich habe es ganz sicher richtig hinkopiert, sieht man am Datum und binär gab es doch Unterschiede, nur in der Größe nicht. So sieht der Output beim Bauen aus (ganz am Schluß in letzter Zeile die Linker-Flags):


    Das dabei erzeugte libvdr-amlhddevice.so.2.2.0 "will" selber nach wie vor nur libamcodec.so, und nur darüber, und nicht unmittelbar libamadec.so. Von libamavutils.so nach wie vor keine Rede. Wird denn da beim Linken zu viel weg-optimiert, kann man es noch durch andere Flags beeinflussen (deswegen postete ich nun den kompletten Output)?


    Gruss,
    Lucian

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo,


    ich wollte mal amlhddevice auf der Wetek ausprobieren, und weil ich es bislang nicht geschafft habe, dafür ein Gentoo zu cross-emergen, habe ich für eine Vorversion von OpenELEC-7.0 das Ausgabeplugin gebaut, und an entsprechender Stelle kopiert, Kodi gestoppt und VDR nun mit amlhddevice gestartet. Leider kommt dieser Fehler:

    Code
    vdr: /usr/lib/libamadec.so: undefined symbol: amsysfs_set_sysfs_str

    der das Starten dann komplett verhindert. Die notwendigen Libs sind auch alle da:


    Aus Mangel einer pkgconfig-Datei der libamcodec im OpenELEC-buildsystem habe ich im Makefile von amlhddevice -lamcodec für den Linker genutzt. War das denn zu wenig?


    Gruß,
    Lucian

  • Windows bekommt eine bash, bald VDR unter Windows?

    Zitat von schnoefftel

    Hoffentlich wird man Windowsprogramme aus der bash aufrufen können. Da würden mir sicher ein paar Sachen einfallen.

    Das geht doch auch mit den cygwin oder mingw32 bash-Implementierungen. Was da aber beschrieben wird, scheint mir das Ausführen von nativen Linux-binaries zu sein, in einer Art Emulator sowas wie Wine unter Linux um Windows-binaries auszuführen, nur halt umgekehrt.