[softhddevice-drm]

  • Das Schneiden erledigt der Server, ich passe nur die Schnittmarken mit dem Pine64 an. Das funktioniert bis auf einpaar Crashes eigentlich ganz gut, ich würde jetzt aber nicht von absolut stabil sprechen. Bei V4 zuckt das Livebild nach dem Verschieben der Marken, als würde es von irgendetwas überlagert werden bis ich einmal den Sender gewechselt habe, gefühlt crasht V4 weniger als V5 also was VDR Neustarts angeht.

  • Um auszuschließen, dass das was mit meinen Änderungen zu tun hat, nimm auch mal zillerbaers branch und checke den Unterschied zwischen den beiden letzten Commits. v4 und v5 unterscheidet sich nur darin.


    Was meinst du mit Crashs? Abbrüche oder segfaults? Hab ja da inzwischen was gelernt ;) Wenn du es reproduzieren kannst, wäre jetzt wohl der richtige Zeitpunkt für ein Backtrace...


    Gruß

    Andreas

  • Ich versuch jetzt erst mal die Versionen von zillerbaer bevor ich mich an Backtraces trau ;)

  • Ich versuch jetzt erst mal die Versionen von zillerbaer bevor ich mich an Backtraces trau ;)

    Code
    apt-get install gdb

    und sowas als "Hilfsskript"

    Bash
    #!/bin/bash -x
    gdb -ex=run --args vdr -u root --vfat -c /etc/vdr -E /video0 -v /video0 --localedir=/usr/local/share/locale -Pstreamdev-client -P'softhddevice-drm'

    sollte reichen.

  • gdb hab ich installiert, ich weiß nur nicht ob das mit yavdr so funktioniert, seahawk hat das hier mal für yavdr erklärt, mal schauen ob ich das hinbekomm.

  • hmm, nachdem ich jetzt syslog und top parallel laufen hatte ist er mir gleich abgeschmiert :huh: (zillerbärs plugin vorletzter commit) ich weiß jetzt nicht ob das was mit dem aktuellen Problem oder mit audio zu tun hat.

    Dateien

  • Bei zillerbärs aktueller Version kommt der cma: cma_alloc: alloc failed Fehler nach dem etwa das erste GB an Speicher durch das Verschieben verbraucht ist (cma Memory hab ich auf 512MB eingestellt). Ein fehler wegen Audio kam auch, lief aber weiter.


    Das Livebild zuckt übrigens auch wenn ich das Video verlasse bis ich den Sender wechsle und der Speicher wird auch nicht mehr freigegeben.

  • Bei zillerbärs aktueller Version kommt der cma: cma_alloc: alloc failed Fehler nach dem etwa das erste GB an Speicher durch das Verschieben verbraucht ist (cma Memory hab ich auf 512MB eingestellt). Ein fehler wegen Audio kam auch, lief aber weiter.


    Das Livebild zuckt übrigens auch wenn ich das Video verlasse bis ich den Sender wechsle und der Speicher wird auch nicht mehr freigegeben.

    Es stellt sich mir so dar das vdr Videodaten im Arbeitsspeicher ablegt. Während des Verschiebens der Marken werden nur Stillpicture angezeigt. Dafür braucht softhddevice-drm nur einen Videobuffer. Der restliche Videobuffer ist freigegeben und wird jetzt Stückweise von vdr benutzt. Wird das Video dann gestartet braucht der Decoder 10 Videobuffer und der Deinterlacer 6 Videobuffer. Der Speicher steht jetzt aber nicht mehr zur Verfügung. Ich sehe nur einen Weg das zu beheben. Vdr darf nicht so viel Speicher benutzen so das er von softhddevice-drm genutzt werden kann.

  • Aber wieso wird der Speicher nicht mehr freigegeben nachdem die Aufnahme verlassen wurde? Ich sehe nur dass mit jedem Verschieben der Schnittmarken der Speicherbedarf ansteigt und nach dem Wechsel auf live TV nichts mehr zurück kommt. Erst wenn ich den VDR neu starte ist der Speicherverbrauch wieder bei ca. 500MB. Und jedes mal wenn ich das OSD (MetrixHD) öffne steigt der Speicherbedarf immer weiter an.

    Sollte es nicht so sein, dass der Speicher nach dem Schließen des OSDs wieder freigegeben wird?

  • Sobald ich eine Schnittmarke gesetzt habe, und ich mit 1 und 3 auf der Fernbedienung anfange die Marke zu verschieben gönnt sich der VDR ca. 30MB Speicher und das sind dann bei ca. 10 Marken 300 MB. Wenn ich Glück hab schaff ich einen Film bevor der Speicher ausgeht, im Zweiten fangen dann die Fehlermeldungen an.

    Wenn das CMA Memmory wieder nach dem Schnittmarken verschieben wieder freigegeben würde das Problem evtl. gar nicht auftachen.


    Alles klar ich versuch das mal mit lcars

  • Hört jemand Radiokanäle in Mono und einer Samplerate von 24000? Wenn das keiner aktiv hört würde ich vorschlagen lösche den Kanal aus der channels.conf und das Problem ist behoben.

    Ich brauche keins von beiden. Löschen ist kein Problem aber nur ein workaround. Wenn man die Kanalliste automatisch ergänzen lässt und aus Versehen von Kanal 1 runterzappt, kanns dumm laufen :) Besser wäre es, wenn der VDR nicht abbricht und dafür evtl. “nur“ schwarzes Stummbild zeigt. Aber ich weiß nicht, ob das den Aufwand wert ist....

  • Ihr redet von CMA Speicher, der ausgeht, oder?

  • rell ja genau, der CMA ging bei deiner V4 mit dem Gleichen Fehler aus wie bei zillerbärs Version nur in V5 kommt eine andere Fehlermeldung s.o.


    zillerbaer das Verhalten kann ich auch mit lcars produzieren, nur dauert es viel länger bis der Speicher ausgeht.

  • Hi zillerbaer ,

    wieder ich ;)

    Ich versuche, den ganzen Abbrüchen bei mir auf die Spur zu kommen und abzufangen.


    Manchmal gibts hier einen Fehler 22, ich glaube das ist EINVAL.

    Daher habe ich mal verfolgt, mit welchen Werten der request bestückt wird:

    Code
    Frame2Display: cannot page flip to FB 51 (22): Das Argument ist ungültig
             PicWidth 1963 != pic_width_tmp 1920
             render->mode.hdisplay 1920, render->mode.vdisplay 1080, frame->width 720, frame->height 576, av_q2d(frame->sample_aspect_ratio) 1,454545
             SetPlaneCrtc(ModeReq, plane_id 31 (video), x 9223372036854775786, y 0, w 1963, h 1080)
             SetPlaneFbId(ModeReq, plane_id 31 (video), fb_id 51)
             SetPlane(ModeReq, plane_id 35 (osd), crtc_id 41, fb_id 50, crtc_x 0, crtc_y 0, crtc_w 1920, crtc_h 1080, src_x 0, src_y 0, src_w 1920, src_h 1080)
             SetPlaneZpos(ModeReq, plane_id 31 (video), zpos 0 (primary))
             SetPlaneZpos(ModeReq, plane_id 35 (osd), zpos 1 (overlay))

    Ich weiß noch nicht, ob es an PicWidth x liegt, letztendlich wird x durch PicWidth berechnet und wird negativ, wenn PicWidth > render->mode.hdisplay.

    Evtl. liegt es auch daran, dass video und osd plane nicht dieselbe Größe haben sollen, das muss ich noch ausschließen. Trotzdem kommen wir PicWidth und x spanisch vor...

    Daher erstmal meine Frage, woher kommt frame->sample_aspect_ratio, bzw. aus welchen Werten wird das berechnet?

    Und ja, wahrscheinlich ist das wieder ein Sender, der nicht ganz konforme Streams liefert, aber ich möchte mich nicht jedes Mal ärgern, wenn sich VDR beendet...

    Das oben passiert mit meinem Code, das Original versuch ich auch nochmal.


    Danke und Gruß

    Andreas

  • sample_aspect_ratio ist das Verhältnis Höhe zu Breite des Bilds und wird vom Decoder ermittelt und eingetragen.

    Und ja, wahrscheinlich ist das wieder ein Sender, der nicht ganz konforme Streams liefert, aber ich möchte mich nicht jedes Mal ärgern, wenn sich VDR beendet...

    Dann schmeiss doch die Sender raus! Das ist doch eh nur Werbemist!


    Wie kommst Du auf PicWidth 1963 bei frame->width 720, frame->height 576? Das sollte ohne Problem auf 1920 x 1080 skaliert werden! So wie ich das sehe ist das Problem das das Bild breiter als 19:9 ist. Der Fall ist in meinem Code nicht abgedeckt. Ich arbeite nur mit 16:9 und 4:3.

  • PicWidth wird hier so berechnet:

    Code
    PicWidth = render->mode.vdisplay * av_q2d(frame->sample_aspect_ratio) * frame->width / frame->height;
    1963 = 1080 * 1,454545 * 720 / 576

    Wenn der Sender 720/576 sendet, wovon ich ausgehe, dann ermittelt der Decoder die aspect_ratio wohl falsch?


    Die beiden Werte PicWidth und x sind bei deinem Code dieselben, allerdings meckert der PageFlip nicht. Ich glaube, das Problem bei mir sind am Ende die unterschiedlichen Werte für crtc_x und crtc_w, die Werte sind trotzdem verdächtig.

    Dann schmeiss doch die Sender raus! Das ist doch eh nur Werbemist!

    Das ist wohl möglich, aber mein Anspruch an einen funktionieren VDR ist halt, dass er auch damit zurechtkommt.

Jetzt mitmachen!

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