Ich schneide nix ab und es flimmert auch nicht.
Posts by nobanzai
-
-
Vielen Dank.
Ich werde dann nochmal neu bauen und anschließend ausgiebig testen.
Gute Woche.
Ciao.
Michael.
-
Das kannst du entweder am Fernseher umstellen oder im VDR beim jeweiligen Plugin - Stichworte Letterbox, Pan&Scan usw.
Allerdings hat das nix mit HD und 16:9 zu tun - es wird ja auch 21:9, 16:10 oder - bei älteren Filmen 4:3 oder Cinemascope (2,55:1, 2,35:1 und 2,40:1) - gesendet.
-
ne 127 - mit 117 lässt sich die neue Plugin-Version nicht mehr übersetzen
-
Ok, dann läuft der Browser jetzt erst mal.
Beim Plugin habe ich noch eine Fehlermeldung:
ERROR: plugin 'hbbtv' called cPlugin::ConfigDirectory(), which is not thread safe!
Könntest du da auch nochmal danach schauen? -
Ja, löschen der config.h hat gereicht.
Muss das ffmpeg, das da verwendet wird, auch das sein, das für den Rest des Systems genutzt wird?
-
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:
Was mache ich falsch?
Danke und ciao.
Michael.
-
Hallo,
mit der aktuellsten Version (3.5?) von softhdvaapi gibt es ständig Hänger in Bild und Ton.
Erst fangen Ton und Bild an zu stottern, dann hängt der Ton, nach einer Weile auch das Bild.
Mit der vorherigen Version passiert das nicht.
Die GPU läuft jetzt auch auf 100% lt. intel_gpu_top, vorher waren es bei sonst gleichen Settings (Shader, Scaler, ...) unter 50%.
Im Log stehen dann Meldungen wie:
Liegt das an der neuen Version des Plugin, an der neuen Version von libplacebo oder an der neuen Version von iHD/vaapi?Die ersten beiden sind ja zusammen so notwendig, bei iHD/vaapi müsste man ggf. mal die Vorversion testen. Allerdings läuft der neue iHD auch mit der vorherigen Pluginversion unauffällig.
Danke und ciao.
Michael.
-
-
Jetzt kommt beim Bauen des hbbtv-Plugins:
Display MoreCode- In file included from status.cpp:13:
- browsercommunication.h:18:26: error: 'string' is not a member of 'std'
- 18 | std::map<eKeys, std::string> keyMapping;
- | ^~~~~~
- browsercommunication.h:7:1: note: 'std::string' is defined in header '<string>'; did you forget to '#include <string>'?
- 6 | #include <vdr/keys.h>
- +++ |+#include <string>
- 7 |
- browsercommunication.h:18:26: error: 'string' is not a member of 'std'
- 18 | std::map<eKeys, std::string> keyMapping;
- | ^~~~~~
- browsercommunication.h:18:26: note: 'std::string' is defined in header '<string>'; did you forget to '#include <string>'?
- browsercommunication.h:18:32: error: template argument 2 is invalid
- 18 | std::map<eKeys, std::string> keyMapping;
-
Ah, wir haben auch -j 2 gemacht gerade
-
Ich habe hier cmake 3.19.
Nach dem Löschen von thridparty/cef hat er es gebaut.
Das Problem ist der "-j 4" scheinbar sind da die Abhängigkeiten nicht sauber definiert, sodass sich die make-Prozesse gegenseitig überholen.
Genauer habe ich es jetzt angaschaut, aber mit einem einfachen make klappt es auch ohne Löschen des Verzeichnisses.
Danke und ciao.
Michael.
-
Da kommt dann allerding
Display MoreCode- [...]
- cp thirdparty/TiresiasPCfont/TiresiasPCfont.ttf Release/font
- cp thirdparty/TiresiasPCfont/TiresiasPCfont.css Release/css
- echo "resourcepath = ." > Release/vdr-osr-browser.config
- echo "localespath = ." >> Release/vdr-osr-browser.config
- echo "frameworkpath = ." >> Release/vdr-osr-browser.config
- cp -a thirdparty/cef/Resources/* Release
- cp -a thirdparty/cef/Release/* Release
- cp: cannot stat 'thirdparty/cef/Release/*': No such file or directory
- make[1]: *** [Makefile:147: prepareexe] Error 1
- make[1]: Leaving directory '/usr/src/packages/BUILD/hbbtvosrbrowser'
- make: *** [Makefile:96: all] Error 2
-
Jo und schon lässt's sich übersetzen.
-
Ich baue mit
Das ist der Masterbranch.
Bei "ldd libcef.so" findet er alles.
Display MoreCode- /vdrosrbrowser --trace
- [2021-04-17 20:42:52.441] [vdrosrbrowser] [info] vdrosrbrowser version 0.1.0pre1 started
- [2021-04-17 20:42:52.441] [vdrosrbrowser] [info] In Main, argc=2, Parameter:
- [2021-04-17 20:42:52.441] [vdrosrbrowser] [info] ./vdrosrbrowser
- [2021-04-17 20:42:52.441] [vdrosrbrowser] [info] --trace
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll started
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll, thread stopped
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll, finished
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll started
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll, thread stopped
- [2021-04-17 20:42:52.442] [vdrosrbrowser] [trace] Dashhandler, ClearAll, finished
Also keine Probleme erkennbar.
Ich probier dann mal den Encoding-Branch.
Danke derweil.
Ciao.
Michael.
-
Ich vermute, dass du die libplacebo auch noch aktualisieren musst, die Änderung, die das hinzugefügt hat, ist erst 19 Tage alt: https://github.com/haasn/libpl…c49a01916998d4a645a93651e
Jetzt hab ich extra die libplacebo nicht aktualisiert, weil die beim letzenmal zu neu war ...
-
Hi,
seit dem letzten Update auf die neue iHD/vaapi-Version von Intel lassen sich softhdvaapi und softhddrm damit nicht mehr übersetzen:
Oder liegt das an den letzten Anpassungen an softhdvaapi/drm bzgl. der Farbtemperatur?
softhdcuvid lässt sich nach wie vor übersetzen.
Ciao.
Michael.
-
Hi,
ich habe die neuesten Versionen des hbbtv Plugin und des OSRBrowsers übersetzt und installiert.
Ich kann das Plugin dann auch laden und im Menü auswählen.
Danach allerdings passiert entweder nix mehr, d.h. ich komme nicht mal mehr zurück ins Menü, bzw. zum VDR selbst, oder aber ich kann in hbbtv selber noch rumklicken, aber keine Videos abspielen - die starten einfach nicht.
Letzteres liegt wohl an diesem Problem:
Vollständiges Log siehe Anhang.
Ich verwende das softhdvaapi Plugins zur Ausgabe, d.h. das ist ein Intel-System mit einer Gen 10 CPU und dem UHD 630 Graphikchip.
Irgendeine Idee, ob das laufen müsste und ich was falsch mache?
Danke und ciao.
Michael.
-
Naja das ist auch kein Wunder. Der ewa_robidouxsharp ist viel aufwändiger beim skalieren und damit auch besser
Das sagst du auch nur, weil du im Gegensatz zu mir Ahnung hast
-
Ich habe noch ein wenig weiter damit herum gespielt und mit intel_gpu_top die Last beobachtet.
Die Shader scheinen sich nicht groß auszuwirken, aber bei den Scalern gibt es große Unterschiede:
Während beim ewa_robidouxsharp die GPU auf 90 - 95% werkelt, sind es beim bilinear nur 35 - 50%.
