[softhddevice-drm]

    Ok, nun mal ein volles Log bis zum segfault: https://pastebin.com/bYm8ues5

    Er meckert tatsächlich über den Speicher und im syslog https://pastebin.com/Pb9BFyiv habe ich

    Code
    Feb 11 10:42:32 orangepiplus kernel: cedrus 1c0e000.video-codec: dma_alloc_coherent of size 4194304 failed
Feb 11 10:42:32 orangepiplus kernel: cma: cma_alloc: alloc failed, req-size: 1024 pages, ret: -12

    CMA habe ich 256MB reserviert

    Code
    andreas@orangepiplus:~$ sudo dmesg | grep cma
[    0.000000] cma: Reserved 256 MiB at 0x60000000
[    0.000000] Memory: 731616K/1015808K available (7168K kernel code, 904K rwdata, 1964K rodata, 1024K init, 273K bss, 22048K reserved, 262144K cma-reserved, 229364K highmem)
[41888.779665] cma: cma_alloc: alloc failed, req-size: 1024 pages, ret: -12

    Das wird der Übeltäter sein, oder?

    Ich habe außerdem bemerkt, dass die CPU Last von VDR auf 100% steigt, wenn ich eine Frequenz wähle, von der kein Signal kommt (z.B. EinsPlus OBSOLETE)

    Ich weiß nicht, ob das an softhddevice oder an streamdev liegt, vermute aber, dass VDR da in einer Schleife hängt ohne mal ein sleep() zu bekommen?

    Nochmal was, diesmal ohne GL Osd:

    und

    Code
    Feb 11 11:13:36 orangepiplus kernel: cma: cma_alloc: alloc failed, req-size: 152 pages, ret: -16
Feb 11 11:13:36 orangepiplus kernel: sun8i-di 1400000.deinterlace: dma_alloc_coherent of size 622592 failed
Feb 11 11:13:36 orangepiplus kernel: cma: cma_alloc: alloc failed, req-size: 138 pages, ret: -16

    Scheint als würde der CMA Speicher ausgehen. Manchmal, wenn ihn der Deinterlacer braucht, manchmal beim Decoder. Stellt sich nur die Frage warum? Und ob das evtl. an meinem Kernel liegt...

    Mit

    Code
    watch cat /proc/meminfo

    habe ich mal die Entwicklung vom CMA Speicher beobachtet. 256 sind reserviert, durch Zappen bekomme ich ihn dann auf ca. 50 runter und dann verabschiedet sich VDR. Der Speicher wird bei Zappen immer weniger, Anixe+ z.B. nimmt ziemlich, der möchte dann die letzten 50 haben und das geht dann nicht mehr.

    Irgendwo geht da Speicher verloren...

    Das ist übrigens mit deinem drm Branch ohne Commits von mir.

    Ich schalt mal den Deinterlacer aus und schau, obs besser wird.


    EDIT: Da muss ich gar nicht lange zappen um zu sehen, dass der CMA ohne Deinterlacer konstant bleibt. Je nach Format halt.

    Führt mich zu dem Schluß, dass der Deinterlacer Speicher leakt. Entweder in softhddevice oder im Kernel.

    Einmal editiert, zuletzt von rell ()

    Zitat von zillerbaer

    Andreas, kannst Du bestätigen das der Speicher nur bei H264 ausgeht? Der selbe Code wird auch bei Mpeg2 genutzt. Da passiert es hier nicht. Bitte teste das mal!

    Nein, kann ich nicht bestätigen.

    Ich kann es so reproduzieren:

    Dein master branch auf H3, d.h. aktiviertem Deinterlacer.

    Zappen zwischen Das Erste SD (MP2/576i) und ZDF SD (MP2/576i) und immer so 3-5 Sekunden warten. Es lässt sich beobachten, dass der Speicher mit der Zeit (nur beim Senderwechsel) weniger wird und irgendwann aus ist, dann crashts.

    Es fand kein Tune auf 1080i/H264 oder 720o/H264 statt.


    Scheint, als fehlt irgendwo ein free beim Senderwechsel, als erste Vermutung.

    Ich bekom softhddevice-drm (Version von zillerbaer / die von rell hab ich noch nicht auf dem System mangels mesa noch nicht getestet) mit dem vdr 2.4.6 (per launchpad erstelltes arm64 packet) nicht zum laufen. Ich habe vor der Instalation von yavdr die Schritte nach meiner anleitung wie beim vdr aus den ubuntuquellen gemacht (2.4.1-4) nur bekomme ich bei 2.4.6 folgende Fehlermeldung beim start des Plugins.

    Code
    Feb 14 14:44:48 PineH64 vdr: [555] ERROR: /usr/local/lib/libavfilter.so.7: undefined symbol: av_gcd_q, version LIBAVUTIL_56
