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*

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

AMSTREAM_IOC_SET_PCRSCR failed.

jojo61 Das Problem mit dem Spulen in chroot CE kann ich bestätigen. Native unter Ubuntu tritt es nicht auf.

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) ?

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

Es kommt folgende Meldung.

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

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

Zitat von jojo61

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

Kannst Du das reaktivieren?

OSD ist wieder da, Danke.

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:

softhdodroid.pip.Alt.Height = 50
softhdodroid.pip.Alt.VideoHeight = 50
softhdodroid.pip.Alt.VideoWidth = 0
softhdodroid.pip.Alt.VideoX = 0
softhdodroid.pip.Alt.VideoY = 0
softhdodroid.pip.Alt.Width = 0
softhdodroid.pip.Alt.X = 0
softhdodroid.pip.Alt.Y = 50
softhdodroid.pip.Height = 18
softhdodroid.pip.VideoHeight = 0
softhdodroid.pip.VideoWidth = 0
softhdodroid.pip.VideoX = 0
softhdodroid.pip.VideoY = 0
softhdodroid.pip.Width = 18
softhdodroid.pip.X = 79
softhdodroid.pip.Y = 78

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?

Zitat von jojo61

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

Zitat

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.