Posts by Grillbert

    Ich denke auch, dass ich ein "hakeliges" Umschalten beim ändern der Auflösung aktuell besser wäre als permanent UHD vom VDR ausgeben zu lassen.
    Wenn jeder 2. Sender UHD bringt könnte das natürlich anders aussehen, aber zur Zeit ist ja nur ausnahmsweise mal ein UHD Sender eingeschaltet - zumindest bei mir.

    Dasselbe Verhalten fände ich auch super für den Switch zwischen unterschiedlichen Bildwiederholraten ... oder ist das Verhalten da schon so?

    (Memory Leak Fix finde ich aber auch wichtiger) :)

    Grillbert Also die Version mit vaapi dekoder sollte stabil sein solange du kein UHD schaust. Bei UHD gibt es noch Probleme mit Speicherverlust.

    Wenn ich mir deinen Footer anschaue dann empfehle ich dir die drm Version weil die sehr wenig resourcen braucht und ohne X server läuft.


    Mir ist schon klar das der WAF nötig ist, aber man muss sich auch mal durchsetzen können :-)

    Inzwischen läuft mein VDR mit einem J4105m (muss mal die Signatur updaten). Das Board hat etwas mehr Power und sollte auch UHD ohne Wandler direkt ausgeben können.

    Macht sich der X Server denn wirklich negativ bemerkmar in Sachen Performance? Bzw. was wird besser im DRM Modus? Reaktivität der Oberfläche?

    Und (bestimmt eine "dumme Frage" hier im Thread) welche der Versionen nutzt eigentlich OpenGL zum Zeichnen der Oberfläche? (Oder gibt es das nur für Nvidia?)

    Gruß,
    Gilbert

    Danke, scheint auch bei mir den WAF wieder zu erhöhen :)

    Das klingt doch sehr gut :)
    Danke an jojo61 für den Einsatz - MEGA!!


    Leider habe ich bei mir keinen Test-VDR und ein hoher "WAF" ist überlebenswichtig für den (Zitat) "Nerd Kram" im Wohnzimmer.

    Was funktioniert denn inzwischen und wo hakt es noch? Ist das Plugin inzwischen reif für einen Intel-basierten "Familien" - VDR?

    Ich habe ein Beispiel von dem modifizierten VDR-live:

    ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i <input> -map 0:v -map 0:a:0 -vf 'deinterlace_vaapi=rate=field:auto=1,scale_vaapi=w=1280:h=720' -c:v h264_vaapi -preset slow -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2 -b:v 2M -maxrate 2M -bufsize 1.8M

    So läuft es bei mir für Live-TV Streaming.

    ffmpeg mit HW encoding support läuft bei mir auch noch nicht so lange.

    Hallo zusammen,
    inzwischen habe ich ein funktionierendes FFMPEG gefunden.
    Das ganze klappt mit VAAPI wenn man das Binary von FFMPEG 4.2 aus diesen Repositories installiert:


    Code
    1. # add-apt-repository ppa:savoury1/ffmpeg4
    2. # add-apt-repository ppa:savoury1/graphics
    3. # add-apt-repository ppa:savoury1/multimedia


    Damit läuft Hardware-Encoding mit meinem Intel System (J4105M) mit den weiter oben vorgeschlagenen Configs rund:


    Code
    1. ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -i <input> -map 0:v -map 0:a:0 -c:v libx264 -preset ultrafast -qmin 18 -vf scale=1280:720 -qmax 30 -g 25 -r 25 -c:a aac -ac 2


    CPU Last von FFMPEG ist damit drastisch geringer als mit der CPU Variante (hier ging der Wert für 1080i Sender bis 180% hoch).


    Code: INPUT: ARD 720p
    1. top - 11:40:12 up 15 min, 2 users, load average: 2,26, 3,09, 2,18
    2. Tasks: 186 total, 1 running, 120 sleeping, 0 stopped, 0 zombie
    3. %Cpu(s): 9,2 us, 9,0 sy, 0,5 ni, 75,3 id, 4,6 wa, 0,0 hi, 1,4 si, 0,0 st
    4. KiB Mem : 7809196 total, 5615688 free, 929956 used, 1263552 buff/cache
    5. KiB Swap: 2097148 total, 2097148 free, 0 used. 6393916 avail Mem
    6. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    7. 1915 vdr 20 0 4264584 434576 66036 S 20,6 5,6 3:27.91 vdr
    8. 6751 vdr 20 0 1096840 78572 41400 S 19,6 1,0 0:07.49 ffmpeg


    Code: Input: QVC HD 1080i
    1. top - 11:41:25 up 16 min, 2 users, load average: 1,86, 2,83, 2,16
    2. Tasks: 186 total, 2 running, 119 sleeping, 0 stopped, 0 zombie
    3. %Cpu(s): 4,8 us, 5,5 sy, 0,7 ni, 80,4 id, 7,4 wa, 0,0 hi, 1,2 si, 0,0 st
    4. KiB Mem : 7809196 total, 5559216 free, 941908 used, 1308072 buff/cache
    5. KiB Swap: 2097148 total, 2097148 free, 0 used. 6337540 avail Mem
    6. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    7. 1915 vdr 20 0 4254316 442044 66016 S 18,5 5,7 3:42.62 vdr
    8. 7029 vdr 20 0 1090560 81744 40680 R 16,6 1,0 0:03.03 ffmpeg


    Damit bin ich erst mal glücklich und freue mich wenn wirklich auch noch eine Möglichkeit für das Abspielen von Aufnahmen kommt...

    Zuzsätzlich zum Abspielen von Aufnahmen wäre es *MEGA* wenn man einfach transcodierte Aufnahmen herunterladen könnte.

    Schönen 3. Advent allerseits,

    Grillbert


    Aus den Quelltext wird das Paket vdr-plugin-softhdvaapi gebaut und das hat vor ein paar Monaten hat es auf meinem Haswell-System funktioniert...


    Man muss auf jeden Fall noch in der /etc/X11/xorg.conf.d/20-intel.conf in der ersten Section "Device" eine Zeile Option "DRI" "3" einfügen, und https://raw.githubusercontent.…-softhdcuvid/master/drirc als /var/lib/vdr/.drirc hinterlegen, damit das Plugin funktionieren kann (die zusätzlich in softhdcuvid jetzt mit VAAPI support von mir beschriebene Anpassung für das yavdr-frontend sollte nicht mehr nötig sein).


    Falls es da noch irgendwo hakt, würden mich interessieren, was das Plugin da so in den Logdateien von sich gibt.

    Bisher lief mein System gut auch mit dem ganz normalen softhddevice auf intel.
    Wenn ich die von Dir beschriebenen Vorraussetzungen erfülle und vdr-plugin-softhdvaapi installieren will bekomme ich ein


    Code
    1. Die folgenden Pakete haben unerfüllte Abhängigkeiten:
    2. vdr-plugin-softhdvaapi : Hängt ab von: vdr-abi-2.4.1-0yavdr ist aber nicht installierbar
    3. E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.


    Wie kann ich den Konflikt auflösen?

    Hier mal mein Versuch Video Transcoding mit GPU unterstützung zu nutzen:
    Ich habe zum Testen die Handy Variante von UWE67 genommen:


    Code
    1. /home/myhome/ffmpeg/ffmpeg-4.2.1-amd64-static/ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i <input> -map 0:v -map 0:a:0 -vf 'deinterlace_vaapi=rate=field:auto=1,scale_vaapi=w=640:h=360' -c:v h264_vaapi -preset slow -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2 -b:v 0.3M -maxrate 0.3M -bufsize 0.3M


    Ich verwende dasselbe Mainboard (J4105M von Asrock) allerdings läuft der VDR bei mir nicht Headless.
    Einen Test mit Frontend detached habe ich aber auch schon probiert - klappt auch nicht. Im Log landet folgendes (Nach einem Umschaltvorgang):



    Problem ist anscheinend, dass ffmpeg in der statischen variante die weiter oben angegeben war ohne vaapi Unterstützung gebaut wurde.
    Das kann man herausfinden mit:

    Code
    1. ffmpeg -buildconf


    Mir fehlt hier die Zeile:

    Code
    1. --enable-vaapi

    Auch diese beiden Version führen bei meinem Ubuntu (yavdr ansible) nicht zum gewünschten Ergebnis...


    https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-4

    https://snapcraft.io/ffmpeg


    Kennt jemand eine geeignete Quelle für ein Binary?

    Wenn man FFMPEG auch ab bestimmten Positionen Transkodieren lassen kann, dann würde ich einfach das bereits transkodierte bei jedem Sprung oder Pause verwerfen (und löschen). Wenn das zuverlässig klappt ist das ja schon mal super.

    Schön wäre wenn auch in einer laufenden Aufnahme die Wiedergabe durchläuft. (ich glaube KODI kann das inzwischen auch - könnte aber Tricky sein weil man FFMPEG beim start ja sicher alle Dateien die wiedergegeben werden sollen übergeben muss...)


    Wie der Player (mit EPD darunter) bei mir in Chrome aussieht habe ich angehängt.

    Leider klappt Transcoding auf meinem Intel System noch nicht so richtig. Das poste ich später mal separat.

    Noch eine kurze Frage: Ist das Login von live eigentlich einigermaßen sicher?
    Also wäre es kritisch einfach per Port-Forwarding Port 8008 auf den VDR weiterzuleiten?

    Gruß,
    Grillbert

    Gibt es denn auch Bestrebungen das Webstreaming auch für Aufnahmen zu ermöglichen ?

    Weiter oben wurde das auf jeden Fall erwähnt - ich hoffe dass das noch implementiert wird....
    Habe auch gestern das Plugin auf meinem YaVDR Ansible installiert und es läuft auf Anhieb schon mal sehr gut!

    Mit FFMPEG (habe mir auch eine aktuelle Version geladen) werde ich dann demnächst mal experimentieren um zu schauen wie gut GPU Transcoding auf meinem Intel Board läuft.

    Super Projekt auf jeden Fall - Vielen Dank!!

    Damit der VDR ein Plugin lädt, muss es eine passende Konfigurationsdatei in /etc/vdr/conf.d/ geben - vgl. https://www.yavdr.org/document…mentation.html#org35d6058

    Danke!
    Dazu musste ich noch das Binary umbenennen und beachten dass live standardmäßig einen anderen Ordner für Ressourcen verwendet, aber dann lief es.
    Zusätzlich braucht man noch ein aktuelles Binary von FFMPEG (muss nicht zwingend installiert sein).

    Ist einen Blick wert - interessantes Projekt!

    Ich hoffe mit dem aktuellen FFMPEG und GPU-Transcoding endlich ordentlich von "außen" auf meinen VDR zugreifen zu können...
    Bisher war mein Fritz-VPN immer einen tacken zu langsam für HD.

    Hallo,
    wie installiere ich bei yavdr ansible ein selbstgebautes Plugin??
    Ich wollte gerne dieses weiterentwickelte live plugin testen:

    vdr-live-plugin HTML5 Web-Streaming

    Nach dem Bau habe ich ...

    Code
    1. cp libvdr-live.so /usr/lib/vdr/plugins/
    2. cp -a live . /var/lib/vdr/plugins


    ... gemacht und den vdr neu gestartet.

    Mein Plugin Verzeichnis sieht jetzt so aus:


    Code
    1. root@vdr:/usr/lib/vdr/plugins# ls
    2. libvdr-dbus2vdr.so.2.4.0 libvdr-dvbapi.so.2.4.0 libvdr-live.so libvdr-osd2web.so.2.4.0 libvdr-softhddevice.so.2.4.0 skindesigner
    3. libvdr-desktop.so.2.4.0 libvdr-epg2vdr.so.2.4.0 libvdr-markad.so.2.4.0 libvdr-pulsecontrol.so.2.4.0 libvdr-tvguideng.so.2.4.0
    4. libvdr-devstatus.so.2.4.0 libvdr-femon.so.2.4.0 libvdr-menuorg.so.2.4.0 libvdr-skindesigner.so.2.4.0 libvdr-vnsiserver.so.2.4.0

    Hallo Ralf,
    hast Du das Problem noch lösen können?

    Das sich die durch Suchtimer generierten Timer doppeln kenne ich gut - und das war auch schon bei verschiedenen Installationen (Distributionen) bei mir zu beobachten... Ich vermute dass da ein Bug in den beteiligten Plugins ist.

    Sollte es ein Konfigurationsproblem sein bin ich brennend interessiert woran es liegt!

    Gruß,
    Gilbert

    Hallo zusammen,
    ich verfolge hier die Entwicklung und frage mich ob es irgendwelche qualitativen Vorteile bietet (außer UHD) die Ausgabe von Yavdr Ansible (Standardinstallation) auf meinem Gemini Lake Intel System auf das Ausgabeplugin aus diesem Thread umzustellen...
    Vor allem: Sind die letzten Versionen alltagstauglich?

    Man sagt zwar "Never Change a Running System", aber nachdem mein neuer Verstärker jetzt wie mein TV UHD-tauglich ist, juckt es schon ein bisschen wieder zu basteln...

    Ich hatte mal den Gedanken das STM32 basierte Projekt von JRIE (eigentlich ein IR Empfänger) um ein kleines OLED zu ergänzen.
    Das könnte man ohne zusätzliche Power an USB betreiben und sogar Informationen als Reaktion auf IR Befehle
    (nächster Timer, geplante Startzeit) anzeigen, ohne den VDR hochfahren zu müssen... Das fand ich ganz charmant weil ich doch ab und an wissen möchte ob das Abendprogramm programmiert ist oder nicht.

    Liegt alles zu Hause - es fehlt nur die Zeit ;)
    (und davon bräuchte ich viel weil ich jetzt nicht der Profi-Bastler bin und mir vieles erarbeiten müsste)

    Klicke in die debug messages , kopiere alles und füge es in einen Editor ein und poste das bitte.

    Zusätzlich poste bitte auch das Ergebnis von "get eeprom", "save file".


    Soweit ich es jetzt beurteilen kann habe liegt der Fehler bei mir ...
    Die map die ich oben gepostet habe war nicht identisch zu dem was ich ausgelesen habe.
    Hier waren Codes mehrfach vergeben und es wurde der 1. Eintrag genommen - "Works as Designed".

    Besten Dank für die schnelle Unterstützung!

    • Bei gestopptem eventlircd (systemctl stop eventlircd.{socket,service}) mit evtest (sudo evtest) nachsehen, welche Tasten vom Empfänger kommen, wenn du die rote Taste auf der Fernbedienung drückst.
    • Mit der von evtest angezeigten Nummer des Input Device kannst du dann seine Udev-Attribute abfragen:
    Code
    1. Event: time 1565624314.088079, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7004d
    2. Event: time 1565624314.088079, type 1 (EV_KEY), code 107 (KEY_END), value 1
    3. Event: time 1565624314.088079, -------------- SYN_REPORT ------------
    4. Event: time 1565624314.096039, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7004d
    5. Event: time 1565624314.096039, type 1 (EV_KEY), code 107 (KEY_END), value 0
    6. Event: time 1565624314.096039, -------------- SYN_REPORT ------------


    Das ist schon mal ein anderer Key als ich ihn definiert habe.
    Für die grüne Taste funktioniert es interessanterweise korrekt...


    In der Ausgabe von



    Code
    1. Event: time 1565624315.456035, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
    2. Event: time 1565624315.456035, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
    3. Event: time 1565624315.456035, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70008
    4. Event: time 1565624315.456035, type 1 (EV_KEY), code 18 (KEY_E), value 1
    5. Event: time 1565624315.456035, -------------- SYN_REPORT ------------
    6. Event: time 1565624315.464029, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
    7. Event: time 1565624315.464029, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
    8. Event: time 1565624315.464029, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70008
    9. Event: time 1565624315.464029, type 1 (EV_KEY), code 18 (KEY_E), value 0
    10. Event: time 1565624315.464029, -------------- SYN_REPORT ------------


    Ich vermute die 2 Events kommen für keypress und keyrelease ...

    In der Ausgabe von

    Code
    1. sudo udevadm info --query=all --attribute-walk --name=/dev/input/event1

    finde ich gar keinen Treffer auf "lircd":