Posts by rell

A64, H3, H5, H6.

Die älteren können H265 hardwareseitig nicht.

Gruß

Andreas

zillerbaer wrote:

So weit ich das verstanden habe wird ffmpeg benutzt. So sollte softhddevice-drm damit klarkommen.

Sollte so sein, habs aber selber noch nicht ausprobiert. ffmpeg sollte imho das von hier sein: https://github.com/Kwiboo/FFmp…4l2-request-hwaccel-4.0.4

Und ein aktueller Kernel sollte es natürlich sein...

Falls es jemand probieren möchte, helfe ich gerne bei Problemen.

Gruß

Andreas

zillerbaer wrote:

Ich habe noch nicht richtig verstanden was geändert wurde. Aber ich bin der Meinung das die Änderungen Kernel intern zwischen v4l und den HW Implementirungen ist. Im user space hab ich noch keine Änderungen gefunden.

Naja, so wie ich das verstanden habe, wurde schon etwas verändert, da wie gesagt die RequestAPI eingebaut wurde. Bzw. ist das noch nicht im Kernel, sondern soll in den 4.20er wandern. Dsa Patchset liegt hier: https://git.linuxtv.org/hverku…ia_tree.git/log/?h=reqv16
Darauf basiert auch der aktuelle Cedrus Treiber. Im Beispielprogramm wird z.B. dieser ioctl https://github.com/bootlin/v4l…t/blob/master/v4l2.c#L724 aufgerufen, der damit erst eingeführt wurde. Insofern wäre der V4l2 Treiber für die reinen M2M decoder im FFMPEG anzupassen - oder eben man geht derweil den Umweg über libva-v4l2-request.

Quote

Hat er auch was zu HW Deinterlacing gesagt?

Nur zu!

Gruss zille.

Nein, der ist dafür nicht zuständig. Ich habe nur nachgefragt, wie denn der einzubauen wäre. Wie ich das sehe, müsste man den Deinterlacer für A10/A20 wohl im drm Kerneltreiber miteinbauen, da der Teil des Scalers ist. Für H3/H5 etc. würde es ausreichen, den vorhandenen Treiber in ein v4l2 m2m-device umzuschreiben... Hört sich allerdings nach Arbeit an, obwohl da zumindest Beispiele vorhanden wären...

Gruß
Andreas

zillerbaer wrote:

Allwinner nutzt bei Kodi libva als frontend zu ffmpeg. Das sollte einfacher gehen über den v4l2 HW Decoder in ffmpeg. Ich werde das mal probieren.

Gruss zille

Das wird daran liegen, dass das libva-v4l2-request Backend genutzt wird, das ja auch mit dem Kernel Treiber zusammenpasst, der die neue Request API nutzt.

Ohne den v4l2 Decoder in FFMPEG an die Request-API anzupassen, wird das wohl nicht gehen.

Am besten wäre es natürlich, wenn alle Programme direkt V4L2 nutzen, aber das ist ein bißchen Arbeit. In der Zwischenzeit gibts den "Umweg" über libva-v4l2-request. Der Autor von libva-v4l2-request hat mir gerade gesagt, dass das Backend relativ vollständig implementiert ist. Dann gibts die Hoffnung, dass dein softhddevice-drm gar nicht so großartig angepasst werden müsste.

Gruß

Andreas

PS: Ich überlege mir gerade, ob ich nicht mal wieder meinen OpenGL/ES Code für das OSD auspacken sollte. Das würde das ganze ja toll ergänzen, wenn man das auf ein zweites drm-plane schiebt ...

Hi zillerbaer,

ich habe eine Verständnisfrage zu softhddevice-drm: Die Frames werden direkt über drm dargestellt, richtig?

Und wer decodiert? FFMpeg? Dann wäre es ja ähnlich der Kodi-Implementierung für Allwinner...

Gruß

Andreas

zillerbaer wrote:

Der A20 unterstützt H265 nicht. Wenn ich das richtig überblicke sind die SOC's die das Projekt beinhaltet alles alte Teile. Ob da einer H265 unterstützt weiss ich nicht.

Der H3 kanns z.B. Für TV ohne DVB-T reichen somit noch die alten...

Quote

Kannst Du probieren. DRM halt ich für das bessere Konzept. Ist halt noch ein bissel Arbeit notwendig

Gruss zille.

Habs damals nicht mehr verfolgt, aber hattest du da nicht schon mal was geschrieben? Für Raspberry oder Amlogic oder was war das gleich?

Jedenfalls wirds jetzt wieder interessant, da nun auch mali mit blobs bzw. lima im Ansatz wohl läuft, das ganze zusammenzupacken. Die kodi implementation soll ja mit zerocopy und den drm planes direkt arbeiten...

Gruß
Andreas

zillerbaer wrote:

H265(HEVC) unterstützt dieser Decoder nicht. H264 sollte laufen. Einen Treiber für den Deinterlacer vermisse ich!

Gruss zille

H265 kommt noch... Und ja, leider hat sich noch niemand den deinterlacer vorgenommen... Ich schau mir den neuen Code zusammen mit VDR demnächst auch mal an... vaapidevice wäre dann wohl der Einstieg, oder?

Gruß Andreas

jsffm wrote:

H264 and H265 are not supported (some of the underlying problems include: allocating 19 surfaces at once and queueing several slices by frames)

Outdated.

Das betrifft den allerersten PoC Treiber von Florent Revest.

Gruß

Andreas

Ich gehe davon aus, dass Bootlin (vormals Free- Electrons) das mit der VPU auch bis Sommer hinbringt. Zwei Leute sind dafür abgestellt (inkl. Maxime Ripard, einer der Maintainer). Voraussetzung für einen erfolgreichen Merge wird aber sein, dass von Seiten v4l2 auch die Request API soweit ist, dass sie in den kernel wandern kann. Aber da ist momentan auch Bewegung. Da wartet wohl unter anderem auch Rockchip darauf...

Display Treiber inkl. HDMI ist für A10/A20 seit 4.15 drin, H3/H5 wird voraussichtlich in den 4.17er Kernel wandern.

Fehlt noch der Treiber für die Mali-GPU. Die ist momentan mit aktuellen Kernels und den ARM-Blobs nutzbar. Der freie Lima-Treiber (Basis Mesa 17.3) wird gerade entwickelt und kann zumindest schon die kmscube Demo mit Texturen. Wenn das noch irgendwann klappt, hätte man wirklich eine Hardware-Basis, die ausnahmslos mit Open Source Software und dem aktuellen Kernel arbeitet. Ich denke, dass die Allwinner dann immer noch hardwaretechnisch für VDR (und Kodi) in Frage kommen...

Andreas

Und was bringt dich zu der Meinung? Verfolgst du die Entwicklung aktuell?

Gruß

Andreas

Falls es jemandem weiterhilft, ich hatte die Shader damals an OpenGL/ES angepasst und die Version 100 hinterlegt. Hat funktioniert.

Habe es aber natürlich etwas auf die verfügbaren Funktionen umbauen müssen, siehe hier

Gruß

Andreas

Den Logeintrag kannst du ignorieren. Der weist nur auf eine fehlende API Funktion in libvdpau-sunxi hin. Weiß nicht genau welche, aber zumindest keine, die die grundsätzliche funktion beeinflusst.
libump brauchst du, wenn du deinen Speicher über den UMP allokieren wolltest. Deshalb das USE_UMP=1. Ist aber nur notwendig, wenn du den Speicher auch mit Mali ansprechen wolltest, d.h. Video Frames mit OpenGL/ES verarbeiten möchtest. Stichwort softhddevice-openglosd.

Freut mich, dass es läuft. Wenn Probleme auftauchen, einfach melden. Tester sind rar...

Gruß Andreas

