Posts by djdagobert

  • [Alpha] RPI Ausgabeplugin

    Hi,
    ich hatte auch auf ARD HD Ton und Bild-Ruckler. (Und im Logfile "TS packet not accepted in Transfer Mode")
    Nachdem ich die Anzahl der Puffer verdoppelt habe funktioniert es (bis jetzt) ohne Aussetzer. Wenn ich dazu komme, werde ich mal die einzelnen Puffer schrittweise reduzieren um den Wert zu finden, bei dem bei mir die Ruckler auftauchen.

    Im replay Modus hatte ich keine Probleme.

    Schöne Grüße
    Patrick

  • [Alpha] RPI Ausgabeplugin

    Quote from reufer


    Keine Ahnung - welche Version hast du denn?


    Ich habe folgende Version (ich hoffe das ist die richtige Ausgabe :) :(


    Greets und Danke
    Patrick

  • [Alpha] RPI Ausgabeplugin

    Hi Thomas,
    erst einmal cool dass du an dem plugin noch so fleißig programmierst, Danke!

    Ich habe gestern mal den ganzen RPI aktualisiert: VDR 2.1.7, rpihddevice 0.0.11, firmware und auch raspbian (testing)

    Da habe ich nun leider kleinere Probleme:
    im Log erscheint auf ARD HD öfters

    und auf kanälen mit 5.1 und angeschlossenem TV über HDMI ist der Ton verzerrt und leise:

    ist nun meine libav zu neu?

    Vielen Dank und schöne Grüße
    Patrick

  • [RPI Ausgabeplugin] Knacken

    Hi,
    so nach längerer Testzeit nun der aktuelle Stand hier bei mir:

    Setup:

    • RPI mitraspbian und 2A Netzteil
    • Buffererhöhung auf 16
    • Samsung TV direkt mit HDMI angeschlossen
    • Aufnahmen über NFS vom VDR-Server gemoutet
    • Stremdev-(Client|Server)


    Live TV geht fast problemlos mit nur sehr kleinen für mich nicht störenden Audio-Plops. Das hört sich fast so an als ob ab und an Audio-Samples an der falschen Stelle früher oder später abgespielt werden.

    Aufzeichnungen anschauen:
    Wenn auf dem Server keine gleichzeitige Aufnahme läuft, dann wird das problemlos abgespielt, wie bei Live-TV.
    Wenn man eine Aufnahme anschaut, die gerade aufgezeichnet wird, dann kommt es ca. jede Sekunde zu Audio- und Bild-Stockungen. Das könnte ein Performance-Problems ein. Doch was löst bei einer Aufnahme auf dem Server periodisch eine höhere Last auf dem Client aus? Kann es sein dass der Client-VDR da mitbekommt, dass sich was am Aufnahme-Verzeichnis geändert hat und dadurch immer wieder irgendetwas neu einliest, was dann zur erhöhten Last und dann zu den Stockungen führt? Wenn die Aufnahme dann am Server fertig ist, dann verschwinden die Ruckler sofort. Da der Client mit LAN-Kabel mit dem Server verbunden ist (kein WLAN dazwischen) denke ich, dass es kein Übertragungsproblem ist.

    Hat noch jemand das gleiche Verhalten bei gleichzeitigen Aufnahmen?

    Greets
    Patrick

  • [RPI Ausgabeplugin] Knacken

    Hi Thomas

    Quote from reufer

    aber welches Problem genau meinst du? Knackser bei Live-TV oder bei der Wiedergabe von Aufnahmen?


    bei mir hat es beide Probleme behoben. Wobei ich nicht weis, ob das beim Live-TV auch schon früher mit der neuesten GIT-Version behoben war. (Ich habe mehr auf das Audio-Video-Problem bei Aufzeichnungen geachtet)

    Patrick

  • [RPI Ausgabeplugin] Knacken

    Hi Thomas,

    Quote from reufer


    Ein Parameter an dem man testweise noch schrauben kann, sind die Anzahl der Audiobuffer. Die sind in omx.c auf Zeile 1054 momentan auf 4 gesetzt:

    Code
    ...
param.nBufferSize = KILOBYTE(160);
param.nBufferCountActual = 4;
m_freeAudioBuffers = true;
...


    Ich würde den Wert versuchsweise mal auf 8 oder 16 erhöhen und schauen, ob sich da was ändert.

    Ich habe den Wert jetzt einmal auf 16 erhöht und bis jetzt (ich konnte nur kurz testen) sind keine Audio-Probleme mehr aufgetaucht.
    Ich werde das aber heute Nacht nochmal etwas länger beobachten.

    Vielen Dank erstmal :)
    Patrick

  • [RPI Ausgabeplugin] Knacken

    Hi,

    Was ich bei den Aufnahmen noch festgestellt habe ist, dass Audio UND Bild im 4-Sekunden Rythmus stockt. Vielleicht hilft das bei der Ursachenforschung :)

    Hi Uli,

    Quote from binduli

    Wie siehts mit der Auslastung auf dem Raspberry PI aus? (top)


    die load-average liegt bei ca. 0.8, vdr braucht ca. 27% CPU

    Quote from binduli

    Sind es Aufnahmen mit DD-Ton?

    Code
    rpihddevice: set audio codec to 6ch AC3
