Beiträge von rell

    Hallo Joe_D,

    ich habe den Patch auf einer VDR*ELEC Maschine mit drin und hier bekomme ich schön im Rhythmus

    Code
    Feb 22 22:21:56 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:21:35 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:21:14 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:20:53 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:20:32 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:20:11 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:19:50 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:19:29 odroid vdr[22441]: [22441] EIT scan: 12 scanList entries                                                                Feb 22 22:19:08 odroid vdr[22441]: [22441] EIT scan: 12 scanList enentries

    Der Scan scheint nie anzulaufen. Allerdings habe ich auf dem device weder vtuner, satip oder einen lokalen Stick, sondern nur streamdev. Hat der Patch damit ein Problem?

    Ich mach mal meinen Monolog weiter ;)

    Die Commits, die das Problem auf dem RPi fixen sollten, habe ich reverted. Grundsätzlich weiß ich, woran es liegt, aber ich habe da zu schnell commited und krasse Bugs eingeführt. Ich muss da erstmal nochmal nachdenken und das etwas überarbeiten.


    Auf dem Odroid kommt das Bild aus dem Deinterlacer richtig als NV12 an. Allerdings scheint der drm ein Problem damit zu haben, das ganze hoch zu skalieren. Ich habe etwas mit den Buffer-Größen etc. gespielt und konnte ein "intaktes" Bild auf dem Bildschirm erhalten, wenn auch nicht in richtiger Größe und Lage und gekachelt, aber immerhin mit Y und UV richtig überdeckt. Farben stimmen. Mir ist dann wieder eingefallen, dass ja auch das 720x576er Schwarzbild kein Schwarzbild mehr auf einer 1920x1080er Ausgabe war (https://github.com/rellla/vdr-…4d038eb0064d687f060873631). Ich habe dann kurzerhand die Größe des Buffers auf die Bildschirmgröße eingestellt, was das Problem gelöst hat. Ähnlich vermute ich das Problem beim Video.

    Ich muss also noch etwas herumspielen, aber zumindest ist das Problem jetzt eingegrenzt. Fortsetzung folgt. Wahrscheinlich.

    Hallo zusammen,


    eigentlich wollte ich es erst für den Odroid-N2 lauffähig machen, aber jetzt waren die Raspberry zuerst dran.

    Die aktuelle Version 0.2.0 von softhddevice-drm-gles funktioniert jetzt mit dem Rpi4 und Rpi5.

    Da ich einiges umgebaut habe, kann ich nicht garantieren, dass keine Bugs enthalten sind. Tester sind willkommen und bei Problemen einfach melden.

    Amlogic schaue ich mir als nächstes an.


    Kommando zurück. Leider zu früh gefreut... Der Softwaredecoder funktioniert noch nicht. Bin noch auf Fehlersuche und hab aktuell wenig Zeit, hoffe aber das bald hinzukriegen...


    Gruß

    Andreas

    Ich glaube, die Ursache ist gefunden und die 576i Kanäle laufen jetzt auf dem RPi4 grundsätzlich. Ich habe die ständigen av_frame_alloc und av_frame_free mal so geändert, dass gleich beim Start die frames im Rb mit av_frame_alloc angelegt werden und stattdessen mit av_frame_unref gearbeitet wird. Scheint, dass damit weniger auf dem Speicher los ist und die Klötzchen sind weg.

    Jetzt muss ich noch etwas nachdenken, damit das ganze alloc/unref/free sauber wird und mit den Threads klarkommt.

    Bei mir startet vdr als erstes, da sehe ich ja gleich ob ein Fernsehbild kommt... zur Kontrolle starte ich dann auch nochmal Kodi und damit bin ich fertig mit der Kontrolle.

    Das startet auch, wenn das Update fehlgeschlagen ist. Mit cat /etc/release siehst du, ob die aktuelle Version auch die ist, die du installieren wolltest.


    Und wenn du einfach das Addon über Kodi installierst? Der einzige Unterschied zur Version von Zabrimus sind m.E. diese Patches und damit eine andere .config. Und wie Dr. Seltsam schon geschrieben hat, ein Vermischen kann auch Probleme machen.

    Wenn du das Update durchgeführt hast, vergewissere dich, dass es auch funktioniert hat. Bei mir schlägt das manchmal aus welchen Gründen auch immer fehl. Ein Update überschreibt dir alles bis auf den /storage-Ordner. Da sind die Einstellungen drin.

    Hast du versucht, ein Image auf SD-Karte zu schreiben und diese Images bei beiden auszuprobieren? Wenn das geht, kann es nur an den Einstellungen, caches etc. unter /storage liegen. Und bevor du da lange suchst, geht es wahrscheinlich schneller, das System ganz neu aufzusetzen.

    Commits · rellla/softhddevice-openglosd
    Contribute to rellla/softhddevice-openglosd development by creating an account on GitHub.
    github.com


    Das war mein Werk von damals. Ahnung von OpenGL hatte ich da noch nicht... Wer sich also ein bißchen einlesen möchte kann damit evtl. was anfangen. Der GLES Teil ist mit defines getrennt und das ganze vdpau Zeugs brauchts nicht... Ob das damals alles so astrein umgesetzt war, weiß ich nicht mehr. https://github.com/rellla/vdr-…atomic-gles/openglosd.cpp jedenfalls ist daraus entstanden und nutzt "nur" gles 2.0 Und nein, Patch kann ich keinen machen ;) Mir ist lieber, ich bringe die Odroids mit LibereELEC ohne blob ans Laufen.

    S950D hat einen Mali 450. Der kann nur OpenGL/ES 2.0 und glGenVertexArrays ist erst in der Spezifikation für OpenGL/ES 3.0 enthalten.


    Ich vermute, dass der libmali-blob dafür keine Unterstützung hat. Wenn dem so ist, brauchst du entweder einen blob, der diese Extension drin hat - wobei ich nicht glaube, dass du da fündig wirst, oder man schreibt openglosd.cpp so um, dass es "nur" OpenGL/ES 2.0 Befehle nutzt. Das habe ich für den opengl Teil in softhddevice-drm-gles gemacht, da ich mein ersten Tests mit Mali400 gemacht habe. Für die paar Rechtecke reicht der Befehlssatz von GLES 2.0 m.E. völlig aus.

    Zwischenstand:


    Habe jetzt hier einen RPi4, RPi5 und Odroid N2 und werkle an verschiedenen Fronten...

    Die RPi schauen allgemein besser aus als der Odroid.

    -> Beim 4er funktionieren die h264 Sender einwandfrei, bei mpeg2 "flackert" das Bild (in der oberen Hälfte) "klötzchenartig" bei Bewegungen.

    -> Beim 5er flackert es bei allen Sendern.

    Das betrifft also alles, was mit Software dekodiert wird. Irgendwo auf dem Pfad (SW-)Decoder->(SW-)Deinterlacer->DRM-Ausgabe gibts hier noch ein Problem.


    Beim Odroid ist das wie beim RPi4, aber zusätzlich gibts hier bei mpeg die Fehler aus dem Bild oben.


    Bis auf die Klötzchen ist das Bild bei den Rpis gut, so dass ich das Problem hier eher auf DRM schiebe und der Decoder und Deinterlacer m.E. funktioniert. Entweder liegt es an den Formaten oder aber DRM hat mit dem VSync noch ein Problem. Ich werde als nächstes versuchen, den drm-Commit nonblocking einzubauen, vielleicht kommt die Software nicht hinterher, wenn der fb zu lange geblockt ist.


    Außerdem wäre es interessant, ob es auf dem RPi4 mit der Version von zillerbaer funktioniert, dann sehe ich zumindest, ob ich das Problem eingebaut habe. Bis jetzt bekomme ich aber mit dieser Version noch kein Videobild - habe aber noch nicht nach dem Grund gesucht.


    Bwdiff ist ein SW Deinterlacer von FFmpeg. Der kann nur mit YUV420 umgehen.

    Ungetestet, aber evtl. schafft dieser Commit hier Abhilfe. Daran liegt das Problem oben aber m.E. nicht. Der Deinterlacer bekommt aktuell 1 AV_PIX_FMT_YUV420P-frame und liefert 2 AV_PIX_FMT_NV12-filt_frame.


    Wer gerne mitsuchen und -testen will, darf sich gerne melden ;)

    Ich habe den Patch und die letzte vtuner Version jetzt auf dem Server mit 6 devices am Laufen. Der Scan dauert bei 21 scanlist entries eine gute Minute. Alles sieht soweit gut aus. In meinen Augen ist das eine sinnvolle Ergänzung.


    Nur eine Frage hätte ich: Wenn der EPG-Scan nur mehr über einen bestimmten Bereich läuft, werden dann neue Transponder hinzugefügt und Pids von den Kanälen geändert, die nicht im Bereich liegen?

    Ich habe/hatte in meiner Kanalliste (wie wahrscheinlich viele) durch einen Separator getrennt am Ende den Bereich aller vom VDR automatisch hinzugefügten Kanäle. Beschäftigt sich der VDR dann jetzt überhaupt noch damit?


    EDIT: Ich glaube, ich kann die Frage selbst beantworten: Man muss dafür den EPG Scan manuell anstossen?!