Gibt es jemanden hier, der sich mit H.264 oder anderen Video-Kompressionsverfahren schon mal beschäftigt hat? Mich interessiert die FPGA Implementierung des Enc- und Decoders. Noch habe ich keine speziellen Fragen, aber ich wollte mich schon mal umhören, ob es hier eventuell Leute gibt, die man fragen könnte oder die sowas gemacht haben. Gibt es überhaupt Interesse an dem Enc- und Decoder? Grüße, Kest
Na dann stelle ich gleich eine "spezielle" Frage: Wird zur Laufzeit entschieden, ob "intra" oder "inter" Prediction verwendet werden soll oder wird es von vorne herein per Switch eingestellt? @Gero A. (gero): Übrigens, wenn Du an "meinen" Versuchen nicht interessiert bist, brauchst Du nicht zu antworten. Ich frage mich sowieso, wie Du aus ein Paar Zeilen Text herauslesen kannst, ob ich in der Lage bin, sowas zu stemmen oder nicht? Leute gibt's... :-o Grüße, Kest
Ich finde das ein geniales Projekt. Ist etwas was mich auch sehr interessiert. Hast Du vielleicht ein paar gute Links zum Thema?
Gute Links zum Thema gibt es sehr viele, starte mal damit: http://www.vcodex.com/h264.html Grüße, Kest
Gibt von Xilinx eine Appnote dazu und ich meine auch einen IP Core Einfach mal auf deren HP ein bisschen rumsuchen Gruß
gero, hast du heut irgendwas flasches gegessen ? wenn dich sein anliegen nicht interessiert und du ihm nicht weiterhelfen möchtest, dann lass es, aber rumflamen bringts irgendwie nicht. also ich muss sagen, dass ich das projekt schon interessant finde, aber wohl wenig helfen kann. ich würde auch nich gleich so hoch anfangen sondern erstmal versuchen einfachere encoder oder decoder zu implementieren und quasi damit zu wachsen. speziell durch den hohen rechenaufwand und die hohen datenraten bei HD video, worums hierbei wohl geht, muss man schon ziemlich große FPGAs einsetzen um da was hinzubekommen.
@Gero A. (gero): Deine Beiträge sind nicht sehr hilfreich. Was hat H.264 mit DSP zu tun? Genauso viel wie mit FPGAs! Wenn Du es nicht spannend findest, es zwingt Dich hier niemand weiterzulesen. @alle anderen: Es geht darum H.264 mit VHDL zu implementieren, zunächst "base"-profile, dann "main"-Profile. Es soll sowohl (Achtung!) _En_- als auch Decoder implementiert werden, um Videosignal übers Netzwerk zu übertragen. Als erstes soll nur SD-Video implementiert werden, später mit größeren FPGAs HD (1080p). Welches FPGA verwendet wird, weis ich noch nicht, ist aber auch egal, solange Simulation läuft. Bevorzugt sind aber Altera FPGAs (Cyclone III, Aria GX) Mit dem Thread wollte ich nur ausloten, ob man hier vernünftig darüber diskutieren kann. Anscheinend aber... na ja. Werde wohl irgendwo anders suchen. Grüße, Kest
Hallo Kest, ich bin grad dabei, eine Bewegtbildkompression für HD 720p60 auf einem Virtex II Pro umzusetzen. Da für meinen Anwendungszweck eine Kompression von 3:1 ausreicht, hab ich erstmal mit MJPEG angefangen. Im Rahmen der Untersuchung betrachte ich allerdings auch Implementationsansätze von MPEG-II und H.264. Auf alle Fälle klar ist, dass die Bewegungsschätzung in Echtzeit schon mal eine Herausforderung im FPGA darstellt. Auch brauchts viel (externen) Speicher. Zu deiner speziellen Frage: Die Entscheidung ob inter/intra-Codierung kannst du handhaben wie du möchtest. Der Standard spezifiziert nur den Decoder(bitstrom), aus gutem Grund. Somit kannst du je nach HW/SW-Voraussetzung beim Encoder eine mehr oder weniger leistungsfähige Implementierung durchführen. Ob du im Encoder alles intra-codierst, eine feste Bildgruppe hast mit der du intra/inter von vornherein bestimmst, oder ob du mit einem sehr leistungsfähigen Encoder die Bildgruppen (abhängig vom Bildinhalt) zur Laufzeit zusammenstellst, ist in Bezug auf den Standard alles konform, nur das Ergebnis ist natürlich mehr oder weniger stark komprimiert. Entsprechend ist auch die Methode Bewegungsschätzung nicht vorgeschrieben, sondern kann selbst festgelegt werden. Bin gerade darüber am grübeln, würd mich freuen, wenn du deine Erkenntnisse oder gefundene Links dazu teilst :-) . Schönen Gruß Markus
Wenn du nicht schon einen fertigen JPEG-Core hast würde ich statt MJPEG eher mit H.264 und reinen I-Frames anfangen. Die Komplexität sollte ähnlich sein, die Qualität ist besser, und man kann bei Bedarf immer noch zusätzliche H.264-Features hinzufügen.
Das klingt vernünftig, danke für den Hinweis. Im Rahmen der Untersuchung entstehen verschiedene Machbarkeitsstudien, dabei eben auch verschiedene Implementierungen (zumindest Teile, v.a. die Transformationskerne der Standards: DCT, DWT, IntegerT), so dass mit etwas Mehraufwand für die Codierung usw. MJPEG quasi "abfällt", genauso wie intra H.264. Fertig umgesetzt ist bis jetzt die DCT (cores sollen wegen Portierbarkeit möglichst nicht verwendet werden) und etwas drum herum für MJPEG. @Kest Danke übrigens für die bmp-Testbench, hab ich hier grad gefunden.
Ich möchte hier noch ein Paar Daten zu kommerziellen Cores preisgeben (Logic Elements / Slices), damit man so einen Pi mal Daumen Vergleich hat, wie komplex alles ist: H.264 High Profile Decoder: Virtex 5 LX110 HD/SD: LUTs 36k, FF 17k, BRAMs 87, 100 MHz H.264 Main Profile Encoder: Virtex 5 LX110 HD LUTs 70k, FF 40k, BRAMs 171, 120 MHz SD LUTs 23k, FF 13k, BRAMs 57, 100 MHz Sorry, keine Ahnung, wie man LUTs in Slices oder umgekehrt umrechnet. Fakt ist, dass man mit einem "kleinen" FPGA höchstens nur SD processieren kann. Ich stehe vor der Entscheidung alles sofort in VHDL zu implementieren und simulieren, oder erst in C/C++/Java und dann nach und nach nach VHDL zu portieren. Das Problem ist, dass ich zwar weis, wie es im groben funktioniert, nicht aber wie es im Detail geht. Es gibt z.B. ein Paar Stolperfallen, wo ich viel Zeit damit verbringe, was aber im Endeffekt nichts bringt. z.B. DCT/iDCT 8x8 Pixel. Nach dem eine Version des DCTs, die mit 64 Takten auskommt funktioniert hat, habe ich weiter optimiert und bin auf 32 Takte gekommen. Das blöde dabei ist, dass ich nicht weis, was man dann mit den Daten anfangen kann -- die Koeff's später parallel zu verarbeiten war dann plötzlich auch doppelt zu kompliziert und die LUTs wurden auch viel größer ;-) Was ich sagen möchte, es würde mich sehr freuen, wenn man sich hier einfach austauschen kann, um nicht das Rad neu zu erfinden. Grüße, Kest
Angehängte Dateien:
-
jpegkompkette.png
170 KB
Hallo Kest, Also meine Methode ist eher anders herum. Ich schaue wie schnell mir wie viele Daten zur Verfügung stehen und wie diese dann bearbeitet werden müssen (serielle oder parallele Operationen). Danach wird dann eine passende Komponente (8x8 DCT mit 64 oder mehr/weniger Takten) gebaut. Die der DCT nachfolgende Operation der Quantisierung kann ja immer noch gut parallel bearbeitet werden (bei mehr Ressourcenaufwand oder entsprechend schnellerer Operation). Spätestens bei der Umsortierung (zumindest bei JPEG/MPEG-II) bzw. der Lauflängencodierung wirds schwierig. Da ist es eventuell sinnvoller, wegen dem seriellen Charakter dieser Operationen 64 Takte pro Stufe zu verwenden. Dann nützt dir diese doppelt schnelle DCT aber trotzdem was: bei der Umwandlung von z.B. RGB nach YCbCr entstehen drei Farbkomponenten. Die müssen alle bearbeitet werden. Um den encodierten Datenstrom zur Übertragung zu multiplexen (also Y und C zu mischen), müssen die dann in etwa parallel zur Verfügung stehen, also auch parallel bearbeitet werden. Angenommen deine DCT benötigt 32 Takte, dann kannst du in 64 Takten schon mal zwei Komponenten verarbeiten und brauchst nur noch die Komponenten doppelt instanziieren, die wirklich 64 Takte benötigen. Gegenargument wäre, dass für den Übergang zur seriellen Verarbeitung Puffer notwendig sind. Die brauchst du aber für den Zweck der Umsortierung (Stichwort Zick-Zack-Scan) in jedem Fall irgendwo. Ich hab mal ein Bild mit den Verarbeitungsstufen (für MJPEG bzw. MPEG-I/II ohne Bewegungsprädiktion) angehängt. Vielleicht nützt es dir ja was oder du hast etwas konstruktive Kritik dazu. Die Umsortierung (bzw. die Puffer dafür) sind hier weggelassen, da die bei mir von der DCT im Encoder bzw. der Decodierung im Decoder mit erledigt wird. Prinzipiell ist dieses Prinzip mit jeder Transformation, usw. umsetzbar. Wenn allerdings die Bewegungsprädiktion dazu kommt wird es (viel) komplexer. Gruß, Markus
Soll das ganze nur eine Übung-/Hobbyprojekt sein? Wenn ja und Zeit dabei
nicht so eine große Rolle spielt, dann würde ich den Algo erstmal in
einer Hochsprache nachbauen um die Funktionsweise 100% zu verstehen (C,
Matlab, etc.)
> Fakt ist, dass man mit einem "kleinen" FPGA höchstens nur SD processieren kann.
Klein ist immer relativ. Ein S3E(-5C) mit dem Xilinx Core packt die
Dekodierung in 1080p mit 25fps. Bei der Encodierung bin ich mir nicht
sicher und ich habe die Doku nicht hier.
Alles in allem ein durchaus interessantes Projekt. Wäre schön, wenn du
hin und wieder mal deinen Status mitteilen könntest.
Viel Erfolg
Aaron
So Leute jetzt reichts ;-) Ihr habt mich nun auch angesteckt etwas mit Video machen zu wollen :-) Allerdings hab ich von FPGA garkeine Ahnung! Wie müsste so eine Grundbeschaltung aussehen um aus einem einfachen Videosignal (PAL oder CCIR) ein Datenstrom zu wandeln? Interessannt wäre das Streamen auf ne HDD... Wie müsste diese FPGA-Eingangsbeschaltung aussehen? Grüße Alex
LOL....soll das dein Ernst sein? Du hast keine Ahnung, willst aber gleich ein riesen Projekt starten. Naja. Kauf dir erst mal ein FPGA-Demo Board und lerne VHDL, schreibe kleinere Sachen. Dann kannst du mal versuchen, den Video-ADC anzuschließen und Daten auszulesen. Das macht man nicht mal nebenher am Wochenende.
Christian R. wrote: > LOL....soll das dein Ernst sein? Du hast keine Ahnung, willst aber > gleich ein riesen Projekt starten. Naja. Darf man heutzutage nichts mehr wollen? > Kauf dir erst mal ein FPGA-Demo Board und lerne VHDL, schreibe kleinere > Sachen. Dann kannst du mal versuchen, den Video-ADC anzuschließen und > Daten auszulesen. Das macht man nicht mal nebenher am Wochenende. Was soll ich denn Deiner Meinung nach Schreiben? Ok fangen wir mal klein an! Wie würde so eine Beschaltung für den Videoeingang aussehen? Grüße Alex
@Alex W. (a20q90): Schau Dir die Schaltpläne zu z.B. NIOS II Cyclone III Starter Kit, da ist alles on-board, was man dafür braucht. Da ist ADV7180 als Videodecoder drauf, der gibt dann die Timings mit Daten aus. Die können dann verarbeitet werden. Ich werde mit diesem Kit anfangen, um Streams zunächst auf SD-Karte zu speichern, später dann per Ethernet an den Rechner zu schicken und auf dem PC dann alles anzuzeigen. Leider ist auf dem Board nur DDR-16 Bit drauf, sodaß es wohl sehr limitierend sein wird. Es geht mir aber darum, erstmal zu verstehen, wie alles funktioniert. Leider muss ich drei-gleisig fahren, um voranzukommen - Bitakkurates Model in C/JAVA/... schreiben - VHDL Implementierung + Testbenches - MPEG 2 TS implementieren, damit ich "richtige" Videos habe und nicht irgendwie Bitstrom, den nur "ich" verstehen kann ;-) Grüße, Kest
Alex W. wrote: > Christian R. wrote: >> LOL....soll das dein Ernst sein? Du hast keine Ahnung, willst aber >> gleich ein riesen Projekt starten. Naja. > > Darf man heutzutage nichts mehr wollen? Schon, aber man sollte sich auch nicht übernehmen, noch dazu bei so teurem "Spielzeug" wie ein FPGA. >> Kauf dir erst mal ein FPGA-Demo Board und lerne VHDL, schreibe kleinere >> Sachen. Dann kannst du mal versuchen, den Video-ADC anzuschließen und >> Daten auszulesen. Das macht man nicht mal nebenher am Wochenende. > > Was soll ich denn Deiner Meinung nach Schreiben? Erst mal VHDL lernen, verstehen, wie ein FPGA funktioniert, Lauflichter, PWM, was weiß ich, gibts ja viele Sachen. > Ok fangen wir mal klein an! Wie würde so eine Beschaltung für den > Videoeingang aussehen? Ein FPGA hat keinen Video-Eingang, weil ein FPGA ein rein digitales Bauteil ist. Analogfilter -> Video ADC -> FPGA.
Kest wrote: > @Alex W. (a20q90): > Schau Dir die Schaltpläne zu z.B. NIOS II Cyclone III Starter Kit, da Ja sowas hab ich gemeint! Ich hab irgendwo mal ein Video gesehen wie man ein Videosignal auf dem LCD dargestellt hat. Ich glaube das Video zeigte das Videospiel DOOM^^ Mit dem Beispielcode Video2LCD kann man schon viele Sachen machen. Und der Lerneffekt ist auch größer als wenn man rumprobiert bis eine LED blinkt. Und VHDL sieht mir sehr ähnlich Pascal aus! Wer das kann, wird weniger Schwirigkeiten haben kompliziertere Sachen zu machen^^ Grüße Alex
Da gehört aber nicht nur VHDL zu. Die Sprache ist nicht sonderlich schwer. Der Hauptteil besteht aus dem Verständnis der Synthese bzw. der Digitaltechnik im Allgemeinen. Da solltest du dich auch direkt mit auseinander setzten.
Bevor ich es vergesse -- hier ist was interessantes! :-) http://www.drtonygeorge.com/Video/h264/h264_rtl.htm Kest
Kest wrote: > Bevor ich es vergesse -- hier ist was interessantes! :-) > > http://www.drtonygeorge.com/Video/h264/h264_rtl.htm > Na also ;-) Und schwupps kann einer ohne große FPGA-Erfahrung selber rumprobieren. Die Arbeit wurde ja schon gemacht und man kann gleich mit dem Anpassen loslegen ;-)
>>> Kauf dir erst mal ein FPGA-Demo Board und lerne VHDL, schreibe kleinere >>> Sachen. Dann kannst du mal versuchen, den Video-ADC anzuschließen und >>> Daten auszulesen. Das macht man nicht mal nebenher am Wochenende. >> >> Was soll ich denn Deiner Meinung nach Schreiben? > > Erst mal VHDL lernen, verstehen, wie ein FPGA funktioniert, Lauflichter, > PWM, was weiß ich, gibts ja viele Sachen. Mein erstes Projekt war ein Kommandodekoder für einen asynchronen Adress/Datenbus. Das zweite war dann ein HQ-PAL-Encoder in VHDL ... Finde auch, dass man hohe Ziele braucht :) Aber einen H264 Encoder finde ich schon ziemlich krass ... Wünsch dir viel Erfolg damit! MfG Thomas Pototschnig
Hallo Kast, Ich arbeitete in H.264. Kodierer ist kompliziert. Bitte starten Sie das Projekt mit Decoder. Erster Schritt ist das Downloaden JM Referenz-Code. (Ich weiß nicht, Deutsch-Sprachkurs. Deshalb bin ich mit einem Google-Übersetzer. Sorry für etwaige Fehler) Best of luck Tony George Gladvin drtonygeorge.com
Hallo, Kennt jemand Untersuchungen, die die Größe eines Suchraumes für die Bewegungsprädiktion beim Block-Matching für HDTV (720p60) abschätzen? Ich geh dabei erstmal von einem Makroblock fester Größe aus, für den eine Referenz in einem Suchraum bestimmter Größe gefunden werden soll. Meiner Meinung nach ist das ja von mindestens den folgenden Faktoren abhängig: 1. Bildabstand zwischen aktuellem Bild und Referenzbild innerhalb einer Bildgruppe (großer Abstand zwischen I und P-Bild, da einige B-Bilder dazwischen -> größerer Suchraum) 2. Auflösung der Bilder (höhere Auflösung -> gleiche optische Bewegung über mehr Pixel als bei kleinerer Auflösung -> größerer Suchraum) 3. Bildwiederholfrequenz (mehr Bilder pro Sekunde -> Bewegung verteilt sich auf mehr Bilder -> kleinerer Suchraum) 4. Bildinhalt (starke Bewegung -> großer Suchraum) 5. ... Gefunden habe ich bis jetzt z.B. http://www.research.ibm.com/journal/rd/434/gonzales.html , die mir einen Suchraum von um die 200x150 vorschlagen aber die Bildwiederholfrequenz nicht beachten. Andere Quellen beim IEEE verwenden Suchräume von 7x7 über 32x32 bis sonstwas, treffen meist aber keine klaren Aussagen über die oben genannten Punkte. Theoretisch müsste es doch möglich sein, mit Kenntnissen über die Trägheit des menschlichen Auges zu bestimmen, über wieviele Pixel (bei bestimmter Auflösung) eine Bewegung (bei bestimmter Bildwiederholfrequenz) von einem zum nächsten Bild überhaupt gehen darf, um noch als Bewegung wahrgenommen zu werden und daraus dann einen maximalen Suchraum abzuleiten (oder geeignete Suchräume für 95%-Fälle oder ähnlich). Falls jemand einen Link auf eine für das Thema relevante Untersuchung geben kann freu ich mich. Über alle anderen Hinweise ebenso, besonders was Hardwareumsetzung der Bewegungsprädiktion angeht. Markus
Hallo Leute, ich finde euer Projekt hochinteressant! Vor allem da ich so etwas in der Art brauchen könnte. Was ich mir nämlich bauen möchte ist ein Computer der von einer normalen digitalen DVB-C Karte ein Fernsehsignal an einen Decoder schickt welcher das Videosignal dann dekodiert. Anschließend soll das Videosignal deinterlaced und die Auflösung des Videos bei Bedarf verkleinert (transformiert) werden und zum Schluß möchte ich das Videosignal mit MPEG4 H.264 encodieren und mit AES verschlüsseln um es anschließend übers Netzwerk zu schicken oder einfach auf der Festplatte zu speichern. Das Ziel dabei ist, daß der ganze Computer einen Gesamtstromverbrauch von unter 30 W erreicht und da ich zukünftig damit rechne, daß das Videomaterial nur noch als HD (1080p) Material kommt, müßte der Enkodierer auch für HD (1080p) geeignet sein. Tja und das ist mein Problem und der Grund warum ich jetzt inzwischen über FPGAs nachdenke. Die Ursprüngliche Idee war, einen normalen aber sparsamen PC zu nehmen. Z.B. einen Intel Atom oder AMD BE-2300. Aber dieser sollte nicht die Dekodier und Enkodier Aufgaben übernehmen, dazu wäre die CPU nämlich zu schwach bzw. würde zu viel Strom verbrauchen. Nein, diese Aufgaben wollte ich von den Video Decoder- & Encodereinheiten in der onboard GPU machen lassen. Die meisten Onboard GPU Chipssätze können nämlich so etwas. Von Intel gibt es Chipsätze mit einfachen MPEG-4 Decodern die das in Hardware machen. Von NVidia gibt es ebenfalls Chipsätze mit Video Dedocer Einheit die einen MPEG-4 Datenstrom dekodieren können. Und von AMD/ATI gibt es sogar welche, die das Videosignal nicht nur dekodieren, sondern auch gleich noch encodieren können. Im Prinzip wäre also so etwas ideal. Nur gibt es für AMD/ATI keine Open Source Treiber die die Video De-/Encodereinheiten ansprechen können und die propritären Treiber schützen das Videosignal meines Wissens nach mit DRM. D.h. ich werde es kaum für meine Zwecke nutzen können. Und bei NVidia sieht es ähnlich schlecht mit Open Source Treibern aus, aber dafür würde zumindest das Dekodieren mithilfe der Video Decodereinheit mit den Propritären Treibern funktionieren. Ich möchte das ganze nämlich unter Linux laufen lassen. Bei Intel sieht es hier sogar noch am besten aus, denn für die Decoder Einheit gibt es Open Source Treiber und passende Dokumenation. Aber das hilft alles nichts, wenn die CPU zum encodieren zu schwach ist. Bei einer Intel Lösung hätte ich z.B. an einen Intel Atom + NVidia Ion Chipset gedacht. Und bei einer AMD Lösung an einen AMD BE-2300 + AMD 780G oder 790G Chipsatz, davon ausgehend, daß das Treiberproblem irgendwie gelöst werden könnte. Tja, wie dem auch sei die CPU dürfte dafür zu langsam sein und selbst wenn sie es könnte, dann würde sie unter Vollast laufen. Außerdem soll die CPU das Videosignal ja noch mit AES verschlüsseln und übers Netzwerk schicken. Das wäre also zuviel des guten. Und hier kommt damit ein FPGA ins Spiel. Wenn ich einen FPGA hätte, der das Videosignal in H.264 encodieren könnte, dann wäre das prima. Das Decodieren kann ja nach wie vor die onboard GPU sehr stromsparend machen. Ich bräuchte also eine PCIe Karte mit programmierbarem FPGA Chip, sowie einem darauf laufenden H.264 Encoder. Meine Frage wäre also erstmal. 1. Was für einen FPGA bzw. was für eine PCIe Karte mit entsprechendem FPGA an Bord käme hier für einen H.264 Endcoder der HD (1080p) beherrscht, in Frage? 2. Und wieviel Strom würde die PCIe Karte mit FPGA benötigen? 3. Gibt es fertige Open Source H.264 Encoder in VHDL, so daß ich meinen FPGA nur noch programmieren müßte? (Da ihr an so etwas arbeitet, schätze ich mal, daß es so etwas noch nicht gibt) Was ich nicht brauchen könnte, wäre ein FPGA der selbst das TV Videosignal direkt von der TV Dose entgegen nimmt. Das sollte nach wie vor die DVB-C Karte machen. Denn ich möchte für die DVB-C Karte irgendwann auch ein CI+ (Common Interface Plus) kaufen bzw. eine TV Karte mit so einem Interface, womit ich dann zumindest auch mein PayTV Abo nutzen könnte. Und so etwas kann man aus guten Gründen nicht mit einem FPGA realisieren. Deswegen sollte der FPGA Chip das Videosignal als Datenstrom von der Standard CPU zugeschickt bekommen bzw. ein reiner Encoder sein. Das wäre mein Wunsch. Das Problem ist, daß ich mit FPGAs nur wenig auskenne und so einen H.264 Encoder auch gar nicht selbst erstellen könnte. Studiumbedingt habe ich zwar mit Verilog, ISE und einer Spartan 3e mal ein Lauflicht und ähnliches erstellt, aber die Gatter einzeln verschoben usw. habe ich nie. Das Spartan 3 Bord hat darüberhinaus auch der Hochschule gehört, d.h. ich habe keine FPGA Hardware. Auch wäre ich deswegen mit dem Thema also völlig überfordert und habe auch nicht die Zeit mich in das Thema reinzuarbeiten, weil ich in meiner Freizeit an anderen Software Projekte mit normaler Standard Hardware arbeite. D.h. das ist nichts für mich, aber vielleicht wollt ihr so ne art Open Source Hardware machen und die fertige H.264 VHDL Implementierung jedem frei zur Verfügung stellen. In diesem Fall bräuchte ich nur noch einen ausreichend dimensionierten FPGA auf einer PCIe Karte. Welche würdet ihr mir da empfehlen? Auf jedenfall wollte ich euch damit sagen, daß es durchaus Leute gibt die so etwas gut gebrauchen könnten, aber leider sich nicht auskennen und nur zuschauen können. :(
PS: Eines habe ich noch vergessen zu erwähnen. Ich weiß leider nicht was so eine PCIe Karte mit FPGA Chip onboard kostet, aber die Kosten sollten noch in einem vertretbarem Rahmen liegen, denn sonst kann ich das ganze vergessen. Der Computer sollte nämlich wie schon gesagt Strom sparen umd damit wieder Geld zu sparen, wenn jetzt aber diese PCIe Karte mit FPGA Chip über 300 € kostet, dann kann ich für das Geld auch gleich eine normale aber schnelle Standard CPU kaufen und das gesparte Geld in die dann höheren Stromkosten stecken. Das ganze sollte also so gesehen schon Sinn machen. Gibt es also solche FGPA Boards überhauot auf einer PCIe Karte zu einem vertretbarem Preis? Also unter 300 €?
Dann noch etwas zum Schluß. Zur Not würde es auch eine PCI Karte anstatt PCIe tun, aber ich bin mir nicht sicher ob deren Bandbreite für HD Videomaterial ausreicht. Immerhin würde das von der Onboard GPU unkomprimiert an die FPGA Karte gesendet werden. Auch ist PCI nicht mehr so zukunftssicher, daher wäre PCIe IMO sinnvoller.
@Ein Gast (Gast): Das, was Du vorhast wirst Du mit einem FPGA nicht realisieren können. 1) Das FPGA ist zu teuer. Ein PCIe-DevKit kostet vielleicht 1000€ (ich habe selbst ein Arria GX-Kit). Dabei schafft dieses Arria GX nicht mal H.264 in HD (hab' schon alles durch, eindeutig zu wenig Ressourcen) 2) Das ganze unter 30 Watt kannst Du auch vergessen. Vielleicht "nur" FPGA und Co, aber nicht mit einem PC kombiniert Bei mir ist die ganze Sache mit H.264 etwas eingeschlafen, weil ich mein Vorhaben mit einem dedizierten Chip realizieren kann -- so ein Codec kann sowohl En- als auch Decodieren und hat sogar Speicher drin. Preis ca. 250 €. Mit einem FPGA komme ich nicht da drunter :-( Ich bleib' zwar dran, aber die FPGAs, die sowas schaffen können kommen vielleicht erst in ein Paar Jahren (ich meine, FPGAs, die das schaffen und nicht teuer sind ;-)) Grüße, Kest
Ein Gast wrote: > Gibt es also solche FGPA Boards überhauot auf einer PCIe Karte zu einem > vertretbarem Preis? > Also unter 300 €? Definitiv nicht. Schau mal bei Xilinx, was meinetwegen ein Virtex 5 Board mit PCIe kostet. Und dann schau mal auf den Stromverbrauch. Dein Vorhaben ist sinnlos. Wir setzen zum Beispiel recht kleine Virtex 4 LX40 ein, die kosten in geringen Stückzahlen über 400 Euro das Stück. Nur der nackte Chip. Für sowas wie H.264 brauchts eventuell mehr Ressourcen, kannst bei Xilinx mal schauen, was die großen Virtex 5 mit DSP-Optimierung kosten. Da schlackerst du mit den Füßen. Das wird dann schnell 4-stellig.
> Bei mir ist die ganze Sache mit H.264 etwas eingeschlafen, weil ich mein > Vorhaben mit einem dedizierten Chip realizieren kann -- so ein Codec > kann sowohl En- als auch Decodieren und hat sogar Speicher drin. Preis > ca. 250 €. Mit einem FPGA komme ich nicht da drunter :-( Vielen Dank für deinen Hinweis. Also gut dann denke ich nicht weiter über einen FPGA nach. Aber eines würde mich noch interessieren, mit welchem dedizierten Chip löst du dein Vorhaben?
Servus, mich würde auch interessieren, mit welchen dedizierten Chip du das gelöst hast? Hat sich schon wer von euch näher mit dem hardH264-Projekt (http://hardh264.sourceforge.net/) auseinandergesetzt? Hab es jetzt am laufen und bin mit dem Code sehr zufrieden. mfg Martin
Chips, die sowas können gibt es immer mehr: http://www.cavium.com/PureVu_CNW36XX.html oder MB86H55 fon Fujitsu Du hast hardh264 im FPGA am laufen? Welche Auflösung? Welche Hardware? Kannst Du etwas mehr Details nennen? Grüße, Kest
Antwort auf Erfahrungsbericht: Also, ich bin gerade an einem JPEG decoder dran. Er ist auch für MJPEG geeignet, weil der Huffmandecoder eine hohe Durchsatzrate erreicht. Zum Entschlüsseln des Huffcodes 2 Takte und zum Laden des nachfolgenden Amplitudenwertes 2 Takte. Also max 4 Takte für ein Wert. Momentan komme ich bei 60Mhz auf eine Spartan 3 heraus. Das würde 15Millionen Zeichen Mindestdurchsatzrate bedeuten. Die große Herausforderung ist der Huffman decoder. Für die einzelnen Bild-Komponenten werden unterschiedliche Codetabellen benutzt. Der Datenstrom besitzt keine feste Länge, das erschwert das Anwenden von vorausschauenden Taktiken, z.B. für die Tabellenumschaltung. Der nachfolgende IDCT ist schon getestet und war im Gegensatz zum Huffman-decoder "nur" Denksport. Auch für den IDCT habe ich auch bereits Ansätze gefunden um diesen auch noch zu verbessern. Diese würde den Platzverbrauch nochmal reduzieren. Ich habe bereits schon eine erhebliche Reduktion erreicht.
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.