Sowas wäre eine nette Aufgabe für FPGAs

[Siga]

Anscheinend ist h.264 encoden wirklich rechenaufwendig.
Sowas wäre eine nette Aufgabe für FPGAs bis die CPUs besser und/oder die Encoder schlauer sind.

Sooo teuer sind die FPGA-Boards nicht und wenn man kewle Anwendungen (encoden, ...) hätte, dann lohnt sich der Kauf u.u. recht schnell.
Statt einem Board(PCI*) dann heutzutagen natürlich ein USB2-Gerät wo der FPGA-Chip drauf ist.

Da aber alles angeblich patentiert ist, kann man es vergessen.
Und weil xilinx und die anderen fette NDA-Klauseln haben (früher zumindest laut ct iirc) kann man nichts dafür verbreiten. "Toll".

[tunnelblick]

oder aber gpus. beide arbeiten halt massiv parallel. und ich denke, dass cuda weitaus einfacher ist als "mal eben" vhdl oder verilog zu lernen, zumal das debuggen eine reine pest auf fpgas ist, weil die synthese bei grossen prijekten sehr lange dauert. achja, "platz" ist auf fpgas auch meist recht wenig, zumindest bei den günstigen.

[H4ndy]

Kauft euch mal die aktuelle c't, da ist ein netter Bericht zu GPGPU-Anwendungen drin. Dort spricht auch ein x264-Entwickler, dass sich H.246 nicht komplett parallelisieren lässt, da bestimmt Rechenschritte mit zu vielen Daten hantieren, die exklusiv verfügbar sein müssen, bzw. die Funktion dahinter nicht parallelisierbar ist (irgendwelche Transformationen).

Mann müsste aber mal probieren x264 in einen FPGA zu gießen und schauen wie schnell der das im Gegensatz zu einer x86-ich-kann-alles-CPU schafft.

[tunnelblick]

die c't habe ich. und nun? kauf du dir besser mal informationen zu fpgas und deren beschränkungen, was platz angeht.

[Siga]

Hardware ist halt parallel. Das muss man verstehen. Und verstehen, was der Algorithmus macht. Und dann vernünftig aufs FPGA bringen so das der Durchsatz maximal wird.

Bei HD1080 (5mal so viel Pixel wie PAL) und h.264 helfen kleine FPGAs wohl auch nicht so wirklich gut.

Die Grafikkarten hatte ich vergessen (siehe auch die aktuellen ct-Artikel auf die H4ndy hinweist). Wenns die billig gibt und man ein Board mit vielen Slots hat/hätte (die GPUs müssten PCI sein), ginge das auch. Ist aber nicht so nett.

Diese Sound-Karte von Creative (x-fi ?) hatte auch viele Einheiten. Man brauchte laut ct zwar für simple Effekte schon ein paar Stück davon (von den 127 Stück oder wieviel das waren) aber das Ding gibts auch sicher nachgeworfen. Blöd nur, das da auch sicher NDA drauf liegt.