Feb 14 14:44:48 PineH64 vdr[555]: vdr: /usr/local/lib/libavfilter.so.7: undefined symbol: av_gcd_q, version LIBAVUTIL_56

    Ich bin jetzt etwas ratlos... liegt das jetzt am VDR? Dienstag bekomm ich noch ne neue SD Karte dann werde ich meine Anleitung nochmal ab dem Bau von FFmpeg durchprobieren.

    Sieht für mich von weitem so aus, als wäre softhddevice gegen eine andere Version (header) gebaut worden als die, mit der sie jetzt laufen soll. Kannst mal mit ldd schauen, welche benutzt werden soll.

    Ja da hast du recht die wurde gegen libavcodec.so.58 => /lib/aarch64-linux-gnu/libavcodec.so.58 gebaut. Soll aber gegen die in /usr/local/lib/ gebaut werden. Warum hat das dann beim letzten mal geklappt? Was muss ich make mitgeben damit die richtige libavcodec.so.58 genutzt wird?


    Ich hab einmal FFmpeg mit prefix kompiliert und seither wird das immer (selbe Dateien im Buildverzeichnis) nach /usr/local/lib installiert obwohl ich bei configure den prefix wieder rausgenommen hab.

    softhddevice sucht sich die Infos mit Hilfe von pkg-config, da muss der Pfad beim Bauen also schon mal stimmen PKG_CONFIG_PATH ist das Stichwort.

    Du kannst beim Start mit LD_LIBRARY_PATH mitgeben, welche Pfad für die libs er zuerst nehmen soll.


    Da ich meine selbstgebauten libraries auch in einem separaten Verzeichnis habe (/opt/prefix) nutze ich z.B. diese beiden Hilfsskripte um VDR zu bauen bzw. laufen zu lassen. https://pastebin.com/raw/KSJ9s5LA

    Einmal editiert, zuletzt von rell ()

    libavcodec nimmt er nach wie vor aus dem aarch64 verzeichnis...


    libavcodec.so.58 => /lib/aarch64-linux-gnu/libavcodec.so.58 (0x0000ffffa246e000)

    libavfilter.so.7 => /usr/local/lib/libavfilter.so.7 (0x0000ffffa212d000)


    das ist mein script

    Bash
    #!/bin/bash -x

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export LIBRARY_PATH=/usr/local/lib/

cd /home/joebar/vdr/vdr-plugin-softhddevice-drm/ && make $@

    und die fehler beziehen sich ja auf die avfilter die er ja eigentlich vom installierten ffmpeg nimmt


    Wenn softhddevic-drm avutil nicht direkt nutzt dann muss ja ffmpeg darauf zugreifen wollen. Dann ist beim Kompilieren von ffmpeg was schief gegangen... nur was?


    Kann es sein das softhddevice da was beim kompilieren vermischt ?

    Einmal editiert, zuletzt von JoeBar ()

    Wenn ich die beiden softhddevice-drm (also das vom funktionierenden VDR und das vom nichtfunktionierenden yaVDR) miteinander mit ldd -v vergleiche sind eigentlich nur die nummern hinter den librarys anders (keine Ahnung was die Nummern bedeuten :/) alles ander ist identisch.

    Zitat von JoeBar

    Kann es sein das softhddevice da was beim kompilieren vermischt ?

    Zitat von JoeBar

    Feb 14 14:44:48 PineH64 vdr[555]: vdr: /usr/local/lib/libavfilter.so.7: undefined symbol: av_gcd_q, version LIBAVUTIL_56

    Softhddevice greift über pkg-config auf /usr/local/lib/libavfilter.so.7 zu. libavfilter findet dann av_gcd_q nicht. libavfilter ist nicht richtig verlinkt. Mit den Feinheiten der FFmpeg Pfade hab ich mich nicht beschäftigt. Ich installiere FFmpeg in /usr/lib und hab damit keine Probleme.

    vdr/softhddevice muss beim Bauen die richtigen include Dateien hernehmen und beim abschließenden Linken die passenden ffmpeg libs. Beides regelt pkg-config, daher müssen hier die Pfade stimmen.

    Während der Laufzeit muss vdr/softhddevice diese lib dann finden bzw. benutzen. Das kann man mit LD_LIBRARY_PATH steuern.

    2 Versionen in 2 verschiedenen Pfaden zu haben, hat immer seine Tücken.

    Manuell kompilierte Software nach /usr/lib zu installieren ist zwar nicht die "sauberste" Art, funktioniert aber, da einfach über die Versionen der Paketverwaltung drüber installiert wird...

    Und wie teile ich softhddevice die richtigen include Dateien mit? Die liegen in meinem Fall von FFmpeg unter /usr/local/include .

    “PKG_CONFIG_PATH=/usr/local/lib/pkgconfig pkg-config --cflags --libs libavfilter libavcodec“ sagt was?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden