cef-osr-browser und vdr-plugin-htmlskin/vdr-plugin-hbbtv

Hallo,

dies ist nur ein Proof of Concept und beinhaltet noch viele Baustellen. Einige Werte sind noch hardcodiert, die Optik ist - wohlwollend ausgedrückt - etwas rustikal und dem Classic Theme angelehnt. Der Zoom-Level ist noch nicht implementiert, aber schon vorbereitet. Und und und.... Aber leider neigt sich mein Urlaub dem Ende zu.

Intention:

Ich wollte wissen, ob es möglich ist, das Skin des VDR in HTML zu implementieren und auch beliebige HTML Seiten im VDR anzuzeigen und das ist mir gelungen.

1. Versuch mit WebkitGTK+
Experimentiert habe ich zuerst mit WebkitGtk+, hatte aber sehr viele Probleme mit dem Rendering, Javascript und eigentlich hat es nicht so richtig gut funktioniert.

2. Versuch mit CEF (Chromium embedded framework)

CEF ist einfach zu nutzen und gerade das Off-Screen-Rendering klappt hervorragend und dabei bin ich dann geblieben.
Aber Vorsicht: Das CEF und damit das Plugin und der cef-osr-browser sind ein ziemliches Schwergewicht. Obwohl die komplette Installation des WebkitGTK+ auch nicht ohne ist.

Architektur:

Das gesamte System besteht aus 2 (oder eher aus 3) Teilen:

• cef-osr-browser
  Dies ist die eigentliche Implementation des Offscreen-Browsers. Die Aufgabe ist nur, HTML Seiten zu rendern die Grafik per nanomsg (Unix Sockets) weiterzugeben. Der cef-osr-browser öffnet dabei in /tmp 2 Unix Sockets. Eine davon ist für die Kommandos an den cef-osr-browser zuständig. Das andere Socket liefert nur die gerenderten Grafikdaten.
• osrclient
  Dies ist nur ein Hilfsprogramm um Kommandos an den cef-osr-browser zu senden und wurde zum Testen verwendet.
• vdr-plugin-htmlskin
  Das eigentlich Skin-Plugin für den VDR. Die Aufgabe besteht nur darin Daten zur Anzeige zu sammeln und als json (bzw. als Javascript) an den cef-osr-browser zu senden. Ein separater Thread liest die gerenderten Seiten und stellt sie im OSD dar. Dabei habe ich versucht, möglichst wenig bzw. gar nicht selber irgendwelche Grafiken oder Images zu kopieren. Im gesamten Plugin findet sich kein memcpy oder ähnliches. Kopieraktionen finden höchstens im VDR bzw. in nanomsg statt. Erweiterte Informationen wie sie z.B. epgd liefern kann, sind noch nicht implementiert. Ich glaube, Schnittmarken dürften auch noch nicht funktionieren.

Der bisher einzige Skin wurde mit vue.js implementiert. Als Einstiegspunkt in den Browser wird nur eine javascript Methode aufgerufen, die dann die Verwantwortung für die Seite erhält. Mit vue.js war es möglich die Komponenten sehr klein und übersichtlich zu halten. Theoretisch kann man aber auch alles andere verwenden, sofern man die Prozedur implementiert.

Build des cef-osr-browser:

Im github habe ich versucht, alles zu beschreiben, daher nur in Kürze.

• git clone https://github.com/Zabrimus/cef-osr-browser.git
• make prepare
  Dabei wird die vorkompilierte Version des CEF heruntergeladen, die Installation vorbereitet und die Library kompiliert. Das Paket ist allerding ziemlich groß.
• make
  Im Release Unterordner finden sich dann die Executables und Softlinks auf das CEF-Installationsverzeichnis

Build des vdr-plugin-htmlskin:

• git clone https://github.com/Zabrimus/vdr-plugin-htmlskin.git
• make prepare
  Hier werden wieder alle Vorbereitungen getroffen, die HTML Templates überhaupt kompilieren zu können. Auch hier wird eine Menge heruntergeladen.
• make && make install

Start:

Der cef-osr-browser muss / sollte gestartet sein, bevor VDR gestartet wird. Das Plugin wie üblich in vdr.conf eintragen und im OSD auszusuchen.

Probleme:

Auf meinem Client-Hauptsystem hatte ich etwas zu kämpfen mit dem Start, deshalb in Kürze die Probleme und meine Lösungen

• der cef-osr-browser muss Zugriff auf den X-Server haben. Also aufpassen mit welchem User man den Browser und X startet. Evt. reicht ein xhost +.
• der cef-osr-browser legt die beiden Unix-Sockets im tmp-Verzeichnis an. Der VDR muss dann Lese- und Schreibrechte haben.

