web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Ich habe gestern wieder versucht den browser und den transcoder mit VDR*ELEC zu bauen. Nach dem Update von libfmt macht allerdings spdlog Probleme. Welche subprojects/meson wraps braucht man denn unbedingt oder könnte man da abspecken und die Abhängigkeiten reduzieren?

    Ein downgrade von libfmt ist auch schlecht, dann baut nämlich kodi nicht mehr...

    Die habe ich probiert, evtl. liegt der Fehler auch woanders.

    Oder alternativ die mitgelieferte libfmt verwenden. Für den Browser wäre das der Patch:

    Ich glaube ja. Das sollte der build von LE bei Änderungen an der package.mk oder an dern Patches automatisch machen. Aber ich schau nochmal.

    Nebenbei, LE/CE hätte libfmt und spdlog als Paket auch mit dabei. In den aktuellen Versionen für kodi, d.h. eigentlich müsste es klappen.

    Also bei remotetranscode funktioniert es mit der neuen Version, bei cefbrowser nicht:

    Mit dem gebundeltem fmt kompilierts zwar, aber vielleicht hat ja jemand eine Idee.

    Zabrimus Ich denke, ich habs.

    Das Problem liegt am DEBUG hier: https://github.com/Zabrimus/ce…/requestresponse.cpp#L270

    Man muss die parameter mit (int) casten, dann klappts. Das hast du auch an anderer Stelle schon gemacht.

    Ich habe aber bisher nur den build getestet...


    Ich habe jetzt lange den Beitrag von jojo61 gesucht, der Probleme mit dem Videowechsel beschreibt und zweifelte schon an meiner Erinnerung.


    Aktuell habe ich den Browser auf dem N2+ unter CE20 laufen und den Transcoder noch auf einer anderen Maschine. Der Videowechsel hat gerade auf Sat.1 ziemlich gut funktioniert:

    Ich muss das noch weiter testen, aber mit softhdodroid konnte ich mehr sehen, als mit softhdcuvid.

    Der Browser und der Remotetranscoder wurden geändert. Der TS-Stream wird vom Transcoder jetzt direkt zum VDR gesendet ohne den Umweg über den Browser. Der Transcoder sendet parallel zum TS-Stream ein Heartbeat zum Browser.

    Das hat den zusätzlichen Vorteil, daß der Transcoder stoppt, wenn entweder VDR oder der Browser nicht mehr verfügbar ist.

    Zitat von beta

    Ich habe noch ein Problem mit dem Spulen. Bei einer Auflösung von 1260 beendet sich das Video beim Spulen sofort, bei 1920 kann ich 2-3 mal vorspulen, beim 4.-5. Mal beendet sich das Video dann. Kennst Du das Problem?

    Das ist tatsächlich von der Auflösung abhängig? Sehr seltsam. An der Auflösung wird gar nichts geändert auf dem ganzen Weg vom Netz -> VDR.

    Und mit mehrfach vorspulen meinst du wahrscheinlich schnelle Sprünge in Folge, oder? Um einige Minuten nach vorne zu kommen?


    Gibt es denn vom Transcoder oder dem Browser dazu irgendwelche Hinweise? Beenden sich die Programme oder nur das Video?


    Im Zielsystem (N2+) habe ich aktuell auch ein paar Probleme mit den Videos. Ich bin mir noch nicht sicher, ob es ein Timing-Problem gibt oder ob eine andere Ursache vorliegt. Am Transcoder muss ich sowieso basteln.


    Mit dem neuen Transcoder kann man mittlerweile den Log-Level einstellen (--loglevel/-l, 1-4, wobei 4 sehr viel ist).

    Der Remotetranscoder auf der Maschine bekommt immer wieder einen segfault, beim Spulen, beim Start eines Videos. Die Herausforderung besteht jetzt darin, die Ursache zu finden.

    Ich weiß noch nicht, wie ich den Fehler auf der Maschine debuggen soll, auf der Entwicklungsmaschine habe ich solche Probleme nicht.

    Der Remotetranscoder hat umfangreiche Änderungen erfahren:

    - Die Ausgabe-Pipe von FFmpeg gelöscht und alles passiert nur noch in-memory.

    - die transparenten Videos werden auch in-memory gespeichert.

    - die TS-Packete gehen direkt an den VDR

    - insgesamt gesehen schreibt der Transcoder keine Dateien mehr


    Die Konsequenz der ganzen Änderungen war nur, daß der Transcoder so schnell geworden ist, daß die Timing-Probleme und Race-Conditions ziemlich hart durchgeschlagen sind und erstmal gar nichts mehr funktioniert hat.


    Um die Probleme zu lösen musste ich an alle 3 Komponenten: Plugin, Transcoder und Browser. Wenn, dann sollte ein Komplett-Update gemacht werden.


    Ein erster Test auf der N2+ lief ziemlich gut. Spulen (bzw. Sprünge), Videowechsel waren einwandfrei und schnell - ungeahnt schnell. Egal wie oft und in welche Richtung.

    Das sind doch gute Nachrichten. Dann werde ich mal testen. Und hoffentlich macht dann auch Klaus noch das API für das skalieren des OSD in den Kernel.


    Ergebniss:
    - Vorspulen geht gut, aber zurück spulen geht gar nicht.

    - Ich habe immer noch irgendwo einen Segfault

    - manchmal kommt das OSD in der vordergrund und dann ist das Video nicht mehr zu sehen. (ZDF)

    - beim ARD kommt nicht immer der Ton in einem Video (kann aber auch am softhdodroid liegen :)

    - bei RTL kommt das zweite Video schon nicht mehr wenn ich weiterblättere (aber RTL ist unwichtig)


    Das ganze ist aber deutlich besser in der Schwuppdizität und gefällt mir gut.

    Zitat von jojo61

    - Vorspulen geht gut, aber zurück spulen geht gar nicht.

    Nutzt die Tasten der FB (wenn ja welche) oder das OSD zum spulen?

    Zitat von jojo61

    - Ich habe immer noch irgendwo einen Segfault

    Welche Komponente stürzt denn ab?

    Zitat von jojo61

    - manchmal kommt das OSD in der vordergrund und dann ist das Video nicht mehr zu sehen. (ZDF)

    Ich habe nur mit ARD gespielt. Ich werde mal ZDF untersuchen probieren müssen.


    Zitat von jojo61

    - beim ARD kommt nicht immer der Ton in einem Video (kann aber auch am softhdodroid liegen :)

    Eieiei. Das habe ich noch gar nicht mitbekommen. Das Testsystem hat gar kein Audio.

    Zitat von jojo61

    - bei RTL kommt das zweite Video schon nicht mehr wenn ich weiterblättere (aber RTL ist unwichtig)

    Primär bin ich noch an den öffentlich-rechtlichen am dran sein tun, weil die Privaten nix als Ärger machen und das System an sich erstmal stabil genug sein muss.

    Zitat von jojo61

    Ich nutze das OSD zum spulen und nach dem vorspulen beginnt die Zeit wieder bei null. Deswegen geht dann kein zurückspulen.

    Damit betreten wir den Bereich der Softwaremagie.

    Das Problem tritt tatsächlich erst seit der letzten Umstellung auf. Das transparente Video wird aus dem Speicher statt dem Filesystem gelesen.


    Die Lösung bestand darin, statt dem HTTP Code 200 einfach eine 206 zu senden und schon klappt es. Ich muss nicht alles verstehen :/


    Also. Transcoder-Update

    Mein Testsystem für die N2+ wurde etwas umgebaut:

    - Auf der emmc: LibreELEC/AMLGX (booten mit dem Switch auf MMC)

    - Auf der sd-Karte: CoreELEC-20-ng (booten mit dem Switch auf SPI)

    Das war aber nicht das, was ich mitteilen will. Der Umbau diente nur dazu, die Installation in beiden Systemen zu testen.


    rell hat eine gute Vorarbeit geleistet, in dem in VDR*ELEC der Transcoder und der cefbrowser integriert wurden. Ich habe mich dann einfach drangehängt und das für CoreELEC erweitert.


    Mit den neuen Images (ab dem Wochenende) ist es sehr einfach möglich, in VDR*ELEC den Transcoder/Browser/das Plugin zu installieren und zu starten. Die Vorgehensweise unterscheidet sich dabei allerdings etwas zwischen CE und LE, weil CE auf einen Docker-Container angewiesen, wobei in LE der Browser nativ laufen kann.


    Installation in LibreELEC:

    Code
    /usr/local/bin/install.sh -c https://github.com/Zabrimus/VDRSternELEC/releases/download/2023-10-28.1/cef-114.2.11-arm.zip

