Cubieboard - gute Raspberry Pi Alternative?

Servus,

ich hab so ein Teil. Nahezu baugleich mit Mele A2000/A100/A1000. Basieren alle auf dem SoC A10 von Allwinner.
Insgesamt ist die Basis ziemlich hackerfreundlich, da unbrickable. Bootet von SD-Card.
Das SoC hat eine integrierte GPU (Mali 400) und Allwinner-eigene VPU (CedarX) zur Videodecodierung. Das Problem an der Sache ist nicht die Hardware, sondern die Software. Mit der Hardware kannst du so ziemlich alles anstellen (GPIOs etc.), softwareseitig gibts sehr gute Kernel Unterstützung aus der community, work in progress!
Allerdings sind die für einen Mediaplayer entscheidenden Parts closed-source. Die OpenGL ES Treiber von ARM liegen nur als binarys und nicht als Quellcode vor, ebenso gibt es von der CedarX-Engine nur binarys, die zudem ein paar bugs zu haben scheinen. Das ganze, gepaart mit der "schwierigen" Kommunikation mit dem chinesischen Hersteller Allwinner, hemmt die Freude der Developer am Entwickeln etwas. Insbesondere die XBMC-Entwicklung steht derzeit still.

Nichtsdestotrotz läuft bei mir ein VDR Server als Streaming-Server auf dem A10-Chipsatz mit angeschlossenen USB-Karten stabil.
Außerdem regiert hier eine Mele A100 als Client. VDR über XBMC-PVR. Das ganze ist zwar noch ausbaufähig was die Performance betrifft, ist aber benutzbar.
Die SD-Karte für das Cubieboard werde ich demnächst fertig machen....

Die Benutzung als VDR-Client ohne den Umweg über XBMC scheitert derzeit allerdings am fehlenden Ausgabe-Device. Weder z.B. vdrsofthddevice noch vomp-client, noch libva oder openmax unterstützen CedarX derzeit. Ich bezweifle, dass sich hier etwas ändern wird, solange die Source-Politik von Allwinner sich nicht öffnet bzw. die Verbreitung von A10 und Nachfrage nach VDRable - Software nicht steigt.

Imho hat das A10-SoC hardwaremäßig alles was man für einen VDR oder XBMC braucht. Allein die Software ist das Problem.

Gruß Andreas

PS: Leider habe ich es immer noch nicht geschafft, meine A10s hier etwas genauer vorzustellen. Vielleicht klappt das ja noch....

Das Cubieboard wurde ja hier im Portal schon andiskutiert:
Alternative zum RasPi?

Weil aber die eine Hälfte der User im Portal es für eine geile Idee hält, im Thread-Titel ihrer eigenen Threads nicht den Namen des Produktes reinzuschreiben, über das sie diskutieren wollen, und die andere Hälfte der User nicht die Suchfunktion benutzt, gibt es oft mehrere Threads zur selben Hardware und das Wissen darüber wird nicht gebündelt.

Zugegebenermaßen gefällt mir aber das Einstiegsposting von cinfo in diesem Thread ziemlich gut, schön mit Infos, Links und Bildern. Vorbildlich!

Viele Grüße
hepi

Danke hepi,
den Thread hab ich ja ganz links liegen gelassen. Da sieht mans mal was der Titel ausmacht.

Gruß
Andreas

Zusatz:
Die Benutzbarkeit der Allwinner-SoCs würde sich extrem steigern, wenn jemand Fähigkeiten, Zeit und Lust hat, für CedarX ein libva-plugin zu schreiben....
Damit sollte eine Vielzahl von Playern, insb. softhddevice-plugin nutzbar werden.
Ein A10-Development-Board könnte ich zur Verfügung stellen.

Gruß
Andreas

Da müsste man die Autoren von vomp fragen, ob sie sich das mal ansehen wollten.
Zielführender fände ich, sich das mit libva anzusehen, da darauf andere Programme aufsetzen können.
Eigentlich bräuchte man imo "nur" einen Wrapper um die binarys ?!

Gruß
Andreas

Was meinst du mit "laufen"? Die Header lassen sich schon installieren, aber was bringt das?
Es fehlt das Driver-Backend für CedarX.
Gruß Andreas

Hm, bin zwar nur ein Laie, aber ich stelle mir das so vor:

VDR -> Ausgabe-Device (vdrsofthddevice/vomp/xbmc) -> libva/vaapi -> libva-cedarx-driver -> libcedarx.so (Binary)

Es gibt bereits Implementierungen für xbmc und vlc, die libcedarx.so direkt oder über einen eigenen wrapper ansprechen. Siehe:
XBMC für A10 (empatzero)
XBMC für A10 (huceke)
VLC für A10 (willswang)