rpihddevice: 6ch PCM, 48.0kHz not supported by HDMI device
rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
rpihddevice: decoding S16 samples in 2 channels


    Kommen zum Beispiel die Aussetzer/Ruckler

    Quote from binduli

    Wie ausgelastet ist der zugehörige Server? Benutzt du NFS um die Aufnahmen zu teilen?


    Der Server langweilt sich :) und ja, ich menutze NFS.

    Hi Thomas,

    Quote from reufer

    Ein Parameter an dem man testweise noch schrauben kann, sind die Anzahl der Audiobuffer. Die sind in omx.c auf Zeile 1054 momentan auf 4 gesetzt:

    Code
    ...
param.nBufferSize = KILOBYTE(160);
param.nBufferCountActual = 4;
m_freeAudioBuffers = true;
...

    Ich würde den Wert versuchsweise mal auf 8 oder 16 erhöhen und schauen, ob sich da was ändert.


    Das und das deaktivieren des neuen Treibers könnte ich auch noch ausprobieren.

    Schöne Grüße
    Patrick

  • [RPI Ausgabeplugin] Knacken

    Hi,
    ich habe auch während live-tv ab und an kleinere Audio Plops oder Ruckler, aber leider noch mehr während Aufnahmen und vor allem wenn ich eine Aufnahme anschaue, die gerade aufgezeichnet wird.
    Ich habe nicht übertacktet und

    Code
    vm.min_free_kbytes = 16384

    und aktuelle GIT-Version ausgecheckt.

    Video format ist bei mir 1080p @50Hz (mode 31) eingestellt.

    Wie kann ich mehr Debug-Ausgaben aus dem Plugin holen? :)
    Im Makefile ist schon

    Code
    DEBUG = 1

    eingestellt

    Schöne Grüße
    Patrick

  • Memory Leak (in softhddevice?)

    Quote from gda

    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:

    Code
    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

  • Memory Leak (in softhddevice?)

    Hi,
    ich habe jetzt mit dem Tool google_perftools herausgefunden, dass die beiden Funktionen:

    Code
    av_malloc
av_mallocz

    immer mehr Speicher benötigen.
    Also besser gesagt aufgerufen durch die Funktionen

    Code
    PesInit(...)

    in der softhddev.c und

    Code
    Codec_get_buffer(...)

    in der codec.c

    Hier ist die Ausgabe von google_pperf: [Blocked Image: http://www.djdagobert.com/google_pprof.png]

    Kann es sein, dass durch

    Code
    decoder->VideoCtx->reget_buffer = Codec_get_buffer

    ein neuer Speicherbereich reserviert wird, ohne, dass der ursprünglich reservierte Bereich vorher freigegeben wird?
    Soetwas ähnliches müsste dann auch bei PesInit passieren, oder?

    Schöne Grüße
    Patrick

  • Memory Leak (in softhddevice?)

    Hi,

    Quote from johns


    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.

    Quote from johns

    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.

    Quote from johns

    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

  • Memory Leak (in softhddevice?)

    Quote from ATD

    djdagobert, wenn Du ein "Freiberufl. Programmierer" bist, dann würde man von Dir erwarten, dass Du mehr methodisch an die Sache herangehst und nicht alles wild durcheinander "testest". ;)


    :) ist zwar OT, aber dennoch äußere ich mich dazu: c++ ist nicht meine Stärke und es mag hier vielleicht "wild durcheinander" wirken, aber ich denke, dass ich hier schon methodisch die Sache anpacke ;)
    Mit Wissen zu den entsprechenden Werkzeugen würde das auch sicherlich schneller gehen.
    Aber ja "Freib. Prog." klingt etwas überheblich hier in meinem Profil und ich werde es mal ändern :)

    Das große Problem hier bei mir ist, dass das ein "Produktivsystem" :) ist bei dem ich nicht alles und dauernd testen kann, sondern den passenden Zeitpunkt für die Tests finden muss.

    Ein Versuch mit -a "" und ausgeschaltetem Passthrough ist am laufen.

    Greets
    Patrick :)

  • Memory Leak (in softhddevice?)

    Auch mit der Option:

    Code
    -Psofthddevice -x -a none -p none -d :0.0 -v vdpau


    wird der speicher weniger.

    Sind das die richtigen Parameter für das?

    Code
    vdr: audio: 'alsa' output module used
