Etwas frist Speicher VDR, Streamdev, SoftHdDevice, ffmpeg, VDPAU? VDR

Zitat von M-Reimer

Und dann bitte nurnoch EPG-Scan für die Favoriten und nicht mehr für jeden Sender in der Kanalliste.

das würde die Situation auf minimalistischen Systemen (ARM) sicher entspannen.

@ SHF

Wir hatten zum Test anfangs auf den Systemen auch explizit EPG Scan vollständig deaktiviert. Trotzdem erhöht sich der Speicher stetig auf 64 bit Systemen. Es geht wohl mehr darum, einen prinzipiellen Fehler zu finden

Für den Favoriten-EPG-Wunsch kann man auch (erst mal) das Plugin noepg benutzen.

Lars.

Kann man leider nicht. Würde gehen wenn du das mit "ab Kanalnummer X kein EPG mehr annehmen" schon implementiert hättest

ups...

Lars.

Zitat von Argus

Wir hatten zum Test anfangs auf den Systemen auch explizit EPG Scan vollständig deaktiviert. Trotzdem erhöht sich der Speicher stetig auf 64 bit Systemen. Es geht wohl mehr darum, einen prinzipiellen Fehler zu finden

Ich hatte die Diskussion schon verfolgt und einen simplen Fehler bei den EPG-Daten schliesse ich auch aus. Allein schon, weil die epg.data nicht unendlich anwächst (wenn das der Fall wäre, würde auch ein Neustart nichts bringen).

Wobei ich dem, was die Sender so als EPG liefern, nach dieser Geschichte, trotzdem nicht über den Weg traue.

Ich hatte beim Blick in die epg.c nur Idee mal die bekannten, großen Brocken mit zu zählen, wo das einfach zu machen ist. Dann sieht man auch genauer, was mit dem Rest passiert und kann den VDR trotzdem weiter nutzen wie gehabt.
Und das EPG ist ja nun definitiv der grösste Brocken. Prinzipiell muss man ja bloss die Objekte mit zählen (+ den RAM für Titel, Beschreibung usw. natürlich).
Aber wenn ihr meint, dass das keinen Sinn macht ... war halt nur so eine Idee.

Zitat von mini73

Für den Favoriten-EPG-Wunsch kann man auch (erst mal) das Plugin noepg benutzen.

Das Plugin ist mir bekannt, das habe hatte ich auch in Verwendung. Auf dem neuen Rechner hab ich es wohl nicht mehr drauf, da ich es eigentlich nicht benötige.

Ich will das Thema hier nicht unnötig auswalzen, also nur ganz kurz, worauf ich eigentlich hinaus wollte:
Der EPG wird periodisch auf der HDD gespeichert (zumindestens wird die Datei dauernd geändert).
Muss er dann auch zusätzlich für alle Kanäle im RAM liegen? Würden da nicht die zuletzt besuchten 50 oder so reichen?
Die meisten EPG-Daten werden bei mir eh nur von epgsearch durchsucht, oder wenn ich nach eine Wiederholung suchen lasse. Und da kann ich durchaus mit einer Sekunde fürs nachladen leben.

Ich hatte ja in VDR 2.3.5 ein Speicherleck in cSectionSyncerHash gefixt. Nun habe ich auf meinem vor einiger Zeit neu aufgesetzten VDR mit softhddevice als Ausgabe gesehen, daß dort immer noch der Speicherbedarf stetig ansteigt (um etwa 1GB pro Tag!). Nachdem ich den VDR mal ohne softhddevice gestartet habe blieb der Speicherbedarf auch über längere Zeit konstant. Es liegt also nahe, daß softhddevice noch ein Speicherleck hat.

Bevor ich Zeit und Mühe investiere wollte ich aber erstmal fragen:

- Wurde der Sourcecode von softhddevice inzwischen konsolidiert, und gibt es jetzt eine Quelle, auf der man aufbauen kann?

- Wenn ja, wo?

- Wenn nein, welches ist die noch am besten gepflegte Quelle?

- Hat inzwischen schon jemand etwas zur Behebung des Speicherlecks getan?

Klaus

Hi,

in der MLD setzen wir dieses Sourcen ein: https://github.com/jojo61/vdr-plugin-softhddevice

Ob es andere aktiver entwickelte Sourcen gibt, weiß ich aber nicht.

Und alternativ bieten wir das softhddevice mit opengl OSD auch noch aus diesen Sourcen an: https://github.com/louisbraun/softhddevice-openglosd

Claus

Zitat von kls

- Wurde der Sourcecode von softhddevice inzwischen konsolidiert, und gibt es jetzt eine Quelle, auf der man aufbauen kann?

Der vpp_support Zweig aus https://github.com/pesintta/vdr-plugin-softhddevice dürfte die aktuellste Variante sein (HEVC + VPP Support, VDPAU funktioniert auch). Bis auf den Merge für die Hardwarebeschleunigung des OSD mit VDPAU, das in softhddevice-openglosd steckt, sollte da alles drin sein, was da in der Zwischenzeit aufgelaufen ist.

Zitat von seahawk1986

The vpp_support branch of https://github.com/pesintta/vdr-plugin-softhddevice probably the most current version be (HEVC + VPP support VDPAU also works). Except for the Merge for hardware acceleration of the OSD with VDPAU that is in softhddevice-open glosd, everything should be in there, what is there accrued in the meantime.

