www.mikrocontroller.net

Forum: FPGA, VHDL & Co. H.264 in FPGA


Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde das ein geniales Projekt. Ist etwas was mich auch sehr 
interessiert.
Hast Du vielleicht ein paar gute Links zum Thema?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Links zum Thema gibt es sehr viele, starte mal damit:

http://www.vcodex.com/h264.html

Grüße,
Kest

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt von Xilinx eine Appnote dazu und ich meine auch einen IP Core
Einfach mal auf deren HP ein bisschen rumsuchen

Gruß

Autor: Nephilim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MW (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor ich es vergesse -- hier ist was interessantes! :-)

http://www.drtonygeorge.com/Video/h264/h264_rtl.htm

Kest

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> 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

Autor: Tony George (Firma: Satyam) (ewizlab)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :(

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 €?

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.