Video Treiber für Odroid-N2+ (softhdodroid)

  • Sind die Erweiterungen eingeflossen um die Plugins vdrboblight oder seduatmo zu füttern?

    Nein bisher noch nicht. Aber ich habe gelesen das es eine hyperion Version geben soll die das schon kann. Deswegen hatte ich da keine Eile.

    Ich werde mal schauen ob ich das dann doch noch einbaue. Hatte mich erstmal am PIP versucht. Da fehlen mir aber noch Infos wie es gehen soll. Der Kernel kann es ja wohl schon.

  • Nein bisher noch nicht. Aber ich habe gelesen das es eine hyperion Version geben soll die das schon kann. Deswegen hatte ich da keine Eile.

    Ich werde mal schauen ob ich das dann doch noch einbaue. Hatte mich erstmal am PIP versucht. Da fehlen mir aber noch Infos wie es gehen soll. Der Kernel kann es ja wohl schon.

    Im Coding sieht es so aus als wäre die Unterstützung schon drin. -> softhddevice_service.h

    Code
    1. #define ATMO_GRAB_SERVICE "SoftHDDevice-AtmoGrabService-v1.0"
    2. #define ATMO1_GRAB_SERVICE "SoftHDDevice-AtmoGrabService-v1.1"

    Ich dachte das wäre schon aktiv.

    Ich könnte das gebrauchen um per Plugin vdrboblight einen Amblight-Raspi zu versorgen.

  • Ich habe hyprion.ng so übersetzt


    cmake -DENABLE_DISPMANX=OFF -DENABLE_SPIDEV=OFF -DPLATFORM=amlogic64 -DCMAKE_BUILD_TYPE=Release -Wno-dev ..


    Die Konfiguration funktioniert prinzipiell, die Effekte sind auch sichtbar, ich kann allerdings keinen Grabber auswählen. Folgende grabber sind prinzipiell da:



    hyperion-aml          hyperion-qt           hyperion-v4l2         hyperion-framebuffer


    Es fehlt das /dev/amlogic0 Device, obwohl es in der Kernel-Config vorhanden ist (evtl. heißt es anders).

  • Da fehlt das Capture Device und in der Kernel config ist es auch nicht gesetzt.

    Code
    1. zcat /proc/config.gz | grep CAPTUR
    2. CONFIG_AMLOGIC_MEDIA_VIDEOCAPTURE=y
    3. # CONFIG_AMLOGIC_VIDEO_CAPTURE is not set

    So wie ich das sehe fehlt damit das device /dev/amvideocap0 und das wird von hyperion genutzt. Da muss man dann wohl einen eigenen Kernel bauen :-(

    Somit ist das einbauen vom Grab auch erstmal obsolet.

  • So wie ich das sehe fehlt damit das device /dev/amvideocap0 und das wird von hyperion genutzt. Da muss man dann wohl einen eigenen Kernel bauen :-(

    Somit ist das einbauen vom Grab auch erstmal obsolet.

    Wenn es um das lokale Nyperion.ng geht ist das wohl so.

    In meinem Fall wollte ich per boblight plugin die Daten ja weitersenden zu einem anderen Rechner.

  • Wenn es das capture device nicht gibt, dann kann auch das Odroid plugin das Video nicht grabben. Die Decodierung wird komplett im Kernel gemacht.

    Das Puggin sieht die Frames nicht die zum Screen gehen sondern müsste sie auch über das capture device wieder zurücklesen.


    Deswegen ist das grab erstmal obsolet.

  • Wenn es das capture device nicht gibt, dann kann auch das Odroid plugin das Video nicht grabben. Die Decodierung wird komplett im Kernel gemacht.

    Das Puggin sieht die Frames nicht die zum Screen gehen sondern müsste sie auch über das capture device wieder zurücklesen.


    Deswegen ist das grab erstmal obsolet.

    Ah, ok das war mir nicht klar. Dann hängt natürlich alles zusammen, Mal schauen wie aufwendig das bauen des Kernels wird.

  • Hallo,
    das Bauen des Kernels scheint nicht das Problem zu sein:


    https://wiki.odroid.com/odroid-n2/software/building_kernel


    allerdings befürchte ich, dass die Konfiguration sich nur auf das Capturen von Kameras bezieht:


    Wenn ich CONFIG_AMLOGIC_VIDEO_CAPTURE=y setze, kann ich noch das alles auswählen:



    Müsste man ausprobieren, ob damit das Device /dev/amvideocap0 angelegt wird und man darüber an den aktuellen Frame kommt.


    Lothar

  • CONFIG_AMLOGIC_VIDEO_CAPTURE=y

    Ja sieht nach Kameras aus. Ich habe noch geshen das in dem overlayfile irgendetwas von video definiert ist. Wenn ich im Kernel nach amvideo_cap suche dann findet er einige overlay files. Evtl. muss es auch "nur" dort eingeschaltet werden. Nur ohne das device wird es wohl nicht gehn.

  • Das Kernel build läuft übrigens mit dieser .config durch:


    Code
    1. #
    2. # Amlogic Camera Support
    3. #
    4. CONFIG_AMLOGIC_VIDEO_CAPTURE=y
    5. # CONFIG_AMLOGIC_CAPTURE_FRAME_ROTATE is not set
    6. CONFIG_AMLOGIC_VM_DISABLE_VIDEOLAYER=y
    7. # CONFIG_AMLOGIC_VIDEO_CAPTURE_PROBE is not set
    8. # CONFIG_AMLCAP_LOG_TIME_USEFORFRAMES is not set


    aber ich denke das bringt uns nicht weiter.

  • Könnte man nicht einfach den amlogic-Kernel von CoreElec nehmen?

    Ich denke das könnte funktionieren. Bisher war ich aber zu blöd um den Kernel von Corelec auf meine Ubuntu SD zu installieren.

    Dann würde wohl auch Kodi mit hardwarebeschleunigung laufen :-) Ich weiss das Kodi ihren eigene Kernel braucht. Da sind Erweiterungen für Kodi drin.

    Deswegen wird wohl das Plugin mit dem Kodi Kernel laufen (ich nutze da nix spezielles) aber Kodi nicht mit dem Ubuntu Kernel.

  • Ich habe eine Möglichkeit gefunden, wie man ein Odroid Dualboot realisieren kann, das man mit der Fernbedienung hin- und her-schalten kann. Ich habe Ubuntu 20.04 mit jojo61 's Plugin auf einer eMMC installiert und CoreElec auf einer SD-Karte. Beide befinden sich im Odroid N2+. Die Auswahl mit Petitboot funktioniert nur, wenn ich den Netzstecker ziehe, aber nicht nach einem Reboot. Den Schalter so stellen, dass er vom eMMC und nicht vom SPI Flash bootet. In diesem Zustand bootet der Odroid zunächst vom eMMC den VDR.


    Ich habe mit dd den Bootloader mit Partitionstabelle so gesichert:


    sudo dd if=/dev/mmcblk0 of=./bootloader.img bs=512 count=2047


    Ein sudo fdisk -l /dev/mmcblk0 hilft, die Blocksize und den count bis zur ersten Partition zu finden.

    Die fängt bei mir mit Sektor 2048 an. Den gesicherten Bootloader muss man dann auf die SD-Karte mit CoreElec übertragen (z.B: ins Verzeichnis .kodi/userdata).


    Jetzt kann man die Boot-Signatur des eMMC kaputt machen:


    sudo dd if=/dev/zero of=/dev/mmcblk0 bs=512 count=3


    Nach einem Reboot bootet der Odroid jetzt das CoreElec von der SD-Karte. Dort repariere ich den Bootloader des eMMC wieder mit dem gesicherten Bootloader


    dd if=bootloader.bin of=/dev/mmcblk0 bs=512


    so dass der nächste Reboot wieder von der eMMC bootet.


    Ich weiß, das ist nicht die feine Art, aber die einzige Möglichkeit, die ich gesehen habe, per Fernbedienung und Scripten zwischen VDR mit softhdodroid und KODI mit Beschleunigung umzuschalten. Vielleicht hilft das ja dem einen oder anderen.


    Bitte macht ein Backup von Euren Images, bevor Ihr Euch mit dem dd-Befehl verhaut...


    LG

    beta