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

    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

    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

    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