Out würde ich nicht sagen. Für VDR reicht die Hardware allemal und das wird auch noch länger so bleiben.
Hier läuft seit gut 2 Jahren ein Cubieboard2 als Client. Derzeit mit https://github.com/rellla/libv…nxi/tree/upstream_next_v5.
Habe eigentlich nur Ausfälle, wenn auf das kistchen die Sonne scheint. Dann gibts Hitzestreik. Ansonsten keine größeren Probleme, die den Produktiveinsatz bremsen würden. Allerdings habe ich auch ein spartanisches Setup. Nur VDR Client mit softhddevice und schlanken Plugins.
Wenn deine Kiste zu sehr rödelt, kann es schon sein, dass irgendwo ein Flaschenhals den VDR ausbremst. Der staging branch ist schon sehr alt. Kann durchaus sein, dass der ein paar Macken hat

Gruß
Andreas

oder

Gruß Andreas

Zille wrote:

Cubietruck wär ein Anfang. Am liebsten auf allen Systemen.

Ist in Arbeit: https://github.com/mripard/linux/commits/sunxi/a10-hdmi bzw. https://github.com/net147/linu…linuxino-lime-drm-wip-ccu
In den kommenden Kernelversionen sollte da dann was fest im Kernel sein, Patches für A10s und HDMI wurden bereits in drm-next gemergt, soweit ich weiß, der Rest sollte eine dts Sache sein.

Quote

Für Videodecoding sollte auch eine Linux Schnittstelle unterstützt werden. Anstatt das jeder Hersteller eine eigene Bibliothek erstellt wäre V4L2 oder FFmpeg der richtige Ansatz.

Wurde begonnen, aber es müsste sich einer finden, der das weiter macht... https://github.com/FlorentRevest/linux-sunxi-cedrus

^ Nur für den Fall, dass du dich wieder an Allwinner austoben willst - jetzt aber mit Mainline Kernel Leider dauerts halt noch, um das wirklich nutzen zu können.
In der Zwischenzeit hat auch jemand den Original cedar Treiber auf aktuellen Kernel portiert - allerdings müsste man in libvdpau-sunxi den Display Part umgeschreiben, um das nutzen zu können. Ich weiß aber nicht, ob ich mir das noch antun will...

Und Mali - wie gesagt, wenn man etwas Arbeit investiert, kann man das auch mit aktuellem Kernel zum laufen bringen... Aber das würde ich hinten anstellen, da es beim VDR wirklich nur für opengl-osd interessant ist.

Gruß
Andreas

Zille wrote:

Ich hoffe das Projekt bekommt mehr Unterstützung. Nach meinen Erfahrungen muss ein solches Projekt der Hersteller unterstützen. Siehe VC4 und Rockchip. An IMX6 arbeiten viele fleissig dran, aber so richtig voran geht es nicht. Wir Verbraucher sollten nur Zeugs kaufen was vom Hersteller mit Treibern versorgt wird bzw. die Entwicklung unterstützt wird.

Ack. Leider wird das bei Mali nicht so kommen, da ARM bisher alles versuchte, um solche freien Treiber zu verhindern. Da gehört Mali bisher nicht dazu! Ich hoffe, bezweifle aber, dass der Entwickler ein längeres Rückgrat als ARM hat...

Quote

Mali ist eine 3D Einheit. Simples DRM/KMS würde mir schon reichen.

Auf welchem System?

crow wrote:

Brauchen wir Mail Treiber überhaupt? Auf cnx-software Seite wurde etwas über S912 geschrieben und LibreELEC user @kszaq welche community image für S905x baut hat folgendes dazu geschrieben:

Im Falle VDR derzeit nur für softhddevice-openglosd. Wie zille sagte, Mali ist eine 3D Einheit und hat nichts mit Video Decoding zu tun.

Gruß
Andreas

P3F wrote:

Allerdings sollte IMHO nicht ein weiteres Informationsablage analog dem VDR Wiki angelegt werden. Schließlich gibt es schon Übersichten welche Plugins zu welcher VDR Version getestet sind WIKI. Dort sollten wir weiter die Dokumentationen vornehmen, wie schon von mehreren vorgeschlagen. Klar ist das auch eine Selbstdisziplin von uns selber.

Stimmt. Dann sollte die Plugintabelle im git verlinkt werden!?

Gruß
Andreas

fnu wrote:

Wäre es nicht sinnvoller eine "Liste" zu pflegen, mit Dingen die generell im Gebrauch sind und auch wirklich aktiv gepflegt werden, d.h. nutzbar sind?

Eine aktuelle Liste wie http://vdr-wiki.de/wiki/index.php/Plugins an zentraler Stelle im Repo fände ich gut. Allerdings getrennt nach Plugins, die wirklich genutzt werden und diejenigen, die keinen interessieren.
Dann noch eine ToDo Spalte, wo eingetragen werden kann, was denn entwicklertechnisch zu tun wäre. Ich fände die Benennung von konkreten Aufgaben gut, um potentielle Teilzeitentwickler anzulocken. Z.B. mich. Würde schon reichen, wenn der Zusatz "kompatibel zu 2.3.* machen" da stehen würde.
Ich weiß, wieder viel Arbeit, aber nur eine Idee von mir.

Gruß
Andreas

fnu wrote:

Umso mehr ich drüber nachdenke, umso unverschämter finde ich tatsächlich jegliches Ultimatum. So, wie es jetzt umgesetzt ist, finde ich "http://vdr-projects.github.io" bei näherer Betrachtung anmaßend, einfach mal eben alle VDR Projekte dahin zu spiegeln, mittels Gruppenzwang Druck aufzubauen und dann die hierarchischen Spielregeln akzeptieren zu müssen ...

Sehe ich anders. Ich sehe weder Druck noch Gruppenzwang noch Ultimatum. Ich finde das Gespiegle auch nicht unverschämt. Ich sehe eine m.E. berechtigterweise angestossene Diskussion um die Zukunft des gesamten Projekts mit offenem Ausgang und zunehmend aggresiver werdende Stimmung. Warum das so ist, weiß ich nicht.

Quote

Richtiger wäre gewesen, diese "http://vdr-projects.github.io" zu erstellen, die Owner zum Mitmachen einzuladen und nur mit deren Zustimmung zu spiegeln! Wenn der/die alten Owner sich nicht melden, hätte geschaut werden müssen, ob sich jemand findet der einen Fork (!) aktiv in der Wartung übernimmt und dieser auch als solcher gekennzeichnet wird. Hierarchische Entscheidungswege darf es hier gar nicht geben. Das ist z.B. bei einem Projekt wie LibreELEC/OpenELEC was anderes, die Lösung ist ein komplettes Paket ...

Sich bis wann nicht meldet? War das nicht erstmal so angedacht, wie du beschreibst? Und warum ein fork und keine branch?

Quote

Auf "http://vdr-projects.github.io" dürfen nur Projekte vorhanden sein die aktiv gepflegt werden,

s/aktiv gepflegt werden/funktionieren/ und ich stimme dir zu.

Quote

z.B. vom ursprünglichen Owner, wenn dieser einverstanden ist mit der Spiegelung oder eben ein Fork von jemand anderes. Projekte wo der Owner nicht teilnehmen möchte, müssen nicht teilnehmen, kein Gruppenzwang.

Es kann nicht sein das hier jetzt die Erwartungshaltung herrscht, das Plugin ist (ohne Nachfrage) auf "http://vdr-projects.github.io" gespiegelt worden, jetzt müssen Anpassungen oder Patches reinlaufen, weil die Community das so möchte. Es kann gar keine Interessen einer Community in dieser Form geben.

Jeder Entwickler hat seinen Workflow, den gilt es ohne wenn und aber zu respektieren, siehe Diskussion mit Klaus und er hat recht.