Ein paar Screenshots:

Ein simples Menu:

Eigentlich ist das Kaleidoskop animiert und wird auch animiert im OSD angezeigt. Hier wurde eine externe Seite eingebunden, die in einem IFrame gerendert wurde. Das Problem mit einem IFrame ist allerdings, das man nicht mittels Javascript ran kommt. Cross-Domain Exception und dergleichen werden geworfen. Dazu muss ich noch eine Lösung finden.

Der obligatorische HTML5 Test. Die niedrige Punktezahl hat die Ursache in den beschränkten Berechtigungen (sandbox), die ich dem IFrame gegeben habe. Normalerweise liegt der Wert weit über 500. Aus dem Gedächtnis irgendwo bei 520.

Es gibt noch eine dritte Animation

http://animateyourhtml5.appspot.com/part4-webgl/index.html

die aber jetzt aus unerfindlichen Gründen einen Fehler innerhalb der Seite wirft. Vielleicht finde ich den Fehler noch.

Anzumerken ist, das alle Animation sehr flüssig dargestellt werden und auch die Navigation durch die Menus keine Probleme machen.

Getestet habe ich das mit VDR 2.4.0 und

• AMD Phenom II X6, Nvidia GTX 1050ti, softhddevice
• Intel Celeron CPU J3455, Onboard-GPU, softhddevice

Selbst der kleine Celeron hat die Aufgabe gemeistert.

Ideen für Erweiterungen gibt es genug. Z.B. schickeres VDR OSD, Videoplayer, Youtube, sonstige Mini-Html Applikationen. Mal sehen. Erstmal alles stabilisieren und die weitere Infrastruktur für z.B. die Fernbedienung schaffen, damit Tasten irgendwelche Aktionen im Browser ausführen können.

Edit:

Die selbstkompilierte Version des CEF (mit anschließendem strip der Libraries) mit proprietären Codecs (u.a. auch H.264) braucht entpackt nur schlanke 187 MB. Das ist schon erheblich kleiner. Der HTML 5 Test liefert 528 von 555 Punkten. Was immer die einzelnen Tests auch aussagen. Sehen kann man sie hier: http://html5test.com/s/f38577423789b59a.html

Zabrimus

So lange irgendwas im Chromium dargestellt werden kann, sollte es auch im VDR verfügbar gemacht werden können.

Fernbedienung bzw. Keyboard Events fehlen zwar noch, sind aber auf meiner Todo-Liste. Aber gerade das Thema Keyboard scheint irgendwie sehr speziell zu sein im Hinblick auf die Keycodes..

Zabrimus

Ich habe mal ein wenig geschaut. Es hat mit dem Skin erstmal nix zu tun. Aber HbbTv ist eine mögliche Anwendung.

Der HybridTvViewer macht genau das, was mir als ersten Test vorgeschwebt hat (nur viel, viel besser): ContentType ändern, MimeType manipulieren, User-Agent ändern und dergleichen.

Also soweit gut. Allerdings sind die Extensions im CEF noch im recht frühen Stadium und nicht vollständig verfügbar:

https://bitbucket.org/chromiumembedd…rome-extensions

Die Fragen wären:

Welche Extensions werden explizit benötigt?

Welcher Aufwand entsteht, wenn die fehlenden Extensions nachimplementiert werden müssten? Oder könnte man den HybridTvViewer entsprechend ändern? Alernativ wäre vielleicht eine Implementierung im CEF direkt möglich.

Wie werden die Extensions im CEF überhaupt eingebunden.

Das Plugin von FireFly ist mir durchgegangen, weil HbbTv mich bisher nicht sonderlich interessiert hat, aber ich sehe Potential für eine interessante Entwicklungsarbeit.

Zabrimus

Hi,

ich versuche mal die Sackgassen und Probleme zu schildern. Vielleicht hat jemand eine Idee, oder vielleicht gibt es auch Präferenzen, welche Variante erfolgversprechender sein könnte.

Folgende Überlegungen habe ich:

• Nutzen von CEF um die Seite im VDR OSD darzustellen. Dabei bin ich mir nicht sicher, wie die Audio/Video Synchronisation funktioniert. Die neueren CEF Versionen bieten zwar auch den Audio Stream als PCM an, aber so richtig Ahnung habe ich davon nicht.
• Nutzen des Chrome Browsers direkt. Da müsste man sich überlegen, wie man den Browser im Fenster oder Kiosk-Mode anzeigt. Die Steuerung des Browsers z.B. mit Websockets müsste man noch in der Extension implementieren.
  Ich bin mir auch nicht sicher, ob transparente Hintergründe funktionieren, die für verschiedene HbbTV Applikation schon sinnvoll wären. Ich bin mir nicht sicher, was genau funktioniert und was nicht:
  https://bitbucket.org/chromiumembedd…er-for-windowed

