Wenn es wirklich ein Crash ist, würde mich der Backtrace interessieren.
Hier mein erstes Backtrace.
Helfe gerne weiter.
[rpihddevice] OSD mit GPU-Unterstützung und Pixmap-Support
-
-
Hier mein erstes Backtrace.
Danke. Da scheint die Default-Pixmap zu fehlen. Das kann vorkommen, wenn kein GPU-Speicher mehr da ist, z.B. weil der VDR zuvor aus einem andern Grund gecrasht ist, und diesen nicht mehr freigeben konnte.Gruss
Thomas -
Hallo Thomas,
habe am WE VDR 2.2.0 und das aktuelle rpihddevice auf einem RPI1-B+zum Laufen zu bekommen. VDR hatte bisher nie die Zeit bekommen, mal eine setup.conf wegzuschreiben, daher bin ich in einer Endlosschleife von "VDR startet, versucht das OSD darzustellen und semmelt weg, weil angeblich kein Speicher beim Erstellen der Pixmaps zur Verfügung steht. Dann muss ich den RPI, wie von dir und den anderen hier im Thread beschrieben, neu starten, da der Speicher nicht mehr freigegeben wurde.
Das kann ich so nicht bestätigen. Ich lade (und benutze) nebst den Standardskins auch skinenigmang und skindesigner (0.2.2).
Ich habe es auch mit Skinenigmang versucht, bisher jedoch ohne Erfolg.
Als weiteren Test muss ich mir mal eine halbwegs gefüllte setup.conf von meinem Haupt-VDR schnappen und darin z.B. die verwendeten Fonts angleichen. Du hattest in einem deiner vielen Beiträge mal geschrieben, dass jeder Font wiederum mehr Speicher wegknabbert und das deckt sich augenscheinlich mit den Logging-Meldungen des VDR."Beruhigend", dass ich nicht alleine mit dem Problem bin
Viele Grüße,
Chriss -
Danke. Da scheint die Default-Pixmap zu fehlen. Das kann vorkommen, wenn kein GPU-Speicher mehr da ist, z.B. weil der VDR zuvor aus einem andern Grund gecrasht ist, und diesen nicht mehr freigeben konnte.Gibt es denn eine Möglichkeit den GPU Speicher manuell frei zu geben? Würde das dann bei mir beim Wechsel zwischen den Frontends einbauen. Zwischenzeitlich habe ich leider auch mal dieses Problem das anscheinend kein Speicher mehr verfügbar ist.
Gruß Patrick
-
Gibt es denn eine Möglichkeit den GPU Speicher manuell frei zu geben?
Nicht das ich wüsste. Aber ich arbeite momentan an dem Problem und hoffe, die Ursache für das Speicherleck zu finden - den Speicher manuell freizugeben wäre nicht mehr als ein Workaround.
Gruss
Thomas -
-
Would it be possible to return the actual video aspect ration in cOmxDevice::GetVideoSize()? The value is used for scaling DVB subtitles and now 16:9 SD content uses a 4:3 layout.
I don't see any flag indicating anamorphic video or a way to read the actual pixel size. If this is required, I could poll popcornmix, the firmware guy, maybe he has an idea.Regards,
Thomas -
Bei meinen Versuchen mit der MLD und dem Raspi2 kann ich auch ab und zu hänger beobachten, teilweise fehlt dann das OSD (trotz 256Mb VPU Ram). Was ich aber noch viel häufiger beobachte sind immer mal wieder beim Umschalten, das Ausfallen des Deinterlacings. Und es passiert bei allen Formaten, egal ob HD oder SD. Manche Sender wie Super RTL bzw Sender mit altem Filmmaterial sind besonders anfällig. Die Kammeffekte sind bei niedrigen Auflösungen schon sehr extrem. Schaltet man um behebt sich der Fehler oft sofort, manchmal gar nicht, manchmal von alleine nach ein paar Sekunden.
Ich habe den Skindesigner mit Skinopacity aktiv.
Vielleicht trägt dass auch zu dem Speicher Problem bei.
-
Bei meinen Versuchen mit der MLD und dem Raspi2 kann ich auch ab und zu hänger beobachten, teilweise fehlt dann das OSD (trotz 256Mb VPU Ram).
Dieses Problem ist bekannt - falls du das gezielt provozieren kannst, wäre ich froh um entsprechende Hinweise. Ich gehe davon aus, dass du den aktuellen git-Stand benutzt?
Was ich aber noch viel häufiger beobachte sind immer mal wieder beim Umschalten, das Ausfallen des Deinterlacings. Und es passiert bei allen Formaten, egal ob HD oder SD. Manche Sender wie Super RTL bzw Sender mit altem Filmmaterial sind besonders anfällig. Die Kammeffekte sind bei niedrigen Auflösungen schon sehr extrem. Schaltet man um behebt sich der Fehler oft sofort, manchmal gar nicht, manchmal von alleine nach ein paar Sekunden.
Das beobachte ich hier auch: Das wird ein Firmware-Problem sein, wahrscheinlich geraten Top/Bottom-Field durcheinander, bzw. werden nicht korrekt signalisiert. Ausserdem meldet der Decoder bei ServusTV HD eine Framerate von 25 Vollbildern pro Sekunde, was falsch ist. Werde, sobald ich dazu komme, versuchen rauszufinden, seit wann das Problem besteht und ein Ticket schreiben.
Gruss
Thomas -
reufer:
Im Log sehe ich bei ServusTV-HD --> 1080@50i .... Wäre doch richtig. Oder sieht man das nicht, was der Decoder meldet, bzw. kommt das selten vor? -
Im Log sehe ich bei ServusTV-HD --> 1080@50i .... Wäre doch richtig. Oder sieht man das nicht, was der Decoder meldet, bzw. kommt das selten vor?
Stimmt, nun passt's bei mir auch wieder. Entweder habe ich das geträumt, oder da war nur vorübergehend was krumm und wurde bereits wieder gefixt.
Gruss
Thomas -
Stimmt, nun passt's bei mir auch wieder. Entweder habe ich das geträumt, oder da war nur vorübergehend was krumm und wurde bereits wieder gefixt.
Das könnte passen, weil ich heute morgen alles aktualisiert habe. (rpi-update und apt-get update...)
Viele Grüße, Uwe
-
Hi Thomas
Nach heutigem "git pull" und neu bauen des Plugins bekomme ich folgende Fehler wenn das OSD auf gehen soll. Danach geht nich mehr.Code
Alles anzeigenMar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) Mar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) Mar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) Mar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) Mar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) Mar 31 21:33:29 rpi1 vdr: [19865] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 21:33:29 rpi1 vdr: [19777] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) -
-
Nach heutigem "git pull" und neu bauen des Plugins bekomme ich folgende Fehler wenn das OSD auf gehen soll. Danach geht nich mehr.
Kann ich mit dem skindesigner auch nachvollziehen, liegt an diesem Commit :Diff
Alles anzeigendiff --git a/ovgosd.c b/ovgosd.c index 2879cb6..f137496 100644 --- a/ovgosd.c +++ b/ovgosd.c @@ -755,6 +755,9 @@ public: virtual bool Execute(cEgl *egl) { + if (!m_target->MakeCurrent(egl)) + return false; + m_target->image = vgCreateImage(VG_sARGB_8888, m_target->width, m_target->height, VG_IMAGE_QUALITY_BETTER);
Werde ich heute Abend rückgängig machen, bis dahin einfach die beiden Zeilen auskommentieren/löschen.Gruss
Thomas -
Super.
Danke dir -
Wie von Thomas vorgeschlagen, habe ich mal den Patch für das OSDTeletextplugin überarbeitet. Alle Zeichenoperationen laufen jetzt auf einer (nicht OSD) cBitmap und werden nach Fertigstellen der Teletextseite in einem Schritt per DrawBitmap in die OSD Pixmap geschrieben. Ich hoffe, damit funktioniert es jetzt auf dem Raspi.
Gruss, kanadakruemel
Hallo,
ist das jetzt die aktuellste Version oder gibt es schon ein aktuelleren Patch?
Habe den Patch gestern mit der aktuellen osdteletext Version angewendet und alles funktioniert hier. -
Hallo Uwe,
Hallo,
ist das jetzt die aktuellste Version oder gibt es schon ein aktuelleren Patch?
Habe den Patch gestern mit der aktuellen osdteletext Version angewendet und alles funktioniert hier.Es freut mich, dass es bei Dir funktioniert!
"Offiziell" ist der Patch die neueste Version
. Auf meinem VDR liegt noch eine Testversion rum, die die Funktion "DrawScaledBitmap" benutzt. Das sollte auf solchen Clients wie RPi nochmal Performance bringen, da ja nur die Teletextauflösung gezeichnet werden muss und die GPU das Scaling übernimmt. Dazu habe ich noch eine AntiAliasing Option vorgesehen - für den, der pixelig nicht so mag wie weichgespült.
Die Version ist aber noch nicht komplett getestet und im Moment komm ich auch nicht dazu (RL ... und die Hitze).Gruss,
kanadakruemel -
Hallo kanadakruemel,
Dank Dir für die Info. Die neuen Sachen für den Patch klingen sehr gut.
Viele Grüße, Uwe
-
Die Version ist aber noch nicht komplett getestet und im Moment komm ich auch nicht dazu (RL ... und die Hitze).
Hallo kanadakruemel,
gibt es hier was neues zum Plugin?Viele Grüße, Uwe
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!