So gesehen hast du mit CUDA/... wohl Recht. Ohne Konkurrenz ATI/NVIDIA wäre das aber auch fett NDA und nur für Spezialkarten (dieselben Karten mit nem halben Hertz weniger und dafür ab 1000 Euro und NDA und EntwicklerSoftwareLibs usw.) aber dank Konkurrenz springt es einen an, wenn man nicht aufpasst, ist kostenlos/günstig und offener als früher oder FPGAs :-(

Für Laptops o.ä. aber auch nicht so ganz passend. Und früher oder später möchte man ja doch simpel encoden und kein Rechenzentrum kaufen.

Vor ein paar Jahren auf der cebit: UNI-Paderborn-Professor mit fpga+gzip. Er meinte, wenn man es naiv aufs fpga packt hat man (iirc) 2-4 mal Geschwindigkkeitssteigerung. Das was er sich hat patentieren lassen ( :-( ) wären halt Anpassungen an den gzip-Algorithmus, um deutlich schneller auf dem fpga zu werden.

@H4ndy: Man hat wegen Zappings bei mpeg2 bei DVB-T üblicherweise die I-Frames alle 12 Bilder. Also komprimiert man immer 12er-Packs von Bildern und nutzt die Cores/Treads passend. Für internetVideos o.ä. halt größere BilderPakete. Auf diese Weise kann man immer parallelisieren.

[tunnelblick]

Siga schrieb:
-------------------------------------------------------
> Hardware ist halt parallel. Das muss man
> verstehen. Und verstehen, was der Algorithmus
> macht. Und dann vernünftig aufs FPGA bringen so
> das der Durchsatz maximal wird.

nicht prinzipiell parallel. hier musst du vor allem überlegen, wie du die daten schnell auf den fpga bekommst und wieder auslieferst. mit schnellen interfaces sind fpga-boards nochmal teurer.

> Bei HD1080 (5mal so viel Pixel wie PAL) und h.264
> helfen kleine FPGAs wohl auch nicht so wirklich
> gut.

eben. und die grossen sind abartig teuer.

> Die Grafikkarten hatte ich vergessen (siehe auch
> die aktuellen ct-Artikel auf die H4ndy hinweist).
> Wenns die billig gibt und man ein Board mit vielen
> Slots hat/hätte (die GPUs müssten PCI sein), ginge
> das auch. Ist aber nicht so nett.

gpgpu-fähige grakas kosten laut c't 120 taler - mein fpga-board hat mich 160 ören gekostet.

> Für Laptops o.ä. aber auch nicht so ganz passend.
> Und früher oder später möchte man ja doch simpel
> encoden und kein Rechenzentrum kaufen.

naja, fpgas in laptops? hmm... auch keine super alternative.

> Vor ein paar Jahren auf der cebit:
> UNI-Paderborn-Professor mit fpga+gzip. Er meinte,
> wenn man es naiv aufs fpga packt hat man (iirc)
> 2-4 mal Geschwindigkkeitssteigerung. Das was er
> sich hat patentieren lassen ( :-( ) wären halt
> Anpassungen an den gzip-Algorithmus, um deutlich
> schneller auf dem fpga zu werden.

hmm, finde ich unsinnig. bei packern kommt es heutzutage fast ausschliesslich auf io an.

[falstaff-1]

Schaut mal unter opencores.com, dort gibt es h.264 decoder für FPGA's...

[march]

Siga schrieb:
-------------------------------------------------------
> Anscheinend ist h.264 encoden wirklich rechenaufwendig.
Rechenaufwand ist relativ - warum gibts Universal-CPUs, multicores, Vektorrechner, DSPs, MicroController GPUs, CPLDs und FPGAs ? weil jede Klasse von "Chip" spezifische Vorteile hat (Preis-Leistung, Effizienz (Leistungsaufnahme,Code), Universalität, Durchsatz, Response-Verhalten)

h.264 kommt halt den aktuellen CPUs relativ wenig entgegen.
(normales MPEG4 geht in SW vertretbar schnell, siehe ffmpeg)

> Sowas wäre eine nette Aufgabe für FPGAs bis die
> CPUs besser und/oder die Encoder schlauer sind.- warum gibts
es würde mich nicht wundern, wenn die verbaute CPU irgendwas in der Richtung wäre -
aber vielleicht findest du ja was heraus: mobilygen MG1264

> Sooo teuer sind die FPGA-Boards nicht und wenn man
> kewle Anwendungen (encoden, ...) hätte, dann lohnt
> sich der Kauf u.u. recht schnell.
Frage von Stückzahlen und Aufwand - aber natürlich.

> Da aber alles angeblich patentiert ist, kann man
> es vergessen.
was h.264 / MPEG4 betrifft, das wurde speziell in Hinsicht auf effizientes HW-Encoding + schnelles Decoding designed und ist explizit ein offengelegter Standard, im Gegensatz zu WMV9 (M$...) und Matroska (.mkv; braucht unmotiviert viel Leistung).

Was die FPGA Hersteller betrifft - die halte ich für liberaler als alle anderen in der HW-Branche, denn sie brauchen !!! Stückzahlen !!! + Entwickler + Libraries + Anwendungen, um sich untereinander zu behaupten. Deshalb kriegt man - dankbarerweise - die SDKs seit Jahren hinterhergeschmissen, so wie vorher schon Mikrokontrollerboards und momentan embedded-Linux-Plattformen.

aber selbst wenn so ein Teil dann in der Peripherie gelöst ist, fehlt noch die sauber SW / Systemanbindung, mit einem USB- oder Shared Memory-Treiber ist es noch nicht getan.

[Ann Greifer]

march: Matroska ist nicht nur offen und als open-source implementiert, es braucht auch nicht "unmotiviert viel Leistung". Es ist darüber hinaus kein Codec, sondern ein Container und zwar der flexibelste, modernste und durchdachteste, den es gibt. Aber dass du keine Ahnung hast, sieht man schon daran, dass du "normales MPEG4" und "h.264" gegenüberstellst als seien das völlig unterschiedliche Dinge, dabei ist h.264 Teil von MPEG-4 nämlich MPEG-4 AVC. Was du als "normal" bezeichnest, ist MPEG-4 ASP. AVC ist einfach nur eine effizientere Weiterentwicklung und nicht etwa ein komplett neuer Codec.

h.264 ist auch auf halbwegs aktueller Hardware "vertretbar schnell", wobei das eben davon abhängt, wie effizient man das Material komprimieren möchte. Die meisten Hardware-Lösungen holen da keineswegs das maximal Mögliche heraus, allein schon, weil die Parameter entweder gar nicht oder nur sehr begrenzt anpassbar sind, im Gegensatz zu reiner Software, bei der dem Fein-Tuning kaum Grenzen gesetzt ist, sodass man je nach Bedarf sehr schnell oder sehr stark komprimieren kann, wenn es eben nicht auf die Kodierzeit ankommt.