• Die obige Variante im Remote-Debugging Modus. Die Seite kann man dann wohl per png oder jpeg bekommen, aber dann tritt das Problem mit Audio/Video Synchronisation auf.
• Im Headless Chrome werden keine Extensions unterstützt und werden es auch nie. Der Aufwand wäre zu groß. Headless müsste man dann den Polyfill wieder direkt in die Seite injizieren und wieder das Problem png/jpeg und audio/video synchronisation.

Die - mit Abstand - bisher beste HbbTV Chrome Extension, die ich gefunden habe, findet sich hier:

https://github.com/smartclip/HybridTvViewer

Damit gibt es wohl 2 Möglichkeiten: Entweder den Polyfill direkt in die HbbTV Seite injizieren und versuchen von außen zu steuern. Oder mittels CSS die Fernbedierung und die Status-Leiste auszublenden und nur den IFrame übrig zu lassen.

Aber genau hier beginnt das erste große Problem: Man muss den Content-Type der Response ändern, weil ansonsten die Seite nur zum speichern angeboten wird. Ich habe in meiner Implementierung im CEF eine schmutzige Variante ausprobiert, die auch funktioniert, aber mit der ich nicht so richtig glücklich bin. Hinweis: Mit Curl die Seite holen, manipulieren und dem Browser vor die Füße werfen.

CEF unterstützt leider die notwendige WebRequest Extension (noch) nicht, die auch von der obigen Extension verwendet wird. Das ist alles noch work-in-progress und auf sehr lange Zeit ausgelegt.

Für CEF gibt es allerdings Hoffnung

https://bitbucket.org/chromiumembedd…-of-response-in

Wann das Ticket angegangen wird und wie lange das dauert, steht aber noch vollständig in den Sternen. Ich habe genau diese Variante (CefResponse manipulieren), als erste Variante probiert, bis ich darauf kam, das zwar alle Daten vorhanden sind und auch geändert werden können, dies aber keinerlei Auswirkungen hat. CefResponse kann aktuell nur read-only sinnvoll verwendet werden.

Übrig bleiben also nur 2 mehr oder weniger sinnvolle Möglichkeiten:

• Chrome nativ nutzen (Kiosk-Modus) und auf dem Bildschirm darstellen und die Steuerung in einem Plugin implementieren. Wobei hoffentlich der transparente Hintergrund funktioniert.
• CEF nutzen (sinnvollerweise erst nach Implementierung der CefResponse Änderungen). Dabei müsste man herausfinden, wie man die audio/video Synchronisation machen kann.

Für mich charmanter ist die CEF-Version, weil sich das "echter" anfühlen würde. Hat jemand schon Erfahrung mit einer separat gestarteten Applikation, wobei die Ausgabe irgendwie "über" den VDR gelegt wird? VDR im Fenster und den Browser wird man wahrscheinlich nicht perfekt übereinander legen können, also würde das wohl nur im Fullscreen funktionieren.
Andere Varianten habe ich gedanklich durchgespielt, aber nicht weiter verfolgt: Z.B. Audio/Video im CEF multiplexen/transcoden und dem VDR zur Anzeige anbieten. Das ist aber wieder ein Bereich, in dem ich mich nicht auskenne.

Vielleicht sieht jemand eine andere Möglichkeit? Welche Variante ist vielversprechender. An der Stelle stehe ich irgendwie auf dem Schlauch.

Zabrimus

Ich habe mal die aktuelle Entwicklerversion des Browsers und des Plugin auf GitHub hochgeladen:

https://github.com/Zabrimus/vdr-plugin-cefhbbtv

https://github.com/Zabrimus/cef-osr-browser

Im Plugin ist die Startpage bisher nur hardcodiert. Ich muss mal das Plugin untersuchen, daß die HbbTV-URLs filtert (FireFlys HbbTV Url Plugin) und schauen, ob ich das irgendwie integriert bekomme und auch, welcher Link wofür steht. Das ist mir noch nicht klar.

Das Ganze ist noch sehr unstable! Man kann bisher die Seite sehen und auch navigieren. Aber Videos machen tatsächlich noch ein Problem. Und es gibt noch ein Problem, an das ich gar nicht gedacht habe: Wenn die Page (wahrscheinlich durch ein Timeout) nicht mehr dargestellt wird, bekommt der VDR davon überhaupt nichts mit und das OSD bleibt mit leerem Inhalt offen.

