vdr-plugin-softhddevice-drm: RPI3, mmal, instabil

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Es wird immer unlogischer. Hast Du vor dem komischen File diese Aufnahme wieder geben können? Greift noch eine andere Anwendung auf Alsa zu? Im git habe ich noch den PCM Status zur Debugmeldung hinzugefügt. Teste das mal bitte von der Konsole. Ich brauche nur den letzten Teil ab der Alsa Fehlermeldung.

    Hi,


    Wir müssen davon ausgehen, dass Alsa fehlerhaft ist. Sonst gäbe es dafür in softhddevice nicht so viele Optionen:

    Code
    softhddevice (1.4.0) - A software and GPU emulated UHD device
  -w workaround enable/disable workarounds
        alsa-driver-broken      disable broken alsa driver message
        alsa-no-close-open      disable close open to fix alsa no sound bug
        alsa-close-open-delay   enable close open delay to fix no sound bug


    Der Fehler ist hier reproduzierber

    • Das Video, das ich Dir geschickt habe, mit dem Mediaplayer des vdr-plugin-softhddevice-drm abspielen
    • Nach ein paar Sekunden "Blau" drücken (stop)
    • Danach eine VDR Aufzeichnung abspielen (egal, welche). Crasht sofort.

    Hier noch die Konsolen Meldung:

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Zitat von MarkusE

    Wir müssen davon ausgehen, dass Alsa fehlerhaft ist.

    Nö, Alsa lässt eine grosse Bandbreite zu was die Treiber können müssen. Die Alsa HW-Treiber sind problematisch.


    "pcm state: XRUN" ist das Problem. Im git ist eine xrun recovery function hinzugefügt. Die Meldungen kommen im Log. Wenn mal Zeit ist muss ich unbedingt das Error handling in Ordnung bringen.

    Danke!

    Dieser Fehler ist damit behoben :) .


    Nächster Fehler :( :

    Abspielen einer VDR Aufzeichnung in SD, beim Zurückspringen auf eine Schnittmarke. VDR crasht (nicht immer reproduzierbar). Konsole:

    Syslog:

    Code
    Apr 25 15:05:19 rpi3 vdr: audio: start? in Rb 1104ms to skip 0ms
Apr 25 15:05:19 rpi3 vdr: audio: start? in Rb 1128ms to skip 0ms
Apr 25 15:05:19 rpi3 vdr: audio: start? in Rb 1152ms to skip 0ms
Apr 25 15:05:19 rpi3 vdr: AudioVideoReady: RB 1152ms skip 71ms to skip 0ms
Apr 25 15:05:19 rpi3 vdr: audio: ----> 1081ms start
Apr 25 15:05:23 rpi3 vdr: [2339] [softhddev]Clear:
Apr 25 15:05:24 rpi3 vdr: audio: wait on start condition
Apr 25 15:05:24 rpi3 vdr: audio/AlsaFlushBuffers: pcm state PREPARED
Apr 25 15:05:24 rpi3 vdr: [2339] [softhddev]StillPicture: pes 0x1787720 44740

    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Du kriegst aber auch alles kaputt! ;D Hier muss gdb ran. Dazu wird ein core file gebraucht. Mit:

    Code
    ulimit -c unlimited

    wird das freigeschaltet. Beim nächsten segfault wird ein core file geschrieben. Entweder schickst mir das zu oder:

    Code
    gdb /usr/bin/vdr -c core
(gdb) bt full
(gdb) quit

    Die Ausgabe von "bt full" brauche ich.

    Ich hatte hier ein ähnliches bzw. dasselbe Problem und meine, dass https://github.com/rellla/vdr-…8ac8a33ba3397d2cb1342afb7 es gelöst hat.


    Gruß

    Andreas

    Code
    [New Thread 0x6c44b380 (LWP 2961)]
[Thread 0x5b8f7380 (LWP 2952) exited]
Thread 13 "softhddev video" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x5f8ff380 (LWP 2913)]
(gdb) bt full
#0  0x750c7fa8 in ?? () from /usr/lib/arm-linux-gnueabihf/neon/vfp/libavcodec.so.58
No symbol table info available.
#1  0x750c8a64 in ?? () from /usr/lib/arm-linux-gnueabihf/neon/vfp/libavcodec.so.58
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE ,

    iss'n bissel doof. Das segfault findet in libavcodec statt und die hat keine Debugsymbole. Man sieht also nix. Bleibt das Standbild an der Marke stehen oder spielt es von da an gleich los?


    rell ,

    das ist von hinten aufgerollt. An den Symptomen rum gedoktert, nicht die Ursache beseitigt.

    Warum von hinten aufgerollt? Verstehe ich nicht.

    Ich denke, dass es dasselbe Problem ist wie hier beschrieben -> [softhddevice-drm] - falls dir das weiter hilft.

    > Bleibt das Standbild an der Marke stehen oder spielt es von da an gleich los?

    Es bleibt stehen

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Hi,


    segfault konnte ich keinen mehr provozieren :) .

    Springen mit Grün/Gelb/7/9 klappt aber nur manchmal richtig. Manchmal bleibt nach dem Springen das Bild an der angesprungenen Stelle stehen, und nur der Ton geht weiter.

    Und dann hat VDR nach einem Sprung gar nicht mehr reagiert. Konsole:


    Ich habe dann mit ctrl-c auf der Konsole abgebrochen. Danach:

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Zitat von MarkusE

    Manchmal bleibt nach dem Springen das Bild an der angesprungenen Stelle stehen, und nur der Ton geht weiter.

    Da hilft nur nach einem Sprung warten bis AV synchronisiert sind und dann den nächsten Sprung machen. Ist nervig, aber da hab ich schon lang dran gesessen und jetzt fasse ich das nicht mehr an.

    Zitat von rell

    Warum von hinten aufgerollt? Verstehe ich nicht.

    Vergleiche doch mal die Lösungen.

    Zitat von zillerbaer

    Vergleiche doch mal die Lösungen.

    Ok, plausibel ;)

    Aber

    Code
    avcodec_flush_buffers(decoder->VideoCtx);
