[Announce] HbbTV plugin / offscreen browser v0.0.9

  • ffmpeg kann wohl TS mit raw Daten muxen, auch wenn das entgegen jeder Spezifikation ist. Dann würde aber jedes Ausgabedevice auf die Bretter gehen, weil wohl einige Buffer zu klein sein dürften. Ich glaube softhddevice/softhdcuvid speichern im Ringbuffer 192 oder mehr Frames.


    Aber das ist eigentlich nicht das Problem. Mein Rechner ist mit dem encoding/decoding noch lange nicht ausgelastet, allerdings stört mich die OSD Latenz ganz extrem und z.T. ist die Seite nicht richtig bedienbar. Auf anderen Systemen mag das sogar noch herber sein.

    Die Ausgabeplugins buffern Video- und Audio-Daten, wahrscheinlich um Video/Audio im Sync halten zu können. Aber Buffer sind eben störend, wenn zero-latency gefordert ist.

    Ich habe halt nur gesehen, daß das Video im OSD abgespielt (also Bild für Bild) perfekt läuft und genauso, wie ich mir das vorstelle, natürlich ohne Sound.


    Das VDR-OSD wird angezeigt, wenn im Browser nur broadast-Videos ablaufen (also TV), damit der Red-Button sichtbar wird oder das Video skaliert in einem kleineren Fenster dargestellt werden soll oder was sich die Sender sonst so alles einfallen lassen.

    Sobald aber im Browser ein echtes Video abgespielt wird (sei es video/mp4 oder MPEG-DASH), dann wird in den Video-Modus geschaltet und sowohl Sound, als auch Video encoded und nach TS gemuxed, weil ich dann keine Möglichkeit mehr habe zwischen dem echten Video und dem Sender-OSD zu unterscheiden. Das sind alles nur noch Bild- und PCM-Daten. Der VDR spielt das auch alles schön ab, aber das ist nicht mehr vernünftig bedienbar, weil der Zeitunterschied zwischen dem neuen Frame mit OSD und dem aktuell dargestelltem Frame sehr groß ist. Der Wechsel zwischen OSD- und Videomodus ist sehr fließend und fällt nicht immer sofort auf.


    Ich denke über verschiedene Möglichkeiten nach, aber so richtig überzeugend ist noch nichts. Also reines Brainstorming ohne Bewertung:

    • Video im VDR-OSD laufen und den Sound über den Browser ausgeben lassen
    • Ein neues Ausgabedevice ähnlich softhd* (aber viel kleiner und eingeschränkter), welches nur für das Plugin wirklich sinnvoll wäre und nur Video/Ton so ausgibt, wie es gerade ankommt.
    • Ein neues X-Fenster aufmachen, in dem ich die Video-Frames ausgebe und dem Browser die Ausgabe des Tons überlasse
    • Ein neues X-Fenster mitsamt Video- und Tonausgabe
    • Irgendein anderes Programm das TS vor die Füße werfen, daß sich um die Ausgabe kümmert (falls es da nicht auch zu großen Latenzen kommt)
    • Alles so lassen, wie es ist und mich weiter rumärgern


    Die Idee, sich die bestehenden softhd* anzuschauen habe ich gestrichen, da es einfach zuviele konkurrierende Plugins gibt.


    Zabrimus

  • Ja die Latenz ist ein Problem und das wird sich auch nicht lösen lassen. Ich denke wenn du schon dekodierst dann musst du auch ausgeben. Ansonsten hast du immer Probleme mit Latenz oder AV Sync.

    Ich habe noch nicht ganz verstanden warum Unbedingt der Browser decodieren muss. Das müsste doch auch das Ausgabeplugin machen können. Wo liegt denn da das Problem ? Am Codec kann es doch nicht liegen, ffmpeg kann die doch wohl alle oder ?

    Ich halte deinen Ansatz das übers OSD auszugeben für falsch, Das OSD ist dafür nicht gedacht und viel zu langsam. Und ausserdem überhaupt nicht in Sync mit irgend etwas. Ausserdem braucht es für ein OSD ein unterlegtes Video um es zum laufen zu bringen.

  • Das OSD war nicht richtig ernst gemeint, sondern diente nur zur Verdeutlichung, daß die Daten schnell und rechtzeitig da sind.


    Der Browser decodiert das von alleine, wenn ein Video abgespielt wird. Das normale Verhalten von <video> in HTML halt. Und darauf kann ich aus 2 Gründen nicht verzichten: MPEG-DASH nachbauen ist alles andere als trivial. Das mpd mag übersichtlich sein, aber was dahinter steckt ist nicht ohne. Nur zum Beispiel die Berechnung der Netzwerk-Latenz und damit die Steuerung der Pakete in verschiedenen Auflösungen um die Latenz/vorhandene Bandbreite auszugleichen. Permanentes Nachladen der mpd-Datei. Ich habe mal spaßeshalber den Debug-Mode im shaka-player angeschaltet und da geht richtig die Post ab.

    Der zweite Grund ist DRM. Darum muss sich der Browser bzw. der Dash-Player kümmern, ich habe da keine einzige Möglichkeit irgendwie steuernd
    tätig zu werden. Und damit ist auch das Encoding wieder im Spiel.


    Ich werde mal ein paar Ideen ausprobieren. Irgendwie muss das Video doch dargestellt werden können. Also zufriedenstellend...


    Zabrimus

  • Ich denke, ich habe eine Lösung gefunden: Ein eigener Videoplayer auf Basis von SDL2.

    Das OSD ist so latenzarm, wie es nur irgend geht. Kein Encoding/Decoding mehr. So macht das richtig Spaß.
    Allerdings ist die neue Version immer noch nicht vollständig nutzbar:

    • Audio/Video-Synchronization bedarf einer Implementierung. Im Moment wird alles dargestellt/abgespielt wie es gerade eben kommt. Knapp daneben ist halt auch vorbei.
    • Tastaturevents muss ich auf jeden Fall im Player abfangen und die irgendwie richtig mappen (z.B. die Farbtasten), da der VDR diese nicht mehr bekommt, sobald ein Video abgespielt wird. bzw. der Player den Focus hat. Ich hoffe, daß Events über LIRC noch an den VDR gehen und von da an den Browser, aber das muss ich noch prüfen.
    • Vollbild und so fehlt auch noch

    Zabrimus

  • SVDRP Events wie z.B. HITK <taste> wären für mich wichtig, da ich meinen VDR mit einer selbstprogrammierten Kombifernbedienung in Android (AVR/TV/VDR) steuere.


    Ansonsten ist das, was ich mir aus deinem GIT geholt habe schon mal recht vielversprechend.


    gruß
    msv

  • SVDRP Events wie z.B. HITK <taste> wären für mich wichtig, da ich meinen VDR mit einer selbstprogrammierten Kombifernbedienung in Android (AVR/TV/VDR) steuere.

    Das Problem besteht nur darin, daß der Videoplayer ein eigenes Fenster und damit den Keyboard-Focus hat. Alles, was direkt vom VDR kommt, sollte einfach so weiter funktionieren (HITK, LIRC, ...). Alleine die Nutzung der Tastatur oder ensprechender Empfänger, die ein Keyboard simulieren (z.B. flirc) brauchen eine Spezialbehandlung.

    Um ein doppeltes Mapping zu vermeiden (im Videoplayer und im VDR) probiere ich gerade aus, ob ich die SDL-Events nach XKeySym mappen kann um diese dann dem VDR als Eingabe zu präsentieren. Von da bekäme der Browser die schon bekannten Events.

    Vorteil wäre, daß nur ein einziges Mapping in der VDR remote.conf stattfinden müsste oder - wie bei mir - schon existiert und das es dann egal wäre, ob VDR oder der VideoPlayer den Focus hätten (zumindest in der Entwicklung wichtig).


    Und dann gibt es noch so Ungereimtheiten wie die Lautstärke-Regelung und Mute/Unmute. Das funktioniert noch gar nicht.


    Zabrimus

  • Die Transformation zu einem eigenen Player ist soweit abgeschlossen und funktioniert ganz gut (Browser + Plugin müssen zusammen passen).

    Keys, Volume und alles andere funktioniert wie gewohnt. Dabei ist es egal, welches das Fenster den Focus hat oder ob der Player im Fullscreen-Mode ist. HITK und dergleichen funktioniert auch.


    Voraussetzung dafür ist ein Mapping in der remote.conf für XKeySym. XKeySym wird für die softhd* Plugins benötigt, diese müssen aber nicht installiert/verwendet werden. Es wird nur das Mapping in der remote.conf benötigt.


    Es gibt aber noch Probleme mit dem blauen Button bei z.B. ARD. Mal funktioniert es, mal nicht. Ich habe noch nicht herausgefunden, woran das liegt.

    Eine schlechte Nachricht gibt es aber auch. Pro7/Sat1/RTL nutzen Microsoft PlayReady als DRM und damit sehe ich keine Lösung. Den UserAgent habe ich wieder so geändert, daß man diese Videos in den Mediatheken erst gar nicht mehr abspielen kann, weil dies zu 100% fehlschlagen wird.


    Ich werde mich jetzt erst einmal um Kosmetik kümmern, solange keine anderen Probleme bekannt werden oder Sender, die so gar nicht richtig gut funktionieren. Kosmetik wären z.B. EPG Daten, die manche Sender darstellen wollen. Aktuell werden nur Dummy-Werte dargestellt, was schon etwas störend sein kann.


    Zabrimus

  • Ist es möglich das Plugin per SVDRP so zu starten, dass gleich der Menupunkt "Red Buton" ausgewählt wird. Wenn ich jetzt das Plugin mit "PLUG hbbtv main" starte und per "HITK ok" die Menuauswahl bestätige wird das OSD nicht umgeschaltet. Erst ein Absenden eines erneuten "PLUG hbbtv main" läßt das OSD umschalten ohne nochmal das Untermenu zu zeigen.


    gruß

    msv

  • Ist es möglich das Plugin per SVDRP so zu starten, dass gleich der Menupunkt "Red Buton" ausgewählt wird. Wenn ich jetzt das Plugin mit "PLUG hbbtv main" starte und per "HITK ok" die Menuauswahl bestätige wird das OSD nicht umgeschaltet. Erst ein Absenden eines erneuten "PLUG hbbtv main" läßt das OSD umschalten ohne nochmal das Untermenu zu zeigen.

    Ich habe das mal nachgestellt und auch per keymacro versucht. Das Hitk Ok scheint nicht zu funktionieren. Ich muss mal schauen, warum das nicht funktioniert. Zumal das bis dahin ja erstmal nur ein einfaches Menu ist.



    Die aktuellen Programminformationen sollten jetzt richtig dargestellt werden. Beim rumspielen mit den entsprechenden Objekten in der Seite habe ich die Default-Einträge mal gelöscht und schwupss wurden die Daten aus dem Netz geladen und angezeigt. Ein reiner Zufallsfund... Falls ein Sender noch nicht funktioniert, dann bitte melden.



    Es gab den Wunsch nach einer Proxy-Konfiguration (Stichwort Geolocation). Allerdings weiß ich nicht mehr, wer den Wunsch für welchen Sender geäußert hat. Ich habe mal in CEF ein wenig gesucht und es scheint so zu sein, daß die Proxy-Konfiguration über ein proxy.pac (und der entsprechenden Kommandozeile) realisiert werden könnte. Allerdings stehen zur Abfrage nur URL oder Fragmente drin und das proxy.pac würde ich gerne lokal von der Platte lesen. Da bin ich dran.

    Aber Beispiele (Sender, eigenes Land, was funktioniert nicht mit der Geolocation, was soll klappen, gibt es einen öffentlichen Proxy zum Testen?) wären schon ganz nett ;) Ansonsten weiß ich nicht, ob überhaupt Auswirkungen zu erkennen sind.


    Zabrimus

  • Hi,

    ich gestehe, nicht alles gelesen zu haben... deshalb hier meine Frage:


    Welche Voraussetzungen gibt es ausser den im ersten Post genannten? XServer? Was muss das Ausgabedevice können?

    Ist es möglich, das mit softhddevice-drm laufen zu lassen, bzw. was müsste das dann können?


    Danke und Gruß

    Andreas

  • Ich habe den Browser mal mit xvfb gestartet und das OSD kann man sehen. Nicht ganz flüssig, aber es geht.

    Allerdings werden keine Videos abgespielt. Ich bin mir nicht sicher, woran das liegt. Es könnte aber an SDL liegen. Wahrscheinlich muss man da noch etwas einbauen, einstellen oder ....


    Die Vorraussetzungen im ersten Post betreffen noch die ältere Version. An der neuen bastle ich noch.
    Ich glaube, ich habe im encoding-Branch auf github die aktuellen Vorausetzungen aufgelistet.

    - Ein X-Server (bzw. die xlibs) wird auf jeden Fall benötigt (CEF selbst hat diese Abhängigkeit).

    - vaapi oder vdpau-vaapi wrapper

    - libffmpeg.so

    Für das OSD sollte softhdddrm funktionieren, weil keine spezielle OSD Funktionalität verwendet wird. Allerdings werden Videos mit SDL2 abgespielt, und da weiß ich nicht, wie und ob es funktioniert.


    Ich habe aktuell nirgendwo softhddrm installiert, kann also nichts prüfen - zumindest noch nicht. Erstmal muss alles soweit funktionieren, bis ich relativ zufrieden bin.

    Zabrimus

  • Welche Distri nutzt du zum entwickeln, testen ?

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Ich meinte softhddevice-drm, nicht softhddrm.

    Dafür brauchst du ein unterstützes ARM Board...

    Ich glaube aber, dass das kompliziert werden könnte, ohne dass ich mich damit genauer befasst habe. Aber wenn vaapi oder vdpau eine Voraussetzung ist, ist es schonmal schlecht. Und CEF scheint mir auch kein Leichtgewicht zu sein und seine Abhängigkeiten zu haben.

  • Man kommt ganz durcheinander bei den vielen verschiedenen Varianten.


    Softhddrm (Intel) und nutzt vaapi. Als einziger Rechner käme das Produktivsystem in Frage. Das wollte ich als letztes angehen, sobald keine üblen Verwünschungen mehr zu erwarten sind und alles soweit ziemlich stabil läuft.


    softhddevice-drm müsste doch auch einem RPI laufen, oder? Aber CEF ist im Prinzip ein fast vollständiges Chromium ohne Oberfläche. Es gibt aber auch die Möglichkeit CEF mit ozone zu kompilieren, welches auch auf dem RPI laufen soll. Den aktuellen Status und Möglichkeiten kann ich nicht abschätzen. Dafür werden die X11 Dependencies rausgeworfen und stattdessen ozone verwendet. Damit soll X11, Wayland, headless und eben auch DRM unterstützt werden. Aber meine Erfahrung dazu ist exakt gleich 0.


    Die ozone-Version klingt aber trotzdem interessant. Das Kompilieren dauert nur einige Stunden.


    Zabrimus

  • Wenn ich Zeit habe, schaue ich mit mal an, was da von wem abhängt. Ich habe noch nicht genau überblickt, welche Rolle die verschiedenen Komponenten übernehmen und wie sie zusammenhängen. 2 Plugins, CEF und softhd*... Kann man das wo nachlesen oder kannst du kurz erläutern, was da wofür zuständig ist?

    1. Das Ausgabeplugin (in meinem Fall ein softhd*, aber es sollte egal sein welches):
      Benutzt werden nur die Methoden aus dem OSD Interface von VDR und keine weiteren Spezialitäten.
      Z.B. osd->CreatePixmap, pixmap->DrawImage, ... Das TV-Bild wird mitunter skaliert, weil dies in der HbbTV-Seite vorgesehen ist.
    2. Das hbbtv-Plugin:
      Das Plugin kommuniziert bidirektional mit dem Browser. Welche Seite soll dargestellt werden, welche Tasten sind gedrückt worden, soll ein Video dargestellt werden, soll das TV-Bild skaliert werden und all dergleichen. Die Kommunikation läuft mittlerweile nur über ein shared memory Segment. Vom Browser kommen auch die Bilddaten (die gerenderte HTML/HbbTV Seite) für das OSD, welches dann über das Plugin in 1. im OSD dargestellt wird.
    3. Der Browser selber ist ein Headless-Browser (also ohne eigene Ausgabe) und verantwortlich dafür die HbbTV Seite zu rendern. Die Bilddaten werden an das HbbTV-Plugin übergeben. Die Seite wird stark durch Javascript angereichert um die HbbTV Objekte und verschiedene Hilfsprozeduren zur Verfügung zu haben. Verschiedene Events im Browser werden abgefangen und an das HbbTV-Plugin gesendet (z.B. Video stopped, Video start, TV-Skalierung,....)
      Der Browser erkennt, wenn ein Video startet und erzeugt dann ein SDL2-Fenster in dem die bereits decodierten Videodaten (vorliegend als rgba-Image) zusammen mit dem Sound (als PCM FLTP) synchronisiert und abgespielt werden.
      Sobald das Video stoppt, wird auch das SDL2 Fenster geschlossen und VDR benachrichtigt, damit das TV-Programm wieder dargestellt wird.

    Browser und HbbTV Plugin liefern sich also permanent Statusinformationen und Kommandos (in beide Richtungen).


    Kommunikation:

    Ausgabe Plugin <-> hbbtv Plugin <-> Browser <-> Internet


    Der Browser ist ein echter Browser (aktuell basierend auf Chromium 89) und kann nicht nur für HbbTV verwendet werden. Ich habe schon beliebige Seiten im OSD des VDR rendern lassen.


    CEF habe ich speziell kompiliert um Lizenzprobleme zu umgehen. In der eigentlichen Version wird ffmpeg statisch gelinkt und damit fallen gerade die wichtigen Video- und Audiocodecs raus (h.264, h.265, aac), weil die nicht mitgeliefert werden dürfen. In meiner Version von CEF wird ffmpeg dynamisch gelinkt und wird nicht mehr automatisch mitgeliefert. Jetzt kann sich jeder selber aussuchen, welche Codecs bzw. welches ffmpeg auf der Maschine installiert/compiliert werden sollen. (Leider werden nicht nicht normalen shared libs verwendet, sondern eine libffmpeg.so in der alle(!) Objekte gelinkt sind, daher die spezielle Anleitung für libffmpeg.so)


    In einer alten Version hatte ich vorgesehen, die Kommunikation Browser <-> hbbtv-Plugin über TCP zu erledigen, aber die Latenz war mir zu groß. Aber im Prinzip wäre es dann möglich gewesen, den Browser auf einer komplett anderen Maschine laufen zu lassen, als den VDR mitsamt Plugins.

    Ich denke, das könnte man wieder durch einen Proxy erreichen, der die Kommunikation shared memory <-> TCP/UDP kapselt, aber es werden unkomprimierte Daten übertragen und die Netzlast dürfte nicht unerheblich sein.


    Wenn du weitere Fragen, immer raus damit.


    Zabrimus

  • Die Idee mit der Proxy-Konfiguration pro Sender muss ich hinten anstellen. Es ist mir bisher nicht gelungen, den Proxy zur Laufzeit zu ändern. Natürlich kann man auf der Kommandozeile einen Proxy-Server angeben oder eine proxy.pac per HTTP Server. Allerdings würde das dann global für alle Aufrufe gelten.


    Es ist mir endlich gelungen, die Seite von Servus TV und die Mediathek zu öffnen. Ich weiß nicht, ob die "deutsche" Version schon fertig ist oder ob es noch ein Fehler in den Scripten von Servus TV ist, aber mit einer kleinen Änderung an den URLs und der Seite selbst, funktioniert es.


    Sorgen machen mir noch die Synchronisation Video/Audio. Manchmal denke ich, die Synchronisation passt nicht exakt. Aber dann scheint es wieder gut auszusehen. Vielleicht war mein naiver Ansatz etwas zu naiv oder ich sehe schon weiße Elefanten, weil ich zu intensiv auf die Lippen starre. So ganz sicher bin ich mir da noch nicht.


    Aber abgesehen von der Synchronisation sollte die Version (encoding-Branch) ziemlich stabil sein. Wenn ich die Synchronisation zufriedenstellend gelöst habe und keine weiteren Probleme auftauchen, kann ich endlich den Branch in den Master mergen.


    Zabrimus

  • Oh cool. Dann scheinen ja Seiten zu funktionieren, die ich nie getestet und gesehen habe.


    Ich habe mir die Seite von npo angeschaut und es ist ein Problem, bei dem man sehr schnell graue Haare bekommt.

    Ob es die Ursache ist oder nur ein Symptom kann ich noch nicht sagen. Auf jeden Fall versucht ein inline Javascript auf HbbTV-Objekte zuzugreifen, die aber genau danach überhaupt erst initialisiert werden. Dies funktioniert natürlich nicht.


    Im Moment fehlt mir noch die zündende Idee, wie man das Problem lösen kann. Um das HbbTV-Init aufzurufen, brauche ich die Seite, bzw. verschiedene Objekte in der Seite. Aber die Senderseite erwartet wohl, daß schon Teile des Inits gelaufen sind und ruft diese fröhlich auf oder versucht es zumindest.


    Darüber muss ich nachdenken und Experimente betreiben....


    Zabrimus