Interessantes ARM-Board für USD 25,- / Raspberry Pi

Zitat

Sehr geehrter Herr naicheben,

Vielen Dank für Ihr Interesse an unserem Produkt.

Sie können bei Farnell als Gewerbetreibender oder Student bestellen.

Schicken Sie uns hierzu entweder Ihren Gewerbeschein oder aktuelle Immatrikulationsbescheinigung ( einfach einscannen und auf diese Email antworten ).

Als Privatperson ( kein Student oder Firma ) können Sie das Rapsberry PI – Art.-Nr. 2081185 nur über das Farnell Export Department beziehen.

Bitte beachten Sie, dass pro Bestellung nur 1 Stück verkauft werden kann.

Die Lieferzeit beträgt momentan ca. 4 Wochen.

Unten stehend finden Sie die Kontaktdaten:

http://export.farnell.com

Email:eesales@farnell.com,

Tel: +44 870 1200 208

Alles anzeigen

Von RS

Zitat

Dear Customer

Thank you for joining the Raspberry Pi revolution and registering your interest in Raspberry Pi’s Model B board from RS Components.

We have received extraordinary levels of demand for this product. To help ensure as many people as possible can experience the Raspberry Pi concept, we are limiting boards to one per customer, and we will send you further information on your request in the next seven days. Once we receive the boards into stock, they will be allocated on a first-come first-serve basis, in order of when requests were received.

Thank you for your patience; we will be in touch as soon as possible with more details.

Alles anzeigen

Zitat von raoul

kann das sein, dass man nur als Selbstständiger bei Farnell bestellen kann?

Ich hatte mal als Privatperson bei Farnell bestellt und wurde da an die folgende Firma weiter vermittelt.

Zitat

Heinz Büchner Elektronik,
Messtechnik, med. Elektronik e.K.
Greifenhagener Str. 22
10437 Berlin
www.HBE-Shop.de

Alles anzeigen

Hat alles problemlos funktioniert. Mit Mindermengen-Zuschlag und Märchensteuer lag ich da letztendlich nur 2 EUR über dem Farnell Angebot (höhere VK als HBE).

Konnte meine Bestellung gerade tätigen.
£32,70
Entspricht 39,21 Euro

Warum es nun doch so viel gekostet hat weiß ich nicht. Habe die Sache nicht mehr so weit verfolgt.

Konnte auch eben bei Farnell, zum gleichen Kurs wie decembersoul bestellen. Kommt wohl mit gratis (Werbe-)T-Shirt als Entschädigung für die Wartezeit.

Wurde denn schon ein XBMC (+PVR) oder ein VDR auf dem Board zum Laufen gebracht?

Zitat von Cybso

Wurde denn schon ein XBMC (+PVR) oder ein VDR auf dem Board zum Laufen gebracht?

https://github.com/xbmc/xbmc-rbp

die MLD http://minidvblinux.dyndns.org/site/cont_index.php?cms_id=918&main_id=5&sub_id=918 ist auch dafür vorbereitet. Testen konnte ich das aber noch nicht und eines der ersten Bords habe ich auch nicht abbekommen
Ich würde mich aber über jeden freuen der das testet und eventuell hilft die letzten Feinheiten anzupassen.

Claus

Ich werd das auf alle Fälle testen sobald ich mein Board habe. Bestellung konnte ich bei Farnell am WE absetzen.

Ich möchte das Board erstmal als streamdev-client nutzen, bin schon gespannt ob das so funzt.

Gruß - Markus

Zitat von clausmuus

die MLD http://minidvblinux.dyndns.org/site/cont_index.php?cms_id=918&main_id=5&sub_id=918 ist auch dafür vorbereitet. Testen konnte ich das aber noch nicht und eines der ersten Bords habe ich auch nicht abbekommen
Ich würde mich aber über jeden freuen der das testet und eventuell hilft die letzten Feinheiten anzupassen.

Claus

Werde ich auch mal testen. Habe zwar mein Buildsystem auch schon vorbereitet aber ich teste gerne was Du gemacht hast.
Welches Frontend hast Du genommen?
Ich glaube es gibt ja noch keines welches OpenGL ES 2.0 kann.
Zumindest die libxine auf der xineliboutput und das xine plugin beruhen.

//EDIT
sehe gerade da das xineliboutput plugin drinnen ist.

Hier mal ne Alternative zum Pi

http://openelec.tv/forum/20-de…0--arm-based-distribution

Wie ich finde sogar noch einiges interessanter aber auch etwas teuerer

cu sky

Hi,

Zitat

Hier mal ne Alternative zum Pi

habs gerade mal überflogen und fast die Krise bekommen
Wie kann man nur!

Auf der einen Seite wird geworben mit

Zitat

2160p Hardware-accelerated Video playback (4x the resolution of 1080p)

und dann hats nur für 100 MBit Netzwerk gereicht.
Was soll das denn? So teuer kann GBit doch nimmer sein!

Also ich würde sagen: Idee auf halbem Wege verreckt.

Gruß Gero

Ja Gigabit wär wirklich schön gewesen aber ansonsten find ich nicht viel was mir hier fehlt

Aktuell sollte aber für alles was man so streamt 100 MBit reichen blos beim rumkopieren wird es etwas lam

cu sky

decembersoul,

ja, ich verwende bisher hauptsächlich xineliboutput. Ich hoffe ja noch, dass dies zumindest für SD TV gehen wird. Und wer weiß, vielleicht haben wir ja Glück und softhddevice unterstützt demnächst auch OpenGL ES. Geplant ist das ja schon mal.
Als alternative Frontends gibt's bei der MLD noch xbmc-pvr und VLC, die beide OpenGL ES unterstützen. Wobei ich zugeben muss, das VLC in der aktuellen Version eher nicht so geeignet ist, weil sich das gerne mal beim Umschalten erhängt. Wenn ich erst selbe nen RPI habe und es dann noch immer keine Alternative gibt werd ich mir wohl die mühe machen und ne VLC Version raussuchen die auch als VDR Frontend stabil läuft.

Claus

Leider wird sich xine nicht so leicht auf den Raspberry PI portieren lassen.

Mal grundsätzliches. Am PI wird OpenMAX für die Video/Audio decodireung/ausgabe verwendet und GLES fürs Rendering.

In OpenMAX wird eine Kette mit OpenMAX Komponenten für die Bearbeitung der Daten aufgebaut. Dies kann eine reine Decodierung von Audio/Video sein, oder eine komplette Kette bis zur Ausgabe bilden. Für die Synchronisierung von Audio/Video verwendet OpenMAX eine eigene Clock welche unter den Komponenten geshared ist.

Prinzipiell könnte man nur das reine Decodieren am PI verwenden, die Daten aus dem Decoder holen und dann mit GLES rendern. Leider geht das aus Performance gründen nicht. Somit lässt man OpenMAX alles erledigen.

Zum Rendering stehen mehrere Planes zur Verfügung. Wenn man OpenMAX bis zur Ausgabe verwendet, kommen zwei Planes ins spiel :

Plane 1.) Videoausgabe durch die OpenMAX Komponente.
Plane 2.) GLES rendering des OSD.

In xine lässt sich das ganze nun nicht so einfach implementieren. Der Teil zum rendern des OSD ist noch der simple Teil. Die Integration der OpenMAX Komponenten wird schon etwas schwieriger. Die gemeinsam benutze Clock in OpenMAX wird zum eigentlichen Problem. in xine ist es nicht so einfach Daten zwischen dem Video und Audio Decoder zu teilen. Das musste ich schon leidvoll bei der VAAPI implementierung für xine feststellen.

Warum ich nun das ganze weiß ist ganz einfach. Zum einen habe ich schon Erfahrungen mit xine gesammelt ( VAAPI ), zum anderen habe ich den XBMC Port auf den PI ( plus omxplayer ) gemacht.

Der wirklich gangbare weg für den PI ist eine eigenständiges VDR Frontend. Das softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt. Was es schon von vorne herein für einen stabilen VDR betrieb disqualifiziert ( meine Persönliche Meinung ).

lg

ebsi

Zitat von ebsi

Das softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt. Was es schon von vorne herein für einen stabilen VDR betrieb disqualifiziert ( meine Persönliche Meinung ).

Prinzipiell gebe ich dir Recht. Allerdings zeigt die Praxis mit dem Softhddevice, dass es relativ robust ist. Zumindest scheint auch ein im Betrieb gestoppter X-Server es nicht aus der Ruhe zu bringen.

Gerald

Zitat von ebsi

softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt

Die im softhddevice Wiki genannte Client/Server Methode reicht nicht?

Gruß
iNOB

Na ja, das ist dann doch ein wenig was anderes, als nen vom VDR los getrenntes Frontend.
Auch ich muss ebsi Recht geben. Nen vom VDR getrenntes Frontend wäre auch mir lieber. Aber solange das Frontend den VDR nicht abstürtzen lässt ist's nur zweitrangig.

Claus

Zitat von ebsi

Leider wird sich xine nicht so leicht auf den Raspberry PI portieren lassen.

Mal grundsätzliches. Am PI wird OpenMAX für die Video/Audio decodireung/ausgabe verwendet und GLES fürs Rendering.

In OpenMAX wird eine Kette mit OpenMAX Komponenten für die Bearbeitung der Daten aufgebaut. Dies kann eine reine Decodierung von Audio/Video sein, oder eine komplette Kette bis zur Ausgabe bilden. Für die Synchronisierung von Audio/Video verwendet OpenMAX eine eigene Clock welche unter den Komponenten geshared ist.

Prinzipiell könnte man nur das reine Decodieren am PI verwenden, die Daten aus dem Decoder holen und dann mit GLES rendern. Leider geht das aus Performance gründen nicht. Somit lässt man OpenMAX alles erledigen.

Zum Rendering stehen mehrere Planes zur Verfügung. Wenn man OpenMAX bis zur Ausgabe verwendet, kommen zwei Planes ins spiel :

Plane 1.) Videoausgabe durch die OpenMAX Komponente.
Plane 2.) GLES rendering des OSD.

In xine lässt sich das ganze nun nicht so einfach implementieren. Der Teil zum rendern des OSD ist noch der simple Teil. Die Integration der OpenMAX Komponenten wird schon etwas schwieriger. Die gemeinsam benutze Clock in OpenMAX wird zum eigentlichen Problem. in xine ist es nicht so einfach Daten zwischen dem Video und Audio Decoder zu teilen. Das musste ich schon leidvoll bei der VAAPI implementierung für xine feststellen.

Warum ich nun das ganze weiß ist ganz einfach. Zum einen habe ich schon Erfahrungen mit xine gesammelt ( VAAPI ), zum anderen habe ich den XBMC Port auf den PI ( plus omxplayer ) gemacht.

Der wirklich gangbare weg für den PI ist eine eigenständiges VDR Frontend. Das softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt. Was es schon von vorne herein für einen stabilen VDR betrieb disqualifiziert ( meine Persönliche Meinung ).

lg

ebsi

Alles anzeigen

Freut mich das wir jemanden hier haben der sich damit auskennt.
Ich habe auch die Hoffnung das sich jemand findet der das softhddevice für die Ausgabe auf dem pi board flot macht.
Client/Server ist zwar nett aber für ein embedded gerät nicht zwingend erforderlich.

Oups - hab mich gerade fast nass gemacht

Zitat von decembersoul

Unterschätze nicht die Datentransferrate
eines mit Festplatten beladenen LKWs

LOL - wie geil ist das denn
Ich seh schon - GBit Ethernet war gestern