/usr/local/bin/install.sh -w

reboot

    Der erste Install holt sich die kompilierten cef-Binaries (in dem Fall die 32Bit Variante), die eher selten geändert werden und auch nur einmal installiert werden müssen.

    Der zweite Install richtet den Transcoder/Browser ein und auch die systemd Startscripte.


    Installation in CoreELEC:

    Hier ist etwas mehr Aufwand/Download nötig. Bevor man richtig startet muss in Kodi das Docker-Addon installiert werden.
    Dann geht es weiter mit

    Code
    /storage/.kodi/addons/service.system.docker/bin/docker pull ghcr.io/zabrimus/cefbrowser-base:latest

/usr/local/bin/install.sh -c https://github.com/Zabrimus/VDRSternELEC/releases/download/2023-10-28.1/cef-114.2.11-arm.zip

/usr/local/bin/install.sh -w

reboot

    Der erste Befehl holt sich das Basis-Image mit dem Startscript, daß für den Browser notwendig ist.

    Die anderen beiden Kommandos unterscheiden sich nicht von der LibreELEC-Version.


    Wenn dann noch in /storage/.config/vdropt/enabled_plugins das Plugin web einträgt, dann kann getestet werden.


    Meine bekannten Probleme:

    Mit LibreELEC/AMLGX

    - funktioniert skindesigner nicht. Das hatte rell schon erwähnt. Hoffentlich wird dafür noch eine Lösung gefunden.

    - könnte das Plugin softhddevice-drm und auch softhddevice-drm-gles starten, wenn nicht zufällig Alsa-Probleme auftauchen. Also geht oder geht nicht. Alsa ist für mich ein Buch mit sieben Siegeln. Aber das sollte auch machbar sein.

    - Mit softhddevice-drm funktionieren Videos in der Mediathek oder auch nicht. Es gibt entweder eine Fehlermeldung bzgl. der Planes (?) oder man sieht was. Aber dafür das AMLGX jetzt noch(?) nicht überragend unterstützt wird, ist das Ergebnis aber schon vielversprechend.


    Insgesamt gesehen bin ich sehr zufrieden und ich möchte rell für ganze Vorarbeit danken :thumbup:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden