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
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.