Posts by 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.

    Das Gesamtwerk besteht eigentlich aus 2 Teilen:

    1. Das VDR Plugin und

    2. Einen Browser der auf CEF (Chromium code) basiert.
    Das Plugin übernimmt die Steuerung des Browsers und die Ausgabe der Seiten/Videos, die der Browser rendert.

    Mal wieder ein Lebenszeichen zum Plugin und dem Browser.


    Aber vorab eine Warnung: Der unten erwähnte Branch ist noch nicht für den Produktivbetrieb geeignet. Es gibt da etwas, was mich massiv stört und für das ich noch keine Lösung habe. Aber dazu später mehr.


    Es gibt für das Plugin und den Browser jeweils den Branch "encoding", der ursprünglich dazu gedacht war, ein paar meiner Ideen zu verfolgen. Der Branch hat ein paar Besonderheiten gerade im Bezug auf den Browser.

    • Mitgeliefert wird eine customized CEF-Version, bei der FFmpeg nicht mehr statisch gelinkt ist (aus Lizenzgründen). Eine eigene Version von libffmpeg.so muss entweder selbst kompiliert werden (mit h264 und aac Decoder und evt. mehr) oder man verwendet ein Ubuntu-Package oder extrahiert aus dem Package die dynamische Library. Mehr dazu im Readme des Branches.
    • ffmpeg-dev (libav* Header und Libs) müssen zum kompilieren vorhanden sein.
    • Chromium/Chrome nutzen nur vaapi. Besitzer von NVidia-Karten sollten einen vaapi-vdpau Wrapper installieren. Die Links zu den Repositories, die ich gefunden habe, sind auch im Readme zu finden.
    • Die Videos und auch Dash werden jetzt direkt im Browser abgespielt. Für Dash nutze ich aktuell nur den shaka-player. Per default wird dashjs verwendet aber die Kommandozeile ist einfach "--dashplayer=shaka" oder "--dashplayer=dashjs". Den Shaka-Player nutze ich hauptsächlich, weil ich weiß, daß damit auch DRM Videos abgespielt werden können.
    • Nach einigen Debug-Sessions habe ich herausgefunden, wie der UserAgent am Besten zu setzen ist, damit ein paar DRM Prüfungen auf verschiedenen Seiten erfolgreich durchlaufen werden.
    • Aber: Für DRM kann ich keinen Support leisten, noch genau erzählen, wie ich es gemacht habe. Die Logausgaben beim Start des Browser können helfen und zusätzlich die Hinweise in cef_web_plugin.h am Ende der Datei oder im CEF Forum findet man auch Andeutungen.
    • Der Netzwerk-Code wurde komplett entfernt und die Kommunikation zwischen Browser und VDR findet nur noch über shared memory statt. Der Teil ist noch nicht sauber und es hakt noch ziemlich.


    Nun zu dem Problem, das einen Produktiveinsatz eigentlich verbietet.

    Aktuell sieht der Durchlauf der Videos so aus:

    1. Der Browser decodiert Video/Audio (und nutzt dabei die erwähnte libffmpeg.so)
    2. Die Video/Audio Daten werden als ARGB und PCM (FLTP) mitsamt PTS an meinen Teil übergeben
    3. Die Audio/Video Daten werden wieder nach H264/AAC encoded und über das Shared Memory als TS an den VDR übergeben, der das dann abspielt.

    Das Problem ist die unglaublich nervig hohe (im Sekundenbereich >> 2) Latenz, bis z.B. das OSD im Browser über das Encoding im VDR landet. Und ich habe die Ursache noch nicht gefunden und schon gar nicht abstellen können. Das In-Video-OSD ist so nicht wirklich nutzbar, weil der Cursor im Browser schon an der richtigen Position steht, aber man dies im VDR nicht sehen kann. So kann es pasieren, daß Aktionen ausgeführt werden, die man gar nicht machen wollte, aber die im VDR eben just zu dem Zeitpunkt zu sehen sind.

    Schaue ich mir das Video/OSD im Chrome Developer an oder lasse auch nur das Video im VDR OSD laufen (Bild für Bild), ist alles wunderbar schnell und es gibt keine wahrnehmbare Latenz. Beides ist nur gar keine Lösung.


    Ich würde gerne auf das Encoding komplett verzichten und dem VDR die decodierten Daten (ARGB, PCM mitsamt PTS) geben und eines der Ausgabedevices kann sich dann um die Ausgabe/Wiedergabe kümmern. Allerdings habe ich dazu keine Möglichkeit gefunden. VDR will TS oder PES Pakete und damit ist das Encoding wieder im Spiel.

    Selbst für die Ausgabe von Video/Audio sorgen und das auch noch synchron ist nicht so mein Ding und würde wahrscheinlich schief gehen. Das können andere besser als ich.


    Die alte Lösung dem ffmpeg die Video-URL zu übergeben und einfach nur transcoding zu machen hat ganz andere Probleme: DRM fällt aus und MPEG-Dash wird nicht sauber unterstützt und es gäbe schon wieder Netzwerkcode, den ich erfolgreich beseitigt habe.


    Hat irgendjemand ein Idee dazu oder weiß Abhilfe?


    Zabrimus

    Seufz...

    Das will ich RTL testen und bekomme SSL Handshake Fehler. Aber zum Glück warnen auch Chrome und Firefox vor der Verbindung. Das kann man dem Browser nicht anlasten. Nur falls ihr auch solche Fehler habt.

    A bit strange? When I started the plugin I thought that I had a browser and a working extension and that I just had to take care of the communication between the browser and the plugin. I was so naive and so phenomenally wrong. Every page and every button has some speciality that needs to be considered.

    But giving up is not an option. Embrace the challenge... 8)

    zb. auf ARD rote taste --> tagesschau --> gelbe taste und dann in der Mediathek irgened einen Film auswählen.

    Sollte jetzt funktionieren (Browser update). Mich wundert aber irgendwie, warum es noch eine andere Mediathek gibt? Bisher habe ich noch keinen kürzeren Weg gefunden, genau dieses zu öffnen. Die Benutzerführung auf dem Ersten ist irgendwie verbesserungswürdig.

    Mehrere gelbe Buttons mit dem Label Mediathek, aber unterschiedliche Ziele.

    Ja Wetter aus der Startleiste wars...

    Das sollte jetzt funktionieren, sowie andere Sender mit Fullscreen/Scaled-Videos. Es wurde das ganze Video-Handling im Browser geändert. Viele Sender wurden zwar getestet und alle aufgefallenen Probleme notiert. Ich bin mir aber nicht sicher, ob es etwas gibt, das vorher funktioniert hat und jetzt nimmer.


    Pro7/Sat1 haben z.T. massiv Probleme bei den Videos. Ich falle häufig in den Fehler

    Code
    1. DOMException: The play() request was interrupted

    Die Ursache scheint zu sein, daß Pause() vor dem wirklichen Videostart mittels Play() (asynchron) aufgerufen wird. Gerade bei kurzen Werbeeinblendungen vor dem Hauptfilm kann das schnell passieren. Meistens hilft es, es noch einmal zu versuchen. Aber schön ist anders.

    Es gibt von Google auch dazu einen Hinweis: Play Request... Wie ich das im Code unterbringe, weiß ich noch nicht.


    Ich will noch einige Darstellungsfehler fixen, bevor ich an ein neues Tag denken kann.


    Eine Frage habe ich noch alle:

    Im Plugin fange ich kBack ab, um das OSD zu schließen und das Video zu beenden. Jetzt will ich aber das kBack oder eine Alternative an den Browser senden (als VK_BACK), weil es verschiedene Seiten gut stehen würde: Die reagieren auf VK_BACK.

    Nur, mit welcher Taste kXXX soll dann die jetzige Funktionalität umgesetzt werden? So eine richtig gute finde ich in der "enum eKeys" nicht.

    Ich fürchte meine remote.conf und auch meine Fernbedienung ist nicht repräsentativ konfiguriert. Auf der FB liegt auf der Back-Taste was anderes und der WAF würde massiv leiden, wenn ich das ändere.


    Und was VK_PAGE_UP und VK_PAGE_DOWN im Browser machen, weiß ich gar nicht. Aber die Extension hat diese zumindest konfiguriert.