Beiträge von louis

    Wenn der VDR beim ersten Kanalwechsel hängt und entweder kein Bild oder ein eingefrorenes Bild des aktuellen Kanals anzeigt, sieht das in Log und mit gdb so aus:

    Laut deinem Log wird der Osd Thread bei dir direkt nach dem Starten aus irgendwelchen Gründen wieder gestoppt. Wird dann das OSD angefordert, gibts einen Deadlock. Der würde aber nicht passieren, wenn der Osd Thread laufen würde...

    jojo : ich könnte mir vorstellen, dass es Probleme macht, dass du aus zwei Threads parallel auf den OpenGL Kontext zugreifst. Du hattest das "ActivateOsd" ja wohl schon mal in cOglCmdCopyBufferToOutputFb drinn. Dadurch würde die Ausgabe des OSD vom Osd Thread erledigt. Vielleicht wäre das besser...du hattest aber wohl sicherlich deine Gründe, warum du es anders herum machst ;)

    Moin,


    die Qualität des Kabels ist ausschlaggebend. Ich hatte ganz am Anfang auch mal so ein billiges, da hatte ich auch Empfangsprobleme. Dann habe ich mir ein hochwertiges kurzes Kabel (1m) gekauft, seitdem hab ich Ruhe.

    PS:

    Du erezeugst keinen GlxContext warum ?

    Da ich ja "offscreen rendering" betreibe und das fertige Ergebnis dann per OpenGL - VDPAU Interop VDPAU "unterschiebe", brauche ich quasi nur einen "Dummy" GLX Context, den ich per glut an dieser Stelle erzeuge. Hier wird aber lediglich ein 1*1 px großes Fenster im Eck oben links erzeugt, das ich dann verstecke, da in diesem Fenster nie gerendert wird.


    Per Cuda wird das dann wohl anders laufen...ich hatte ja geschrieben, dass es womöglich sogar direkter funktioniert, da du dir diesen Umweg wohl sparen kannst. Aber an dieser Stelle kenn ich mich nicht aus ;)

    Moin,

    Es gibt keinen CUDA Buffer den ich so einfach auf den Screen bekomme. Das einfachste wäre wenn ich den FBO den du erzeugst ausgeben könnte. Oder das dazugehörige texture einfach als quad rendere. Mir ist aber nicht klar in welchem texture das ergebnis vom OSD rendern liegt.


    das fertige OSD wird in void cOglOsd::Flush(void) zusammengebaut. Jede erzeugte Pixmap beinhaltet selbst einen Framebuffer bzw. eine Textur, die in der Schleife über die Pixmaps dann entsprechend des Layers der jeweiligen Pixmap transparent übereinander gelegt werden. An dieser Stelle ist das OSD dann fertig auf den "bFb" gerendert und wird auf den (von Vdpau geholten) oFb kopiert. Wenn du also die Möglichkeit hast, den bFb direkt auszugeben, sollte das die Stelle der Wahl sein ;)

    Moin,

    hm...ich hole mir ja hier aus dem Videothread das Vdpau Output Surface, auf das dann der oFb kopiert wird. Könntest du dir hier ggf. was ähnliches CUDA Spezifisches holen?


    Ciao Louis

    Aber das jetzige OSD wird auch schon mit opengl gemacht.

    Wir reden von zwei unterschiedlichen Sachen: bei dir wird bei der Ausgabe des OSD die komplette Surface per CPU im Hauptspeicher gerendert, dadurch entsteht z.B. im Falle von UHD ein 4096 × 2048 großes Array aus 32bit ARGB Werten. Das sind dann pro Surface ca. 32 MByte an Daten, die du aus dem Hauptspeicher per OpenGL auf die GPU transferierst.


    Das OpenGL OSD hingegen überschreibt die cOsd und cPixmap Klassen vom VDR, wodurch die Erzeugung von Pixmaps und das Zeichen auf diesen Pixmaps direkt per OpenGL auf der GPU und im dortigen Speicher geschieht. Zum einen sind so die Zeichenbefehle effizienter auf der GPU per OpenGL abbildbar, zum anderen müssen die Daten nicht mehr quer durch die Maschine geschoben werden...das sollte von der Performance her also schon einen gewissen Unterschied machen ;)


    Ciao Louis

    Moin,


    könntest du dir vorstellen, das hardwarebeschleunigte OSD einzubauen?


    Siehe https://github.com/louisbraun/softhddevice-openglosd


    Ich habe mich zwar nicht in die Cuda API eingelesen, aber theoretisch sollte es relativ einfach auf deine Umgebung portierbar sein. Ich rendere offscreen per OpenGL auf ein OpenGL Surface und gebe das dann per OpenGL / VDPAU Interop als VDPAU Surface aus. Ähnliches sollte doch mit Cuda auch machbar sein, womöglich sogar direkter...


    Unterstützung kann ich dir leider keine anbieten, da ich aktuell weder eine passende Grafikkarte noch eine Entwicklungsumgebung aussen herum habe ;) Aber ich würde natürlich gerne auf Fragen deinerseits bzgl. des Codes eingehen.


    Wäre cool, wenn du Lust hättest, dir das mal anzuschauen :)


    Ciao Louis

    Man sollte sich vorher noch beim Kabelbetreiber informieren, wie das mit der Verschlüsselung aussieht.

    Zumindest bei Unitymedia ist das einfach...da gibt es keine Smartcards mehr sondern nur noch den Horizon Receiver, der die Entschlüsselung integriert hat. Also nix mehr mit alternativen Methoden.


    Wohl dem der noch einen Altvertrag und eine Smartcard hat...bei der letzten Anpassung wollte mir dir Dame am Telefon einen solchen Receiver aufschwatzen, da musste ich mich vehement wehren :D

    Moin,

    Ist zwar eine andere Frage und hat eigentlich weniger mit dem Thema zu tun, aber was bräuchte man für DVB-C, damit ich mein Setup weiter so betreiben kann, d.h. Server mit VDR für Aufnahmen, VNSI Server sowie Client mit VDR. Für mich reichen ja eigentlich 4 Clients/paralelle Aufnahmen.

    eigentlich musst du deinen Sat>IP LNB nur gegen einen "DD Octopus NET V2 C2T2I/2 - Kabel>IP Netzwerktuner" austauschen und der Drops sollte gelutscht sein...


    Ciao Louis

    @Klaus: ich habe es schon verstanden, wie es korrekt funktionieren würde. Ich wollte nur ausdrücken, dass der "Holzhammer Patch" von Saman Mist ist ;)


    Paulaner : naja, private Gründe waren es eher nicht, vielmehr hat es mich genervt, wie die Entwicklung im VDR Umfeld abläuft und wie die "VDR Community" so tickt. Deshalb habe ich mich dazu entschlossen, meine Zeit anderweilig für mich sinnvoller zu investieren...

    Schaut so aus als ob der VDR in einen Deadlock läuft...scheint der VDR-2.3.x Patch für den Zapcockpit Patch noch nicht ganz rund zu sein. Komisch, ich dachte eigentlich, zumindest bei den MLD Jungs wird der benutzt...

    Seit einigen Wochen ist ja das Laden von Bildern gefixt. Ich nutze EPGD, epg2vdr und scraper2vdr mit DVB Daten (Sat) und EPG-data Abo.

    Bilder erhalte ich nun für die meisten ÖR Programme. Bei den Privaten Fehlanzeige.

    Du musst unterscheiden zwischen "EPG Bildern", die von den EPG Providern kommen, und den Bildern, die der Scraper (das scraper2vdr Plugin) für die bestehenden Events in der Datenbank zusätzlich herunterlädt. "EPG Bilder" sind i.d.r. Screenshots von Szenen aus der Sendung, bei den scraper2vdr Bildern handelt es sich um Poster, Banner und Fanarts.


    Damit scraper2vdr Bilder für einen Event in der DB lädt, muss das Event als Serie oder Movie in der DB identifiziert sein. Mit den EPG Loadern selbst hat das erst mal nichts zu tun, das funktioniert mit jedem. Anders bei den EPG Bildern, die kommen ja direkt vom EPG Provider. Hier hängt das Ergebnis sehr wohl vom benutzen EGP Provider ab.


    Zu guter Letzt ist es auch noch relevant, welchen Skin du einsetzt. Es gibt Skins, die nur die EPG Bilder unterstützen, andere Skins unterstützen nur die scraper2vdr Bilder, andere Skins unterstützen beides.


    Ist alles ein bisschen unübersichtlich und die größtenteils nicht vorhandene Doku ist scheisse ;) Aber irgendwo steht schon mal alles im Forum in den unterschiedlichen Threads...