Die Farbtasten (sofern in der Seite vorhanden, z.B. EPG, Mediathek und so) funktionieren wohl nur, wenn der Sonnenstand stimmt.

Aber zu Wiederholung: Das ist eine reine Entwicklerversion und noch sehr unstable...

Zabrimus

Es gibt einen kleinen Fortschritt zu vermelden. Das Plugin von FireFly habe ich erweitert und nun wird die ausgewählte URL im OSD angezeigt (zumindest ein paar, die öffentlich-rechtlichen gehen ganz gut, aber Pro7/RTL/... funktionieren noch nicht so prickelnd. Ich bin mir nicht sicher, ob die KeyCodes passen.).

Videos machen tatsächlich noch Probleme, bzw. werden nicht dargestellt. Aber navigieren und dergleichen funktioniert aber sonst ganz gut.

Das ist alles noch eine Baustelle: Die Größe der Seite ist nicht Full-HD, sondern hardcoded auf etwas kleineres, z.T. bekomme ich Meldungen, daß Hbbtv 2.0 erwartet wird, Videos gehen nicht, und und und...

Die Sourcen sind hier zu finden: Github Benötigt wird natürlich auch der cef-osr-browser, der die Seiten rendered.

Zabrimus

Das hatte ich befürchtet:

ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: no supported streams"}

ERROR:batching_media_log.cc(26)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_NO_SUPPORTED_STREAMS

Die automatischen Builds von Spotify enthalten leider nur freie Codecs. Es gibt eine Möglichkeit, CEF neu zu compilieren. Nur das ist leider nichts, was so nebenbei gemacht werden kann. Mal abgesehen vom Plattenplatz 40-50 GB ist sehr viel Zeit und eine potente CPU und viel RAM (ich habe was von 16GB frei gelesen) erforderlich.

Ich forsche schon die ganze Zeit, ob es nicht schon Pakete gibt, aber leider bin ich nicht so richtig fündig geworden. Für Debian hat ein Entwickler versucht, das Problem anzugehen Debian Bug report logs - #893448. Nur ist das abhängig von Chromium Source package, das wohl auch noch nicht existiert und auch erst erzeugt werden müsste.

Eine andere Idee ist, Launchpad zu nutzen. Aber dazu müsste man CEF paketieren und meine Erfahrung liegt dabei bei exakt 0. Irgendeine Binär-Version von CEF müsste man schon bereitstellen.

Zabrimus

Hi,

das erwähnte PPA ist sehr gut geeignet um schnell und einfach die CEF-Libraries zu installieren und den Browser zu kompilieren. Allerdings werden nur die Spotify-Builds paketiert (und zwar wirklich geschickt), und leider mit den bereits erwähnten Einschränkungen.

Die 500 MB für die Sourcen resultiert genau daraus, daß die Binary-Builds von Spotify verwendet werden. Ich habe nach der offziellen Anleitung den Build vorbereitet und alleine nur für die Vorbereitung (git pull, downloads von allerlei Sachen) werden schon 38 GB verbraucht. Wohlgemerkt ohne den eigentlichen Build überhaupt angestossen zu haben.

Meine Idee ist jetzt folgende: Automatischer Build nach AutomatedBuildSetup und dann das obige PPA nutzen bzw. die Sourcen dazu, um den Spotify-Build durch das Ergebnis des AutomatedBuilds zu ersetzen um danach die Debian Packages generieren zu lassen.

Nachdem der Build durch ist, werde ich erstmal die Applikation testen, ob sich der Aufwand überhaupt lohnt.

Der Build läuft auf einem Core i7 schon 8 Stunden und wird vorraussichtlich erst morgen früh fertig werden.

Zabrimus

Nur zum Spaß mal der bisherige Resourcenverbrauch:

Resources:
  Processes: 54
  CPU usage:
    CPU usage (in seconds): 127688
  Memory usage:
    Memory (current): 19.52GB
    Memory (peak): 24.25GB
  Network usage:
    eth0:
      Bytes received: 30.41GB
      Bytes sent: 72.23MB
      Packets received: 1753153
      Packets sent: 944691
    lo:
      Bytes received: 153.79kB
      Bytes sent: 153.79kB
      Packets received: 1686
      Packets sent: 1686

Die Erstellung von Debian Paketen und das PPA sind eine Wissenschaft für sich. Aber letztendlich ist es mir doch gelungen.

