Posts by Zabrimus

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')

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.

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.

Quote from stegro

wie kann ich remotrans überreden auf 50 Hz zu transcodieren?

Als erstes wird geprüft, ob ein einfacher Stream-Copy ausreicht:

codec_copy = h264,h265,hevc,mpeg2video

Ich nehme an, du hast z.B. noch h264 mit drin, oder? Falls der codec des gewünschten Streams nicht in der Liste ist, wird erst dann der transcode Eintrag verwendet.

Du kannst auch den remotetranscoder mit dem Parameter "-l 3" starten um den kompletten Aufruf von ffprobe/ffmpeg zu sehen. Die URL des Streams würde ich als erstes prüfen. Was gibt z.B. ffprobe aus? Sind es wirklich 25 fps?

Quote from reini-at

Wenn ich 2 VDR an mein Remotetranscode auf meinem server (mittels proxmox virtualisiert) anbinden möchte, starte ich das einfach 2x mit unterschiedliche sockets.ini?

Den remotranscode hatte ich eigentlich mandantenfähig geplant (also beliebig viele VDR mit einem Transcoder). Allerdings habe ich das nie wirklich getestet und weiß deshalb gar nicht, ob das wirklich funktioniert. Und hier habe ich mittlerweile auch pro Client einen eigenen remotetranscoder.

Quote from reini-at

Macht es sinn / ist es möglich / ist es sinnvoll das transcoding auf die gpu auszulagern, z.b. auf intel systeme?

Der Transcoder liest auch eine codecs.ini ein, mit der die Parameter für ffmpeg etwas angepasst werden können. Z.B.

[video]
codec_copy = h264,h265,hevc,mpeg2video
transcode = libx264 -preset ultrafast -crf 22

[audio]
codec_copy = ac3,aac,mp2
transcode = aac

codec_copy ist das schnellste Verfahren, weil kein wirkliches trancoding stattfindet, sondern nur das Containerformat (mp4 oder was immer da auftaucht) nach TS gewandelt wird, sofern der codec passt.

Ich habe einen zusätzlichen Check eingebaut. Das VDR (und die anderen) crashen, wenn mit -c ein Verzeichnis oder kein existierendes File angeben werden, ist die denkbar schlechteste Lösung.

Wieso ist das eigentlich notwendig? Ist das eine Spezialität des Systems? Es düfte nicht schaden, aber mich wundert das.

LD_LIBRARY_PATH=/usr/local/src/VDR/PLUGINS/src/cefbrowser/build/Release ./cefbrowser

Im Backtrace sehe ich folgendes:

#11 0x00007f7181356254 _ZN10cPluginWeb11ProcessArgsEiPPc (libvdr-web.so.6 + 0x74254)

Der Crash kommt wohl beim Verarbeiten der Plugin Argumente. Kannst du mal posten, welche Parameter du für das web-Plugin gesetzt hast, damit ich das nachvollziehen kann?

Quote from stegro

Was ist mein Problem: Bei ARD und ZDF geht erst alles gut, dann fängt der Ton zu stocken an. Das Bild läuft richtig weiter, der Ton ist abgehackt. Das passiert nach ca 10 - 15 Sekunden.

Wenn der Ton gar nicht käme, aber so "ein bisschen" ist ätzend. Auffällig ist auch, dass der Ton deutlich leiser ist, so lange es noch flüssig läuft.

Hast Du einen Tipp für mich? Wo kann ich nachschauen, was schief läuft?

Das klingt für mich nach einem Problem mit dem Ausgabeplugin. Hast du die Möglichkeit ein anderes Plugin zu testen? Wie woanders mal erwähnt wurde: Die Büchse der Pandora wurde geöffnet mit den verschiedenen Ton- und Video-Formaten.
Auf dem x86 Rechner habe ich aktuell z.B. vdr-plugin-softhddevice laufen.

Ich würde als erstes mal im Logfile (syslog) schauen, ob es da Hinweise gibt, was und wo etwas schief geht.

Quote from qumad

Also gelernt habe ich, dass beide cefbrowser und remotetranscode immer zusammen aktualisiert werden müssen.

Das kommt darauf an. Zuletzt gab es eine große Änderungen in der Kommunikation zwischen den Komponenten und da war ein Update aller Komponenten Pflicht, weil es ansonsten gar nicht funktioniert.

Aber gut, daß alles jetzt funktioniert.

Quote from qumad

