[gelöst] HBBTV mit vdr-plugin-web, cefbrouwser, remotetranscode

Quote from stegro

Ja habe mich zu früh gefreut, bei Intel tritt es auch auf:

Code

2025-05-06T14:40:34.176318+02:00 white vdr: codec/audio: drift(     0) 2825ms reset
2025-05-06T14:40:37.757799+02:00 white vdr: codec/audio: inital drift delay 382ms

Ja ich habe zur Sicherheit noch mal das plugin ausgecheckt. Es gibt also bei Intel auch die gleichen Probleme.

hallo jojo61 Ich habe es etwas eingrenzen können:

mit ffprobe habe ich mehrere ZDF Streams anschauen können, alle progressive 50Hz, hier was geht und was nicht:

Es funktioniert, wenn ffprobe ein "h264" "1280*720" stream anzeigt. (Rosenheim Cops)

Es funktioniert, wenn ffprobe ein "hevc" 1920x1080 anzeigt (Dr. Nice)

Es funktioniert nicht, wenn ffprobe ein "h264" 1920x1080 stream anzeigt. (Heute Show)

Das sieht mir nach einem interlaced Problem aus. Da ich gestern 3 Stunden vergeblich versucht habe bei meinen x86 Rechner das web plugin und cefbrowser zum laufen zu bringen, könntest du mir mal ein Schnipsel von dem h264 1920x1080 Stream bereitstellen.

Quote from jojo61

Das sieht mir nach einem interlaced Problem aus. Da ich gestern 3 Stunden vergeblich versucht habe bei meinen x86 Rechner das web plugin und cefbrowser zum laufen zu bringen, könntest du mir mal ein Schnipsel von dem h264 1920x1080 Stream bereitstellen.

Hallo Jojo, ich habe Dir hier ein Schnipsel gebastelt. Die .ts Datei ist ok (mit VLC getestet) zeigt aber das sync Problem, wenn sie mit softhdvaapi abgespielt wird.

stegro Danke für das Schnipsel. Ich habe das Problem gefunden und hoffentlich so behoben das es keine negativen Effekte auf den Fix für die kaputten SD Streams hat.

Es ist eingecheckt und du kannst es testen.

Quote from jojo61

stegro Danke für das Schnipsel. Ich habe das Problem gefunden und hoffentlich so behoben das es keine negativen Effekte auf den Fix für die kaputten SD Streams hat.

Es ist eingecheckt und du kannst es testen.

Du bist derWahnsinn. Ich teste gleich mal und gebe Bescheid.

jojo61 Weisser Rauch! Es funktioniert! Danke!

Wäre cool, wenn seahawk1986 das in Launchpad aufnehmen würde!

Quote from stegro

... Weisser Rauch! ...

Der war gut und zeitlich so passend

Quote from stegro

Wäre cool, wenn seahawk1986 das in Launchpad aufnehmen würde!

Das Problem ist, dass man beim Bauen von Paketen auf Launchpad keinen Internetzugriff hat und sowohl remotetranscode als auch der cefbrowser beim Bauen Sachen aus dem Internet nachladen wollen - wenn mir jemand sagt, wie man meson davon überzeugt das vorab in einer Weise zu machen, die ein dh_clean (bzw. was immer meson --clean oder ähnliches macht) überlebt, dann baue ich da gerne Pakete.

Quote from seahawk1986

Das Problem ist, dass man beim Bauen von Paketen auf Launchpad keinen Internetzugriff hat...

Wenn ich das richtig verstanden habe, dann hat clausmuus mit yocto exakt dasselbe Problem und irgendwie gelöst.
Meine erste Vermutung wäre, die Sourcen direkt in das Verzeichnis subprojects(oder vielleicht auch nur einen Link dahin) zu packen, weil meson dann keinen Download mehr macht. Aber das wäre nur eine Vermutung.

Für remotetrans geht es von hinten durch die Brust ins Auge unter Ausnutzung der Tatsache, dass man Debian-Paketen extra Sourcen unterschieben kann:

meson setup build
cd build
meson compile
cd ..
meson setup clean
tar --exclude="subprojects/packagecache"  -cvzf remotetranscode_0.0.1+git20250502-83.orig-subprojects.tar.gz   subprojects

Aber schön ist das nicht - gibt es denn einen Grund dafür, dass thrift als einziges Paket nicht in subprojects/packagefiles vertreten ist?

Beim cefbrowser ist das nicht so einfach, weil es da für jede Architektur ein extra Source-Paket bräuchte und die Source-Pakete riesig werden würden.

Quote from seahawk1986

Aber schön ist das nicht - gibt es denn einen Grund dafür, dass thrift als einziges Paket nicht in subprojects/packagefiles vertreten ist?

Die packagefiles enthalten nur Patches oder zusätzliche Files, die vor dem Build (eigentlich direkt nach dem Extrahieren der Archive) in die Source Folder angewand/kopiert werden. Für thrift musste ich da nichts patchen, da thrift mit cmake (und nicht mit meson) gebaut wird.

Quote from seahawk1986

Beim cefbrowser ist das nicht so einfach, weil es da für jede Architektur ein extra Source-Paket bräuchte und die Source-Pakete riesig werden würden.

Der cefbrowser ist aufgrund des vorkompilierten cef schon etwas größer, aber da wüsste ich nicht, wie man das umgehen kann um das kleiner zu machen. Der einzige Versuch wäre ein strip der shared libraries. Damit werden die *.so Files ziemlich eingedampft, aber das wären immer noch ca. 90MB.

Ich lade in der Tat die benötigten Sourcen vorab herunter und entpacke die nach subproject Packagefiles. Hier findest Du die BitBake Rezept Dateien:
https://gitlab.com/MLD-6/meta-mld…?ref_type=heads
https://gitlab.com/MLD-6/meta-mld…?ref_type=heads

Solltest Du Fragen zum Verständnis der Rezepte haben, helfe ich gerne weiter.

Ich habe aus verschiedenen Gründen die Sourcen (bzw. die Projekte) in subprojects übernommen:
- Ich wollte systemunabhängig sein. Z.B. gibt es thrift in Debian/Stable nur in einer alten Version, die letzten Bugfixes wollte ich aber mitnehmen
- Den Aufwand zusätzlich verschiedene Pakete zu installieren wollte ich mir ersparen. Versionskonflikte eingeschlossen
- Die Libs werden statisch gelinkt und damit umgehe ich auch Probleme bei einem Update des Systems

Falls man das System (und die Installation) unter Kontrolle hat, ist es auch möglich, statt den subprojects auch installierte Pakete zu verwenden. Dabei wird nur ein Patch von meson.build benötigt. Das habe ich z.B. in VDR*ELEC gemacht. Siehe z.B. hier.

# thrift
-thrift_opts = cmake.subproject_options()
-thrift_opts.add_cmake_defines({'WITH_AS3': 'OFF',
-                               'WITH_QT5': 'OFF',
-                               'BUILD_JAVA': 'OFF',
-                               'BUILD_JAVASCRIPT': 'OFF',
-                               'BUILD_PYTHON': 'OFF',
-                               'BUILD_TESTING': 'OFF',
-                               'WITH_C_GLIB': 'OFF',
-                               'WITH_OPENSSL': 'OFF',
-                               'BUILD_SHARED_LIBS': 'OFF',
-                               'BUILD_COMPILER': 'OFF',
-                               'CMAKE_INSTALL_PREFIX': '.',
-                               'CMAKE_POSITION_INDEPENDENT_CODE': 'ON' })
-
-thrift_proj = cmake.subproject('thrift', options: thrift_opts)
-thrift_dep = thrift_proj.get_variable('thrift_dep')
+thrift_dep = dependency('thrift')

Vielleicht würde es sich lohnen da mal in Richtung Appimages zu denken, dann spart man sich den ganzen Aufwand das für jede Distribution anders zu verpacken und hat dann einfach eine ausführbare Datei, die man verteilen kann.