Soll ich ein eigenes Repo erzeugen oder macht es Sinn, das in Dein Repo vom Plugin dazuzupacken?
Mach mal ein eigenes Repo. Das ist ja nur ein Anwendungsfall. Für alle SoC's, Distros solche Scripte zu pflegen ist nicht möglich.
Posts by zillerbaer
-
-
1080i Sender (Anixe HD und Servus TV) gehen auch nicht, was für mich weniger das Problem wäre. Für HD+ Sender zahle ich nicht.
Diese Sender gehen hier mit Anlaufschwierigkeiten. Der Decoder geht erstmal in ein timeout, besinnt sich dann und startet. Ich nutze hier aber Gentoo. Die Debian Abkömmlinge reagieren dagegen recht zäh und langsam. Das kann ein runtime Problem sein. Der FFmpeg Code für v4l2m2m ist aber auch eine Katastrophe! Das sich da jetzt jemand drüber macht und das lauffähig macht ist toll! Da heisst es das git im Auge zu behalten und die neuesten Entwicklungen zu testen.
-
Alles neu installiert, und was soll ich sagen ...der selbe Schei.....
Vielleicht liegt es ja doch am Material was Du abspielst. So das Raspi Internetzugriff hat sende doch mal:
Dann solltest Du den Live Stream von ARD sehen. Wenn Du keinen Internetzugriff hast spiel doch mal ein H264 decodiertes Mediafile über den Mediaplayer ab!
-
Also ist da auch einer von den beiden genannten Chips drin fürs deinterlacing?
Da ist ein rk3399 drauf. Der Treiber arbeitet sicher mit mehr SoC. Ich habe aber nur RK3399 und RK3288 hier und kann nur diese testen.
-
Hat es schon jemand mit einem ROCKPro64 versucht?
Darauf habe ich mein Haupt VDR aufgesetzt. Eine DD Cine Karte steckt im PCIe. Ein 2x90W Verstärker komplettiert mein Setup.
-
Kansst du was damit?
Vorbildliche Bugbeschreibung, einfache Lösung, schnell fertig. Im git sollte das Problem behoben sein.
-
Leider segfault vdr, das wird noch geloggt:
#0 0x0000007fa1c5acac in ReadBit () at softhddev.c:804
Der Decoder will Höhe und Breite des Materials haben. Darum parse ich das aus dem Stream. Das scheint mit dem Mediaplayer nicht zu funktionieren da das kein TS Stream ist. Ich schau mir das an.
-
Bring das erstmal richtig zum laufen! Du kannst dazu auf Deinem jetzigen Stand bleiben. Neu dazu gekommen ist nur Raspi4 Zeugs. AW H3 betrifft das nicht. Ich schreib softhddevice-drm jetzt nicht um oder integriere Patches ohne zu wissen das das auch Mehrwert hat. OSD GL sollte schon spürbar schneller sein als die aktuelle Implementierung.
-
Das Du kein H264 auf dem Raspi4 decodieren kannst kann ich nicht nachvollziehen. Hier läuft es ohne Probleme. AW und bald Rockchip haben einen HW Deinterlacer. Ob und wann der auf Raspi kommt kann keiner sagen. Ich will nur deutlich ausdrücken das auch auf diesen Chipsätzen SW Bastelei notwendig ist.
-
Das da jetzt auch gleich der passende Kernel drin ist rundet das Ganze natürlich ab
Um Kernel neu aufsetzen wirst Du bei den meisten Boards nicht herum kommen. LE hat viele Patches die andere Distributionen nicht haben.
Fernbedienung ist meistens kein Problem. Ein IR Empfänger auf ein GPIO Pin Deiner Wahl und fertig. SW seitig kommst Du um Basteln nicht herum.
-
Das verstehe ich nicht! Erst wird es aus allen Treibern rausgeschmissen und jetzt will sunxi das wieder einführen?
Was Deinen Code betrifft, neuer Code sollte sich in den bestehenden einpassen. Nicht den bestehenden funktionierenden Code so grossflächig umschreiben. Ist das notwendig? Ohne alles verstanden zu haben würde ich das so nicht akzeptieren. Welcher branch funktioniert jetzt?
-
Ich schau mir das erst mal genauer an. Du hast ja eine ganze Menge umgemodelt. Dazu kommt das zpos aus dem mainline Kernel entfernt wurde und eine neue Lösung gefunden werden muss.
-
Bei Rockchip tut sich was. Ich teste gerade den neuen Treiber für den HW Deinterlacer. Auf RK3399 und RK3288 läuft der momentan hier.
-
Das ist leider noch nicht bei allen durchgedrungen, [sic] Patches per Fax brauchen nun mal länger.
Wir sind hier nicht beim Gesundheitsamt! ;-))
-
Was noch hackt ist Sound über HMDI, da es bei der MLD kein pulseaudio gibt.
Wozu wird pulseaudio benötigt? softhddevice-drm nutzt nur Alsa!
-
Ich verstehe, ihr rettet jetzt was noch zu retten ist. Danke!
-
Ja, der Raspi4 hat mich da auch positiv überrascht, sorry for offtopic.
Ein RK3399 ist da noch schneller!
-
Das Raspi4 ist schneller als mein alter Schlepptop. Ich mache das direkt. Bei einem armv7 SoC kann crosscompile noch sinnvoll sein.
-
Ein Armbian als Einstieg macht natürlich Sinn. FFmpeg und Kernel müssen aber meist getauscht werden. Ein guter Einstieg ist da wieder das LE git.
-
Wo das gepflegt wird ist eigentlich egal. Wichtig wäre m.E. das Plugins einen Maintainer haben und gepflegt werden und man nicht im Forum verstreute Patches suchen muss. Wo der aktuelle Code zu finden ist kann dann im Wiki gepflegt werden. Dort sollte auch stehen ob plugins gepflegt werden oder verwaist sind.