I agree with this. I forked vpp_support and added Louis's VDPAU openglosd support to it. I started adding in gles2 (from rella) as well but I have no device to test so I stopped.

johns: wenn der VDR älter als Version 2.3.5 (2017-05-25) war, dann kann das auch durch das Speicherleck in cSectionSyncerHash verursacht worden sein.

Ich schaue mir das nochmal genauer an.

Klaus

@Klaus,

was mir aufgefallen ist, das im codec.c vom softhddevice, die Funktionen

avcodec_decode_audio4()

avcodec_decode_video2()

von ffmpeg genutzt werden, die eigentlich schon als deprecated gelisted sind. (seid der 3.1 Version von ffmpeg)

Gruß,

Roland

Hi,

die Funktion avcodec_decode_video2 in codec.c laesst sich ersetzen mit

in codec.c

// FIXME: this function can crash with bad packets
#if 1
     used = avcodec_decode_video2(video_ctx, frame, &got_frame, pkt);
#else
         if (video_ctx->codec_type == AVMEDIA_TYPE_VIDEO ||
             video_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
             used = avcodec_send_packet(video_ctx, pkt);
             if (used < 0 && used != AVERROR(EAGAIN) && used != AVERROR_EOF) {
            } else {
             if (used >= 0)
                 pkt->size = 0;
             used = avcodec_receive_frame(video_ctx, frame);
             if (used >= 0)
                 got_frame = 1;
             if (used == AVERROR(EAGAIN) || used == AVERROR_EOF)
                 used = 0;
             }
         }
#endif

CU

9000h

oder durch als *ersatz function

used = decode(video_ctx, frame, &got_frame, pkt);

int decode(AVCodecContext *avctx, AVFrame *pkt,
           process_frame_cb cb, void *priv)
{
    AVFrame *frame = av_frame_alloc();
    int ret;

    ret = avcodec_send_packet(avctx, pkt);
    // Again EAGAIN is not expected
    if (ret < 0)
        goto out;

    while (!ret) {
        ret = avcodec_receive_frame(avctx, frame);
        if (!ret)
            ret = cb(priv, frame);
    }

out:
    av_frame_free(&frame);
    if (ret == AVERROR(EAGAIN))
        return 0;
    return ret;
}

Ich habe jetzt einfach mal etwas experimentiert und durch schrittweises Weglassen von Funktionsaufrufen versucht, mich immer weiter in den Code von softhddevice hineinzuhangeln und zu schauen, wann der Speicherbedarf noch ansteigt und wann nicht mehr.

Normalerweise holt sich softhddevice bei mir etwas über 1GB pro Tag und gibt es nicht mehr frei. Nach einigen Tagen ist dann der Speicher voll. Wenn ich in video.c in der Funktion VaapiQueueSurface() die Zeilen zwischen

/* Queue new surface and run postprocessing filters */

und

pthread_mutex_unlock(&VideoMutex);

ausser Betrieb nehme, also so:

--- video.c     2017-04-02 22:38:51.000000000 +0200
+++ video.c     2017-11-02 14:46:44.244645675 +0100
@@ -4890,6 +4890,7 @@
         return;

     /* Queue new surface and run postprocessing filters */
+#if 0//XXX
     VaapiQueueSurfaceNew(decoder, surface);
     firstfield = VaapiApplyFilters(decoder, decoder->TopFieldFirst ? 1 : 0);
     if (!firstfield) {
@@ -4927,6 +4928,7 @@
         decoder->SurfaceField = decoder->TopFieldFirst ? 1 : 0;
         atomic_inc(&decoder->SurfacesFilled);
     }
+#endif//XXX

     pthread_mutex_unlock(&VideoMutex);

dann wird kein Bild mehr wiedergegeben (nur noch Ton), und der Speicherbedarf bleibt auch über lange Zeit konstant.

Das bedeutet wohl, daß irgend etwas, was in diesen Zeilen geschieht - oder etwas, was an anderer Stelle passiert oder fehlt, aber durch diese Zeilen ausgelöst wird - das Memory-Leak verursacht. Der Fehler liegt damit eindeutig in softhddevice (oder von diesem benutzen Funktionen).

Weiter bin ich leider nicht gekommen, dazu fehlt mir einfach der Überblick über das ganze Thema Software-Decodierung. Aber vielleicht kann mit dieser Information ja jemand etwas anfangen, der sich in der Ecke besser auskennt...

Klaus

I had a quick look at the code and pipeline_buf might be leaking as the documentation vaCreateBuffer of states: "The user must call vaDestroyBuffer()"

So, could you add the "vaDestroyBuffer(VaDisplay, pipeline_buf);" line to the end of VaapiPostprocessSurface().

An initial test looks promising!

I'll let it run for 24 hours to see if this can be confirmed in the long run.

Klaus

Beiliegender Patch behebt das Memory-Leak in softhddevice mit VAAPI.

Thanks to rofafor!

Klaus

The patch is now merged into my and pesintta's github repos.

Blöde Frage, weil es einem sofort ins Auge springt:

Im Thread-Titel steht "VDPAU", der Fix ist für VAAPI.

Das bedeutet doch, dass es noch ein weiteres Problem geben muss?