Posts by rell

    JoeBar Ich versuche grade das zu reproduzieren, kann aber nur per ssh zugreifen.

    Muss der Schnitt angestossen sein, damit das Problem auftritt, oder reicht es, Schnittmarken zu setzen, zu verschieben und aus der Aufnahme zurückzukehren?

    Ich habe hier zwar Probleme, dass der VDR nach dem Schließen der Aufnahme nicht mehr auf Tasteneingaben reagiert, aber den CMA Speicher ausgehen zu lassen, habe ich noch nicht geschafft. Allerdings läuft hier auch kein Schnitt.


    Gruß

    Andreas

    Ich denke, das müsste gehen. Aber worin liegt der Unterschied zur CMA-Reservierung über die Kernelconfig oder einen Kernelparameter? Der Speicher wird ja auch weniger, wenn man ihn über den device tree reserviert? Oder habe ich einen Denkfehler?


    EDIT: CMA wird ja vom Decoder für die frames, von drm für die framebuffer und ggfs. für GLES genutzt falls aktiviert. Also von allem, was mit Bilddaten zu tun hat, damit zerocopy möglich ist. Irgendwas gibt da diesen Speicher nicht mehr frei. Was mich stutzig macht ist, dass es wohl mit dem Skin zu tun hat?! Ich sehe das Problem eher bei VDR oder dem Ausgabedevice.

    Wie verhalten sich denn hier die Desktops, auch wenn sie keinen CMA nutzen?

    Danke, hört sich gut an. Ich werde mal eine 4:3 Aufnahme bei mir suchen... Wenn du jetzt noch ein Log mit der 4:3 Aufnahme und aktiviertem DEBUG, DRM_DEBUG und CODEC_DEBUG hättest, wär's super ;)

    Hi,

    ich gestehe, nicht alles gelesen zu haben... deshalb hier meine Frage:


    Welche Voraussetzungen gibt es ausser den im ersten Post genannten? XServer? Was muss das Ausgabedevice können?

    Ist es möglich, das mit softhddevice-drm laufen zu lassen, bzw. was müsste das dann können?


    Danke und Gruß

    Andreas

    Hallo rookie1 ,

    ich habe die Änderungen mal in https://github.com/rellla/vdr-…m/tree/drm-atomic-v7-gles übernommen.


    Die Fehler aus deinen letzten beiden Logs haben aber imho nicht mit drm oder gles zu tun, sondern riechen nach einem Codec Problem. Die drm und gles Logs sehen gut aus, nur der Codec nicht:

    Es wäre also gut, wenn du das mit zillerbaers Branch auch nochmal versuchst.

    Hast du unterwegs irgendwas an ffmpeg geändert?


    Gruß

    Andreas

    habe ich nicht getestet, kann ich aber gerne machen wenn du möchtest

    Wäre hilfreich um es einzuschränken...

    Aber keinen Stress, vor morgen abend oder Montag kann ichs aber eh nicht anschauen.

    Ok, vorletzte Frage: Ohne gles heißt mein branch, nicht zillerbaers?

    sg75 hatte auch so ein Problem...

    Letzte Frage: zillerbaers Original geht in beiden Fällen?

    Schau ich mir nächste Woche mal an.

    Das gbm Problem scheint gelöst, aber es hapert noch mit drm.

    So als Schnellschuß zum Ausklang des Abends kannst du das nochmal testen und die Debugs wieder aktivieren. Wenn das nicht klappt aber ohne GLES=1 funktionierts, muss ich nochmal etwas länger drüber nachdenken :p


    Danke fürs testen!

    Bei sowas sag ich immer: Wenn Du nicht weisst, was das ist, dann brauchst Du das auch nicht :D

    So ist es :)


    Da du (noch) nicht weißt, was ich mit gles meine, eine kurze Erklärung:

    Mit GLES=1 rendert das OSD mit Hilfe von OpenGL/ES, so wie es z.B. die anderen softhddevice* forks mit OpenGL machen. Das Zusammenbauen des OSDs wird dann von der GPU übernommen, was evtl. etwas schneller ist als mit CPU und diese entlastet. Ob das für den Raspi4 einen Vorteil bringt, weiß ich nicht, da ich selber keinen zum Testen habe.

    Falls du aber vor hast, dich in dieses Unterfangen zu stürzen, benötigst du ein lauffähiges OpenGL, d.h. du benötigst erstmal die Mesa Treiber - ob die aus deiner Distribution neu genug sind oder ob du mesa selbst bauen musst, weiß ich nicht. Dazu brauchst du noch libglm und dann sollte es schonmal wieder bauen.

    Ich helfe gerne weiter, wenn ich kann, da mich interessiert, ob der RPI4 damit läuft und ob das merkliche Vorteile bringt.

    Die "einzigen" (auch wenn es immer mehr werden;) Unterschiede zu zillerbaers Version sind ein veränderts DRM-Handling und (mit gesetztem GLES=1) das OpenGL/ES OSD. Zuletzt kam noch die Scale Funktion dazu. Der aktuelle Branch baut auf zillerbaers aktuellem Stand auf.


    Gruß

    Andreas

    Aufgefallen ist mir das beim umschalten daß die Kanal Info erst wieder sichtbar wird, wenn auch das Fernsehbild wieder vorhanden ist, Vorher war die Kanal Info nachdem umschalten sichtbar und anschließend das TV Bild.

    Sollte jetzt wieder passen. Hier mit gles getestet...

    Code
    1. Apr 1 21:05:55 raspiVDR vdr[3545]: Frame2Display: cannot page flip to FB 232 (34): Das numerische Ergebnis ist außerhalb des gültigen Bereiches

    Das dürfte es sein. Schau ich mir mal an. Hast du das auch mit zillerbaers Version?

    Code
    1. Apr 1 19:21:37 raspiVDR vdr: [1133] SATIP: Detected 1 RTP packet error [device 0]

    Kenn mich mit satip nicht aus, aber danach beendet sich VDR.

    Das ist mein Branch ohne gles gebaut. Wenn es mit zillerbaers Version und sonst gleichem Setup geht, dann aktivier im Makefile mal DEBUG und DRM_DEBUG.


    Im Log steht erstmal nichts, dass es an softhddevice liegt. Was passiert am Schluß? Da hört das Log einfach auf?!