Magst du einen Pull-Request erstellen?
Erledigt. Wenn extra nicht gesetzt ist, sollte erstmal nichts passieren. Lediglich der ffmpeg-Patch wird angewandt. Da wäre es für die Zukunft interessant, wie man generell patches davon abhängig macht, welches Paket erstellt wird....
... und cefbrowser und remotetranscode starten noch nicht automatisch. Da fehlt noch was an systemd.
Mir ist aufgefallen, dass der VDR auf 100% CPU Last geht, wenn web geöffnet wird. Ich glaube, das liegt daran, dass https://github.com/Zabrimus/vd…master/webosdpage.cpp#L60 nicht macht, wofür es gedacht ist. M.E. müsste es so aussehen:
Mir ist nicht mehr klar, warum das so implementiert wurde. Ich habe deine Version übernommen, weil auch einfach logischer 
Mir ist nicht mehr klar, warum das so implementiert wurde. Ich habe deine Version übernommen, weil auch einfach logischer
Du kannst die Zeiten auch höher setzen, aktuell läuft er600x durch die Schleife bis wieder getriggert wird. Nachdem der Menutimeout auf 120 steht http://git.tvdr.de/?p=vdr.git;…71812222ef656;hb=HEAD#l87 kann man das auch etwas relaxter angehen und CPU sparen...
Du kannst die Zeiten auch höher setzen, aktuell läuft er600x durch die Schleife bis wieder getriggert wird.
Erledigt 
Der Transcoder und der Browser müssen ja nur gestartet werden, wenn auch das Plugin aktiviert ist. Ich meine, ich hätte mal in /storage/.config/vdropt/enabled_plugins nach dem Plugin gesucht und in autostart.sh die units aktiviert/deaktiviert. Aber ich finde das nicht wieder und fürchte das war in irgendeiner Testversion, die verschollen ist. Das funktioniert allerdings nur beim boot und nicht beim Restart des VDR mit anderen/geänderten Plugins.
Erledigt
Da war zuviel Jetz schließt das OSD vor dem Triggern.
So wird alle 20 sec geprüft und nach 100 sec getriggert:
int counter = 0;
int waitTime = 20 * 1000; // 20sec
int catchMenuTimeout = 90 * 1000; // 90sec (catchMenuTimeout + waitTime) must be < MENUTIMEOUT
while (runTriggerActivity) {
counter++;
if ((catchMenuTimeout) - (counter * waitTime) <= 0) {
cRemote::TriggerLastActivity();
counter = 0;
} else {
std::this_thread::sleep_for(std::chrono::milliseconds(waitTime));
}
}oder evtl so ?
int trigger = 0;
int catchMenuTimeout = 110 * 1000; // 110sec (must be < MENUTIMEOUT)
while (runTriggerActivity) {
if (trigger) {
cRemote::TriggerLastActivity();
trigger = 0;
} else {
std::this_thread::sleep_for(std::chrono::milliseconds(catchMenuTimeout));
trigger = 1;
}
}... oder ganz anders
... oder ganz anders
Nö. Die letzte Version habe ich so übernommen. Das eine so kleine Funktion so oft angefasst wird ....
kannst Du es in Deinem Plugin konfigurierbar machen auf welche Größe gerendert werden soll? Dann kann jeder entscheiden ob er HDReady, HD oder UHD OSD haben will. Dann muß nix mehr scaliert werden.
Das Problem ist nicht das Plugin, sondern der Browser. Standardmäßig rendern die Seiten alle mit 1280x720 und so bekomme ich die Daten. Ich kann vermutlich mit dem Zoom-Level auf eine andere Größe kommen, allerdings müssen die Daten vom Browser zum VDR und dann auch noch optional übers Netz und genau da liegt das Problem. Die CPU- und Netz-Last wird immer größer werden, falls das OSD überhaupt noch schnell genug zum VDR kommt. Und der Browser muss auch schwerer arbeiten. Ich hatte mit png experimentiert (weil ich den Alpha-Channel brauche) und alle getesteten Libs sind insgesamt zu langsam und das OSD wird dadurch immer träger und das macht gar keinen Spaß mehr.
Im Moment encode/decode ich mit QOI, das ein guter Kompromiss zwischen Netz- und CPU-Last ist. Sehr schnell, etwas größer als png und lossless.
Zwischenstand: VDR, browser und transcoder auf demselben VDRELEC laufen. Grundsätzlich. Performance ist gut.
ARD Vollbild klappt, was nicht klappt ist z.B. Tagesschau in 100 Sekunden im Fenster. Ton kommt, der Videobereich bleibt schwarz. Irgendwann stoppts dann. Ich komme da auch nicht mit "Back" zurück, sondern nur mit Taste "Menü". Bei ZDF ist es genauso, wenn ich "heute" sehen möchte.
Insgesamt ist das Hbbtv aber um Längen schneller als an meinem Samsung TV. Gefühlt 10x schneller.
Nachtrag: Das Video wird kurz richtig skaliert und angezeigt und wird dann schwarz. Evtl. liegts wieder an meinem Ausgabeplugin, ich glaube aber eher nicht.
EDIT: Die letzten beiden commits sollten übrigens wieder raus. Damit reagiert das Plugin nicht mehr auf Tastendrücke...
Im softhddevice-drm-gles Patch ist ein typo (scalex und scaley muss scaleX und scaleY heissen) und außerdem ist er nicht aktiv, da er auf .txt endet
Das VideoSetOsdSize speichert aber die Werte im Setup und das wäre auch nicht so richtig gut.
Was wäre denn, wenn ich dem Ausgabedevice einmal per Servicecall mitteile, welche OSD Size ich gerade brauche und am Ende eine Art Reset durchführe, mit dem die ursprünglichen Werte aus dem Setup wieder hergestellt werden?
Ich glaube jetzt kommen wir der Sache näher. Das was du als "Servicecall" bezeichnest , IST die Funktion VideoSetOsdSize. Damit kannst die Grösse des OSD einmalig (z.b. beim öffnen) festlegen und danach soviele Images laden (in die Koordinaten "deines" OSD) wie du willst. Beim schliessen des OSD stellst du die Grösse dann wieder zurück so wie sie war. Mit GetOsdSize kannst du die originalgrösse auslesen. Derzeit ist die Funktion VideoSetOsdSize
nicht durchgereicht ans Ausgabeplugin. Ich mache dir einen patch für den softhdcuvid dann kannst du das mal testen.
Ich stehe mit C++ auf Kriegsfuss und deswegen bin ich mir nicht sicher ob ich es richig gemacht habe. Aber hier nun der patch für softhdcuvid.
Falls ich da Fehler mit dem C++ gemacht habe erkennst du aber bestimmt wie es richtig sein soll
Tagesschau in 100 Sekunden im Fenster. Ton kommt, der Videobereich bleibt schwarz.
Ich muss das mal im Zielsystem checken. Keine Reaktion mehr? Ich hätte erst gedacht, daß der entsprechende Bereich nicht transparent gemacht wird. Aber das klingt nach einem anderen Problem.
Insgesamt ist das Hbbtv aber um Längen schneller als an meinem Samsung TV. Gefühlt 10x schneller.
Ah cool Mir fehlen die Vergleichsmöglichkeiten. Also im Prinzip ein Blindflug.
EDIT: Die letzten beiden commits sollten übrigens wieder raus. Damit reagiert das Plugin nicht mehr auf Tastendrücke...
Das habe ich auch schon gemerkt und wieder geändert. Ich will auch keine fast 2 Minuten warten, damit das OSD weg ist.
Den Patch werde ich mir genauer anschauen. Das VideoSetOsdSize ist genau das SetOsdSize? Okayyy.
Tagesschau in 100 Sekunden im Fenster. Ton kommt, der Videobereich bleibt schwarz.
Kannst du mal den Transcoder stoppen, bevor du die Tagesschau aufrufst? Dann müsste das TV-Bild im Fenster skaliert abgespielt werden. Sollte das klappen, dann liegt es am eingehenden Video, geht das aber auch schief, dann ist noch etwas anderes krumm.
Mittlerweile weiß ich gar nicht mehr, ob es eine saubere und einfache Lösung für das Problem gibt.
Reicht es nicht das der Browser mit -z angepasst werden kann?
Reicht es nicht das der Browser mit -z angepasst werden kann?
Im Prinzip schon, außer die Maschine ist nicht schnell genug oder man will den Browser auf einer anderen Kiste starten. Das dürften aber aktuell eher meine eigenen Anforderungen sein. Das Skalieren im Browser löst schon einige Probleme.
So habe ich nun cefbrowser und remotetranscode bauen und auf VDRELEC laufen (erstmal für LE):
Den Pull Request habe ich gemerged und es baut auch in CoreELEC. Die Binaries befinden sich in
/usr/local/config/remotetranscode-sample-config.zip
/usr/local/config/cef-sample-config.zipSoweit so wirklich gut. Die cef-Library selbst ist noch ein kleines Problem. Man muss die cef-Lib + browser auf /storage mergen.
Die cef-Lib sieht allerdings noch komisch aus und ich komme nicht dahinter warum.
Aktuell sind im Archiv die beiden Verzeichnisse cefbrowser/Release und cefbrowser/Resources. Eigentlich gehört der Inhalt in ein einziges Verzeichnis. Und im gemeinsamen Verzeichnis dann der browser selbst.
Jetzt stellt sich die Frage, wie man das in ein Script packen kann
Aber nun der Haken. Ich komme nicht an cOglOsd::SetOsdPosition. Die Funktion ist statisch und ich kann nur cOsd::SetOsdPosition aufrufen. Und leider landen die Werte alle im setup.conf und beim restart von VDR habe ich die falsche OSD Größe.
Übrigens ist der Patch von mir Du musst die OSD Size wieder zurück setzen wenn du sie geändert hast. Dann bleibt auch das setup.conf stabil.
Warum hat Klaus das denn statisch gemacht ?
Ich wollte das Ganze jetzt auch mal ausprobieren, habe aber Probleme damit.
Auf der TT6400 (dvbhddevice) stürzt der VDR ab, das vertagen wir mal auf später.
Im Moment versuche ich das mit softhddevice von lnj auf x86_64.
1. Das Kompilieren hat ohne Auffälligkeiten funktioniert
2. Die socket.ini ist angepasst auf lokal (127.0.0.1)
3. remotetranscode startet:
[root@home-05 build]# ./remotrans -c /etc/vdr/sockets.ini
[2023-07-29 10:50:33.475] [transcoder] [info] [main.cpp:118] Stop streamId 127.0.0.1_50001Die 2.Zeile taucht erst später auf.
4.cefbrowser startet mit folgender Fehlermeldung:
[root@home-05 Release]# LD_LIBRARY_PATH="/home/vdr/Downloads/cefbrowser.git/build/Release" ./cefbrowser --config=/etc/vdr/sockets.ini
[0729/105148.977708:WARNING:chrome_browser_cloud_management_controller.cc(87)] Could not create policy manager as CBCM is not enabled.
[0729/105148.977930:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[0729/105148.977962:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")5. web-Plugin startet und stellt auch eine Verbindung her:
Jul 29 10:51:17 vdr[65475]: [65510] [vdrweb] Hello received
Jul 29 10:51:17 vdr[65475]: [65511] [vdrweb] Hello received
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] MainMenuAction: reopen = no
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] Create WebOSDPage
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] WebOSDPage show
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] WebOSDPage Display
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] Area size set to 0:0 - 1920:1080
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] webospage SetOsdSize()
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] webosdpage SetOsdSize, Get new OSD size
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] webosdpage SetOsdSize, Create pixmap 1920x1080
Jul 29 10:51:30 vdr[65475]: [65475] [vdrweb] webosdpage SetOsdSize, Clear Pixmap
Jul 29 10:51:36 vdr[65475]: [65475] [vdrweb] Destruct WebOSDPage
Jul 29 10:51:36 vdr[65475]: [65475] HTTP error (LoadURL): Could not establish connection
Jul 29 10:51:37 vdr[65475]: [65486] [vdrweb] InsertHbbtv, browser is not available6. Sobald ich das web-Plugin über das Menü aufrufe, stürzt der cefbrowser ab:
Trace/Breakpoint ausgelöst
[root@home-05 Release]# [0100/000000.535641:ERROR:zygote_linux.cc(622)] Zygote could not fork: process_type renderer numfds 4 child_pid -1
[0100/000000.535708:ERROR:zygote_linux.cc(654)] write: Datenübergabe unterbrochen (broken pipe) (32)softhddevice ist für VDPAU übersetzt und das OSD hat OpenGL an.
Mehr Infos habe ich im Moment leider nicht.
Was lässt sich da machen.
Grüße
kamel5
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!