[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