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

  • Ich denke ich weiß, wo das Problem mit meinem Bild liegt (und jojo61 müsste noch dasselbe Problem beim Grabben haben):


    The driver needs to allocate memory for a whole frame, but its more than the kernel allows in its default configuration.
    To make the driver work the FORCE_MAX_ZONEORDER parameter in arch/arm64/Kconfig needs to be changed from "11" to "13" (https://forum.odroid.com/viewtopic.php?t=20901).


    Wenn ich aber den Kernel übersetze mit "13", bootet er nicht mehr. Ich kann zwar über Petitboot booten, VDR läuft aber gar nicht mehr. Ich frage mich nur, wie CoreElec das macht, hier steht der Wert auch auf "11".


    jojo61 Hast Du ein komplettes UHD-Bild grabben können, oder fehlt Dir da auch die Ecke?

  • Das nutzt mir leider nichts, da ja erst einmal der gesamte Videospeicher gelesen wird, selbst wenn es dann nur runterskaliert ausgegeben wird.


    Kennt sich denn jemand mit boblight aus? Mein Ambilight (ada102) hängt an einem Atmel Controller und funktioniert mit Hyperion. Wenn ich VDR mit boblight-Plugin starte, habe ich einen segmentation fault.

  • Hallo,


    Das musste man auch für softhdcuvid und andere ergänzen.

    Patch für Softhdcuvid


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

  • Hallo,

    Wo finde ich denn ein aktuelles boblight plugin?

    vdr-plugin-boblight-0.0.7 ist von

    https://projects.vdr-developer.org/git/vdr-plugin-boblight.git/

    Ob es da noch was aktuelleres auf z.B github/gitlab gibt,weiss ich nicht.


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

  • Hallo,

    gerade ersten Test gemacht.

    Mit gepachten ubuntu Kernel hauts noch nicht richtig hin.

    Das Log wird geflutet mit:

    Code
    1. vdr: video: grab
    2. BOBLIGHT: Got image with 64x64 pixel; 12288 bytes
    3. BOBLIGHT: sleeping 53ms (15 Hz)
    4. Softhddevice NOT detached: 910


    BoblightPlugin verbindet sich mit Hyperion, aber die Farben passen nicht.

    vdr läßt sich dann kaum noch bedienen.

  • Mit dem CoreElec-Ubuntu-Mix-Kernel funktioniert das leider genauso wenig. Hier habe ich denselben Effekt wie mit dem anderen Kernel. Ich frage mich nur, wie CoreElec das löst. Auch dieser Kernel kann nicht das 4k-Bild aus der VPU mit einem Schlag auslesen (s.o., FORCE_MAX_ZONEORDER ist dafür auch zu klein).


    Im Log habe ich bei beiden Kerneln übrigens ein:


    Nov 25 11:01:11 odroid kernel: [  134.956174@0] ge2d: ge2d timeout!!!


    Es sieht so aus, als würde der CoreElec-Grabber den FrameBuffer auslesen und nicht die VPU. Darin ist aber hier nur das OSD.


    Hier gibt es noch einen Kernel, in dem das videocapture-Device bereits eingebaut ist. Vielleicht funktioniert der ja?


    https://github.com/tobetter/li…a/video_sink/amvideocap.c


    Edit: Gerade probiert. Der Kernel bootet nicht.

  • In den Coreelec Sourcen wird auch das amvideocap0 device aufgerufen. Das habe ich genau so programmiert.

    Wenn es bei Corelec geht dann muss doch noch etwas am Corelec kernel anders sein oder sie nutzen den Teil der Quellen nicht die über das device grabben.


    PS: Der Link auf tobetter enthält exakt die gleichen Capture sourcen wie dein Patch.

  • Mit dem neuen Commit habe ich einen crash in vdrboblight:


    Code
    1. Thread 9 "vdr" received signal SIGSEGV, Segmentation fault.
    2. [Switching to Thread 0x7f84606170 (LWP 3495)]
    3. 0x0000007fac592200 in cAmbiThread::putData (this=this@entry=0x5555bf2ca0)
    4.     at ambithread.c:397
    5. 397   rgb[0] = p->r;
  • Wenn ich den Framebuffer grabbe so wie das in den Quellen von Hyperion drin ist, dann bekomme ich bei fb0 das OSD aber keine Bild. alles andere ist immer schwarz.

    Und wo der decoder das Bild hinschreibt kann ich nicht beeinflussen. Zumindest weiss ich nicht wie.

  • Ich poste hier meinen aktuellen Zwischenstand mit dem Odroid N2+ und Hyperion.


    Ich habe hier einen Odroid N2(+)-Kernel abgelegt ("aktueller" 4.9), bei dem ich alle media-Treiber und -Module durch die von CoreElec ersetzt habe. Eine .config liegt bei. Die Overlays müssen so gepatcht werden, wie ich das weiter oben in diesem Thread schon beschrieben habe (ebenfalls enthalten). Der Link läuft leider in 7 Tagen ab, vielleicht kann das jemand sonst noch irgendwo hosten.


    Als hyperion nutze ich dieselbe Version, die CoreElec auch benutzt (2.0.12). Wahrscheinlich funktioniert auch der aktuelle git-Stand, ich habe den aber nach dem Auschecken mit der o.g. Version überschrieben. Übersetzt habe ich so


    Code
    1. cmake -DENABLE_WS281XPWM=0 -DENABLE_X11=0 -DENABLE_FB=0 -DENABLE_DISPMANX=0 -DENABLE_SPIDEV=OFF -DENABLE_AMLOGIC=1 -DPLATFORM=amlogic -DCMAKE_BUILD_TYPE=Release -Wno-dev ..


    Da ich im Moment nicht vor dem Rechner sitze, konnte ich nur remote testen. Ich habe eine SES Astra 4k Demo-Aufnahme getestet und eine Full-HD-Aufnahme:





    Der grab der Bilder sieht erst einmal in Ordnung aus (sowohl 4K als auch 1080i).


    Für das Grabben von 4k habe ich in die /etc/rc.local folgendes eingetragen:

    Code
    1. echo 3 > /sys/module/amvdec_h265/parameters/double_write_mode
    2. echo 3 > /sys/module/amvdec_vp9/parameters/double_write_mode


    Getestet habe ich mit c2play. Es gibt noch ein kleines Problem. Nach Beenden eines Videos und dem Start eines neuen Videos deaktiviert sich die Video-Ausgabe. Die kann man aber (als root) einfach wieder einschalten mit einem


    Code
    1. echo 0 > /sys/class/video/disable_video


    jojo61 : Vielleicht ist das ja auch das Problem mit mit Deiner fehlenden Konsole. Könntest Du evtl. (bis ich das eigentliche Problem gefunden habe), das echo 0 > ... mit in Dein Plugin aufnehmen. Es müsste ausgelöst werden, wann immer das Video wechselt.


    Ein paar Ideen habe ich noch, falls es (noch) nicht zuverlässig funktionieren sollte. Man könnte alle Patches aus dem CoreElec-build noch implementieren und noch weiter mit den .config-Parametern spielen.


    Evtl. hat ja der eine oder andere Lust, zu testen und mitzuhelfen Kernel-Debugging ist echt ein Aufwand...

    Das Ganze ist quick and dirty implementiert und ich habe einige -Werrors aus dem Makefile auskommentiert. Falls es irgendwann einmal zufridenstellend läuft, müsste man diese Warnungen noch alle beseitigen.