Hallo, Ich möchte gerne folgendes Projekt realisieren: An einem FPGA sind 3 CMOS Sensoren (5Mpix) sowie Speicher und Ethernet Schnittstelle angeschlossen. Von den Sensoren sollen die Bilder abgeholt, umgerechnet (mittels Lookup Table) und zu einem Bild zusammengefügt werden. Dieses Ergebnisbild soll dann zu einem Video komprimiert werden und über die Ethernet Schnittstelle gestreamt werden. Gibts vielleicht einen Spezialisten der mir da weiterhelfen könnte? Liebe Grüsse, Andreas
> Ich möchte gerne folgendes Projekt realisieren ... Was hast du bisher mit FPGAs gemacht? Welchen Zeitrahmen hast du?
hast du eine ahnung was fur eine grossenordnung es ist fur ein projekt? erkundige bitte zuerst die preise fur H.264 IP-Cores! ah die sensoren liefern micht MPEG, das ist schon eine hilfe, mit camera sensoren zu arbeiten ist kein grosses thema, wenn die digital raw daten liefern konnen Antti
Mein Lieblingsthema :-) alles ist möglich. Vom Preis her: ab 100.000,- eher mehr mit FPGA-Lösung. Weniger mit DSPs, da geht es vielleicht so ab 10 kEuro. Ohne Erfahrung vergiss die Sache ganz schnell. Ansonsten schreib' bitte, was Du genau suchst Grüße, Kest
Hi, Es gibt bereits Sensoren von Micron, die JPEG-Streams liefern. Diese verpackt man relativ wenig aufwendig in einen MJPEG-Stream. Allerdings faellt die Option der Vorverarbeitung dann weg, die muesste man dann auf dem Front End (Viewer auf dem PC?) machen. Allerdings wuerde ich davon absehen, die Video-Kompression ausschliesslich mit einem FPGA zu machen, die Kosten fuer die Entwicklung sind um Vielfaches hoeher als der Hardware noch einen DSP als Frontend zu spendieren. Falls die Bildrate gering genug ist, ergo 100MBit Ethernet von der Bandbreite ausreichend waere, kann ich fuer solche Jobs das Blackfin/uClinux-Gespann empfehlen. Ich denke, am effektivsten kommen man so zum Ziel (diese Meinung ist stark subjektiv und basiert auf Erfahrung mit bisherigen Projekten): 1) 'dumme', rechenintensive Vorverarbeitung auf dem FPGA: stitching, Entzerrung, DCT-Transformationen, etc. 2) intelligente Zwischenverarbeitung (Huffman Coding, Motion Compensation, etc.) auf einem Dual Core BF561 3) 'Verpacken und Versenden' des Streams auf einem BF527 per USB oder Ethernet mit uClinux Das Projekt allein waere schon eine rechte Nummer.. Meine Schaetzung: Budget: 60 k€ Dauer: min. 2 Mannjahre Vielleicht waere es die Option wert, die Cores alle einzukaufen, aber damit habe ich keine Erfahrung. Gruesse, - Strubi
60KEUR? mit FPGA alleine losung hatte ich ehe 200Keur gesehen (das mit allen IP-core einkaufen usw), tjah mann kann schon was einsparen... aber ein wochendprojekt fur FPGA ist es definitive nicht Antti PS 2 mannjahre ist ja auch >60K (nicht zu sprechen uber andere NRE kosten)
Hallo, Vielen Dank für die vielen raschen Antworten. Dass es sich nicht um ein Wochendprojekt handelt ist mir klar! Meine Erfahrungswerte beschränken sich hauptsächlich auf die Softwareentwicklung, ich habe also keine FPGA Erfahrung. Eines der wichtigesten Themen wird sicher sein, wie man sich die meiste Entwicklungszeit ersparen kann. Derzeit sind wir auf Investorensuche und bereiten das Webportal vor. Ein wesentlicher Bestandteil wird jedoch die Kamera sein und es wär wichtig, schnell eine vernünftige Lösung zu finden. Bezüglich Bezahlung müsste man sich im Detail was aushandeln, sollte Ruhm und Ehre in diesem OpenSource Projekt nicht ausreichen. Mir ist schon klar, dass sich das Projekt normalerweise bei mehreren Mannjahren bewegt. Allerdings hoffe ich eigentlich, dass wir im Netz passende Komponenten finden, welche die Entwicklungszeit reduzieren. Daher versuchen wir erstmal mit einer Elphel Kamera zu starten. In diesem Fall kann die Entzerrung auf dem 10539 Board für einen erfahrenen FPGA Entwickler doch nicht 2 Jahre in Anspruch nehmen, oder irre ich mich da? Also wie kann ich jemanden von Euch für das Projekt gewinnen? Seht es als Herausforderung! Nichts ist unmöglich. Bezüglich H.264, wer kennt von euch den H.264 Encoder MB86H55APBS-M-AE1 von Fujitsu? Wäre dieser eine Option? Vielen Dank an alle von euch
Ich kenn das Teil von Fujitsu und auch ein Paar andere. Die Sache ist, dass man nur wenn man hohe Stückzahlen alles wirtschaftlich machen kann. Dazu kommen dann solche Sachen wie Bildqualität, Latenz, Eval-Kits, "nicht"-Verfügbarkeit der Samples und so weiter und so fort. Für Ruhm und Ehre habe ich auch mal alles angefangen, leider habe ich dafür keine Zeit mehr. Um H.264 im FPGA zu lösen braucht man auch sehr große Bausteine, die alleine schon ein Paat Tausend Euro kosten, da muss man sich schon genau überlegen, was man tut. Auf dem Eiphel board H.264 zu implementieren halte ich für nicht möglich. Es wäre schon schön zu wissen, was außer Ruhm und Ehre dabei rauspringt ;-) Hängen da dran Stückzahlen? Ist es eine spezielle Anwendung, wo man keine konventionellen Kameras nehmen kann? Grüße, Kest
Hallo Kest! Es hängen keine großen Stückzahlen dran, es ist eine spezielle Anwendung. Komerziell verfügbare Kameras sind nicht unter 10k€ erhältlich. Die 300€ für den Fujitsu Chip wären daher verschmerzbar. Was ist mit dem hardh264 Projekt? Laut der Angabe benötigt es nicht so viele Resourcen, allerdings wird auch angegeben dass keine Inter-Frame Prediciton vorhanden ist. Dummerweise ist eine starke Komprimierung eine Vorraussetzung in diesem Projekt, weil das Ergebnis per Mobilfunk übertragen wird. Würdest Du also davon abraten den Encoder von Fujitsu zu verwenden? Liebe Grüße, Andreas
Also um Fujitsu Chip verwenden zu können bräuchte man erstma einen DevKit. Dazu noch Support und so weiter und so fort. Wenn es keine große Stückzahlen dran hängen, dann kannst Du es eigentlich vergessen, genauso bei anderen Chipherstellern, die Ähnliches machen. Was wir hier gehabt haben, waren Entwicklerkits für schlappe 15kEuro aufwärts (nicht Fujitsu). Die Leute mit H.264 suchen jemanden im Broadcast bereicht und nicht jemanden mit 100 Geräten im Jahr. Traurig, aber wahr. Fujitsu hat eine sehr hohe Latenz (500 ms), es kommen aber bald neue Chips raus. Auf der Embedded World habe ich ein Board mit Fujitsu gesehen, welches relativ simpel aufgebaut war. Allerdings stammte das Board nicht von Fujitsu selber, sondern von jemand anderem. Da an das Know-How ranzukommen ist sehr schwer. Das Problem ist halt hohe Auflösung. Wenn Du mit 720p oder gar PAL leben könntest, dann hättest Du sofort eine unendliche Auswahl. Ansonsten, schaue Dir DaVinci DSPs von TI an. Der Preis ist akzeptabel und die Zusatzsoftware (H.264) ist quasi schon da (kostet aber wohl extra). Dann bräuchstest Du noch was drumherum, ein bisschen (schwarze) Magie und schon hast Du deine H.264 Kamera... Kest p.s.: hab' natürlich alles vereinfacht dargestellt, so einfach ist es nicht ;-)
ach so: hardh264 habe ich nur kurz mal ausprobiert -> hat in einen sehr großen FPGA nicht reingepasst, da habe ich es sein gelassen (eigentilch wollte ich nur wissen, ob es möglich ist oder nicht). Andere IP-Cores sind sehr teuer. Den "preiswertesten" habe ich für 40kEuro angeboten bekommen (plus 100 Euro pro Greät), aber auch da müsste ich dann auf Arria GX 90 migrieren, war mir dann doch nichts :-/ Grüße, Kest
> weil das Ergebnis per Mobilfunk übertragen wird.
d.h. die Framerate ist sehr gering?
UMTS schafft im Upload ja nicht sonderlich viel.
Hallo, Mit HSUPA sollten 7Mbit/s upload möglich sein. Wenn das nicht ausreicht, muss das Video zwischengespeichert werden und später übertragen werden. Bezüglich TI DSP. Das scheint interessant zu sein, allerdings hab ich nicht rausgefunden ob man nun die $20000 für das Software Bundle bezahlen muss oder wie man diesen "Discount code" bekommt. Grundsätzlich ist es kein Problem drei einzelnde Videostreams zu codieren, wenn das viel einfacher und günstiger ist. Wegen dem hardh264, die schreiben doch dass das auf einen Xilinx Spartan passen sollte? Stimmt das nicht? Liebe Grüße, Andreas
> Wegen dem hardh264, die schreiben doch dass das auf einen Xilinx Spartan > passen sollte? Stimmt das nicht? bin jetzt nicht auf dem Laufendem, aber es hängt schon sehr von der Auflösung und der Größe der Makro-Blöcke ab. Wenn man 320x200 komprimiert, dann wird es schon reinpassen... vielleicht auch 640x480. Alles drüberhinaus ist von der Bandbreite her nicht trivial. Da brauchst Du schon DDR2 Speicher -> hohe Frequenzen -> kompliziertes Layout und so weiter... Grüße, Kest
Mit HSUPA ist geplant 5,8 MBit/s zu erreichen, nicht 7. Aber das nur in sehr wenigen Regionen und das ist auch nur das theoretische Maximum - also in der realität wirds deutlich weniger sein. Du sagtest was von 5 MPixel Sensoren? Und dann auch noch 3 Stück! Schafft das wer über WLAN ;)
Hallo, Da H.264 wegen dem Lizenzproblem irgendwie fast ausscheidet, was ist der nächst beste Video Kompressor? Ich habe gerade die vorhergesagte Antwort von Fujitsu erhalten. Fujitsu Chip scheidet also aus. Kest: Könntest Du mir eine private Nachricht mit Deiner Email schicken? Liebe Grüße, Andreas
Hallo, Ich möchte das Video nur in vernünftiger Zeit uploaden. Es muss nicht in Echtzeit sein. Das würd auch nicht funktionieren, da mach ich mir keine Illusionen. Ich möchte es aber auch nicht so schlecht komprimieren (z.B JPEG Einzelbilder, dass ich 3GB statt 70MB habe). Liebe Grüße, Andreas
Ah OK dann ist das realistisch. Für H.264 wird aber doch erst ab 10.000 (oder 100.000 ?) Geräten überhaupt eine Gebühr fällig oder sehe ich das falsch?
So, hab' mich mal eingelogt. Schreib' aber ruhig hier rein, da es auch andere interessieren könnte. Und "ja", für H.264 muss man erst zahlen, wenn man ab 10,000 Geräte produziert. Bei gekauften Chips fallen die Gebühren meines wissens flach. Wenn es nicht Echtzeit sein muss, dann bist Du wohl mit einem Embedded PC besser beraten. Hast dann keine Kopfschmerzen mit der Hardware und der ganzen Entwicklung. Dann brauchst Du "nur" noch einen Framegrabber und das war's. Diese Lösung ist dann preisgünstig, abkündigungssicher und leichter zu pflegen (mit der Software kennst Du Dich ja aus). Grüße, Kest
Hallo, An das habe ich natürlich auch schon gedacht. Z.b ein Nano-Itx Board oder etwas ähnliches + Webcams. Allerdings ist das nicht optimal. Derzeitige Webcams liefern nicht den gewünschten Erfolg. z.B erreiche ich mit der Creative Optia AF und ffmpeg H.264 encoder 8 Frames/sec bei 1280x960 auf einem QuadCore 2.5GHz. Die alte Version von ffmeg ging besser, da hatte ich 24 Frames/sec. Wenn (hoffentlich) nur ein Kern benutzt wurde, dann gings mit einem Quadcore mit 3 Kameras, sofern das Board wirklich 3 USB Isochrone Streams glz behandeln kann. Allerdings ist das auch sehr am Limit finde ich. Hinzu kommt, dass ich immer abhängig von den Webcam Herstellern bin. Ich würd doch lieber ganz gern auf Sensorebene arbeiten. Möglicherweise müssen Abstriche gemacht werden. Eventuell dahingehend, dass 3 Einzelstreams kodiert werden, oder dass man mit der Framerate runter geht. Es handelt sich jedoch um ein langfristiges Projekt, wo die erste Entwicklung lediglich der Start ist. Den Vorschlag mit den TI DSP's finde ich ganz gut, falls das Software Bundle nicht gekauft werden muss. Dass es mit den FPGA's schlecht bezüglich H.264 aussieht habe ich inzwischen zur Kenntniss genommen, da die IP'Cores zu teuer sind. Ich bin ja schon gespannt, was aus dem H.264 Projekt auf opencores.org wird. Hier nochmal die Aufgabe zusammengefasst: Video Streams von 3 CMOS Sensoren bearbeiten und komprimieren (zu einem Bild oder getrennt) und per Ethernet streamen oder auf SD speichern. Mit so wenigen Komponenten und so günstig wie möglich. Liebe Grüße, Andreas
> Webcams
Die liefern aber schon M-JPEG. Zwar nur schwach komprimiert aber es
müsste immer JPEG sein, Rohdaten von ner Webcam sind mir bisher
jedenfalls noch nicht untergekommen.
D.h. ffmpeg transcodiert den Datenstrom (also erst das JPEG
dekomprimieren und dann nochmal in ein anderes Format encodieren) was
zusätzlich Rechenleistung kostet.
Kann auch sein das ich mich da irre also korrigiert mich bitte falls
nötig ;)
Hallo, Vielen Dank für die vielen konstruktiven Beiträge und Vorschläge. Da die H.264 Implementierung auf einem FPGA schwierig bzw aufwendig zu sein scheint, werden wir einen TMS320DM64x von TI für die H.264 Komprimierung verwenden. Das Abholen der Bilder sowie die geometrische Entzerrung übernimmt ein FPGA. Das sollte machbar sein, denke ich. Danke nochmals, Andreas
Moin, kleiner Hinweis: Für den Blackfin gibts den x264 codec, und die komplette GCC Toolchain (m.E. sehr stabil) kostenlos. Wir benutzen zwar andere Codecs, aber x264 funktioniert ganz ok, habe allerdings keine genauen Performance-Angaben. Unter http://blackfin.uclinux.org findet sich mehr. Die TI-Leute hatten auf der Messe einige nette Demos, allerdings haben wir von TI wegen mehrerer Gründe abgesehen: - Teure Tools, alles 'closed source' - Kein GCC fuer den DSP-Kern - Debugging von inhomogenen Architekturen offensichtlich ein Graus - Nicht gerade stromsparende Architektur Der BF561 mit 2 Cores bietet da mehr Power, auf dem einen Core läuft uClinux, der andere Core ist mit Rechenaufgaben beschäftigt. Leider hat der BF561 kein direktes Ethernet Interface eingebaut, wir verwenden einen externen Chip gemäss den diversen Referenzdesigns (EZKIT, etc.). Mit dem relativ günstigen ICEbear USB-JTAG lässt sich der Code prima zur Laufzeit des uClinux-Systems debuggen. Mit dem Blackfin hat man relativ schnell ein Testsystem am Laufen, was das Prototyping deutlich leichter macht. Übrigens steckt der Chip auch in einer der Leica-Kameras, ich glaube es war die M8. Grüsse, - goz
Wenn du auf der PC-Schiene bleibst: Es gibt Anbieter von h.264 Encodern, die große Teile der Berechnungen auf die Grafikkarte (CUDA ...) schieben, dort ist ja mehr als genug Rechenzeit verfügbar. Vielleicht reicht dazu ja schon so ein "GeForce Mobile"-Teil, oder sogar die integrierte VGA in manchen NVIDIA-Chipsätzen? Und wenn nicht, selbst eine High-End Gamer Graphikkarte ist immer noch billiger als ein FPGA-PCIe board mit ausreichend großem FPGA drauf.
@goz: Der BF561 mit 2 Cores schafft allerdings nach Angabe von Analog mit deren hochoptimierten closed source (! Man braucht VisualDSP dafür, nix GCC) Codec D1 bei 30fps. Für Andreas Anwendung bräuchte man wohl schon 3 Stück davon + einen BF548 als Master um flüssiges Video aufzunehmen... Die C64x sind eine andere Leistungsklasse (auch preislich und vom Energiebedarf her natürlich aber ich denke das ist bei Andreas Anwendung nicht so wichtig). 2400MMACs beim BF561 versus bis zu 7200MMACs + diverse Hardware Videobeschleuniger. 16 Bit SDRAM Interface versus 32 Bit DDR2 Interface. > DM648 Vorher TI fragen ob der kostenlose Codec auch die Auflösungen kann die Du brauchst! Vielleicht besser den tms320dm6467 hernehmen...
Hallo, Weiss eigentlich von Euch jemand was in dem Aiptek Pocket DV Camcordern verbaut ist? Energiebedarf, Größe und Leistung sind schon ein Thema. Haltet Ihr es für möglich den Aiptek Pocket DV zu zerlegen und statt dem Sensor einen FPGA mit 3 Sensoren anzuschliessen? Das wär eigentlich genau was ich brauchen würde. Klein, leicht, effizient, H.264 und ein Monitor und SD Card Speicherung sind auch dabei. Somit ideal. Das ist eigentlich eine ganz gute Beschreibung von dem, was das Ergebnis sein sollte. Liebe Grüße, PS. Ethernet würde zwar fehlen, da müsste man sich was anderes einfallen lassen.
> Der BF561 mit 2 Cores schafft allerdings nach Angabe von Analog mit > deren hochoptimierten closed source (! Man braucht VisualDSP dafür, nix > GCC) Codec D1 bei 30fps. Ich meine nicht den kommerziellen, sondern den openSource x264 unter uClinux. Der ist natürlich von Haus aus nicht so schnell, man muss einige Assembler-Module einschleusen. Du meinst wahrscheinlich den: http://www.design-reuse.com/articles/17399/h-264-baseline-decoder-ip-adi-blackfin-dsp.html Die tollen MMAC-Angaben bei TI kann man leider in die Tonne treten, da sie nur in einigen Spezialfällen gelten. Wenns um konkrete Anwendungen geht (da habe ich die TI-Leute ziemlich gelöchert), macht der BF561 trotz geringerer MMAC-Hausnummer dank Cache und effizientem DMA einiges wett. Wenn man allerdings genau das machen will, was einem die TI-Leute verkaufen (und man auch die Kohle spendieren will dafür), dann ist der TI möglicherweise die bessere Wahl. Aber auch da geht's ev. nicht mit nur einem Chip bei der Auflösung und fps, die Andreas haben möchte. Grüsse, - goz
@goz:
Der Artikel beschreibt nur den DEcoder - Andreas braucht den Encoder.
> Der ist natürlich von Haus aus nicht so schnell
Kann man freundlich ausgedrückt so sagen. Der taugt für 320x240 pixel
ganz gut - viel mehr aber nicht ;->
Das die MMACs beim TI nur dann gelten wenn man alles parallel ausführen
kann ist klar - das ist bei Videoverarbeitung aber nunmal extrem häufig
der Fall weil man da nunmal viel parallel laufen lassen kann.
Von den eingebauten Hardwarebeschleunigern für HD Video in dem DM6467
fange ich lieber gar nicht erst an zu erzählen...
@Andreas
Brauchst Du wirklich mehr als Full HD also 1920x1080? Wenn Du nämlich
von Pocket DV Camcordern erzählst die gerade mal 1280x720 schaffen (5M
Pixel wären ja was um die 2500x2000 Pixel und das mal 3 ;) ) glaub ich
das eher nicht?
Hallo, Full HD ist ausreichend, ich hatte mich wohl etwas mißverständlich ausgedrückt. Die Bilder sollen im FPGA skaliert und umgerechnet werden. Das absolute Minimum für das Ergebnis ist 1536*512. Mehr wär jedoch besser. Bei all den vorgeschlagenen Lösungen scheint jedoch Full HD schon ein Problem zu sein. Die DSP's wie der TMS320DM schaffen Full HD 10fps, für den BF561 habe ich kein Daten gefunden. Allerdings scheint dieser auch nicht schnell genug zu sein. Wie machen die das also in den Aiptek Pocked DV's. Diese komprimieren 1440x1080 mit 30fps. Andreas
hier ist noch eine Komplettlösung von Basler: http://www.baslerweb.com/beitraege/unterbeitrag_en_91476.html Als Prozessor ist ein '600Mhz Dual Core DSP' angegeben.
Die TIs schaffen FullHD @>30fps und H.264. Schaust du hier: http://www.linuxfordevices.com/c/a/News/HD-surveillance-camera-design-runs-homespun-Linux/ Sogar 5 Megapixel bei 12fps. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.