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

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

    Edited once, last by stegro (May 6, 2025 at 6:16 PM).

  • 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.

  • 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.

    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!

    Edited once, last by stegro (May 7, 2025 at 2:16 PM).

  • ... Weisser Rauch! ...

    Der war gut und zeitlich so passend :D

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 21 - xstream
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • 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.

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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:

    Code
    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?

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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.

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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.

    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.

    MLD 6.5 mit vdr 2.7 - lirc yaUSBir - 4 x DD-Sat - SCR - Intel N100M - 4GB RAM - WD Green 12TB HDD - 22TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 6.5 mit vdr 2.7 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • 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.

  • 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.

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!