Ich habe mir mal das Logfile angeguckt und würde vermuten snd_pcm_open in libasound verliert Speicher.
Wenn der Test ohne Sound besser läuft, dann würde ich mal libasound aktualisiern.
Den Fehler könnte man mit
#!/bin/sh
count=1; while true; do for i in `seq 1 20` ; do echo $count; sleep 0.5s; svdrpsend chan $i >/dev/null; : $(( count += 1 )); done; done
oder Ähnlichen, was den Kanal oft wechselt beschleunigen.
Johns
Hi,
Also Memoryleak gefunden? Oder nur weniger Speicher benutzt.
Oder Schreibfehler.
Ich meinte, dass damit auch der freie Speicher weniger wird, also der VDR immer mehr Speicher belegt.
Du schaltest aber X11 nicht auf Konsole um? X11 braucht auch sehr viel Speicher, besonders wenn man die virtuellen Konsolen umschaltet.
Ich weis gerade nicht was du damit genau meinst. X11 wird bei mir durch das Plugin gestartet und ist nur für die Ausgabe da. Ich greife auch nur per SSH auf den Rechner zu. X11 ist während der VDR läuft immer aktiv und "im Vordergrund". X11 braucht bei mir immer ca. 102MB Speicher, was aber extra angezeigt wird, also nicht im VDR Prozess.
Wenn der Test ohne Sound besser läuft, dann würde ich mal libasound aktualisiern.
Leider vird der benutzte Speicher auch ohne Ton immer mehr.
Ich werde da nochmal Massif mitlaufen lassen (wobei ich hoffe, dass durch das Ausbremsen die Messung nicht zu sehr verfälscht wird.)
Greets
Patrick
Wenn du X11 nicht umschaltest, dann ist es gut. Wenn du per ssh guckst, dann ist diese Möglichkeit ausgeschlossen.
ZitatIch werde da nochmal Massif mitlaufen lassen (wobei ich hoffe, dass durch das Ausbremsen die Messung nicht zu sehr verfälscht wird.)
Es läuft zwar ein etwas anderer Code, aber der sollte eher Fehleranfälliger sein.
Wobei ich mir nicht sicher bin, was passiert ohne Ton und 100% CPU Last, da kann es zu vollen Puffern kommen.
Johns
Das av_malloc Speicher verbraucht, wundert jetzt nicht so sonderlich. Ein schneller Blick in die Sourcen zeigt, dass der Speicher den sich Codec_get_buffer holt in Codec_release_buffer wieder freigegeben werden soll. Da musst du mal nachsehen ob das nicht immer gemacht wird.
Gerald
Das av_malloc Speicher verbraucht, wundert jetzt nicht so sonderlich
*lach* ja sicherlich 
Ich meinte ja auch eher die Funktionen, in denen der Speicher durch av_malloc und av_mallocz alloziert wird...
Wie ich geschrieben habe, vermute ich dass "Codec_get_buffer" über "decoder->VideoCtx->reget_buffer" aufgerufen werden könnte, obwohl der Puffer noch alloziert ist.
Man könnte in dieser Funktion zur Sicherheit vor dem Überschreiben des Pointers frame->data[0] diesen freigeben:
av_freep(&frame->data[0]);
frame->data[0] = (void *)vrs;Wenn nicht noch an einer anderen Stelle das frame-Objekt einfach gelöscht wird, ohne den allozierten Speicher von data[0] wieder freizugeben.
Eine andere Baustelle könnte auch noch die Funktion "PesInit" mit dem Objekt pesdx vom Typ PesDemux sein. Hier könnte man auch zur sicherheit "pesdx->Buffer" frei geben, bevor pesdx auf 0 gesetzt wird.
Greets
Patrick
Codeav_freep(&frame->data[0]); frame->data[0] = (void *)vrs;
Was dann vermutlich auf die Nase fallen würde, wenn doch schon Codec_release_buffer vorher aufgerufen wurde.
Gerald
Was dann vermutlich auf die Nase fallen würde
Sollte laut Beschreibung nicht passieren:
Zitatvoid av_freep ( void * ptr )
Note: passing a pointer to a NULL pointer is safe and leads to no action.
void av_freep ( void * ptr )
Note: passing a pointer to a NULL pointer is safe and leads to no action.
Ich habe jetzt keine Zeit mir das anzusehen, aber wenn av_freep() den Pointer selbst auf NULL setzt nach free(), dann sollte das sicherlich gehen.
Gerald
Es kann sein das get_buffer vom ffmpeg kaputt ist, diese Funktion sollte nicht mehr verwendet werden und fliegt dann in einer der nächsten ffmpeg Versionen heraus.
Damit könnten die aktuellen ffmpeg Versionen ein Memoryleak haben.
Ich will erst mit der nächsten stabilen Version von SoftHdDevice auf die neue API umsteigen.
Auf meinem Produktionsclient läuft noch immer ffmpeg 1.2.6.
Diese Funktion verwenden eigentlich alle so und hatte bisher keine Probleme gemacht.
Außerdem verwenden die bei VDPAU gar keinen richtigen Speicher sondern, speichern dort die Hardware ID der Flächen.
PesInit wird nur einmal beim Initialisieren aufgerufen, muß also Speicher verlieren.
Scheint ein sehr komisches Tools zu sein, wenn das nicht erkennt, daß der Speicher noch verwendet wird und erreichbar ist.
Johns
Ich hatte auch das Problem, dass der vdr innerhalb von ein paar Tagen 80% von meinen 2GB Ram belegt hat und dann irgendwann abgeschossen wurde. Hatte softhddevice gegen FFmpeg 2.3.1 kompiliert.
Mit FFmpeg 1.2.6 läuft alles wieder normal
Dann hoffen wir mal das eine der nächsten ffmpeg Versionen, den Memoryleak schließt.
avcodec_decode_video2 kann nun mit Referenzzählern arbeiten, aber der default ist keine Referenzen.
Also sollte es keine Auswirkung auf meinen Code haben.
Wenn es an 2.3.x liegt, dann sollte ich nachstellen können.
Johns
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!