Moin,
zu dem "1 s beim ersten OSD Aufruf" Problem: ich erinnere mich dunkel, dass einige DVB Karten bzw. die Treiber sehr lange benötigen, bis die Signalinformationen der DVB Adapter gelesen sind. Deshalb tritt dieser Effekt bei manchen auf, bei manchen nicht...
Ciao Louis
Good point, but who creates the associated XML files for each skin.
And for native skins a separate OSD must also be implemented.
Exactly because of this reasons I decided to stop my VDR activities 
In "skindesigner universe" the Skindesigner Plugin Interface is intended to do this job
Moin,
ich habe übrigens absolut kein Problem damit, wenn du das Git auf vdrdeveloper übernimmst...weiter so
Ciao Louis
Moin,
ein Plugin, dessen OSD Objekt von cOsdObject erbt, hat die volle Kontrolle über das OSD.
Moin,
wenn du magst, ich hab hier noch eine CTV7 rumliegen, die ist ca. 2 1/2 Jahre alt, die könntest du haben. Falls Interesse besteht, können wir uns über den Preis sicherlich einigen...
Ciao Louis
rella hatte einmal eine softhddevice-opengl-version gemacht. Darauf aufbauend hatte Louis spezielle Versionen seiner drei Plugins gebaut zum Testen.
Das ist Quatsch. Es gibt keine "OpenGL Versionen" dieser Plugins.
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:
- Syslog: start_freeze_after_channel_change.txt
- gdb Backtrace: start_freeze_after_channel_change.bt.txt
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,
Alles anzeigenlouis Ich habe nun mal versucht das openglosd einzubauen. das klappt auch soweit ganz gut. Nur mit der Anzeige kämpfe ich noch.
Der oFb ist ja das finale rendering Ziel vom OSD Thread. Diesen FBO will ich nun im videothread anzeigen. Das klappt aber irgendwie nicht.
Hast du ein Idee wie ich einen FBO von einem Thread zu einem anderen übergeben kann ? Oder was ich als Callback vom video thread zum OSD Thread
einbauen kann damit er dann das OSD direkt auf den Screen rendert.
mfg
Jojo61
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 
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...
