Amlogic SOC Ausgabedevice für Odroid C1 & WeTek Play?

Hi,
schau mal bei diesem Link:

http://www.minidvblinux.de/for…66.msg50122.html#msg50122

Es ist scheinbar möglich mit Mali GPUs über sunxi ein softhddevice zu bauen.
Im Prinzip könnte man also beim Banana Pi spicken.

Wenn es mal ein voll funktionsfähiges Wetek MLD gibt, werde ich mir wohl auch eine besorgen.

Zitat von ichamthe1st

Es ist scheinbar möglich mit Mali GPUs über sunxi ein softhddevice zu bauen.

Nicht, dass ich den Thread ins offTopic bringen möchte, muss aber immer mal wieder was klarstellen: Die MaliGPU spielt für softhddevice auf sunxi devices überhaupt keine Rolle, da sie nur der 3D Beschleunigung dient. Und ja, softhddevice funktioniert auf diesen Boxen inzwischen sehr gut.

Gruß Andreas

Zitat von ollo

rell - Könntest Du mehr Details preisgeben? Sunix nutzt ja die CedarX VPU der Allwinner SOC. Die AmLogic SOC nutzen doch aber eine andere VPU?! Bohrt MLD das softhhddevice Plugin um libamcodec-Support auf? Das wäre ja super!

Sunxi:
- Video Engine (bekannt als CedarX, VPU, ...) des A10/A20 sorgt fürs hardwarebeschleunigte Dekodieren <- open source
- Mixer Processor (G2D) des A10/A20 sorgt fürs hardwarebeschleunigte 2D blitting/ filling <- open source
- Display Engine (Display Ausgabetreiber z.B. über HDMI) stellt das ganze dar <- open source
- Mali GPU (3D Engine für z.B. OpenGLES) wird bei libvdpau-sunxi/ softhddevice gar nicht genutzt. <- closed source!

Die Mali GPU wird z.B. bei XBMC benötigt, da XBMC das OSD 3D-beschleunigt darstellt. Da sich aber noch niemand an eine Implementierung von libvdpau-sunxi als decoder in XBMC gemacht hat und die "alten" Entwickler bzw. das TeamXBMC keine Lust haben mit Allwinner closed source binaries zu hantieren, gibts da auf Linuxseite keine Unterstützung für sunxi. Außerdem beachte man die offensichtliche Verletzung der GPL in den CedarX binaries (zumindest in den alten)!!

AmLogic: Habe ich keine Ahnung
MLD wird sich halt der entsprechenden Bibliotheken bedienen, die mit einer API angesprochen werden können. Ich glaube nicht, dass es da offene Software gibt. Welches Ausgabedevice oder welcher wrapper dann dafür genutzt wird, wissen die sicher

Ich hoffe, ich konnte die Sunxi Seite aufklären, obwohl ich das hier gefühlt schon öfter mal so geschrieben habe.
Aber da du der Threadstarter bist, habe ich auch kein Problem mit den hijacking

Gruß
Andreas

Inzwischen habe ich auch eine WetekPlay in Betrieb und eigentlich wäre der Weg zu einem schlanken Ausgabedevice à la rpihddevice kein allzu grosser: Amlogic stellt Bibliotheken zur Verfügung, welche direkt TS akzeptieren (ein einfaches Beispiel ist hier zu finden) - damit verhält sich die Hardware praktisch wie eine FF-Karte, was den Aufwand für ein Plugin, zumindest in der Theorie, in Grenzen hält.

Etwas prekärer schaut es auf der Grafikseite aus. Gemäss ARM unterstützt die Mali GPU zwar OpenVG, womit man den OSD-Teil vom rpihddevice praktisch 1:1 übernehmen könnte. Allerdings scheint Amlogic oder ARM bei den Treibern zu geizen und stellt das API nicht zur Verfügung ... somit fällt der GPU-Support fürs OSD schon mal ins Wasser. Auch die unbeschleunigte Darstellung via OpenGLES wird schwierig, da die in Openelec enthaltenen Userspace-Treiber für X11 geschrieben und die Framebuffer-Varianten nicht verfügbar sind.

Irgendwie schade, dass hier so viel unter Verschluss gehalten wird - es gibt keine offiziellen Repos für aktuelle Treiber, selbst OpenELEC bezieht die Sourcen über irgendwelchen Dropbox-Links. Die Leute von Wetek sind zwar sehr hilfsbereit und antworten rasch, aber auch sie scheinen der Geheimniskrämerei von Amlogic und ARM ausgeliefert zu sein.

