Posts by ollo

  • vdr-plugin-dynamite, Anpassung an aktuelle VDR Version

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

  • vdr-plugin-dynamite, Anpassung an aktuelle VDR Version

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

  • vdr-plugin-dynamite, Anpassung an aktuelle VDR Version

    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?

  • vdr-plugin-dynamite, Anpassung an aktuelle VDR Version

    Hallo Markus,


    hier die Debuginfos:



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


    Danke & Gruss

  • vdr-plugin-dynamite, Anpassung an aktuelle VDR Version

    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!

  • [markad] überarbeiteter Decoder

    kfb77 wrote:

    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. 1:36:40.16 assuming stop (145015)


    Der neue Decoder setzt 2 Marken:

    Code
    1. 1:31:01.12 detected start of horiz. borders (136536)*
    2. 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.

  • [markad] überarbeiteter Decoder

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

  • [markad] überarbeiteter Decoder

    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!

  • Videos konvertieren mit Raspberry ?

    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

  • Videos konvertieren mit Raspberry ?

    Hi Kibu,


    TS und MP4 sind Container Formate, die Audio und Video (und andere) Pakete enthalten koennen. Diese lassen sich recht einfach von TS nach MP4 umkopieren, auch auf einem RasPi:


    ffmpeg -i datei.ts -vcodec copy -acodec copy datei.mp4


    Falls Du wirklich umcodieren willst, geht das auf dem RasPi eventuell per omxtx in Hardware:


    https://github.com/dickontoo/omxtx


    Gruss, ollo

  • [Gelöst] rpihddevice & Raspbian Stretch - EGL/OpenVG Fehler

    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

  • [Gelöst] rpihddevice & Raspbian Stretch - EGL/OpenVG Fehler

    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