Auf meinem PPA sind jetzt die Pakete für libcef (inkl. codecs) und der vdr-osr-browser verfügbar. Der Browser ist nur ein Snapshot der aktuellen Entwicklung. Aber mittels libcef und libcef-dev lässt sich sowohl der Browser (vdr-osr-browser), als auch das Plugin (vdr-plugin-hbbtv) einfach übersetzen. Die libcef(-dev) habe ich selbst auf meinem Debian/Buster im Enwicklungseinsatz.

Videos werden mal dargestellt und mal scheint der Javascript-Anteil irgendwie ein Problem zu haben. Ich habe den Eindruck, daß es ein Timinig-Problem ist mit der Initialisierung des Players. Zumindest deuten die Ausgaben auf der Konsole darauf hin.

Die Architektur sieht so aus:

Standalone vdr-osr-browser lädt eine URL, die entweder vom vdrosrclient oder dem Vdr-Plugin übergeben wird. Dabei ist es völlig egal, welche URL man dem Browser unterschiebt. CEF rendert das Ganze und liefert die Seite per nng (Nachfolger von nanomsg) über Unix-Sockets an das VDR Plugin, welches die Bilder im OSD darstellt. Der Sound wird noch vom Browser an die soundausgebende Instanz geliefert.
Das VDR Plugin stellt die Seite (oder das Video) im OSD dar und kennt auch verschiedene Tasten (Farb-Tasten, Pfeile, Zahlen), die über einen Rückkanal an den Browser gehen und dort den entsprechenden Event simulieren. Damit wird die Navigation in Hbbtv-Applikation ermöglicht.

Was mir noch fehlt:

- Meldungen/Kommandos aus Javascript heraus an das VDR Plugin senden zu können. Dieser Kanal fehlt noch, wird aber benötigt um z.B. dem Plugin mitteilen zu können, ob ein Video dargestellt werden soll, vielleicht auch die aktuelle URL und was man sich noch so ausdenken kann.

- Eine vernünftige Möglichkeit, irgendwie dahinter zu kommen, was im hbbtv Polyfill (Javascript) eigentlich passiert und schnell Änderungen vornehmen zu können. Ich habe da noch keine Idee, wie das zu bewerkstelligen sein könnte. Einfach weil es nicht mein Gebiet ist. Im Moment kompiliere ich alles per "npm run build", kopiere die hbbtv_polyfill.js in das Javascript-Verzeichnis des Browsers und teste wieder. Sehr unbefriedigend das Ganze, aber leider der Unwissenheit geschuldet.

Gibt es hier vielleicht Javascript-Experten, die eine Idee haben wie man die Entwicklungsumgebung aufsetzen kann oder vielleicht sogar verstehen, warum es manchmal zu einer Art Endlosschleife bei den Videos kommt?

Achja. Ich möchte nochmal erwähnen, daß es dem Browser egal ist, welche HTML-Seite er rendern soll. Die Bedienung könnte noch Anpassungen erfordern, aber testweise lade ich mir auch immer irgendwelche Seiten. Ich habe auch schon nach anderen Hbbtv-Applikationen gesucht, die man evt. über Bookmarks im Plugin auswählen könnte.

Zabrimus

Quote

Javascript called me: VDR:ERROR VIDEO:{"isTrusted":true}

Das ist doch erst seit sehr kurzem drin. Und vielleicht auch zuviel an Debug-Ausgaben.

Man kann jetzt in beide Richtungen Nachrichten senden:

• VDR per Javascript an den Browser und

• der Browser/die HTML Page mit Javascript entweder an CEF oder direkt an das VDR Plugin.
  

Welche libcef hast du denn verwendet?

• Den offiziellen Build von spotify? Dem fehlen einige Codecs
• Selbstkompiliert? Da müssen die Parameter richtig gesetzt werden: GN_DEFINES="use_jumbo_build=true proprietary_codecs=true ffmpeg_branding=Chrome"
• Aus dem PPA? Da sollte eigentlich alles drin sein. Die nutze ich ja selber.

Aber gerade mit den Videos bin ich sehr unglücklich. Das ist nur etwas für jemandem mit ausgesprochen niedrigen Ansprüchen. Es wird abgespielt, aber ausgesprochen asynchron zum Ton und auch nicht wirklich flüssig. Die Datenmengen, die transportiert werden müssen (unkomprimiertes Full HD) sind einfach zuviel.

Seitdem suche ich eine Lösung für das Problem. An die URL des Videos komme ich ran. ffmpeg/ffplay spielen das auch flüssig ab. Nur was dann? Das OSD aus dem HbbTV wäre nicht vorhanden.

Zabrimus