Leider macht das vdr-plugin-web , das normal umschalten zwischen den programmen langsamer (5 Sekunden).

Oh wow. Bist du sicher, daß es am Plugin liegt? Das Plugin reagiert auf einen Kanalwechsel, aber ich sehe nicht, was den Wechsel so lange bremsen sollte.

Quote from vdr_rossi

Es müsste statt vdr-2.7.3-dynamite.patch > vdr-2.7.5-dynamite.patch heißen.

Ach mist. Ich erinner mich....

Quote from vdr_rossi

Wollte eben auch mal ein aktuelles Image bauen. Aber fakeroot will nicht:

Bitte schau mal wie sich das reparieren lässt.

Ich habe ja unbemerkt einen Spiegelserver eingerichtet um solche Probleme schnell ohne Patch lösen zu können

Starte den Build einfach nochmal. Ein git pull ist nicht notwendig.

Quote from clausmuus

[0418/121226.630101:ERROR:icu_util.cc(223)] Invalid file descriptor to ICU data received.

Das working-directory für den Start des Browsers muss das Installationsverzeichnis sein. Die ganzen libraries und sonstigen Dateien werden relativ dazu gesucht. Im Installationverzeichnis sollte auch die icudtl.dat vorhanden sein.

Quote from clausmuus

Die Variable browserDbPath wird bisher gar nicht verwendet.

Danke. Die Änderungen dazu müssen in irgendeinem Branch versickert sein Ich check das...

Edit:
Jetzt weiß ich es wieder. Die Datenbank wird initialisiert, bevor die Commandline überhaupt gelesen wird. Dazu hatte ich damals die ENV Variable BROWSER_DB_PATH eingeführt, um das Problem zu lösen.
Ich habe den Parameter -d/--browserdb <path> jetzt vollständig implementiert. Die Auswertung von ENV bleibt erhalten um Bestandsinstallationen nicht zu stören, sobald aber -d verwendet wird, hat dieser Wert Vorrang.

Quote from clausmuus

annst due den thrift Fix auch noch im remotetranscode einbauen?

Die Änderung für den remotetranscode wurde übernommen und committed.

Quote from clausmuus

Ich habe ein Problem mit dem Build des aktuellen cefbrowser. Dieser versucht (anders als die Version vor einigen Wochen), eine sqlite Lib direkt nach /usr/lib/libsqlite3.a zu kopieren. Das scheitert natürlich, da ich ja nicht als root kompiliere. Das gleiche Problem tritt auch bei libthrift auf.

Beide Libs sollten eigentlich gar nicht kopiert werden, da sie statisch gelinkt werden und sie nach dem Build nicht mehr gebraucht werden. Ich muss schauen, wie ich die Installation in den subprojects verhindere.

Ich kompiliere auch nicht als root und die Libs werden nach /usr/local/lib installiert. Aber da will ich die eigentlich auch nicht haben.

Der letzte Commit sollte die Installation verhindern. Du solltest vorher das Verzeichnis subprojects/sqlite-amalgamation-3490100 löschen, damit auch das neue meson.build verwendet wird. thrift wird mit cmake gebaut und die Änderung sollte sofort greifen.

In der letzten Version mache ich genau das. Das Links solchen Ärger machen....

Quote from LotharE

Wenn ich wie oben explizit beide Tests mache, sollte es für CE21 und CE22 passen.

Der zweite Teil der Bedingung war falsch. Keine Ahnung, was ich da im Kopf hatte. Jetzt sollte es aber passen.

Edit:
Neee. Da passt immer noch etwas nicht

Edit 2:
Ich weiß jetzt, wo mein Denkfehler lag und habe deine Version übernommen. Es besteht das Risiko, daß bei einem Upgrade von libcec, die Links wieder nicht richtig erstellt werden.

Quote from LotharE

Das muss für CE22 jetzt wohl so aussehen:

Okay. Da gab es ein Update, daß ich nicht bemerkt habe. Ich werde das Script anpassen.

Danke fürs melden.

Quote from LotharE

Was lange währt ..., das frische Build für CE22 ist jetzt fehlerfrei durch.

Änderungen an der toolchain sind immer ätzend. Aber gerade bei CE22 hoffe ich immer auf einen Schub an Stabilität. Aber auch bei LE13 ist auch noch keine Alpha (soweit ich weiß) vorhanden.

Das Update auf VDR 2.7.5 habe ich schon drin.