softhddevice mit High Level OSD

Cool. Jetzt sehe ich auch, wo ich mit meinem Patch daneben liege.

Also, der Grund für den Absturz bzw. Hänger bei Wechsel des primary device mit offenem OSD ist, dass der OsdProvider von softhddevice einen Pointer auf den OpenGL-Thread an das cOsd mitgibt, der Provider diesen aber einfach löscht, wenn es zerstört wird. Das noch offene Osd hat aber noch diesen Pointer und benutzt ihn.

Ich schau mal, ob ich das irgendwie umbauen kann, so kann das ja nichts werden.

Lars.

Ok, mit std::shared_ptr überall statt cOglThread* und entsprechenden .reset() aufrufen bei delete bzw. Neuzuweisung, und schon sind die Abstürze vorbei.
Wenn man allerdings mit offenem OSD dann z.B. zu dummydevice (oder dbus2vdr's nulldevice wechselt), und dann wieder zurück, sieht man nichts, der vdr hat das OSD aber noch offen, d.h. man muss dann ggf. zwei mal Menü drücken. Ist nicht unbedingt schön, aber schon mal besser als vorher...

Ich versuche mal, einen passenden Patch zusammenzustellen.

Lars.

Moin!

Hier ist der Patch, so dass die cOglThreads per shared_ptr verwaltet werden. Es ist sicherlich noch nicht das Ziel, aber zumindest ein Schritt dahin.

Lars.

Vermutlich sollten die OpenGL-Pixmaps irgendwie testen, ob der Thread noch aktiv ist oder nicht und dann entsprechend nichts mehr tun, keine Ahnung. Da stecke ich jetzt nicht tief genug drin...

Lars

Urgs... ich seh hier 3 - 4 Baustellen bezüglich softhddevice:

1. unnötiges dropping / duping frames
2. softhddevice mit High Level OSD / Frontend Switch
3. softhddevice kompatibel machen zu ffmpeg 2.9

Ich hoffe, ihr kommt da nicht durcheinander

Mit entsprechenden git-Repositories wäre es etwas einfacher, aber es geht schon irgendwie...

Lars

Zitat von mini73

Mit entsprechenden git-Repositories wäre es etwas einfacher

Hab ich schon ein paar mal erwähnt bei diesem Plugin

Hallo Louis,

Zitat von louis

Funktioniert bei dir denn alles soweit?

Der ffmpeg-2.9/3.0 Patch läuft, soweit gestern abend gestet und verwendet, mit dem nativen softhddevice (git stand) ohne bisher erkennbare Probleme.
Einzig ist mir aufgefallen, dass im Bereich der Lautstärke sich etwas verändert hat. Scheinbar, ist bei mir irgendein Regler verdreht, oder ffmpeg 3.0 mixed auf anderen Pegel/Lautstärke.

Mit softhddevice-openglosd hatte ich soweit keinen Erfolg, VDR startet, das Bild kommt, jedoch beim ersten Tastendruck auf der FB schmiert etwas ab (vermutlich in dem Moment, in welchem ein OSD dargestellt werden soll).
Ich hab mir noch nicht die Zeit genommen einen genaueren Blick draufzuwerfen, und kann auch nicht sagen ob das mit dem ffmpeg-2.9 patch zusammenhängt.

Mit freundlichen Grüßen,
z421

Zitat von louis

Bitte mal testen...Ciao Louis

Baut bei mir nicht (make clean && make -j5):

/usr/include/c++/5.3.0/bits/stl_deque.h:580:8: error: call of overloaded ‘swap(cOglCmd***&, cOglCmd***&)’ is ambiguous
    swap(this->_M_map, __x._M_map);
        ^
In file included from /usr/include/c++/5.3.0/bits/stl_pair.h:59:0,
                 from /usr/include/c++/5.3.0/bits/stl_algobase.h:64,
                 from /usr/include/c++/5.3.0/memory:62,
                 from openglosd.h:29,
                 from openglosd.cpp:1:
/usr/include/c++/5.3.0/bits/move.h:176:5: note: candidate: void std::swap(_Tp&, _Tp&) [with _Tp = cOglCmd***]
     swap(_Tp& __a, _Tp& __b)
     ^
In file included from /usr/local/src/vdr-2.2.0/include/vdr/i18n.h:14:0,
                 from /usr/local/src/vdr-2.2.0/include/vdr/plugin.h:13,
                 from openglosd.h:32,
                 from openglosd.cpp:1:
/usr/local/src/vdr-2.2.0/include/vdr/tools.h:57:31: note: candidate: void swap(T&, T&) [with T = cOglCmd***]
 template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
                               ^
<builtin>: recipe for target 'openglosd.o' failed
make: *** [openglosd.o] Error 1
make: *** Waiting for unfinished jobs....

Bei arch ist es ähnlich

Unter Ubuntu kann ich es bauen, aber das OSD sieht etwas abenteuerlich aus (mit skindesigner 0.8.7, commit gcdc1c10):
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/skindesigner/softhddevice-openglosd_1.jpg]
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/skindesigner/softhddevice-openglosd_2.jpg]
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/skindesigner/softhddevice-openglosd_3.jpg]

Edit: nach einem Blick ins Git probiere ich es mal mit der aktuellen skindesigner-Version.

Mar 06 21:35:34 vdr01 vdr[5573]: [5573] [softhddev]CreateOsd: 154, 621, 0, using OpenGL OSD support
Mar 06 21:35:34 vdr01 vdr[5573]: [5573] [softhddev]Trying to start OpenGL Worker Thread
Mar 06 21:35:34 vdr01 vdr[5573]: freeglut (-display 0:0): failed to open display ''
Mar 06 21:35:34 vdr01 vdr[5573]: [5597] oglThread thread started (pid=5573, tid=5597, prio=high)
Mar 06 21:35:34 vdr01 vdr[5573]: [5597] [softhddev]OpenGL using display 0:0

softhddevice startet nicht ohne DISPLAY Variable. Ich habe die bei mir gesetzt und habe den Fehler in VDR4Arch gar nicht wirklich realisiert.
Habe aber jetzt vermehrt Anfragen deswegen.

Das Log ist ohne gesetzte Display Variable. Installierte Version ist commit: bf608ab52cbbeb763e620bfe68267ff5c4edcae0

Bei mit genau das gleiche Problem ohne gesetzte DISPLAY Variable mit meinem vdr4arch. Starte ich allerdings den VDR mit dem Benutzer root, so startet softhddevice und alles läuft. Gibt es da irgendwo Probleme mit Rechten des Benutzers?