Hi!
Kennt sich einer von euch mit JPEG-Encodern aus?
Vorweg: ich habe mir schon einige opensource Projekte angesehen, die
aber alle eher grausig geschrieben sind. Bisher habe wir alles in
Software gemacht, aber das ist deutlich zu langsam.
Ich habe auch bei einigen Firmen herumgefragt aber habe fürchterlich
hohe und ungenau Preise genannt bekommen (um die 30-50'000 EUR).
Ist das realistisch?
Die geplante Zielplattform ist Spartan-6 LX75 von Xilinx. Damit müsste
sowas eigentlich gehen. Ich brauche etwa 60 Bilder pro sec bei 1024x1024
also pixelclock rund 60 MHz.
Über Tips und Hinweise würde ich mich freuen.
>Ich brauche etwa 60 Bilder pro sec bei 1024x1024 also pixelclock rund 60 MHz.
Das ist schon sehr sportlich. Was genau soll der FPGA machen, bzw. wo
sollen die Daten hin? Und was soll Pixelclock sein? Pixelweise wird
normalerweise nicht geclockt, sondern bei den CCD Sensoren eher
zeilenweise.
Kann es sein, dass das ein serieller Datenstrom ist, wie beim HD / DVI?
Ungeachtet dessen brauchts Du etwas Speicher für die Ermittlung der
Bildfrequenzkoeffizienten, samt Pufferung, mit einem kleinen FPGA
alleine geht das nur in Verbindung mit einem schnellen Speicher. Du
musst im Speicher mindestens einmal schreiben und zweimal lesen,
brauchst also die dreifache Nettobandbreite. Ob das mit einem FPGA geht?
Bei 60MBps sind das schon 125MHz x 16Bit Nettorate von und zu den RAMs /
dem Controller. Wenn Du mit Videotakt arbeitest noch mehr. Da ist der
Speicherpfad ziemlich zu, würde ich mal sagen.
Ich bin da nicht der Fachmann, habe das mal auf einem Virtex gesehen und
benutzt (aber nicht selber erstellt.)
Einen kompletten Encoder in einem FPGA zu schreiben dauert geschätzte
3-6Monate, da ist der Kauf sicher das Beste. Lizenzen darf man auch noch
zahlen.
Die Preise sind realistisch. Leider kosten teilweise gute IP-Cores
richtig viel, vor allem, wenn sie nicht allzuhäufig verkauft werden.
Zudem ist meistens bei dem IP-Core auch noch der Support enthalten, der
oft richtig zeitaufwendig ist.
Ich geh mal davon aus, dass du weißt wie JPEG arbeitet. Primär wird
fürdie Diskrete Cosinus-Transformation verwendet. Erst wenn du die genau
verstanden hast und dir selber Gedanken gemacht hast, wie sowas in
Hardware aussehen könnte würde ich einen Blick in die Open-Source IPs
werfen. Sonst versteht man wirklich nur Bahnhof.
Auf deinen FPGA halte ich es für sehr realistisch, dass es umgesetzt
werden kann. Was mich ein bisschen verwundert ist der Pixelclock von 60
MHz, dass wären bei meiner Rechnung mindestens 9 Pixel parallel. Ich
würde hier auf eine höhere Pixelclock gehen und mit 8 Pixel parallel
rechnen, da JPEG in der Regel auch mit 8x8 Pixelblöcke arbeitet.
Grüße
Mensch, seid ihr schnell mit antworten.
Ja, die Grundlagen kenne ich, unsere DCT ist schon soweit
assembly-optimiert, da ist nichts mehr heraus zu holen.
Ich fürchte nur, dass die opensource Cores nicht wirklich in der Praxis
zu nutzen sind, am ehesten würde ich allenfalls den mkjpeg von openCores
einsetzen. Wir haben auch über reine DCT-Vorverarbeitung nachgedacht,
und den Rest (Huffman und RLE) in der MCU rechnen.
Sorry wegen der Verwirrung mit dem Pixelclock. Das Interface ist ein
ziemliches standard Interface mit 16 Bit datenbus, pro Clock und
LineValid HIGH liegt ein monochrom Pixel (nur 10 Bit) an. Also nichts
serielles.
Soweit ich die Infos zusammmen habe, geht das wohl auch ohne externes
RAM, das Block-RAM des Spartan-6 ist offensichtlich ausreichend.
Der Pixel clock lässt sich konfigurieren.
Also mein rohe Vorstellung ist: Datenstrom rein, komprimierter
Datenstrom raus, die Übertragung erst mal per Ethernet mit der MCU.
Betreffend Lizenzen: Muss man zusätzlich noch Lizenzen wie bei h264
bezahlen?
Bei der Softwarelösung war das nach meinen Wissen nicht nötig.
Hi Videolaner,
wieviele Kanäle brauchst Du denn (Monochrom, YUV420, YUV422, ...)?
Wie soll das Ding konfiguriert werden (Quantization)?
Soll hinten JFIF rauskommen oder genügen die Rohdaten ohne Header?
Soll die volle 10bit-Dynamik ins JPEG?
Womit liest Du die Daten? GigE-Vision-Player, Browser, eigenes Protokoll
(TCP oder UDP?). Alles sehr knifflige Details..
Kann zumindest schon mal bestätigen, dass das schon auf einem Spartan3E
bei 54 MHz ohne externes RAM zu machen ist. Mit dem Spartan6 biste auf
der sicheren Seite, da geht einiges mehr.
50k€ finde ich bisschen viel, aber die 5-stellige Grössenordnung ist
schon realistisch. Soviel steckst Du oder die Firma vermutlich auch rein
:-)
Soweit ich weiss, ist der baseline-Codec mit Huffman lizenzfrei. Nur
beim arithmetischen Coding gab's mal irgendwas...
Ciao,
- Strubi
Rechnen wir mal:
1024x1024 Pixel werden in 128x128 Segmente (8x8) überführt.
Das sind 128*128=16384 Segmente pro Bild
bei 60 Bilder sind das 983040 Segmente pro Sekunde.
Das sind rund 1Million 2D-DCT Operationen und da sind wir nur bei
Schwarz Weiß angelangt
Bei Buntbilder verdoppelt/dreifacht sich die Anzahl.
3Million DCT/s
Eine optimierte 2D-DCT 400Takte geschätzt.
Da sind wir bei 1,2GHz
Was sagt und das:
Es muss ca. 10 fach parallel gerechnet werden.
Mit dem Spartan 3 würde ich hier nicht mehr anfangen.
Ich habe mich mit dem Thema auch mal beschaftigt und mich gefragt wie
man eine optimale Huffman Tabelle bekommt? Alle benutzen eine feste
Huffmantabelle.
Kanns nicht auch jpeg2000 sein? Da hat Analog-Devices nämlich fertige
ICs für ein Paar €uronen (ADV212 oder ADV202). Man kann mehrere
"zusammenschalten" und dann reicht es auch für 720p50 oder 1080i50 in
Echtzeit.
videolaner schrieb:> Bisher habe wir alles in> Software gemacht, aber das ist deutlich zu langsam.
Hier grüßt die HLS (High Level Synthesis) von Xilinx Vivado. Der HLS
Syntheser kann C/C++ direkt in Netzliste synthetisieren. Das Ziel von
HLS ist es, vorhandene komplexe Software von C/C++ in einen FPGA zu
bringen.
Tom
Thomas Reinemann schrieb:> Das Ziel von> HLS ist es, vorhandene komplexe Software von C/C++ in einen FPGA zu> bringen.
Das Ziel der Firma Xilinx ist es immer, irgendeine Logik in die Chips zu
bringen und zwar vorzugsweise in die eigenen und mit eigenem Code,
eigenen Source und so weiter, um auch ja die Kundenbindung aufrecht zu
erhalten, die tausende Firmen nach wie vor bei der X-Stange hält. Vivado
ist nichts anderes, als ein Versuch, das auszubauen.
Ob das technisch einen Sinn macht, steht auf einem anderen Blatt:
Wie Rene bereits verdeutlicht hat, müssen zur effektiven Implementierung
angemessene Lösungsansätze gefunden und realisiert werden. 20x C++
Instanzen reinzuwerfen ist nicht so der Brüller.
Das hat Mentor mit dem Catapult-C schon erfolglos verucht.
Wenn ich in C++ arbeite, kann ich auch gleich in DSPs gehen, bzw
GPU-basiertes Rechnen angehen.
Nahmd,
Von Vivado würde ich mal gern ein Beispiel bzgl. komplexer Arithmetik
sehen.
Aber abgesehen davon: mich hat bisher noch keins dieser (teuren) Tools
überzeugt. Die schnellen Apfelmännchen-Demos aufm FPGA hauen mich nicht
wirklich von der Stange. Denke auch, dass solch ein Versuch bei einem
JPEG-Encoder massiv scheitert, gerade wenn es an die Grenzen der
möglichen Bandbreiten geht. Und: wer will sich schon wirklich an einen
Hersteller binden?
An René: Ich würde eher mit dem Durchsatz als solchem rechnen. Der Trick
ist das Pipelining, was bei JPEG recht gut klappt. Ein paar Zeilen des
Bildes musst du erst puffern und blockweise auslesen. Eine 1D DCT
braucht nur 4 parallelisierte Pipeline-Stages (und verarbeitet zwei
Werte pro Takt). So kriegt man interleaved die doppelte Bandbreite durch
den "DSP". Die zweidimensionale Geschichte ist nur noch etwas Pufferung
und Kaskadierung. Beim Huffman-Encoding muss man dann allerdings
parallelisieren (Luma/Chroma). Und bei YUV422 ist in der Konfiguration
erst mal Schluss, für YUV444 oder RGB muss man noch einen weiteren
Encoderchannel anreissen. Das wird dann recht schweinisch...
Ein Spartan3-500 schafft einen Kanal (monochrom bzw interleaved), sogar
der Soft-core für die Konfiguration geht noch rein. Für den Sp6 spricht
primär nur der Speed und vielleicht die etwas verbesserten DSP Units.
Übrigens: Die DCT-Unit ist aus einem recht kranken Ansatz entstanden,
per Python einen Mini-DSP zu generieren. Im Prinzip besteht die DCT aus
Microcode in Form eines 4-Instruction Programms. Wäre interessant, ob
das bei Vivado ähnlich geht, bzw. was man da für Kontrolle über die
Resourcen hat.
Wegen Huffman-Tabellen: Du kannst natürlich für deine Bilder eine
bessere "Entropie" anhand statistischer Untersuchungen ermitteln und
andere Tabellen generieren bzw. in den Codec laden. So ich verstehe,
wurde aber die Standard-Tabelle als im Schnitt 'bester' Kompromiss
ermittelt.
Timmo, hast du mit dem ADV212 konkret was gemacht? Der ADV202 ist ja nun
etwas alt..
Grüsse,
- Strubi
René D. schrieb:> Ich habe mich mit dem Thema auch mal beschaftigt und mich gefragt wie> man eine optimale Huffman Tabelle bekommt? Alle benutzen eine feste> Huffmantabelle.
Hallo,
ich habe mich mal auch mal mit einer Kompression von Bilddaten
beschäftigt gehabt. Unsere Hufmann-Tabelle war damals auch nicht
dynamisch, aber konfigurierbar, d.h. die Tabelle ist in einem BRAM
gewesen und der BRAM konnte auch aktualisiert werden. Die Berechnung der
Hufmann Tabelle hatten wir auf einem PC gemacht, sodass ich quasi nur
eine "feste" Tabelle in den BRAM laden müsste. Da habe ich mir dann auch
einiges an Zeit und Resourcen gesparrt.
Gruß Cihan
Martin S. schrieb:> Und: wer will sich schon wirklich an einen> Hersteller binden?
Mit der Auswahl eines Spartan6 hat er sich bereits an einen FPGA
Hersteller gebunden. Das betrifft sowohl das Board, als auch das
FPGA-Design. Die wenigsten Chefs werden einfach mal so den Wechsel eines
FPGAs mitmachen.
Vivado ist in der normalen ISE Lizenz enthalten, ok es unterstützt
keinen Spartan6.
Tom
Hat du bei deinen Angeboten auch die Info,
dass Sie bei der Auflösung die 60Bilder noch schafften?
Ich habe in alte Datenblätter mal geschaut, da geht die Auflösung bei
größer Bildrate runter.
Wichtig wäre zu wissen, wo du mit den vielen Daten hin willst?
Hi!
Ich muss erst mal die viele Info verdauen.
Zu den Daten: Es sind zunächst monochrom Daten zu verarbeiten. Aber
Farbe wird vielleicht später wichtig. Es wäre gut, ein 10/8 bit modus zu
haben aber das kann ich im FPGA voher schieben.
Die Daten können als Strom gespeichert/versenden werden, es reicht ein
Synchronisation-Signal oder ein Feld mit Blocklängen-Angabe. Die
quantization braucht nicht verändert werden. Zu debug Zwecken soll das
Bild auch in Mozilla oder mplayer angesehen werden können, das
funktioniert schon so. Das versenden sollte mit etwa 6-8MB geschehen.
Gigabit Ethernet wäre schön, ist aber nicht das Kriterium.
Von dem FPGA Hersteller bin ich nicht abhängig, eine andere Gruppe
arbeitet mit anderen Hersteller. Deswegen soll alles möglich in VHDL
sein und wenig black box components nützen. Ich denke, es wird auch in
einen Kauf eines Encoder-IP enden. Nur den FPGA möchte ich nicht
wechseln.
Danke für eure Hilfe so weit!
videolaner schrieb:> Die Daten können als Strom gespeichert/versenden werden, es reicht ein> Synchronisation-Signal oder ein Feld mit Blocklängen-Angabe. Die> quantization braucht nicht verändert werden. Zu debug Zwecken soll das> Bild auch in Mozilla oder mplayer angesehen werden können, das> funktioniert schon so. Das versenden sollte mit etwa 6-8MB geschehen.> Gigabit Ethernet wäre schön, ist aber nicht das Kriterium.> Von dem FPGA Hersteller bin ich nicht abhängig, eine andere Gruppe> arbeitet mit anderen Hersteller. Deswegen soll alles möglich in VHDL> sein und wenig black box components nützen. Ich denke, es wird auch in> einen Kauf eines Encoder-IP enden. Nur den FPGA möchte ich nicht> wechseln.> Danke für eure Hilfe so weit!
wieviel Zeit hast du dafür?
Hallo videolaner,
ein Mitarbeiter hat mich gerade auf diesen Thread aufmerksam gemacht.
Wir bieten JPEG-Encoder und Decoder an, die sehr wenig Ressourcen
benötigen, sehr schnell sind (die genannte Geschwindigkeit schaffen wir
leicht) und auch herstellerunabhängig.
Weitere Infos finden Sie sind unter:
http://www.entner-electronics.com/tl/index.php/jpeg-codec.html
Die IP-Cores kosten natürlich auch etwas, sind aber weit unter den
genannten Preisen.
Falls das für Sie interessant klingt, kontaktieren Sie mich bitte
einfach.
Schöne Grüße
Thomas
videolaner schrieb:> Zu den Daten: Es sind zunächst monochrom Daten zu verarbeiten. Aber> Farbe wird vielleicht später wichtig. Es wäre gut, ein 10/8 bit modus zu> haben aber das kann ich im FPGA voher schieben.> Die Daten können als Strom gespeichert/versenden werden, es reicht ein> Synchronisation-Signal oder ein Feld mit Blocklängen-Angabe. Die> quantization braucht nicht verändert werden. Zu debug Zwecken soll das> Bild auch in Mozilla oder mplayer angesehen werden können, das> funktioniert schon so. Das versenden sollte mit etwa 6-8MB geschehen.
Weiss nicht, ob Dir das jetzt im Detail hilft - falls Du die
Handy-Sensoren von Aptina, die JPEG ausspucken, kennst (wie z.B.
MT9T111, etc.): Genauso habe ich es auch gemacht. Könnte Dir ansich eine
komplette Referenzlösung anbieten, die auch nicht ganz so übel
dokumentiert ist :-)
Ein paar Details findest Du hier: http://section5.ch/vkit
Da ist auch etwas Info zum JPEG-Encoding verlinkt.
Der 'kleine' Codec (L1) kann auch über i2c konfiguriert werden. Der
'grosse' ist eher ein SoC, featured by Renés MIPS-SoftCPU.
Die momentane Referenzplattform ist ein Blackfin Hybrid-DSP mit USB und
100MBit Ethernet plus ein Spartan6 LX45 zur Vorverarbeitung. Der Spartan
macht Bayer->YUV und das JPEG-Encoding, der Blackfin den "Videoserver".
Das ganze ist recht portabel, lief zB. auch auf nem Tegra-2-Board, OMAP,
Marvell, o.ä. ginge wohl auch.
Der Ansatz mit nur der DCT im FPGA ist gar nicht so übel, damit kriegt
man recht schnell was zum Laufen. DCTs findet man auch einige
brauchbare.
Aber: die Bandbreite bei den meisten Videoports ist limitiert, unter
Linux wird das noch eng mit 60 MB/s. 8 MB/s für die Ausgabe ist jedoch
zu schaffen, allerdings kriegt Mozilla diese Rate im MJPEG-Stream nicht
so recht hin bei mir.
Für 1Kanal(monochrom)-Daten haste erst mal keinen Stress, weil Du da den
Clock nicht hochjagen musst, heisst, du kannst alles pixelclock-synchron
durch die Pipe schieben, ohne fieses asynchrones FIFO-Gepuffer.
Wenn Du es doch nicht selbermachen willst, könnte ich dir die
Monochromlösung anbieten, die Deine 'shopping list' abdecken sollte,
schick mir einfach bei Interesse ne Message. Mit dem Support müsste man
dann gucken. Ich schiesse mich damit jetzt voll selber ins Knie, aber
ehrlich gesagt: Wenn der Chef die Kohle locker macht, würde ich auf
jeden Fall auch einen gut etablierten Codec von der Stange evaluieren.
Denn so ein Projekt könnte euch intern auch 40-50k kosten...
Viele Grüsse,
- Strubi