Gruss
Thomas

Zitat von reufer

Etwas prekärer schaut es auf der Grafikseite aus. Gemäss ARM unterstützt die Mali GPU zwar OpenVG, womit man den OSD-Teil vom rpihddevice praktisch 1:1 übernehmen könnte. Allerdings scheint Amlogic oder ARM bei den Treibern zu geizen und stellt das API nicht zur Verfügung ... somit fällt der GPU-Support fürs OSD schon mal ins Wasser. Auch die unbeschleunigte Darstellung via OpenGLES wird schwierig, da die in Openelec enthaltenen Userspace-Treiber für X11 geschrieben und die Framebuffer-Varianten nicht verfügbar sind.

Ich blick den Unterschied zwischen den Ausgabedevices noch nicht und der Möglichkeit, wie sie Hardwarebeschleunigung nutzen.
Video ist klar. Aber OSD ...
Rpihddevice nutzt OpenVG für 2D beschleunigte Aufgaben um das OSD darzustellen? Welche Aktionen werden z.B. von OpenVG übernommen? Wie ist der Ablauf beim rpihddevice?

Zitat

Use GPU accelerated OSD: Use GPU capabilities to draw the on screen display.
Disable acceleration in case of OSD problems to use VDR's internal rendering
and report error to the author.

D.h. ,die GPU nimmt das VDR interne rendering ab? Was ist damit gemeint? Bzw. wo ist der Einstieg.
Und wie ist das im Vergleich zu softhddevice/ vdpau, wo ich meine mich inzwischen ein bißchen auszukennen. Teilweise :p

Und generell frage ich mich oft, was der Grund ist/war, nicht gleich auf VDPAU (wenn auch nur als "Wrapper") aufzusetzen und Board spezifische Backends zu schreiben statt programmspezifischen Ausgabedevices?
Danke für eine kurze Aufklärung.

Gruß Andreas

Wenn wirklich Bedarf besteht könnte man problemlos auch mal mit den Jungs von Wetek sprechen.

Die idlen z.B. im Kodi IRC unter dem Namen "wetek"

Zitat von rell

Ich blick den Unterschied zwischen den Ausgabedevices noch nicht und der Möglichkeit, wie sie Hardwarebeschleunigung nutzen.
Video ist klar. Aber OSD ...

Der VDR sieht grundsätzlich zwei Arten von OSD vor:

1) Das Low Level oder RAW-OSD: Der VDR Core implementiert alle Zeichnungsfunktionen welche die Skins aufrufen und zeichnet auf interne Pixmaps. Dabei muss er sich um Dinge wie Transparenz, Antialiasing oder auch nur schon das Rendern von Text selbst kümmern. Bei einem Flush liefert der VDR dem Ausgabedevice das fixfertig gerenderte OSD als Pixmap ("Bild"), welches von diesem nur noch dem Videobild überlagert werden muss. Das Ausgabeplugin muss sich dabei um keinerlei Rendering kümmern und überlässt alles dem VDR und somit der CPU. Die meisten Ausgabeplugins, u.a. auch softhddevice, nutzen diese Variante.

2) High Level OSD: Etwas komplizierter wird es, wenn die GPU das Zeichnen übernehmen soll. Dabei überschreibt das Ausgabedevice die Default-Implementation der Zeichenfunktionen und übergibt, im Falle vom rpihddevice, diese Aufgabe mittels OpenVG der GPU. Das beinhaltet nicht nur das Zeichnen der Grundformen (Pixel, Rechteck, Ellipse, Bogen) sondern auch das Darstellen von Text oder das Handling und Überlagern von verschiedenen Ebenen (Pixmaps). Das klingt aufwändig und ist es auch, bietet aber, gerade beim Raspberry Pi, nicht nur immense Geschwindigkeitsvorteile, sondern ist auch qualitativ der Default-Implementation des VDR überlegen. (perfektes Scaling und Anti-Aliasing) Das dvbhddevice unterstützt Zeichnungsfunktionen auf OSD-Ebene, High Level-Support auch für Pixmaps bietet - nach meinem Wissen - bisher nur das rpihddevice.

Zitat von rell

Und generell frage ich mich oft, was der Grund ist/war, nicht gleich auf VDPAU (wenn auch nur als "Wrapper") aufzusetzen und Board spezifische Backends zu schreiben statt programmspezifischen Ausgabedevices?

