H.264 in FPGA

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

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

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

@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

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

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

> 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