vdr: audio/alsa: playback open 'none' error: Datei oder Verzeichnis nicht gefunden
vdr: audio/alsa: mixer default - PCM open
vdr: audio/alsa: PCM mixer found 0 - 255 ratio 255000
vdr: audio:  44100Hz supports 0 0 0 0 0 0 0 0 channels
vdr: audio:  48000Hz supports 0 0 0 0 0 0 0 0 channels
vdr: audio: 192000Hz supports 0 0 0 0 0 0 0 0 channels
vdr: [softhddev] ready

    Ich habe vom VDR mit gdb ein Core Dump gemacht, der ca. 980MB groß ist.

    Als nächstes werde ich das ganze mal mit Massif von valgrind analysieren.

  • Memory Leak (in softhddevice?)

    Hi,

    Quote from tecfreak


    Schon ohne Audioausgabe/libasound probiert?


    nein, das habe ich noch nicht probiert. das wird dann das nächste sein. (Sorry ich hatte oben fälschlicherweise gedacht, den Ton einfach zu muten ;) )

    Gerade habe ich den VDR und softhddevice mit debug symbolen neu kompiliert, lasse ihn bischen laufen und schaue mir dann mal im debugger die einzelnen Threads an, vielleicht finde ich da was...

  • Memory Leak (in softhddevice?)

    Hi,

    Quote from _Martin_

    Hast du denn nochmal streamdev ausprobiert?


    Meinst du, ob ohne streamdev auch der Speicherverbrauch mehr wird?

    Bei der obigen Messung habe ich NUR das Plugin softhddevice laufen lassen und der Speicherverbrauch stieg an. Damit gehe ich davon aus, dass irgendwo in der Kombination VDR und softhddevice mit dazugehörigen Bibliotheken der Fehler ist.
    Vielleicht ist es auch kein echter Memory leak, sondern es wird nur irgendwo in einer Datenstruktur immer mehr abgelegt, was unnötig ist.

    Gibt es ein Programm, das den jeweilig verbrauchten Speicher zu den einzelnen Klassen visualisiert?

    Greets
    Patrick

  • Memory Leak (in softhddevice?)

    Hi,
    ich konnte aus dem Logfile, das memcheck gemacht hat:

    Code
    valgrind --tool=memcheck --undef-value-errors=no --leak-check=full ./vdr -w 60 -c /etc/vdr -v /video --no-kbd --lirc=/dev/lircd -p 2001 -P'softhddevice -x -a hdmi:CARD=NVidia,DEV=1,AES0=0x4  -p hdmi:CARD=NVidia,DEV=1,AES0=0x6 -d :0.0 -v vdpau'>memcheck.log 2>&1


    nichts wirklich kritisches finden.

    Was könnte da nur passieren?

    Gibt es noch eine andere Möglichkeit zu erkunden, was da so viel Speicher beansprucht?

    Schöne Grüße
    Patrick

  • Memory Leak (in softhddevice?)

    Hi,
    jetzt habe ich mal den VDR eine Stunde nur mit dem Plugin softhddevice laufen gelassen und das Problem besteht noch.
    Gerade lasse ich zusätzlich noch den memcheck von valgrind für eine Stunde laufen.
    Mal schauen, ob da etwas brauchbares herauskommt, denn nachdem das den Prozessor zu 100% auslastet verwirft softhddevice erwartungsgemäß etliche frames.

    Ich berichte dann das Ergebnis.