Posts by ollo

    Die Box bzw. Installation hatte nie ein Ausgabedevice, ist ein reiner Server.

    Bzgl. OSD ist folgendes in der setup.conf zu finden - sollte alles default sein?!?

    ... die 2 Fälle vom 2.5.1 mit dem dynamite Plugin - vdr251dynamite & vdr251D0dynamite - haben den Segfault.

    Bei denen fehlt die Zeile "OSD size changed to 720x480 @ 1" weil dort knallt's.

    Interessant ist die Zeile "ERROR: device '2' in device bondings '1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0' is not a cDvbDevice" wenn das Plugin geladen ist.

    Außerdem scheint das Plugin den "-D0" Parameter zu ignorieren?! Es werden weiterhin 2 Devices verwendet.

    Hallo Markus,

    anbei ein paar logfiles vom Start:

    • vdr251.log - VDR 2.5.1 auf dem git mit dem Patch (v2.4.6) vom dynamite Plugin, ohne Plugin
    • vdr251dynamite.log - VDR 2.5.1 wie zuvor mit dem dynamite Plugin
    • vdr251D0.log - VDR 2.5.1 wie zuvor aber mit dem "-D0" Parameter um nur einen Tuner zu nutzen
    • vdr251D0dynamite.log - VDR 2.5.1 wie zuvor mit dem dynamite Plugin und dem "-D0" Parameter
    • vdr240dynamite.log - mein aktuell funktionierendes Setup

    Erkennst Du da was draus?

    Hallo Markus,

    hier die Debuginfos:

    In meinem Setup verwende ich 2 Tuner, die "bonded" sind - falls das wichtig ist.

    Danke & Gruss

    Hallo,

    bei mir schmiert der VDR (2.5.1 aus'm git) immer ab sobald das dynamite Plugin (von

    https://github.com/MarkusEh/vdr-plugin-dynamite) verwendet wird. Mit Patch und ohne Plugin tut er aber.

    Die Besonderheit bei mir ist, dass ich den VDR auf einem ARM laufen lasse - WeTek WePlay 2 mit Amlogic S905H CPU.

    Aus irgendeinem Grund wird in "GetOsdSize" die "Height=656465". Gibt es da ein bit order Problem?

    Danke!

    Jetzt hast du mich abgehängt. Wo ist dann das Problem ? Dann müsste doch eine Start und eine Ende Marke korrekt sein. Oder stimmt die Position nicht ? Was kommt dann wirklich an den erkennten Stellen ?

    Das Problem ist dass die generierte marks weder mit dem alten noch mit dem neuen Decoder richtig ist.

    Der alte Decoder setzt nur eine Stop Marke :wow

    Code
    1:36:40.16 assuming stop (145015)

    Der neue Decoder setzt 2 Marken:

    Code
    1:31:01.12 detected start of horiz. borders (136536)*
    1:33:21.16 detected stop of horiz. borders (140040)

    Beides ist falsch. Es müssten Marken bei Frame 3552 für Start (ca. 2:22) und bei 140040 für Stop (ca. 1h 33:21) gesetzt werden.

    Hi kfb77,

    bzgl. #49

    Quote

    der Film mit Frame 3552 starten (ca. 2:22) und mit dem 140040 enden (ca. 1h 33:21)

    und #50

    Quote

    Kein Wunder findet er in der Aufnahme keine Änderung der horizontalen Balken, weil er nur nach Änderungen der Audio Kanäle sucht (und keine findet).

    beides ist richtig - in der Aufnahme ist keine Werbung! Sowohl vor als auch im als auch nach dem Film geht es direkt von einer Sendung in die andere über - offenbar auch ohne Änderung am Tonformat. Das einzige Erkennungsmerkmal wäre wohl das Senderlogo oder tatsächlich Balken - es gibt eine Zwischensequenz mit ohne Balken.

    Vielleicht kann man ja die erkannten Übergänge vorhalten und im Zweifel dann doch nutzen?!

    Hallo kfb77,

    ich habe hier folgendes Problem - die marks Datei enthält nur die Stop Marke, kein Start?! Und einen Fehler bzgl. des indes gibt es auch?!


    Danke!

    Hi mtron,

    das ist ja goil - habe mir nach dieser Anleitung ffmpeg selber gebaut und kann nun mit vielen fps (30..90) auf dem RasPi transcodieren :tup

    ffmpeg -c:v mpeg2_mmal -i /srv/vdr/video/some.rec/00002.ts -vf yadif=0 -c:v h264_omx -c:a copy -b:v 1500k filme/test.mp4

    ffmpeg version N-91046-g974eb4aaaa Copyright (c) 2000-2018 the FFmpeg developers   built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1+deb9u1) 20170516   configuration: --arch=armhf --target-os=linux --enable-gpl --enable-omx --enable-omx-rpi --enable-nonfree --enable-mmal --prefix=/usr/local --enable-libx264 --enable-libx265

    ...

    frame= 2516 fps= 41 q=-0.0 Lsize=   21964kB time=00:01:41.53 bitrate=1772.0kbits/s dup=7 drop=0 speed=1.66x

    Gruß, ollo

    Problem erkannt und gebannt :strike1

    Ich habe hier 2 verschiedene libEGL installiert. Eine kommt aus dem libegl1-mesa package (libEGL.so) und eine aus dem libraspberrypi0 package (libbrcmEGL.so). Im Makefile des rpihddevice wird bei LDLIBS "-lEGL" verwendet. Das habe ich auf "-lbrcmEGL" geändert und neu gebaut - schon funzt es wieder :strike2 Offenbar kommen sich die 2 libs sonst in die Quere.

    Gruß, ollo

    Hallo,

    ich habe neulich auf Raspbian Stretch aktualisiert und seit dem Probleme mit der OSD Darstellung des rpihddevice - es kommt keins. Im syslog ist folgendes dazu zu finden:

    Die Videoausgabe funktioniert jedoch prima. Offenbar hat sich was an den EGL/OpenVG libs geändert!?? Gibt es dafür schon eine Lösung?

    Danke & Gruß, ollo