Ein Anfang wäre also schon gemacht.

Gruß Andreas

Ok. Also ich spreche von hardwareunterstützter Dekodierung. Mag sein, dass wir aneinander vorbei reden.

Wie liefert der VompServer den Stream? Schafft der VompClient die Dekodierung und Ausgabe softwareseitig, oder wird die Hardware genutzt. Funktioniert HD? Das geht mit Sicherheit nur über Hardwaredekodierung.
Und wenn dem so ist, muss der Client ja irgendwelche Bibliotheken oder die Engine direkt ansprechen, auch beim RPi.
Also für A10 eventuell über den Weg von libva:

vompclient (-> libva/vaapi -> libva-cedarx-driver) -> libcedarx.so

Weil Vomp auch so eine Speziallösung ist, wäre m.E. das Vernünftigste für ein natives VDR-Ausgabe-Plugin:
VDR -> vdrsofthddevice -> libva/vaapi -> libva-cedarx-driver -> libcedarx.so (Binary)

Es fehlt libva-cedarx-driver. Hätte man diesen, könnte auch XBMC / VLC / XINE etc. davon profitieren.

Bei mir läuft derzeit:
PVR VDR-Addon -> XBMC(A10) -> libcedarx.so
Das läuft, aber ist halt eine XBMC-spezielle Implementierung von cedarx und spricht libcedarx.so direkt an. Vomp macht da ja auch irgendwie sein eigenes Ding und nutzt imo keine Standards.
Oder hab ich einen Denkfehler?

Gruß Andreas

Zitat

richtig aber cdr VompClient ist aber schon ein gutes "Frontend" um HDTV zu schauen und um auf Aufnahmen etc.. zugreifen.
XBMC steht hier nicht so sehr um Fokus da könnte doch auch alles über vnsi oder xvdr gehen.

Das Streamen ist das eine. Das geht schon mit vnsi, wäre auch das kleinere Problem mit vomp.

Zitat

So wie es ja auch der Allwinner bei den Android-Tab´s mit Mali Support macht.

Mali = GPU, CedarX=VPU
Das Problem ist die VPU, die sich um das Decoden von mpg2, h264 etc. kümmert.
Bei Android ist CedarX in den Player integriert. Bei Linux gibts nur das Binary, das sich darum kümmert. Auch vomp müsste die lib ansprechen, wenns hardwareseitig laufen soll. Und bei deinem Vorschlag bräuchte es erst eine libva-Schnittstelle von vomp und dann den Anschluß an cedarx. Da wäre der Weg von VDR über softhddevice oder xineliboutput kürzer.

Korrigier mich bitte. In jedem Fall wird es an jemanden scheitern, der das Ding programmiert

Gruß Andreas

Zitat von hepi

Das Cubieboard wurde ja hier im Portal schon andiskutiert:
Alternative zum RasPi?

Weil aber die eine Hälfte der User im Portal es für eine geile Idee hält, im Thread-Titel ihrer eigenen Threads nicht den Namen des Produktes reinzuschreiben, über das sie diskutieren wollen, und die andere Hälfte der User nicht die Suchfunktion benutzt, gibt es oft mehrere Threads zur selben Hardware und das Wissen darüber wird nicht gebündelt.

Hepi hat natuerlich recht, ich hab' den Titel mal geaendert...

Also zur Anpassbarkeit von vomp an dieses Board kann, ich folgendes sagen. Ihr solltet, wenn video und audio und osd objekte für diese Hardware schreiben, mit direktem Zugriff auf die Hardwareapi. Die Dokumentation kann allerdings als dürftig bezeichnet werden, da wird viele wie av sync schwierig. Auch frage ich mich warum keine Industriestandards eingehalten werden.
Ein Implementiere wäre möglicherweise machbar (aber es ist nicht sicher ob es gut genug dokumentiert ist), aber die Frage ist ob es sich lohnt, also wie lange wird das Gerät am Markt sein. Außerdem müßtet ihr jemand finden der das Implementieren möchte. Ich sehe da wenig Sinn schließlich gibt es mit der raspberry pi zur Zeit eine gute und verfügbare Lösung, die wegen der guten Dokumentation sicher immer besser werden wird, außerdem hält sie sich an viele Industirestandards.

Vomp hält sich im übrigen sehr wohl an Standards, wenn dies möglich ist. Im Fall der raspberry pi ist das OpenVG, OpenMax IL ( das sind die typischen Schnittstellen im embedded Bereich. libva ist eine reine Desktop Sache) und dann leider ein paar VideoCore spezifische Dinge, aber die können wenn andere Geräte, die diese Schnittstellen verwenden kommen leicht in Objekten oder Abfragen gekapselt werden.

Marten