avcodec_free_context(&decoder->VideoCtx);

    vor dem alloc in CodecVideoOpen() oder alternativ ein CodecVideoFlushBuffers() und CodecVideoClose() vor dem CodecVideoOpen() brauchts aber trotzdem, um keinen Speicher zu verlieren?

    Wofür braucht man das atomic_inc(&MyVideoStream->PacketsFilled);?


    Gruß

    Andreas

    Schau mal in CodecVideoClose() da wird avcodec_free_context() gemacht. Wenn der Buffer freigegeben wird, muss er vorher nicht zurück gesetzt werden. Nur wenn das struct als leeres struct wieder benutzt werden soll.

    Zitat von rell

    Wofür braucht man das atomic_inc(&MyVideoStream->PacketsFilled);?

    Damit wird die Queue um eins erhöht. Ist eigentlich nicht notwendig, aber da das erste Packet der Queue genutzt wird, ist es sauberer.


    Gruss zille

    Zitat von zillerbaer

    Schau mal in CodecVideoClose() da wird avcodec_free_context() gemacht. Wenn der Buffer freigegeben wird, muss er vorher nicht zurück gesetzt werden. Nur wenn das struct als leeres struct wieder benutzt werden soll.

    Bei einem normalen Playback sollte CodecVideoClose in VideoDecodeInput ja vor einem neuen Stream-Start sauber beim close aufgerufen werden, aber bei StillPicture/StreamFreezed kommt man ja gar nicht soweit.

    Ich denke, wenn CodecVideoOpen ein avcodec_alloc_context3 macht und decoder->VideoCtx noch zugewiesen ist, landet der alte AVCodecContext von decoder->VideoCtx doch im Niemandsland, oder kann der Fall nicht eintreten? Ich habe mir das damals so zusammengereimt, als wir über den steigenden Speicher diskutiert haben...

    Zitat von zillerbaer

    Damit wird die Queue um eins erhöht. Ist eigentlich nicht notwendig, aber da das erste Packet der Queue genutzt wird, ist es sauberer.

    Verstanden. Danke für deine Antworten.

    Zitat von rell

    Ich denke, wenn CodecVideoOpen ein avcodec_alloc_context3 macht und decoder->VideoCtx noch zugewiesen ist, landet der alte AVCodecContext von decoder->VideoCtx doch im Niemandsland, oder kann der Fall nicht eintreten?

    Das kann nicht passieren weil alle Threads mit StreamFreezed blockiert sind.

    Zitat von zillerbaer

    Das kann nicht passieren weil alle Threads mit StreamFreezed blockiert sind.

    Ich werde es nochmal ausprobieren, aber ich glaube dir das nicht ganz ;)

    Wenn ich mein Log von damals anschaue (https://pastebin.com/raw/U201NELh) wird am Anfang der Stream bzw. eine Aufnahme abgespielt. Dann kommt ein Clear() auf VideoCtx 0xa4f14450, aber kein CodecVideoClose. Der erste Aufruf von StillPicture macht ein neues CodecVideoOpen und erst dann wird der mit CodecVideoClose: VideoCtx 0x1d10b50 wieder geschlossen. Auch weiter unten kommts nochmal, wo StillPicture das erste Mal einen VideoCtx anlegt, ohne den alten zu löschen. Das Problem liegt m.E. nur beim ersten Durchgang von StillPicture(). Aber wie gesagt, ich werds sicherheitshalber nochmal debuggen.

    Ok, wenn ich eine Aufnahme abspiele und zu einer Schnittmarke springe und zugleich die Aufnahme pausiert, will StillPicture über CodecVideoOpen den VideoCtx neu allokieren, obwohl dieser noch belegt ist. Das passiert beim “pausierenden“ Sprung aus einer laufenden Aufnahme in eine Schittmarke. Ich denke, das sollte nicht sein.

    Mit einer kurzen Abfrage wie in https://github.com/jojo61/vdr-…/blob/master/codec.c#L218 kann man das sehen.

    Gruß Andreas

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden