www.mikrocontroller.net

Forum: FPGA, VHDL & Co. 3 CMOS Sensoren an einem FPGA + MJPEG oder H.264


Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich möchte gerne folgendes Projekt realisieren ...
Was hast du bisher mit FPGAs gemacht?
Welchen Zeitrahmen hast du?

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.. no projects listed.  Geil

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Antti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> weil das Ergebnis per Mobilfunk übertragen wird.

d.h. die Framerate ist sehr gering?
UMTS schafft im Upload ja nicht sonderlich viel.

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kest S. (kest)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;)

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: goz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: goz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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-b...

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

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Andreas Bean (Firma: BEANBOX.COM) (andibean)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hier ist noch eine Komplettlösung von Basler:
http://www.baslerweb.com/beitraege/unterbeitrag_en...
Als Prozessor ist ein '600Mhz Dual Core DSP' angegeben.

Autor: // (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die TIs schaffen FullHD @>30fps und H.264.
Schaust du hier:
http://www.linuxfordevices.com/c/a/News/HD-surveil...

Sogar 5 Megapixel bei 12fps.


;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.