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

  • Ich bastele zu Zeit an einem vdr-client der per streamdev seine Daten bezieht und nicht durchlaufen muss und sich deshalb als prozess mit dem kodi abwechseln kann.

    Das switchen zwischen vdr und kodi geht sehr einfach und elegant mittels systemd script.


    Ich habe auf github einen eigenen coreelec fork aufgesetzt der den Sourcecode soweit enthält:


    https://github.com/durchflieger/CoreELEC/tree/coreelec-19


    Im Branch coreelec-19 sind meine Erweiterungen enthalten.


    Das ist zur Zeit ein kodi addon 'vdr-client' das mit den Plugins softhdodroid, streamdev-client, svdrpservice, epgsync, remotedosd sowie vdr 2.6.1 daherkommt.

    Gebaut wird mit "./scripts/create_addon vdr-client".


    Das Addon installiert im Kodi ein Programm-Addon "vdr" das nur ein "systemctl start vdr.service" ausführt.

    Im vdr gibts ein "commands.conf" Kommando das "systemctl start kodi.service" ausführt.

    Mehr brauch es nicht.


    Installiert wird das Addon im Kodi jedoch fehlt noch die konfortable Initialisierung der Konfigurationsverzeichnisse für den vdr.

    Weiteres wird es erst nach einer Osterurlaub-Pause von mir geben.


    Wer trotzdem schon mal in den Source schauen möchte hier die relevanten Verzeichnisse:


    packages/addon/service/vdr-client

    packages/addon/addon-depends/vdr*

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.6.1
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.6.1+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • Im Anhang ist ein Patch der den unnötigen softremote thread abklemmt.

    Damit brauchst auch kein XKeySym Einträge mehr in der remote.conf.

    So ich habe den Patch nun eingecheckt. Daneben habe ich noch den Video Pfad optimiert und einen deinterlacer eingefügt.

    Da ist dann auch die Noise Reduction mit drin. Damit habe ich nun den gleichen Video Pfad wie Kodi :-)

  • wie ist es mit Spulen? Es scheint grundsätzlich so etwas wie einen schnellen Suchlauf zu geben, aber er ist nicht benutzbar, denn wenn man ihn beendet, springt die Wiedergabe wieder auf den Anfang der Aufnahme. Im Log steht

    Code
    1. AMSTREAM_IOC_SET_PCRSCR failed.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • meines Erachtens kann das gar nicht funktionieren. Beim Spulen fragt vdr ständig den Zeitstempel der Aufnahme über GetSTC() ab. Diese Funktion verweist in softhdodroid auf VideoGetClock - die wiederum ist in video.c aber gar nicht mit Inhalt implementiert.


    Eventuell könnte der Zeitstempel mittels AMSTREAM_GET_VPTS wie in GetCurrentVPts ermittelt werden. Oder mit AMSTREAM_GET_PCRSCR (bisher nicht implementiert) ?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • meines Erachtens kann das gar nicht funktionieren. Beim Spulen fragt vdr ständig den Zeitstempel der Aufnahme über GetSTC() ab. Diese Funktion verweist in softhdodroid auf VideoGetClock - die wiederum ist in video.c aber gar nicht mit Inhalt implementiert.

    Sehr gut gefunden. Ich habe es nun gefixt und damit sollte auch Spulen funktionieren. Ich nutze Spulen nie und springe immer mit Gelb über die Werbung :-)

  • Auf meinem C4 habe ich mit der aktuellen Version kein OSD mehr.


    Es kommt folgende Meldung.


    Code
    1. codec_h_ioctl_set failed,handle=60,cmd=118,paramter=17fdf328, t=ffffffff errno=9
    2. AMSTREAM_IOC_SET_PCRSCR failed.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Diese Meldung habe ich auch regelmäßig im log, auch noch mit der aktuellen Version. Fehler habe ich dennoch nicht bemerkt, OSD ist da.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Da ist noch ein fixer printf drin der raus muss. Die Meldung ist völlig unkritisch und kommt dann wenn Audio vor dem öffnen des Video Device kommt.

    Das fange ich aber ab und wiederhole den Aufruf. Ich mach den print noch raus.


    Warum aber das OSD nicht geht kann ich leider nicht sagen. Ich vermute aber das der C4 kein OSD DMA kann und die nicht DMA Variante hatte ich totgelegt.

  • Ich vermute aber das der C4 kein OSD DMA kann und die nicht DMA Variante hatte ich totgelegt.

    Kannst Du das reaktivieren?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • OSD ist wieder da, Danke. :):thumbup:


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich habe nun noch das PIP auf autodetect umgestellt. Damit muss man beim bauen nicht mehr entscheiden ob man PIP haben will.


    Ausserdem habe ich die Audio Features nun hart kodiert und versuche keine Audiosettings mehr zu öffnen die es nicht gibt.

  • Ich habe nun erstmals einen Kernel aus dem Project von Zabrimus eingesetzt. Und der kann nun auch PIP. Sogar für mpeg2 und h264 :-)

    Dafür war noch eine kleine Änderung notwendig die ich gerade eingecheckt habe.


    Leider kann ich das PIP für mpeg2 nicht autodetecten. Deswegen schalte ich es immer ein wenn ich PIP für h264 entdecke. Das ist für alle CE Kernels die PIP können dann auch richtig. Nur wer einen normalen Ubuntu Kernel verwendet der muss nun das Plugin mit dem Paramter -m starten. Sonst gibt es kein mpeg2 Bild.

  • So nun habe ich es doch noch geschafft das mpeg2 PIP automatisch zu finden. Damit entfällt der Parameter -m wieder und alles wird beim start automatisch gefunden. Jetzt muss ich mir mal das Dummy OSD für nopacity anschauen.


    Edit.

    Habe nun ein Dummy Pixmap erstellt. Hoffe das nopacity nicht mehr abstürzt.

  • Ich verwende das Plugin (neuester Stand aus dem git) in einer Ubuntu-chroot-Umgebung unter CoreElec, Kernel 4.9.269

    Wie benutze ich PIP? Ich finde keine PIP-Option im Plugin-Menü (nur 'Suspend SoftHDDevice'). In den Einstellungen des Plugins gibt es den Punkt Picture-in-Picture. Diese default-Einstellungen sind konfiguriert:

    Mir fiel auf, dass in den Plugin-Einstellungen unter 'General' der Punkt 'Suspend stops x11' enthalten ist. Hat das irgendeine Funktion oder ist es ein vergessenes Übrigbleibsel aus softhdcuvid? Mir fiel auch auf, dass es beim Kompilieren Hunderte von Compiler-Warnungen gibt.

    Nachdem das Plugin ja inzwischen einen recht stabilen Stand erreicht hat, wäre es schön, wenn Du anfangen könntest, da ein wenig aufzuräumen.


    Gibt es bei der Umschaltgeschwindigkeit noch Optimierungspotenzial? Grundsätzlich ist die für so eine Hardware wohl normal. Ich frage mich aber, ob die vielen Debug-Meldungen das nicht auch verlangsamen. Das meiste kommt vom Kernel und ist wohl nicht abschaltbar, sonst hätte CoreElec es schon längst getan. Es gibt aber auch viele Meldungen vom plugin, die der normale Anwender nicht unbedingt sehen muss. Vielleicht kann man einen Loglevel einbauen, um standardmäßig nur Fehlermeldungen zu protokollieren?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Wenn du im Menü nur Suspend findest dann kann der Kernel kein PIP. Deswegen ja autodetect.

    Damit das klappt brauchst du einen Kernel aus dem Zabrimus build. Nur dort wird das Multidecode wieder aktiviert.


    Ja ich müsste mal die Compile Warnings etwas aufräumen :-) Und der Punkt Suspend stops X11 muss auch raus.

  • Wenn du im Menü nur Suspend findest dann kann der Kernel kein PIP. Deswegen ja autodetect.

    Damit das klappt brauchst du einen Kernel aus dem Zabrimus build. Nur dort wird das Multidecode wieder aktiviert.

    Es ist dann wohl dieser Patch von CoreElec schuld?


    Ich verstehe bloß nicht, warum der in der von mir genutzten aktuellen CoreElec-Version (CoreElec-Version ist 19.5-Matrix-rc1 mit der Architektur Amlogic-ng-arm) immer noch drin ist. Schon vor 2 Jahren hieß es in den release notes zur 9.2.2


    Quote

    Also of importance to our -ng releases is a fix to Kodi that makes use of the Amlogic multi decoder u-code, as development by Amlogic on the single decoder u-code used in earlier releases appears to have ceased. This brings improved hardware video decoding capabilities and more content is now playable with fewer issues than ever before.


    Läuft CoreElecs kodi denn stabil mit MAX_INSTANCE_MUN 9 , oder muss da dann auch noch etwas gepatcht werden?

    Wie ersetze ich am einfachsten bei meiner bestehenden CoreElec-Installation den Kernel gegen eine Version von Zabrimus ? Gibt es den fertig kompilierten Kernel irgendwo? Oder kann ich ihn einzeln bauen? Es ist mir bisher nicht gelungen, mit dem build script von Zabrimus ein fertiges image zu erzeugen (aus dem ich dann den Kernel extrahieren könnte) - es bricht immer irgendwo vorzeitig ab.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.