in der 5.14 soll es wohl drin sein, habs aber nicht ausprobiert.
LE hat aufgegeben weil im Kernel nix voran geht.
Posts by zillerbaer
-
-
Mmmh, das baut auf dem proprietärem Hersteller Kernel auf. Da kann niemand sagen wie lange das gepflegt wird. Weiss jemand wie weit die Mainline Kernel Unterstützung ist?
-
Unverschlüsselt und kostenfrei gibt's das auch nicht! Welche Inhalte verbreitet werden ist die nächste Frage.
-
Was wäre denn aktuell DIE arm-Box die am besten unterstützt wird? Am liebsten bereits von yavdr-Ansible…
Die fertige Lösung gibt es nicht! Die aktuelle HW Unterstützung habe ich in dem Post zusammen gefasst. ARM VDR Distributionen sind mir auch keine bekannt. Hier ist eine Beschreibung wie vorgegangen wird.
-
Aber ein NUC hat halt auch seine vorteile bzgl. größe und Strombedarf.
Eine ARM Lösung ist in puncto Größe und Strombedarf nicht zu schlagen. Da kann weder Intel noch AMD mithalten. Das Bild ist genauso gut und neutral. Bei meinen TV's kann pro HDMI Steckplatz eine Einstellung abgespeichert werden. Vieleicht hilft das weiter?
Hochgerechnetes SD sieht bestimmt immer noch mies aus....
Da ist aber viel dem Anbieter anzulasten. Bei Eurosport sieht man das gut. Die Sportsendung sieht sehr bescheiden aus aber kaum kommt Werbung ist das Bild gut!
-
Ich vermute, dass die fehlenden Videodaten bei Dir dazu führen, dass das Plugin sich beim Versuch, Bild und Ton zu synchronisieren, irgendwie totrechnet.
Ganz so schlimm ist es nicht. Der Videothread arbeitet auf einem Kern. Dadurch geht auf einem Kern die Last auf 100%.
Die Erkennung, ob ein Stream Audio-only ist, habe ich damals mit einer Prüfung gelöst, ob zuerst Daten in PlayVideo oder PlayAudio ankommen. Ein Audio-only-Stream beginnt immer mit einem Audio-Paket. Zumindest war das früher bei mpeg2 so
Dann werde ich mir auch sowas einfallen lassen müssen.
Danke und Gruss
zille
-
Ich habe heute eine Bugmeldung erhalten das bei Radioempfang die CPU Last hoch geht. Beim Untersuchen habe festgestellt das vdr PlayMode pmAudioVideo sendet. Das sollte aber in dem Fall pmAudioOnly sein! Oder verstehe ich da was falsch?
Gruss
zille
Edit: getestet habe ich mit vdr-2.4.6.
-
Wenn Du ein bissel Bastelei nicht schäust wäre ein RockPro64 eine gute Alternative.
-
Da sehe ich keine Chance das zu integrieren. Atmo will ein RGB Bildformat das nicht zugänglich ist. Das Bildmaterial ist in YUV Formaten, die meistens noch eine Hersteller spezifische Sortierung der Pixel hat. Diese Herstellerformate kennt FFmpeg nicht so das eine Konvertierung nicht möglich ist.
-
Das Atmo Plugin braucht irgendwelche Daten. Wie müssen die aussehen? Was sollen die beinhalten?
-
Die Schnittstelle wird von softhddevice-drm nicht bedient. Ich werde mal schauen wie hoch der Aufwand ist das zu integrieren. Was wird dazu benötigt?
-
jsffm , ich kann das theoretisch nicht nachvollziehen. Eigentlich sollte das Sorting wie es Johns geschrieben hat stimmen. Da Du das aber getestet hast und es keine andere Meinung gibt habe ich Deine zweite Variante eingecheckt.
-
Wo läuft es problemloser, flüssiger?
Flüssig laufen beide. Auf meinem BananaPi M2 ist aber ein Quartz verlötet der zu schnell taktet. Dadurch läuft die Uhr zu schnell und die Bilder werden schneller verarbeitet als der Stream reinkommt. Die Wiedergabe bleibt stehen und startet wieder wenn in der Queue wieder Daten sind.
-
wenn Du es entspannt haben willst, dann nimm doch einen NUC.
... einfach, ... Energieverschwendung, zu groß! Mein Rockpro64 läuft seit einem Jahr stabil als Haupt VDR. Eine DD Cine versorgt mit SAT, ein im Gehäuse eingebauter 2 x 90W Verstärker befeuert die KLEINEN Teufelchen ;-). Das Kistchen macht in der Stube alles was mit Multimedia zu tun hat. Es gibt bei mir kein weiteres Gerät.
Diese Diskussion sollten wir aber in einem anderen Thread fortführen.
-
(ich meine das deinterlacing)
Einen HW Deinterlacer Treiber gibt es nicht!!! Deinterlaced werden kann nur MPEG das in SW decodiert und deinterlaced wird. Siehe.
auch das ändert nichts. Hatte auch zur Sicherheit vor dem ffmpeg bauen nochmal die Kernel header installiert
Ein Log würde vielleicht helfen.
-
dann ohne den rpi patch?
Ja, das ist in dem git bereits enthalten.
-
Für Ffmpeg verwende den 4.3 Branch von hier:
Ich wollte vorhin ffmpeg-4.3.2 mit dem rpi patch versehen. Das hat nicht geklappt. Daraufhin habe ich https://github.com/jc-kynesim/…ree/dev/4.3.1/drm_prime_1 benutzt. Dort passiert die Entwicklung für das RPI. Das funktioniert hier gut.
Hast Du auch die Kernel Header installiert nach dem Kernel Update? Das ist notwendig vor ffmpeg compile!
-
Das patchen von ffmpeg-4.3.2 hat hier auch nicht funktioniert. (?!) Das git funktioniert nach wie vor. Aufgefallen ist mir das Du Kernel 5.10.0-v7l+ benutzt. Das ist zu alt! LE benutzt 5.10.27 und ich habe hier 5.10.33-v7l. Das Kernel solltest Du zuerst erneuern.
-
ist das richtig:
Das sieht schon seltsam aus. Hier steht da:
Code- ldd /usr/lib/vdr/plugins/libvdr-softhddevice-drm.so.2.4.5 | grep libav
- libavcodec.so.58 => /usr/lib/libavcodec.so.58 (0xb5d82000)
- libavfilter.so.7 => /usr/lib/libavfilter.so.7 (0xb5b05000)
- libavutil.so.56 => /usr/lib/libavutil.so.56 (0xb53f2000)
- libavformat.so.58 => /usr/lib/libavformat.so.58 (0xb4ffd000)
Aber wenn in dem Pfad die richtige FFmpeg Version liegt sollte das funktionieren. Liegt unter /lib/arm-linux-gnueabihf/neon/vfp/ die richtige Version?
FFmpeg reagiert nicht wie erwartet. Eigentlich sollte Video_get_format aufgerufen werden. Statt dessen wird das decodierte Bild im falschen Format ausgegeben und fälschlicherweise der VideoFilter aufgerufen. Ich bringe hier FFmpeg auf dem Raspi auf die neueste Version und teste das.
-
nun hängt ich hier:
Lass Dich nicht rumhängen!
Schalt bitte DEBUG und CODEC_DEBUG im Makefile ein und poste das Log.
