Posts by Zabrimus

    Beim Plugin habe ich noch eine Fehlermeldung:

    ERROR: plugin 'hbbtv' called cPlugin::ConfigDirectory(), which is not thread safe!

    Ich dachte, daß hätte ich schon bereinigt. Aber wohl nur zur Hälfte. Im Repository ist es jetzt final gefixed.


    Zabrimus

    Muss das ffmpeg, das da verwendet wird, auch das sein, das für den Rest des Systems genutzt wird?

    Nein. Das libffmpeg wird nur für den Browser verwendet. Meines Wissens nutzt nur noch Ubuntu Chromium eine libffmpeg.so. Das entsprechende Ubuntu-Package installiert diese aber woanders. Wobei Ubuntu Chromium nur noch per snap anbietet, aber da bin ich mir nicht sicher.


    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

    Jetzt kommt beim Bauen des hbbtv-Plugins:

    Mist. Ich habe vergessen den Fix aus dem Master-Branch in den encoding-Branch zu übernehmen. Der Fix ist jetzt im Repository.



    Noch ne Fräche: Wie kriege ich denn die libffmpeg.so gebaut?

    Das avbuild Paket habe ich runter geladen, die Sourcen von ffmpeg ebenfalls, aber avbuild mault rum:

    Ich weiß nicht, warum avbuild so dermaßen pingelig ist. Der stört sich an der Existenz der "config.h".

    Wenn Du also mal ein 'configure' im ffmpeg Source Verzeichnis aufgerufen hast, bekommst du den Fehler.


    Also entweder ein ffmpeg- Source Verzeichnis verwenden, daß komplett unangetastet und noch so richtig sauber ist oder evt. (ungetestet) hilft es auch, das "config.h" im ffmpeg Verzeichnis zu löschen.


    Zabrimus

    Ich war auf einem völlig falschen Trip. Den Build-Fehler habe ich gefunden und beseitigt.


    Achja. Den encoding-Branch gibt es für den Browser und das Plugin. Beides muss zusammen passen.


    Zabrimus

    cp: cannot stat 'thirdparty/cef/Release/*': No such file or directory

    Oh nein....

    Ich suche den Fehler schon länger. Welche Version von cmake hast du installiert? cmake 3.18?


    Lösch mal das Verzeichnis thirdparty/cef und baue nochmal. Wenn es dann klappt, hast Du genau das Problem, was ich nicht verstehe.


    Zabrimus

    Hast Du den Encoding- oder den Master-Branch verwendet? Den Master-Branch habe ich schon lange nicht mehr getestet.

    Im Log sieht man, das der Browser überhaupt nicht startet oder abstürzt.

    1. Was gibt denn "ldd libcef.so" aus? Werden alle libs gefunden?
    2. Versuche mal den Browser standalone zu starten:
      ./vdrosrbrowser --trace
      Startet der Browser oder sieht man direkt Probleme?
    3. Wenn bis hierhin alles klappt, dann den Browser standalone starten
      ./vdrosrbrowser --trace
      In der VDR Config den Parameter "-s" für das hbbtv-Plugin entfernen oder auskommentieren und den VDR starten.
      Im VDR dann auf das Menu gehen und schauen, ob der Browser mehr oder andere Meldungen ausgibt.

    Wenn das auch alles keine hilfreichen Informationen liefert, wird es schwieriger. Dann wäre eine gdb-Session um an den Backtrace zu kommen, an dem der Browser aussteigt.


    Das Display stimmt?

    --display=:0.0


    Der Parameter ist für den encoding-Branch nicht mehr notwendig und kann gelöscht werden. Der Master-Branch braucht den noch.

    --video=UNIX

    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

    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

    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

    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

    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

    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

    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

    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

    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

    A hard dependency is really not a good idea. I think of command line parameter of the plugin to switch to a fast mode (currently not existing, raw audio and video) if supported and the currently existing implementation to encode to TS and use the VDR functionality as is.

    I will take a look to the softhd* plugins if i'm able to find a solution. Because OSD is near the functionality i need.

    I thought about mpv plugin, but there exists several problems:

    I don't have a file or an URL. At hand i have only the raw video data (ARGB or YUV as desired) and audio data (currently PCM floating point planar) including the PTS. If i want to write the data to an file, the file will be really huge, nearly 100 MByte per second. Therefore i used shared memory and avoided as much copying as possible.


    The OSD will be rendered as fast as possible and this looks good and there exists no mention-able delay.

    But the idea of a service in the output plugins (softhd*) sounds good. I don't need a decoder or something like this, i need the possibility to "send" decoded audio and video data to the output device and the output device could play both as today (but without decoding something).

    Is this possible?


    I think, the delay happens in the softhd* plugin, because if i stop the browser and don't send data anymore, the video/audio still plays several time, before playing stops. I assume that there exists some buffering. And any interaction in the page will only be shown, if the current buffer is empty or filled with new data.


    A side note i discovered today: Youtube already has an application which is used for TV: https://www.youtube.de/tv

    After some changes in the browser regarding key events, the application works as a charme. Only one or two keys has still to be mapped to get better results.