Es herrscht doch keine Erwartungshaltung nur weil ein Plugin gespiegelt wurde!? Ich persönlich spiegele Projekte wann und wie ich will, solange es die Lizenz zulässt. https://projects.vdr-developer.org/git/vdr.git/ ist doch auch nichts anderes? Ist das schlimm? Klaus, stört es dich, dass es dieses Repository gibt?

Leider habe ich das Gefühl, dass das ganze Projekt nicht an den Interessen der Community scheitert. Ich vermisse die "Community"...

Gruß
Andreas

Gegen ein reines Mirroring von projects.vdr-developer.org/git spricht m.E. erstmal gar nichts. Bleibt zu überdenken, ob bzw. welche Vorteile Github als reines Spiegelungssystem überhaupt bringt.

Mir fallen spontan folgende Dinge ein, die ich beim derzeitigen Frontend als Teilzeit-Git-User vermisse/ nicht so gut finde:
1) einfaches forken, über die Weboberfläche -> patch erstellen -> pull request stellen
2) einfache Möglichkeit, repo-übergreifend branches zu vegleichen, diffs anzuzeigen etc.
3) generell einfacher zu handhabende Kommentier- und Anzeigefunktionen ...

Schlechter finde ich an Github, dass ich noch nicht herausgefunden habe,
4) wie man eine schöne Repo-Übersicht der Organization bekommt und die nach idle-time sortiert [EDIT: Ähhm, ich glaube das macht er wohl doch automatisch ... :)].

Man kann es natürlich den Entwicklern nicht vorschreiben, wo sie ihr plugin entwickeln, daher finde ich es auch nicht nachteilig, wenn es bei einem Mirror bleibt. Das war ja erstmal der Grundgedanke. Die Vorteile der pull requests per Mausklick hat man dann halt nicht. Ich würde das ganze aber auch nicht überinstrumentieren.

Den Entwicklern etwas vorzuschreiben oder sie mit einem Reaktionszeitlimit unter Druck zu setzen halte ich für nicht gut. Allerdings muss die Frage schon erlaubt sein, was mit plugins passiert, bei denen Jahre lang nichts passiert ist https://projects.vdr-developer.org/git/?s=idle&ofs=50 ... Es wäre schade, wenn sich Leute finden, die zumindest Kompatibilitätspatches erstellen, und die dann im Nirgendwo verschwinden. Es kann doch nicht nachteilig sein, solche Dinge zumindest in einem Branch zu sammeln!? Ich selbst habe mal für mich versucht, alle softhddevice forks in einem Github-Repo zu sammeln, nur um einen Überlick über den Sachstand zu bekommen. Das muss doch auch moralisch in Ordnung sein. Abgesehen davon, dass es die GPL sowieso erlaubt.
Der nächste Schritt wäre dann immer der Versuch, Kontakt zum Entwickler aufzunehmen und ggfs. den Patch anzubieten. Über welchen Weg auch immer. Wird er abgelehnt, auch gut. Es wird Gründe dafür geben. Reagiert über einen (wohl doch irgendwie zu definierenden) langen Zeitraum niemand auf Anfragen, würde mein Verstand sagen, dass dieser jenige das Kapitel plugin abgeschlossen hat. Ich halte es dann nicht für verwerflich, wenn der Allgemeinheit ein fork oder branch angeboten wird, den jemand anderes betreut. Nochmal, ich rede hier von vermeintlich "toten" Plugins. Bei "lebenden" ist die Vorgehensweise selbstredend vom Entwickler abhängig.

Lange Rede kurzer Sinn, ich finde die Idee Github an sich gut, auch wenns nur ein Spiegel ist. Trotzdem muss die Frage beantwortet werden, ob das projects.vdr-developer.org nicht auch könnte und man nicht mehr Verwirrung stiftet als es Vorteile gibt.
Egal wo, wenn man komplett sein will, müssen auch die release-by-tarball plugins rein. Wie z.B. http://vdr.schmirler.de/ etc.

Gruß
Andreas