Kommando zurück.
Kannst du versuchen, die ganze Funktion HasIBPTrickSpeed rauszunehmen:
https://github.com/rellla/vdr-plu…evice.cpp#L1624
Ich bin C++ Neuling und das false ist in VDR schon der Standard...
EDIT: Bei mir wirft der compiler weder Warnungen noch Fehler... Aber evtl. stört er sich an dem const hinter der Funktion. Ich glaube das ist falsch.
Ich bin C++ Neuling und das false ist in VDR schon der Standard...
Nur nicht so bescheiden. Ich könnte so etwas nicht programmieren.
EDIT: Bei mir wirft der compiler weder Warnungen noch Fehler... Aber evtl. stört er sich an dem const hinter der Funktion. Ich glaube das ist falsch.
Die KI sagt auch das es an dem const liegt und schlägt mir folgende Patches vor:
diff --git a/softhddevice.h b/softhddevice.h
index abcdef1..1234567 100644
--- a/softhddevice.h
+++ b/softhddevice.h
@@ -76,7 +76,7 @@ class cSoftHdDevice : public cDevice {
- virtual bool HasIBPTrickSpeed(void) const;
+ virtual bool HasIBPTrickSpeed(void) override;diff --git a/softhddevice.cpp b/softhddevice.cpp
index abcdef2..1234568 100644
--- a/softhddevice.cpp
+++ b/softhddevice.cpp
@@ -1624,7 +1624,7 @@
-bool cSoftHdDevice::HasIBPTrickSpeed(void) const
+bool cSoftHdDevice::HasIBPTrickSpeed(void)
{
return false; // oder deine Logik
}Ich kann nicht beurteilen ob das die beste/korrekte Lösung ist, aber damit bekomme ich einen neuen/weiteren Fehler:
drmdevice.cpp: In member function ‘cDrmBuffer* cDrmDevice::GetBufFromBo(gbm_bo*)’:
drmdevice.cpp:816:53: error: taking address of temporary array
816 | memcpy(buf->Handle(), (uint32_t [4]){ gbm_bo_get_handle(bo).u32, 0, 0, 0}, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drmdevice.cpp:817:52: error: taking address of temporary array
817 | memcpy(buf->Pitch(), (uint32_t [4]){ gbm_bo_get_stride(bo), 0, 0, 0}, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drmdevice.cpp:819:51: error: taking address of temporary array
819 | memcpy(buf->Size(), (uint32_t [4]){ buf->Height() * buf->Width() * buf->Pitch(0), 0, 0, 0}, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [<eingebaut>: drmdevice.o] Fehler 1Hier schlägt mir die KI folgenden Patch vor:
diff --git a/drmdevice.cpp b/drmdevice.cpp
index e.g. <deine alte SHA>..<deine neue SHA> 100644
--- a/drmdevice.cpp
+++ b/drmdevice.cpp
@@ -1620,13 +1620,20 @@ cDrmBuffer* cDrmDevice::GetBufFromBo(struct gbm_bo *bo)
buf->SetNumPlanes(1);
- memcpy(buf->Handle(), (uint32_t [4]){ gbm_bo_get_handle(bo).u32, 0, 0, 0}, 16);
- memcpy(buf->Pitch(), (uint32_t [4]){ gbm_bo_get_stride(bo), 0, 0, 0}, 16);
- memset(buf->Offset(), 0, 16);
- memcpy(buf->Size(), (uint32_t [4]){ buf->Height() * buf->Width() * buf->Pitch(0), 0, 0, 0}, 16);
+ {
+ uint32_t handleArr[4] = { gbm_bo_get_handle(bo).u32, 0, 0, 0 };
+ memcpy(buf->Handle(), handleArr, sizeof(handleArr));
+
+ uint32_t pitchArr[4] = { gbm_bo_get_stride(bo), 0, 0, 0 };
+ memcpy(buf->Pitch(), pitchArr, sizeof(pitchArr));
+
+ memset(buf->Offset(), 0, sizeof(handleArr)); // oder 16, wenn feste Länge
+
+ uint32_t sizeArr[4] = { buf->Height() * buf->Width() * buf->Pitch(0), 0, 0, 0 };
+ memcpy(buf->Size(), sizeArr, sizeof(sizeArr));
+ }
buf->SetNumObjects(1);
buf->SetObjectIndex(0, 0);
buf->SetFdPrime(0, gbm_bo_get_fd(bo));Ich kann zwar nicht beurteilen ob das gut ist, aber damit baut das Plugin jetzt bei mir und ich werde mal testen wie es läuft. 
Ich weiß noch nicht, warum ich nicht mal eine Warnung bekomme, schaue mir das aber an. Welche Compilerversion hast du?
Welche Compilerversion hast du?
g++ --version
g++ (Raspbian 12.2.0-14+rpi1+deb12u1) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Fix ist gepusht.
Vielen Dank damit klappt das kompilieren. 
Ich habe mal einige Aufnahmen mit Fehlern am Anfang getestet und dort sehe ich nur noch kurz Pixelfehler und nach dem Fehler wird die Aufnahme korrekt abgespielt. 
Ich hatte dir ja damals die eine Aufnahme zukommen lassen die nach 8:44 Minuten stehen geblieben ist. Laut VDR ist die ohne Fehler. Bei dieser Aufnahme habe ich jetzt den Effekt das diese nach 8:44 Minuten beim Bild sehr pixelig wird. Der Ton bleibt aber normal. Das bleibt solange bis ich die Aufnahme mit zurück beende. Wenn ich die Aufnahme dann an der Stelle fortsetzte wird diese korrekt korrekt abgespielt. Nur wenn ich wieder knapp über 8 Minuten warte dann wird es wieder pixelig. Allerdings ist mir das bisher auch nur bei dieser einen Aufnahme aufgefallen.
Ich teste auf jeden Fall weiter und kann es produktiv einsetzen. Vielen Dank
Freut mich. Dann wären wir ja einen Schritt weiter mit den kaputten Aufnahmen.
Bei der 08:44 Aufnahme: Tritt das auch auf, wenn ich ab Minute 8 starte? Dann versuche ich das nachzustellen.
Also ich habe mir jetzt mal die ersten 11 Minuten von der Aufnahme angeschaut und konnte keine Probleme feststellen.
Evtl. liegt es an der ffmpeg Version. Wenn ich mir das anschauen soll, bräuchte ich das Log mit den codec logs - falls hier was auffällig ist.
Puh, das kann ich nicht nachstellen. Wie ist denn die Speicherentwicklung dabei? Kannst du das mit top beobachten? Ich möchte nicht ausschließen, dass es irgendwo ein memory leak gibt, aber die Suche wäre etwas mühsamer...
Da bin ich tatsächlich überfragt. Welche ffmpeg Version hast du?
Mit der Debug Codec Log Option ist jetzt noch folgender Fehler dazugekommen:
Codevdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbarCodeSep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:14 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 1)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 2)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 3)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 4)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 5)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 6)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 7)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 8)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 9)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 10)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 11)! Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice][Codec] videocodec: SendPacket: send_packet ret: Auf dem Gerät ist kein Speicherplatz mehr verfügbar Sep 30 12:29:15 merkur vdr[892]: [893] [softhddevice] videorender: RenderFrame: WARNING!!! frame without interlaced flag arrived while deinterlace filter is active (P 12)!
Ich hoffe, ich verstehe es richtig... Die ENOMEM Meldung deute ich so, dass es der ffmpeg decoder nicht schafft, aus einem packet des streams zwei interlaced frames zu machen. Kein Speicher wird zurückgegeben, wenn unterwegs irgendwo ein alloc fehlschlägt. Die Render-Frame Warnung ist die Konsequenz, die uns sagt, dass ein als progressiv markiertes frame in einem eigentlich interlace stream kommt.
Beides kann ich hier auf dem RPI4 nicht nachstellen, ich vermute aber das Problem in ffmpeg.
https://github.com/jc-kynesim/rpi-ffmpeg/branches
Das wäre der aktuellste Stand, falls du dir das Selbstbauen antun willst.
Die Render-Frame Warnung ist die Konsequenz, die uns sagt, dass ein als progressiv markiertes frame in einem eigentlich interlace stream kommt.
Das ist durchaus üblich, siehe
Das ist durchaus üblich, siehe
Ja, das weiß ich und softhddevice sollte generell damit zurecht kommen. Ich bin nur stutzig, dass bei mir in der besagten Aufnahme diese progressive frames nicht "angewarnt" werden.
https://github.com/jc-kynesim/rpi-ffmpeg/branches
Das wäre der aktuellste Stand, falls du dir das Selbstbauen antun willst.
Ich habe jetzt auf meine Raspi3 VDR*ELEC mit Libreelec 12 und Libreelec 13 gebaut und mit deinem Plugin getestet. Da sollte ich ja jeweils neuere ffmpeg Versionen haben.
Tatsächlich tritt der Fehler unter VDR*ELEC bei der Aufnahme nicht auf. Dort läuft diese fehlerfrei durch.
Auch habe ich dort nicht das Problem mit dem grünen dünnen Streifen unten am Bildschirm und es macht insgesamt einen sehr guten Eindruck.
Welche Libreelec Version verwendet du denn? Sollte ich lieber 12 oder 13 nutzen.
Don’t have an account yet? Register yourself now and be a part of our community!