Der VDR hantiert "bloss" mit TS-Paketen und gibt diese ans Ausgabedevice weiter, damit ist die grundlegende Schnittstelle für Ausgabedevices cDevice::PlayTS() (und deren Varianten), wie sie auch HD-FFs unterstützen. Wenn nun die Amlogic-Treiber genau so eine Schnittstelle anbieten, warum sollte dann jemand den Umweg über vdpau gehen? Das mag für eine Desktop-Grafikkarte unter X11 sinnvoll sein, ist aber IMHO auf einem Embedded-Board der falsche Ansatz.

Zitat von ollo

Würde denn der OpenGLES X11 Treiber auch mit Wayland funktionieren? Das wäre deutlich schlanker als X11 und so ein möglicher Ausweg??

Keine Ahnung, damit kenne ich mich zu wenig aus. Aber X11/Wayland sind für mich bei einem solchen Projekt kein Thema (siehe oben).

Zitat von Copperhead

Wenn wirklich Bedarf besteht könnte man problemlos auch mal mit den Jungs von Wetek sprechen.

Der Kontakt zu Wetek ist nicht das Problem - die Leute dort sind schnell und hilfsbereit! Aber ich denke auch Wetek ist zu klein, um bei ARM/Amlogic in Sachen Treiber was zu bewegen...

Gruss
Thomas

Zitat von ollo

dann wäre also nicht-beschleunigtes OSD durchaus per framebuffer möglich?

Ja und nein - es braucht halt einen Weg, ein tansparentes OSD dem Videobild zu überlagern. "Nur" mit Framebuffer wird das kaum funktionieren...

Gruss
Thomas

Danke Thomas für die Erläuterung. Jetzt bin ich (etwas) schlauer :p

VDPAU war hier nur als Beispiel gedacht, eine standardisierte API zu nutzen. Wie ein (Embedded) Device dies dann im Backend umsetzt, ist dann die andere Sache. Im Falle von sunxi endet das zwar in einem sehr gut nutzbaren, aber halt nicht allzu schönem und arg workaround-artigem Hack
Im Umkehrschluß heißt das für mich jetzt, dass das High-Level OSD nur über VDR (falls irgendwann geplant), ein extra Plugin oder eben über das Ausgabeplugin selbst umgesetzt werden kann, das direkt die Klassen vom VDR Core überschreiben kann. Eine Implementierung im driver backend ist gar nicht möglich, weil das ja schon das fertige Bild erhalten muss. Bei softhddevice müsste man das also im Plugin selbst machen, wenn man es haben will.
Wäre es nicht generell sinnvoll das als vdr-plugin-openvg/... -osd auszugliedern und dann den Ausgabedevices zur Verfügung zu stellen?

Back to topic:
Man könnte den Amlogic sicher auch ohne High-Level-OSD nutzen, wenn die Hardware es ermöglicht, 2 Layer per alpha zu überblenden, so wie das bei den Allwinner geht. Das blitting (des fertigen Surface) klappt hier z.B. auch hardwarebeschleunigt.
Wenn man auf OpenVG verzichtet, wäre auch ein Weg über softhddevice denkbar, wofür allerdings ein eigenes libvdpau-backend notwendig wäre.

Gruß Andreas

Laut Beispiel kann Amlogic OSD mit Alpha.

Entweder werden Framebuffer 0 und 1 gemischt oder Framebuffer Inhalt mit Video.

Johns

Wegen der Wetek und dem Ausgabe-Plugin in der MLD, da ist ein kleines Missverständnis aufgekommen es ist ein Ausgabe-Plugin in Entwicklung aber noch nicht raus. Es wird auch noch eine weile dauern bis es da ist. Wollte das nur sagen weil ich mich da im MLD Forum ein wenig falsch ausgedrückt habe.

Zitat von ollo

Openelec ... nutzen auf der WeTeck Play offenbar Xorg zur Ausgabe.

Wie kommst du zu der Aussage? Ich kann gerade nicht selbst nachsehen, habe aber meine Zweifel.

Siehe hier:

# Displayserver to use (x11 / no)
    DISPLAYSERVER="no"

Gerald

Zitat von mafe68

Wegen der Wetek ... es ist ein Ausgabe-Plugin in Entwicklung aber noch nicht raus.

Cool, da freue ich mich schon drauf. Habe ein OdroidC1 hier rumliegen und könnte auch testen, falls bedarf besteht.

Viele Grüße, Uwe

Inzwischen habe ich keine Zweifel mehr. Da läuft kein X-Server in OpenELEC auf der Wetek. Es muss also auch ohne gehen.

Gerald