Forum: FPGA, VHDL & Co. Filter auf HDMI 1080i Signal


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von EchtzeitMuss (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich muss für ein Projekt ein 1080i=720p 25fps Signal in Echtzeit 
Filtern,
z.B. Kantendetektion, Hochpassfilter... Kriegt das ein FPGA hin? Welches 
bräuchte ich da? Ich kann nur schwer einschätzen, wie leistungsstark der 
FPGA sein muss.

von Ingo L. (corrtexx)


Bewertung
0 lesenswert
nicht lesenswert
EchtzeitMuss schrieb:
> Ich kann nur schwer einschätzen, wie leistungsstark der
> FPGA sein muss.
Und hier kann keiner hellsehen, solange du nicht mehr Infos bringst

von Gustl B. (gustl_b)


Bewertung
2 lesenswert
nicht lesenswert
Mach das zuerst in der Simulation. Und guck dann wie viel FPGA Hardware 
dazu benötigt wird.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,


So ganz allgemein:

> Kriegt das ein FPGA hin?
Ja.

> Welches bräuchte ich da?
Kein ganz kleines.

> Ich kann nur schwer einschätzen, wie leistungsstark der FPGA sein muss.
Unterschaetze nicht den Aufwand, dein Signal in's FPGA zu bringen und 
wieder raus. Also alles ausser Filtern.

Gruss
WK

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
EchtzeitMuss schrieb:
> Moin,
>
> ich muss für ein Projekt ein 1080i=720p 25fps Signal in Echtzeit
> Filtern,
> z.B. Kantendetektion, Hochpassfilter... Kriegt das ein FPGA hin? Welches
> bräuchte ich da? Ich kann nur schwer einschätzen, wie leistungsstark der
> FPGA sein muss.

Das bekommen moderne FPGAs locker hin. Mein Tipp: Erst die Algorithmen 
Entwickeln, durch Simulation verifizieren, dann das FPGA Projekt mit der 
Hersteller Toolchain aufsetzen und dort kannst du dann munter die 
verschiedenen FPGAs durchprobieren und schauen ob sie das Design packen.

In der Xilinx Welt werden das alle modernen Typen hinbekommen, von 
Spartan 7 bis Virtex 7, haengt nur davon ab wieviele Algorithmen du hast 
und wie gross die sind. 1080i @ 25fps sind weit unter 74,25 MHz 
(abhaengig davon wie du das interlaced vorher prozessierst und 
bufferst), das erzeugt heutzutage nur ein muedes Laecheln. ;-)

von Donni D. (donnidonis)


Bewertung
-1 lesenswert
nicht lesenswert
Das solltest du mit nem PC machen. Capture Card rein, und dann gängige 
Libs wie OpenCV etc. nutzen.
Da du scheinbar mit nem FPGA noch nicht wirklich was gemacht hast, wirst 
du kein HDMI und auch keine Filter für Bildsignale in absehbarer Zeit 
hinbekommen.

Außerdem kannst du alles mit Videodateien testen, bevor du dich um HDMI 
Capture kümmerst.

Der Elgato CamLink wäre perfekt dafür geeignet. Der sollte mit OpenCV 
gehen.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Donni D. schrieb:
> Da du scheinbar mit nem FPGA noch nicht wirklich was gemacht hast, wirst
> du kein HDMI und auch keine Filter für Bildsignale in absehbarer Zeit
> hinbekommen.

Ist ja nicht so dass die gaengigen FPGA Hersteller eine Klicki-Bunti 
Anwendung anbieten, in der man fertige IPs einfach zusammenklicken kann.

Und selbst einfachste Filter haben bei uns schon die Praktikanten 
hinbekommen. Man muss halt einfach mal anfangen und machen, dann merkt 
man auch dass alles nur halb so tragisch ist.

von Donni D. (donnidonis)


Bewertung
-1 lesenswert
nicht lesenswert
Das mag vielleicht sein. Aber ein gesamtes System mit HDMI, Filtern, 
Ausgabe etc. wird nicht mal eben aus IPs klicki bunti zusammen gesteckt. 
Zumal je nachdem auch Lizenzkosten fällig werden.

Klar, wenn die Zeit da ist, leg los. Aber warum, wenn es sehr viel 
einfacher, schneller und kostengünstiger am PC geht? Zumal, wenn man mit 
einem FPGA noch nie was zu tun hatte, und es keine Voraussetzung ist, 
einen zu nutzen.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ganz oben steht als Anforderung FPGA. Warum es diese Forderung gibt ist 
doch erstmal Wurst. Woher nimmst du allerdings an, dass sich der FPGA 
einfach durch einen PC mit Processing Kette ersetzen laesst? Vielleicht 
spielen noch andere Bedingungen eine Rolle, warum ein FPGA gewaehlt 
wurde.

Auch weisst du noch nichts ueber den Video in und Output. Vielleicht 
bekommt er die Video Daten schon parallel, vll. hat er entsprechende 
Konverter Chips die HDMI nach parallel machen.

Die Frage ist: Kann ein FPGA die Beispiel Filter bereitstellen und wie 
leistungsstark muss er sein?

Und die Antwort ist: Ja kann er, sogar relativ einfach und daher muss 
das FPGA nichtmal sehr gross sein sondern ist eher in der unteren Klasse 
zu finden. Die Groesse haengt dann letztendlich von der genauen Aufgabe 
ab.

Ich sehe hier noch 0 Grund einen Systemwechsel vorzuschlagen. Lass doch 
den TO einfach seine Erfahrungen machen.

von Donni D. (donnidonis)


Bewertung
-1 lesenswert
nicht lesenswert
Der TE fragt, ob es mit einem FPGA möglich ist. Nicht, dass es mit einem 
FPGA gemacht werden muss. Wenn dem so ist, dann ja, ist es eben so. Ich 
habe lediglich einen Vorschlag gemacht, wie das ganze im Handumdrehen zu 
erledigen ist, halt ohne FPGA. Wenn der TE schreibt es muss ein FPGA 
sein ist doch gut, ich hab lediglich eine zweite Option geäußert.
Und da der Anfangspost danach klang, dass noch wenig Erfahrung mit einem 
FPGA vorhanden ist, ist ein System mit HDMI Eingang nicht der einfachste 
Einstieg.


Da ich nun alles meinerseits zum Thema geäußert hab, bin ich damit erst 
mal raus.

: Bearbeitet durch User
von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Knackpunkt sind die Interfaces, nicht das FPGA ansich.
Es gibt einige Boards mit denen man das machen kann.
Die Frage ist aber allgemein zu schwammig und riecht für mich nach 
Trollerei.
Frei nach Hallervorden: Brauchen mehr Details.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo L. schrieb:
> EchtzeitMuss schrieb:
>> Ich kann nur schwer einschätzen, wie leistungsstark der
>> FPGA sein muss.
> Und hier kann keiner hellsehen, solange du nicht mehr Infos bringst

Wie will er denn den Bildfilter bauen, wenn er nicht weiß wie so was 
aussieht? Und wenn er weiß wie sowas aussieht, kann man die Elemente 
zählen. Manchmal weiß ich wirklich nicht, wen Firmen an ihre Aufgaben 
dranstellen. Ingenieure können das nicht sein ... denn die wissen sich 
zu helfen.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Donni D. schrieb:
> Das solltest du mit nem PC machen. Capture Card rein, und dann gängige
> Libs wie OpenCV etc. nutzen.

Welchen DSP will man da nehmen? Wie schnell kannst du mit open CV in 
Echtzeit arbeiten?

Und welche Capture Card? Die komprimieren doch das Signal, das aber wäre 
doch gerade Aufgabe des FPGA, das vorher zu machen, bevor komprimiert 
wird.

Kantenfilter auf MPG-Kanten ist nicht so prickelig.

von Donni D. (donnidonis)


Bewertung
-1 lesenswert
nicht lesenswert
Da nimmt man gar keinen DSP, sondern die CPU oder eben GPU, je nachdem 
ob und wie die Filter unterstützt werden. Und ja, die Capture Card 
komprimiert das ganze ein bisschen, aber bei einem 720p Signal, bzw. 
generell, wirst du bei einer Datenrate von bis zu 30MBit/s keinen 
Qualitätsverlust wahrnehmen. Und in Echtzeit bekommst du das mit 
moderner Hardware locker hin.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Donni D. schrieb:
> Da nimmt man gar keinen DSP, sondern die CPU oder eben GPU, je nachdem
> ob und wie die Filter unterstützt werden.

Diese Pauschalitaet ist absoluter Unfug. Ein FPGA ist hier genau das 
Mass aller Dinge (nebst spezialisierten ASICs in Bildsensoren die oft 
auch einen ISP entahlten) um Video Signale in Echtzeit zu verarbeiten, 
weil du nur hier das auch wirklich kannst.

Schau dir doch einfach mal den Signal Pfad in einem GPU basierten System 
an. Der erste Frame wird im Speicher gebuffert, dann wendest du einen 
Filter darauf an und wird vor der Ausgabe wieder gebuffert. Da hast du 
schonmal 2 Frames Latenz ohne ueberhaupt etwas weltbewegendes erreicht 
zu haben. Bei einem FPGA hast du das nicht. Deine Latenz ist hier 
begrenzt durch das Pipelining und die liegt in der Regel im Bereich von 
ein paar Pixel, respektive Zeilen wenn du Algorithmen auf vertikaler 
ebene hast.

Ein Hochpassfilter ist da ein super Beispiel. Hochpassfilter die rein 
horizontal arbeiten haben sogut wie keine Latenz. Wenn du dann noch die 
vertikale Ebene dazu nimmst, dann musst du entsprechend Zeilen buffern 
damit dir die Information aus mehreren Zeilen vorliegt.

Ein Beispiel dazu aus meiner taeglichen Praxis sind Endoskop Systeme wo 
Hochpass Filter gerne eingesetzt werden um feinste Adern oder Nerven 
hervorzuheben, damit der Arzt nicht ausversehen mit dem Skalpel da 
reinschneidet. Hier werden bei allen grossen Herstellern FPGAs fuer das 
Video Processing verwendet um die Latenz moeglichst gering zu halten. 
Nichts ist ekliger als Latenz bei der Fuehrung des Endoskops, aehnlich 
wie ein Keyboard Spieler der zuviel Delay zwischen Tastendruck und der 
Wahrnehmunng des Tons im Ohr hat.

: Bearbeitet durch User
von Donni D. (donnidonis)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe garn ichts pauschalisiert, meine Antwort bezieht sich auf den 
Text darüber, und da wird gefragt, welchen DSP ich einsetzen würde um 
mit OpenCV etc. die Daten zu Verarbeiten. Und da ist ganz klar die 
Antwort: gar keinen.

Wenn der TE 100% Echtzeit / Vorhersehbarkeit bei einer Verarbeitung 
haben möchte, kann er ja den FPGA nehmen. Ich habe, wie aber auch schon 
10 mal erwähnt, lediglich eine Möglichkeit aufgezeigt, wie es einfach, 
schnell und kostengünstig mit dem PC funktioniert.

Wenn du im medizinischen Bereicht arbeitest, wo du die von mir 
vorgestellte Möglichkeit nicht nutzen kannst, ist das ja Ok. Ich 
bezweifle aber, dass der TE das hier auch benötigt. Und wie groß die 
Latenz in wirklichkeit ist, wenn man es mit einem GPU basiertem 
Processing macht, kann ich nicht sagen, wenn du da Infos zu hast wäre 
ich sehr interessiert daran, ich bezweifle aber, sie liegt weit 
unterhalb der Wahrnehmungsgrenze. Alles was ich auf Anhieb so beim 
schnellen Googlen gefunden habe, zeigt eine Processingzeit von <3ms, 
meist je nach Filter <1ms. Wenn einem das nicht reicht, kann man immer 
noch zum FPGA greifen.

Wie gesagt, ich will das Processing mit dem FPGA in keinster weise 
schlecht reden, ich nutze auch FPGAs für Breitbandige Ethernet 
Processings, aber wo es geht probiere ich eher auf Software / Pc zu 
setzen, weil es "einfacher", schneller und günstiger ist.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Donni D. schrieb:
> Ich habe, wie aber auch schon
> 10 mal erwähnt, lediglich eine Möglichkeit aufgezeigt, wie es einfach,
> schnell und kostengünstig mit dem PC funktioniert.

Bei einem FPGA bist du ebenfalls schnell und kostenguenstig unterwegs. 
Vor allem wenns um Stueckzahlen geht. Auch die Entwicklung ist kein 
Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in 
moderne FPGA Enwicklungsmethoden macht kein Unterschied.

Donni D. schrieb:
> Und wie groß die
> Latenz in wirklichkeit ist, wenn man es mit einem GPU basiertem
> Processing macht, kann ich nicht sagen, wenn du da Infos zu hast wäre
> ich sehr interessiert daran, ich bezweifle aber, sie liegt weit
> unterhalb der Wahrnehmungsgrenze. Alles was ich auf Anhieb so beim
> schnellen Googlen gefunden habe, zeigt eine Processingzeit von <3ms,
> meist je nach Filter <1ms. Wenn einem das nicht reicht, kann man immer
> noch zum FPGA greifen.

Das haengt davon ab was du machen willst. Nimmst du z.B. die 
Bildverarbeitung um die Video Daten von einem Bildsensor zu verarbeiten. 
Dann hast du eine relativ grosse Verarbeitungskette (DeBayering, 
Farbkorrektur, Noise Reduction, Gamma Korrektur und in der Regel noch 
weitere Farbanpassungen, z.B. Saettigung, und Format Anpassungen um den 
Monitor zu Speisen).

Das Problem bei einem GPU bsiertem System ist nun, dass mit jedem 
weiterem Filter das ganze anfaengt nicht mehr zu funktionieren und 
Frames gedroppt werden mussen. Das System skaliert einfach unglaublich 
schlecht. Bei einem FPGA hast du das Problem nicht, der skaliert rein 
mit seiner groesse.

Die Angabe von der Processing Time ist natuerlich so erstmal sinnlos. 
Aber ja, es gibt Systeme in denen sind 3ms schon gefaehrlich. Man denke 
an autonomes Fahren. Deshalb kommen hier auch FPGAs zum Einsatz und 
nicht wenig. Ebenso sind die 3ms nur die Verarbeitungszeit. Dazu kommt 
noch das Capturen des Eingangs und das Buffern fuer die Ausgabe. Da bist 
du dann schon bei 2 Frames, macht bei 60 Hz ueber 32 ms. Mit speziellen 
Capture Karten kann man auch hier optimieren, z.B. wenn man eine nimmt 
die nicht komprimiert, dann kann man direkt mit dem RAW Processing 
beginnen sobald die Daten da sind. Das OS mit seinem Scheduler 
verhindert aber auch hier, dass das ein Echtzeit Processing ist.

Donni D. schrieb:
> Wie gesagt, ich will das Processing mit dem FPGA in keinster weise
> schlecht reden, ich nutze auch FPGAs für Breitbandige Ethernet
> Processings, aber wo es geht probiere ich eher auf Software / Pc zu
> setzen, weil es "einfacher", schneller und günstiger ist.

Passt halt in keinster Weise zu den Anforderungen des TO. Und die 
Empfehlung das mit einem PC zu machen zeugt nicht gerade von 
Professionalitaet. Daher sollte man wenn man in dem Bereich nicht 
arbeitet sich vielleicht ein bisschen zurueckhalten und nicht erklaeren 
was jemand machen soll sondern wie man es selbst machen wuerde. Ds 
wuerde auch die eigene Kompetenz auf dem Gebiet klarstellen was wiederum 
hilft die Qualitaet der vorgeschlagenen Loesung zu bewerten. ;-)

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Auch die Entwicklung ist kein
> Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in
> moderne FPGA Enwicklungsmethoden macht kein Unterschied.
Soso. Ich kann diese Einschätzung nicht teilen.

> Und die
> Empfehlung das mit einem PC zu machen zeugt nicht gerade von
> Professionalitaet.
Eigentlich schon. Erstens sind die Dinger billig und weit verbreitet, 
zweitens weiß der TO doch noch gar nicht, welche Filterung er genau 
will. Man kann erst dann optimieren, wenn die Verarbeitungskette klar 
ist.
Natürlich kann ein FPGA die richtige Lösung sein. Aber möglicherweise 
sitzt der auf einer Grabberkarte oder es kümmert sich doch eine GPU oder 
eine CPU um die Bilddaten.

Und Echtzeitfähigkeit geht auch mit Windows. Man muß Windows in eine 
eigene Task stecken, so wie es Beckhoff bei seiner SPS macht.

Duke

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Tobias B. schrieb:
>> Auch die Entwicklung ist kein
>> Hexenwerk, ob man sich da in die PC Programmierung einarbeitet oder in
>> moderne FPGA Enwicklungsmethoden macht kein Unterschied.
> Soso. Ich kann diese Einschätzung nicht teilen.

Dann hast du dich auch noch nicht wirklich damit befasst. Ich bin imemr 
wiede beeindruckt was selbst Bacheloranten in relativ kurzer Zeit 
hinbekommen. MAn muss sich halt mit den modernen Methoden befassen, dann 
kommt man auch in kuerzester Zeit an sein Ziel.

Beispiel zum Thema:

https://shop.trenz-electronic.de/de/28871-Zybo-Z7-20-akademisch-Zynq-7000-ARM/FPGA-SoC-Plattform-SDSoC-Voucher

Dazu gibt es ein HDMI BEeispiel:

https://github.com/Digilent/Zybo-Z7-20-hdmi

Wenn man das als Startpunkt nimmt, dann bekommt selbst ein Anfaenger in 
ein paar Tagen seinen ersten Video Filter zum laufen. Der Rest ist wie 
bei allem auch Uebungssache. Man muss halt einfach mal furchtlos an die 
Sache rangehen und FPGAs nicht als etwas Komplexes betrachten. Wenn ich 
mir da ein PC System anschaue, mit all seinen HW Komponenten, nemm OS, 
der Application, dann ist das doch deutlich komplizierter als etwas was 
bare-metal auf nemm FPGA laeuft.

Duke Scarring schrieb:
> Und Echtzeitfähigkeit geht auch mit Windows. Man muß Windows in eine
> eigene Task stecken, so wie es Beckhoff bei seiner SPS macht.

Sorry, das ist aber alles andere als Echtzeit (allein Windows ist 
nichtmal ansatzweise ein Echtzeit Betriebssystem). Und genau daher 
widerspreche ich dem, dass man via PC an die Aufgabe rangehen sollte.

von Donni D. (donnidonis)


Bewertung
0 lesenswert
nicht lesenswert
Du redest von Anforderungen des TE, der hat aber bis auf: Filter, HDMI 
und 720p NICHTS gesagt. Seine Anforderung Echtzeit kann da vieles 
Bedeuten, erstmal heißt es Latenz 0ms und das geht so eh nicht. Also 
gehe ich erst mal davon aus, der will es nicht aufzeichnen und 
Bearbeiten, sondern direkt wieder ausgeben.  Und gemeldet hat er sich 
seit dem Startposting auch nicht mehr. Und das die Einarbeitung in einen 
FPGA genau so einfach sein soll wie für PC Software, würde ich wie Duke 
Scarring auch anzweifeln. Gerade wenn es ans Timing geht kann es recht 
knifflig werden. Muss nicht, aber kann. Wenn er schon Erfahrung hat mit 
FPGAs kann es alles schneller gehen.

Und wieso du dauernd von 2 Frames minimale Letenz redest ist mir auch 
nicht ganz klar. Capturecard Bild rein, Kopieren auf die GPU per DMA, da 
setze ich mal Frech 0ms an, ok 1ms, Bearbeitung 3ms, und das Teil kann 
schon in die Ausgabe.

Wie gesagt, ich kenne mich auch mit FPGAs aus und nutze sie selber, aber 
solang der TE nicht seine Echtzeitfähigkeit und von Latenz <1ms redet, 
bleibe ich dabei, PC ist die bessere Wahl.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Sorry, dass ist störe, aber Echtzeit bedeutet nur, dass das System 
innerhalb einer vorher definierten Zeit garantiert ein Ergebnis liefert. 
Da kann man die Zeit auch auf einen Tag festsetzen, wenn das System das 
erfüllt ist es ein Echtzeitsystem.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Donni D. schrieb:
> Du redest von Anforderungen des TE, der hat aber bis auf: Filter, HDMI
> und 720p NICHTS gesagt. Seine Anforderung Echtzeit kann da vieles
> Bedeuten, erstmal heißt es Latenz 0ms und das geht so eh nicht.

Genau und all diese sind mit einem FPGA easy abgedeckt. Ich seh da nicht 
ansatzweise ein Problem. Auch seine Beispiel Algorithmen sind einfache 
Beispiele die sich super implementieren lassen, mittels HLS sogar 
einfacher und schneller als man denkt.

Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach 
dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein 
paar Pixel Clockzyklen, also im ns Bereich. Da darf man dann schon von 
wirklicher Echtzeit sprechen, zumal ein FPGA da rein deterministisch ist 
und die Latenz konstant bleibt.

Donni D. schrieb:
> Und das die Einarbeitung in einen
> FPGA genau so einfach sein soll wie für PC Software, würde ich wie Duke
> Scarring auch anzweifeln. Gerade wenn es ans Timing geht kann es recht
> knifflig werden. Muss nicht, aber kann. Wenn er schon Erfahrung hat mit
> FPGAs kann es alles schneller gehen.

Das haben frueher meine Praktikanten schon hinbekommen und selbst die 
Studenten wenn wir einen Versuchsaufbau bei irgendwelchen Hochschultagen 
hatten. FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk. 
Man muss halt einfach mal ran und anpacken. Hilfe gibts im Netz mehr als 
genug.

Donni D. schrieb:
> Und wieso du dauernd von 2 Frames minimale Letenz redest ist mir auch
> nicht ganz klar. Capturecard Bild rein, Kopieren auf die GPU per DMA, da
> setze ich mal Frech 0ms an, ok 1ms, Bearbeitung 3ms, und das Teil kann
> schon in die Ausgabe.

Weil die Capture Karte das Bild erstmal dekomprimieren muss. Mit dem 
komprimierten Bild kannst du im Processing nichts anfangen, das muss raw 
vorliegen. Und falls du das Bild wieder ausgeben moechtest (dazu hat der 
TO wie du schon schreibst nichts angegeben), dann muss er das Bild in 
einen Framebuffer schreiben zum ausgeben. Da braucht er mindestens einen 
Doublebuffer damit er keine Artefakte in der Ausgabe hat. Da kommt dann 
nochmal ein Frame Latenz drauf.

Eine Uebersicht was Framegrabber fuer Latenzen haben, siehst du hier:

https://techwatch.de/testreihen/capture-card-test/

Das ist sogar im Bereich von 10 Frames aufwaerts.

Hier mal noch ein Whitepaper zu dem Thema was ich auf die Schnelle 
finden konnte:

http://www.bertendsp.com/pdf/whitepaper/BWP001_GPU_vs_FPGA_Performance_Comparison_v1.0.pdf

Donni D. schrieb:
> Wie gesagt, ich kenne mich auch mit FPGAs aus und nutze sie selber, aber
> solang der TE nicht seine Echtzeitfähigkeit und von Latenz <1ms redet,
> bleibe ich dabei, PC ist die bessere Wahl.

Und das ist das Problem, es ist keineswegs die bessere Wahl. Evtl. fuer 
dich weil du mit FPGAs nicht so bewandert bist und dir das nicht 
zutrauen wuerdest. Aber selbst Anfaenger koennen heute schon schnell 
Erfolge erzielen (vorallem im Bereich Videoverarbeitung), man muss sich 
halt nur mal trauen.

Gustl B. schrieb:
> Sorry, dass ist störe, aber Echtzeit bedeutet nur, dass das System
> innerhalb einer vorher definierten Zeit garantiert ein Ergebnis liefert.
> Da kann man die Zeit auch auf einen Tag festsetzen, wenn das System das
> erfüllt ist es ein Echtzeitsystem.

Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein 
System setzen dass die Latenz schon nach unten beschraenkt (zumal bei 
einem FPGA die Latenz deterministisch und kosnattn ist, das erreicht ein 
GPU System allein schon durch das OS nicht). Sonst merkt man evtl. viel 
zu spaet dass man aufs falsche Pferd gesetzt hat und darf erstmal nenn 
Technologie Wechsel durchfuehren. Und dann wirds richtig ineffektiv. ;-)

: Bearbeitet durch User
von Donni D. (donnidonis)


Bewertung
-1 lesenswert
nicht lesenswert
Du kannst ja schreiben so viel du willst, von Latenzen und und und. 
Ändert trotzdem nichts daran, das auch du die Anforderungen des TEs 
nicht kennst. Vielleicht bist auch einfach du zu sehr auf deine FPGAs 
eingefahren, weil du dich mit Software nicht auskennst? Ich hatte schon 
geschrieben, dass ich auch selbst mit FPGAs arbeite, auch an komplexeren 
Projekten (10G Ethernet etc.).

Scheinbar möchtest du es ja nicht verstehen, dass ich den FPGAs nicht 
abgeneigt bin, aber eben auch Software hier sehr wahrscheinlich 
ausreichend ist, der TE äußert sich ja nicht mehr. Du scheinst dagegen 
zu glauben das Software nie zu gebrauchen ist und für alles, wo man ein 
FPGA einsetzen kann, also quasi alles, auch einen nehmen sollte.

Damit bin ich nun endgültig raus, du scheinst wohl zu festgefahren in 
deiner Meinung zu sein.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach
> dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein
> paar Pixel Clockzyklen, also im ns Bereich.

Was in so ziemlich allen Anwendungsfällen irrelevant ist.
Du bist die Ausnahme, nicht die Regel.

> Da darf man dann schon von wirklicher Echtzeit sprechen,
> zumal ein FPGA da rein deterministisch ist
> und die Latenz konstant bleibt.

Auch das ist normalerweise komplett irrelevant, solange der Jitter 
unterhalb einer Framedauer bleibt.

> Das haben frueher meine Praktikanten schon hinbekommen und
> selbst die Studenten wenn wir einen Versuchsaufbau bei
> irgendwelchen Hochschultagen hatten.

Üblicherweise haben Studenten bei sowas aber mindestens ein Vierteljahr, 
wenn nicht sogar ein Dreivierteljahr Tiefenbespaßung mit FPGAs und HDL.

> FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk.
> Man muss halt einfach mal ran und anpacken.
> Hilfe gibts im Netz mehr als genug.

Für OpenCV mit GPUs gibt es wesentlich mehr.

> Weil die Capture Karte das Bild erstmal dekomprimieren muss.

Blödsinn. HDMI schiebt in aller Regel RGB oder YUV422 raus, da muss nix 
"dekomprimiert" werden (außer "jeweils zwei Pixel verrechnen"). Das ist 
nicht die gleiche Hausnummer wie ein Debayer mit PDAF-Pixelkorrektur.

> Und das ist das Problem, es [PC] ist keineswegs die bessere Wahl.

Für die meisten Anwendungsfälle, wenn es um Entwicklung und nicht um 
Stückzahlen geht, doch.

> Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein
> System setzen dass die Latenz schon nach unten beschraenkt

...du bezahlst also lieber im Voraus für Anforderungen, die 
möglicherweise garnicht existieren. Machst du auch alle anderen 
Datenverarbeitungen im FPGA, auch für den Hobbygebrauch? Weil könnte ja 
sein, dass die UART- oder SD-Kommunikation im ns-Bereich exakt sein 
muss... oder übertreibe ich gerade etwas?

: Bearbeitet durch User
von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit einer PC-Loesung sind durchaus Latenzen im Sub-Frame-Bereich 
moeglich,  es gibt eine Menge industrielle Framegrabber, die das machen, 
und da wird nichts komprimiert.
Nur ist HDMI da nicht gerade Usus.

Da der Fragessteller aber keine Details zu seinen 
'Echtzeitanforderungen' liefert und offenbar auch kein Interesse an 
einer dahingehenden Diskussion hat, ist es wohl auch weiterhin muessig, 
sich darueber zu streiten.

Eine spezifische FPGA-Loesung einzusetzen lohnt sich nur, wenn das 
System embedded/ohne Linux laufen soll/muss 
(Stromsparend/Sicherheitsaspekte usw.) oder eben gerade ein 
Bilderfassungsgeraet ist, was HDMI/GigE ausgibt (und weniger 
latenzbehaftet sein muss als z.B. eine GoPro).

Solange die klassische Frage 'wo sollen die Daten hin' nicht mal 
eroertert wird, macht's auch so gar keinen Sinn, Komplexitaeten a la 
ZynQ reinzubringen.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
So, jetzt zu Effekten und Rechenlast:
Ich habe jetzt als Spaß mal den OpenShot Editor installiert und ein 
1080p Video geladen. Darüber einen Effekt gelegt und das läuft auf 
meiner CPU, 8550U noch fast flüssig. Also ohne das vorher rendern zu 
lassen sondern das wird direkt berechnet. Ohne Nvidia/AMD GPU. Wenn ihr 
einen Videoeditor habt der Kantenerkennung als Effekt bietet dann 
probiert das einfach mal aus.

Aber auch der VLC kann Effekte. Das funktioniert wunderbar flüssig, man 
kann sogar mehrere Effekte gleichzeitig verwendet nur bei zu vielen 
ruckelt das Video dann. Jedenfalls glaube ich dass Kantenerkennung auf 
einer aktuellen CPU oder GPU ohne Probleme läuft. Und bei 1080i/720p 
wunderbar flüssig.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Tobias B. schrieb:
>> Und 0ms nicht, aber Pixel wird verarbeitet im naechsten Taktzyklus nach
>> dem Eintakten. Und das ist nicht 0 ns Latenz, aber im Bereich von ein
>> paar Pixel Clockzyklen, also im ns Bereich.
>
> Was in so ziemlich allen Anwendungsfällen irrelevant ist.
> Du bist die Ausnahme, nicht die Regel.

Dann wird es schleunigst Zeit mal in der Branche ein Praktikum zu 
machen. Deine Aussage ist aber mal sowas von falsch. Kannst ja z.B. mal 
bei Basler nachfragen, einfach mal bei der naechsten Messe an deren 
Stand gehen. Die werden dir sicher gerne erzaehlen wo ueberall ein FPGA 
eingesetzt wird.

S. R. schrieb:
>> Da darf man dann schon von wirklicher Echtzeit sprechen,
>> zumal ein FPGA da rein deterministisch ist
>> und die Latenz konstant bleibt.
>
> Auch das ist normalerweise komplett irrelevant, solange der Jitter
> unterhalb einer Framedauer bleibt.

Auch das ist eine Verallgemeinerung die voellig Praxis fern ist. 
Endoskopie, autonomes Fahren, Broadcasting, Highspeed Imaging zur QS 
(z.B. Sortieranlagen) sind ganz prominente Beispiele in denen das nicht 
toleriert werden kann. Auch die Jitter Grenze von unterhalb einem Frame 
ist absolut willkuerlich dahin geplappert und zeugt von keinerlei 
Fachkompetenz.

S. R. schrieb:
>> Das haben frueher meine Praktikanten schon hinbekommen und
>> selbst die Studenten wenn wir einen Versuchsaufbau bei
>> irgendwelchen Hochschultagen hatten.
>
> Üblicherweise haben Studenten bei sowas aber mindestens ein Vierteljahr,
> wenn nicht sogar ein Dreivierteljahr Tiefenbespaßung mit FPGAs und HDL.

Und in OpenCV etc. muss man sich nicht einarbeiten? Was ist denn dein 
Argument warum du glaubst dass die FPGA Entwicklung komplexer sein soll 
als z.B. mit OpenCV zu arbeiten?

S. R. schrieb:
>> FPGA Entwicklung ist weder etwas Komplexes noch ein Hexenwerk.
>> Man muss halt einfach mal ran und anpacken.
>> Hilfe gibts im Netz mehr als genug.
>
> Für OpenCV mit GPUs gibt es wesentlich mehr

Es gibt auch mehr Salzwasser als Suesswasser auf der Welt, trotzdem bin 
ich froh dass aus meinem Wasserhahn nicht ersteres kommt. ;-) Mehr ist 
keine Metrik fuer besser, wieder durchgefallen.

S. R. schrieb:
> Blödsinn. HDMI schiebt in aller Regel RGB oder YUV422 raus, da muss nix
> "dekomprimiert" werden (außer "jeweils zwei Pixel verrechnen"). Das ist
> nicht die gleiche Hausnummer wie ein Debayer mit PDAF-Pixelkorrektur.

Genau und eine gewoehnliche Grabber Karte, z.B. mit USB Anschluss macht 
dann eine Komprimierung auf das Signal und jagt es z.B. via USB in den 
PC. Klar kannst du auch professionelle Grabberkarten nehmen die dir die 
Daten raw praesentieren. Dann bist du aber auf keinenfall kostenguenstig 
unterwegs. Und Funfact am Rande: Was steckt in diesen KArten drin? Ein 
FPGA, welch Wunder.

S. R. schrieb:
>> Und das ist das Problem, es [PC] ist keineswegs die bessere Wahl.
>
> Für die meisten Anwendungsfälle, wenn es um Entwicklung und nicht um
> Stückzahlen geht, doch.

Bisher hast du nicht einen genannt und redest von den meisten. Auch hier 
ist 0 Inhalt. Ja, auch ich kenne viele Anwendungen in denen ich ein PC 
System bevorzugen wuerde und kann daher sehr wohl abschaetzen wann was 
am besten geeignet ist. Und hier faellt die Wahl ganz klar auf den FPGA.

S. R. schrieb:
>> Das stimmt allerdings. Und genau deshalb wuerde ich niemals auf ein
>> System setzen dass die Latenz schon nach unten beschraenkt
>
> ...du bezahlst also lieber im Voraus für Anforderungen, die
> möglicherweise garnicht existieren. Machst du auch alle anderen
> Datenverarbeitungen im FPGA, auch für den Hobbygebrauch? Weil könnte ja
> sein, dass die UART- oder SD-Kommunikation im ns-Bereich exakt sein
> muss... oder übertreibe ich gerade etwas?

Du machst den gleichen Denkfehler wie Donni, weil du glaubst dass die 
Entwicklung aufwendig ist. Die Beschaffungskosten sind erstmal hoeher 
als beim FPGA. Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer 
bezahlst du alleine die Grabberkarte.

Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar 
schneller, als sich in die unzaehligen PC basierten Video 
Bearbeitungsframeworks einzuarbeiten.

Dazu kommt noch dass du ein System hast mit OS, einer Treiberschicht, 
dem SDK fuer die Grabberkarte und erst dann kommt eine Applikation. Und 
jetzt meinst du ernsthaft dass ist weniger komplex als ein FPGA? Sorry, 
dann wuerde ich ernsthaft mal anfangen ein Praktikum in der 
Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-)

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber auch der VLC kann Effekte. Das funktioniert wunderbar flüssig, man
> kann sogar mehrere Effekte gleichzeitig verwendet nur bei zu vielen
> ruckelt das Video dann. Jedenfalls glaube ich dass Kantenerkennung auf
> einer aktuellen CPU oder GPU ohne Probleme läuft. Und bei 1080i/720p
> wunderbar flüssig.

Fluessig und geringe Latenz sind zwei unterschiedliche paar Schuhe. Was 
hier passiert ist, dass ein paar Frame gebuffert werden um immer einen 
nachschieben zu koennen damit nichts rueckelt. Je groesser der Buffer, 
desto geringer die Wahrscheinlichkeit fuer einen Ruckler, jedoch 
erkaufst du dir damit eine groessere Latenz.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> jedoch
> erkaufst du dir damit eine groessere Latenz.

Exakt. Da wäre es mal interessant was die Anwendung am Ende können soll.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Mit einer PC-Loesung sind durchaus Latenzen im Sub-Frame-Bereich
> moeglich,  es gibt eine Menge industrielle Framegrabber, die das machen,
> und da wird nichts komprimiert.
> Nur ist HDMI da nicht gerade Usus.

Jep Full ACK. Aber dann ist die Loesung auch nicht mehr Easy Peasy 
sondern man muss sich mit dem SDK des Grabbers auseinandersetzen (oft 
hat man da auch spezielle Grabberkarten mit einem FPGA drauf die dann 
relativ easy mit der Hersteller Software programmiert werden koennen um 
das Processing zu uebernehmen). Das ist dann in etwa der gleiche Aufwand 
wie sich mit einer FPGA Toolchain zu befassen, wobei man evtl. noch 
Gefahr laeuft als Privatanwender da nichtmal Zugriff darauf zu bekommen. 
Aber beide Loesungen haben definitiv ihre Daseins Berechtigung.

Strubi schrieb:
> Da der Fragessteller aber keine Details zu seinen
> 'Echtzeitanforderungen' liefert und offenbar auch kein Interesse an
> einer dahingehenden Diskussion hat, ist es wohl auch weiterhin muessig,
> sich darueber zu streiten.

Da wird wohl auch nichts mehr kommen. Aber immerhin dient der Thread 
dazu Wissen zum Thema FPGA vs CPU/GPU zu eroertern.

Strubi schrieb:
> Eine spezifische FPGA-Loesung einzusetzen lohnt sich nur, wenn das
> System embedded/ohne Linux laufen soll/muss
> (Stromsparend/Sicherheitsaspekte usw.) oder eben gerade ein
> Bilderfassungsgeraet ist, was HDMI/GigE ausgibt (und weniger
> latenzbehaftet sein muss als z.B. eine GoPro).

Nicht unbedingt. Auch hier ist Medizintechnik ein gutes Beispiel. FPGA 
macht die Bildverarbeitung Linux System verarbeitet die Patientendaten, 
speichert Bilder und Videos, etc.

Jede Anwendung hat halt eine bestmoegliche Loesung. Und die 
Argumentation das FPGA komplizierter als PC ist, ist halt leider an den 
Haaren herbeigezogen. Gerade die Ganze HLS Geschichte hat die 
Entwicklung von einfachen Videofilter so unfassbar einfach gemacht, dass 
es kein Unterschied mehr ist ob ich da irgendwelchen C Code reinhacke 
oder ein SDK von einer Grabberkarte verwende.

Man sollte einfach aufhoeren den Leuten abzusprechen dass sie Dinge 
nicht hinbekommen, nur weil man selber an seiner Grenze ist. Getreu dem 
Motto: "Wenn ich das kann, kann das jeder" statt "Wenn ich das nicht 
kann, dann du auch nicht". ;-)

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Tobias B. schrieb:
>> jedoch
>> erkaufst du dir damit eine groessere Latenz.
>
> Exakt. Da wäre es mal interessant was die Anwendung am Ende können soll.

Und wenn man das nicht weiss, waehlt man im Zweifel immer die Loesung 
die einen nicht beschraenkt und die Gefahr laeuft dass ein 
Technologiewechsel noetig ist (ganz klassisches Projektrisko 
Management). Kuenstlich Latenz ins System Pumpen kann man am Ende immer 
noch. ;-)

von OhGott (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar
> schneller, als sich in die unzaehligen PC basierten Video
> Bearbeitungsframeworks einzuarbeiten.
>
> Dazu kommt noch dass du ein System hast mit OS, einer Treiberschicht,
> dem SDK fuer die Grabberkarte und erst dann kommt eine Applikation. Und
> jetzt meinst du ernsthaft dass ist weniger komplex als ein FPGA? Sorry,
> dann wuerde ich ernsthaft mal anfangen ein Praktikum in der
> Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-)

So langsam glaube ich, du hast noch nie etwas mit Bildbearbeitung / 
Videoprocessing am PC in Software erledigt.

In die Toolchain schneller einarbeiten, als in die am PC? Was benötigst 
du für die Softwarelösung? Genau, einen Texteditor, wenn es angenehm 
sein soll Atom,  VSCode etc. Fertig. Du installierst dir Python und 
OpenCV, übrigens in einem Command im Terminal erledigt. Und in welche 
unzähligen Frameworks willst du dich einarbeiten? Hier wird NUR von 
OpenCV gesprochen, dem quasi Standard. Hier mal ein paar Beispiele, wie 
wenig Zeilen es braucht, Filter auf ein Bild anzuwenden, die Adaption 
auf ein Video ist dann ein Witz.
https://pythonexamples.org/python-opencv-image-filter-convolution-cv2-filter2d/
Allein für das Constraint File wirst du mehr Zeilen brauchen, als du bei 
der Softwarelösung insgesamt brauchst.

Ja, natürlich hat man ein System mit OS, Treibern, SDK etc. Darum 
kümmert sich aber KOMPLETT die Library OpenCV. Vielleicht solltest du 
mal ein Praktikum bei einer Softwarebude machen, denn dann wirst du 
sehen, man lernt nie aus.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
OhGott schrieb:
> Ja, natürlich hat man ein System mit OS, Treibern, SDK etc. Darum
> kümmert sich aber KOMPLETT die Library OpenCV. Vielleicht solltest du
> mal ein Praktikum bei einer Softwarebude machen, denn dann wirst du
> sehen, man lernt nie aus.

Ich behaupte auch nicht das man mit OpenCV langsam ist, sondern dass man 
mit einer FPGA Loesung genauso schnell ans Ziel kommt. Hier kuemmert 
sich auch das SDK um den HDMI In- und Output und den HLS Code fuer einen 
Videofilter schreibst du auch in einem Texteditor und fertig. Und wenn 
man mag auch direkt als HDL, ist etwas aufwendiger aber nicht dass man 
gleich in ganz andere Zeitskalen vorrueckt.

Ich seh nicht was daran so schwer verstaendlich ist. Wo sind den jetzt 
exakt die Knackpunkte warum das mit einem FPGA so unfassbar viel laenger 
dauern soll? Die ganzen FPGA Hersteller arbeiten immer mehr und mehr 
dahin, dass Rapid Prototyping zu optimieren. Und da hat sich in den 
letzten Jahren eine Menge getan. Einfach mal ausprobieren und dann eine 
Meinung bilden.

OhGott schrieb:
> Allein für das Constraint File wirst du mehr Zeilen brauchen, als du bei
> der Softwarelösung insgesamt brauchst

In der Xilinx Welt uebernimmt das Vivado z.B. komplett fuer dich sofern 
der Hersteller wie z.B. beim Zybo Board ein entsprechendes Board Design 
mitliefert:

https://it.mathworks.com/help/hdlcoder/examples/define-and-register-custom-board-and-reference-design-for-zynq-workflow.html#d120e20791

Du waehlst im Block Design Creator einfach aus welche Features du nutzen 
willst und die Constraints werden automatisch erzeugt.

Vor 10+ Jahre waere die Umsetzung auf einem FPGA in der Tat noch 
wirklich mit Arbeit verbunden gewesen. Aber mittlerweile nehmen die 
Tools einem genausoviel Arbeit ab, wie es die ganzen Software basierten 
Frameworks machen. Man muss sich halt man ransetzen. Ich traue das auch 
einem Anfaenger zu in wenigen Tagen etwas auf die Beine zu stellen.

Aber im Allgemeinen gebe ich da allen recht, dass man mit Software 
schneller ans Ziel kommt. Jedoch auf welchen Zeitskalen wird hier 
diskutiert? Was ich in Software an einem Tag schaffe brauch ich mit 
einem FPGA ja nicht gleich 10 Tage. Man muss sich halt modernen Methoden 
bedienen und dann ist man da ebenfalls flott unterwegs.

von OhGott (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich rede hier von 5 Minuten Installation und 5 Minuten Code 
zusammensuchen, wohl gemerkt, für einen Anfänger mit ein wenig Erfahrung 
im Developer Umfeld. Da du ja scheinbar die Fähigkeiten an deinen misst 
bezüglich Einfachheit etc., kann ich dir sagen, ich schaffe es in unter 
10 Minuten. Da ist wahrscheinlich beim FPGA nicht mal der Fitter durch 
gelaufen.

Niemand hat gesagt, dass ein FPGA in speziellen Scenarios wie Medizin, 
Automotive etc. ersetzt werden sollte. Nur, dass man eben nicht immer 
direkt ein riesen FPGA rankarren sollte, wenn es die Anforderungen nicht 
erwarten.

Zeig doch mal, wie du es in 30 Minuten schaffst, ein System mit HDMI 
Eingang, Ausgang, Hochpassfilterung mit anpassbaren Koeffizienten etc. 
hinzubasteln. Testbenches für Komponenten die nicht vom Hersteller 
kommen natürlich nicht vergessen. Natürlich dann noch schnell 
erweiterbar, falls andere Filter zum Einsatz kommen sollen, ist bei 
Software nämlich nur fix ein Funktionsaufruf. Wenn du all das unter 30 
Minuten schaffst sage ich Respekt, aber zweifle dann trotzdem an, dass 
es jeder andere mit weniger Erfahrung schafft.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
OhGott schrieb:
> Ich rede hier von 5 Minuten Installation und 5 Minuten Code
> zusammensuchen, wohl gemerkt, für einen Anfänger mit ein wenig Erfahrung
> im Developer Umfeld. Da du ja scheinbar die Fähigkeiten an deinen misst
> bezüglich Einfachheit etc., kann ich dir sagen, ich schaffe es in unter
> 10 Minuten. Da ist wahrscheinlich beim FPGA nicht mal der Fitter durch
> gelaufen.

Framegrabber Karte einbauen, Treiber installieren, evtl. noch das 
passende SDK. Auch hier kommt einiges an Arbeit zusammen. Und wenn man 
ein System from scratch aufzieht und ein abgeschlossenes embedded System 
will kommt sogar noch die OS Installation und Konfiguration hinzu.

Auch hier wird das eine unter- und das andere ueberschaetzt.

OhGott schrieb:
> Niemand hat gesagt, dass ein FPGA in speziellen Scenarios wie Medizin,
> Automotive etc. ersetzt werden sollte. Nur, dass man eben nicht immer
> direkt ein riesen FPGA rankarren sollte, wenn es die Anforderungen nicht
> erwarten.

Und ich habe nirgens behauptet dass ueberall FPGAs eingesetzt werden 
muessen. Aber das setzt ein Mindestmass an Textverstaendnis vorraus.

OhGott schrieb:
> Zeig doch mal, wie du es in 30 Minuten schaffst, ein System mit HDMI
> Eingang, Ausgang, Hochpassfilterung mit anpassbaren Koeffizienten etc.
> hinzubasteln. Testbenches für Komponenten die nicht vom Hersteller
> kommen natürlich nicht vergessen. Natürlich dann noch schnell
> erweiterbar, falls andere Filter zum Einsatz kommen sollen, ist bei
> Software nämlich nur fix ein Funktionsaufruf. Wenn du all das unter 30
> Minuten schaffst sage ich Respekt, aber zweifle dann trotzdem an, dass
> es jeder andere mit weniger Erfahrung schafft.

30 Minuten sind unmoeglich, an einem halben Tag kommt man da aber schon 
richtig weit. Und du willst jetzt ernsthaft wegen den paar Stunden 
Mehraufwand die bzgl. Echtzeit Verabreitung schlechtere Technologie 
bevorzugen? Und wenn jemand keine Erfahrung hat, dann schafft er es auch 
nicht einen OpenCV Filter in Python in 5 Minuten zum laufen zu bringen 
und schon gar nicht seinen eigenen zu schreiben.

Testbenches sind dann natuerlich auch keine geschrieben, aber du 
schreibst auch in 5 Minuten nicht deine Unit Tests. Und Unit Tests fuer 
OpenCV sparst du dir wahrsheinlich auch komplett. von daher hinkt der 
Vergleich hier gewaltig.

Durch das AXI Subsystem ist auch eine Erweiterung ueberhaupt kein 
Problem.  Mit dem Vorteil dass ein FPGA seine Echtzeitfaehigkeit behaelt 
wenn die Rechenlast waechst. Auch hier wuerde ich also erstmal auf einen 
FPGA setzen solange die Requirements nicht naeher bekannt sind um mich 
nicht im Vorfeld schon in die Brennesseln zu setzen. Sobald diese naeher 
spezifiziert sind und eine Softwareloesung Sinn macht, wuerde ich auch 
ohne zu zoegern wechseln. Wenn diese aber unbekannt bleiben, muss man 
erstmal pessimistisch an die Sache rangehen, sonst faengt man naemlich 
wieder von vorne an wenn der Projektumfang waechst.

Und mehr habe ich in dieser ganzen Diskussion auch nie behauptet.

Und ich denke nicht dass ich hier irgendjemanden irgendeinen Beweis 
schuldig bin. Du darfst mich aber gerne fuer einen Tagessatz buchen, 
dann siehst du ja was man im Stande ist an einem Tag zu schaffen. ;-)

: Bearbeitet durch User
von OhGott (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achso, du brauchst also kein OS um Mit dem FPGA zu arbeiten. Treiber 
scheinbar auch nicht. Sehr interessant. Testbench nur für selbst 
geschriebene Module, die IPs der Hersteller sollten ja gehen. Für so 
etwas simples wie Videoinput, Filter drauf und Ausgabe ist ja nicht mal 
ein UnitTest erforderlich, das sind ja nur 10 Zeilen testbarer Code. Und 
doch, der OpenCV Filter läuft in 5 Minuten, hab doch ein Beispiel link 
gegeben. Copy and Paste und fertig.

Alles in allem hast du prima dargelegt, dass du scheinbar wenig Ahnung 
von Softwareentwicklung und deren Möglichkeiten hast. Wenn du einen 
halben Tag benötigst für diese simple Aufgabe und dann scheinbar nur 
‚weit gekommen bist’, statt fertig, es jemand anders aber in wegen mir 
30 Minuten macht, fällt mir die Wahl leicht.

Auch im Automotive Bereich wird viel in Software erledigt, kannst ja mal 
bei nVidia vorbei schauen, wie deren Produkte für autonomes fahren etc. 
aussehen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
OhGott schrieb:
> Alles in allem hast du prima dargelegt, dass du scheinbar wenig Ahnung
> von Softwareentwicklung und deren Möglichkeiten hast.

Und du wie wenig Ahnung du von Embedded Systems hast. Ich habe oben doch 
extra den Kontext erlaeutert. Aber im Allgemeinen hast du ein gewaltiges 
Textverstaendnis Problem. Ich meine mich zu erinnern dass es dazu auch 
VHS Kurse zu dem Thema gibt, vielleicht da mal anfragen?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
>>> Und 0ms nicht, aber Pixel wird verarbeitet im naechsten
>>> Taktzyklus nach dem Eintakten. Und das ist nicht 0 ns
>>> Latenz, aber im Bereich von ein paar Pixel Clockzyklen,
>>> also im ns Bereich.
>>
>> Was in so ziemlich allen Anwendungsfällen irrelevant ist.
>> Du bist die Ausnahme, nicht die Regel.
>
> Dann wird es schleunigst Zeit mal in der Branche
> ein Praktikum zu machen.

Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine 
Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte 
Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend.

Die meisten Anwendungsfälle benötigen keine maximale Latenz im 
einstelligen ns-Bereich.

> S. R. schrieb:
> Endoskopie, autonomes Fahren, Broadcasting, Highspeed
> Imaging zur QS (z.B. Sortieranlagen) sind ganz prominente
> Beispiele in denen das [Jitter] nicht toleriert werden kann.

Wir hantieren mit Videos, und (etwas weiter gefasst) auch mit 
Broadcasts. Solange der Jitter unterhalb einer Framelänge bleibt, gibt 
es auf der Ausgabeseite keinerlei messbare Effekte.

Vorne kommen 30-120 fps rein, hinten kommen 30-120 fps raus, die 
Framerate ist auf beiden Seiten absolut stabil. Erkläre mir mal, warum 
die Verarbeitung dazwischen (die Black Box) jetzt auch noch 
pixeltaktgenaue Latenzen haben muss.

> Auch die Jitter Grenze von unterhalb einem Frame ist absolut
> willkuerlich dahin geplappert und zeugt von keinerlei Fachkompetenz.

Nun, wahrscheinlich ist meine Fachkompetenz einfach an anderer Stelle 
als deine Fachkompetenz. Ich sage ja nicht, dass du Unrecht hast - 
sondern dass du ziemlich enge Scheuklappen trägst.

> Und in OpenCV etc. muss man sich nicht einarbeiten?
> Was ist denn dein Argument warum du glaubst dass die FPGA
> Entwicklung komplexer sein soll als z.B. mit OpenCV zu arbeiten?

Ich habe sowohl mit OpenCV als auch mit FPGAs gearbeitet, und die 
letzten Jahre dann mit Kamerasystemen. Diese Erfahrungen - und auch die 
Erfahrungen vieler Studenten, mit denen ich sowohl lernend als auch 
lehrend zu tun hatte, sprechen dafür.

> Genau und eine gewoehnliche Grabber Karte, z.B. mit USB Anschluss
> macht dann eine Komprimierung auf das Signal und jagt es z.B. via
> USB in den PC.

Ich wüsste jetzt nicht, von was für komischem Unfug du da faselst.
So ziemlich jede billige Webcam kann einen YUV-Datenstrom schicken, in 
der Regel ist das NV12. Unsere Lösung schiebt UYVV via MIPI-CSI in den 
SoC.

Klar kannst du dich auch doof anstellen und MJPG anfordern. Dann 
bekommst du einen komprimierten Datenstrom mit recht unbekannter Latenz 
- aber hey, dann hast du dich doof angestellt. Habe ich mich mit meiner 
Bachelorarbeit auch, bis mir das irgendwann aufgefallen ist und ich das 
ordentlich gemacht habe.

> Klar kannst du auch professionelle Grabberkarten nehmen
> die dir die Daten raw praesentieren.

Ich habe hier eine recht antike Microsoft-Webcam, eine etwas bessere 
Logiech-Webcam, und im Büro steht ein professioneller 
HDMI-auf-USB3-Konverter rum. Da kommt überall YUV raus.

> Dann bist du aber auf keinenfall kostenguenstig unterwegs.

Ab 3€ auf dem Grabbeltisch bist du dabei...

> Und Funfact am Rande: Was steckt in diesen KArten drin?
> Ein FPGA, welch Wunder.

Ich bin mir ganz sicher, dass in den Webcams kein FPGA drin ist, viel zu 
teuer und zu energieintensiv. Die eine Cam hat schon gute 10 Jahre auf 
dem Buckel.

Im Framegrabber steckt sicherlich ein FPGA, aber der kann auch 4k30 über 
USB3 und 4k60 in MJPEG in Echtzeit. Aber nur, weil da ein FPGA verbaut 
ist, muss ich für meinen Anwendungsfall keinen verbauen.

Millionen Fliegen fressen Scheiße, deswegen muss das für mich nicht die 
bevorzugte Nahrungsquelle sein.

> Bisher hast du nicht einen genannt und redest von den meisten.

Ich hab ein paar umgesetzt, kann aber darüber nicht reden.
Das, womit ich die letzten Jahre verbracht habe, läuft auf 
Embedded-Systemen. Das sind keine PCs, aber im hier relevanten 
Betrachtungswinkel unterscheiden sie sich nicht besonders.

> Und hier faellt die Wahl ganz klar auf den FPGA.

"Hier" gibt es nichtmal klare Anforderungen. :-)

> Du machst den gleichen Denkfehler wie Donni, weil du glaubst
> dass die Entwicklung aufwendig ist.

Oh, das ist sie. Dein Denkfehler ist zu behaupten, dass FPGA-Entwicklung 
ähnlich einfach und effizient ist wie Programmierung.

> Die Beschaffungskosten sind erstmal hoeher als beim FPGA.
> Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer
> bezahlst du alleine die Grabberkarte.

Aber für die entsprechenden FPGAs sind da die Lizenzkosten für 
Vivado/Quartus noch nicht mit drin. Die IPs für HDMI kommen ebenfalls 
nicht gratis - im Gegensatz zu OpenCV und gcc. Beide mit kommerzieller 
Qualität.

> Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar
> schneller, als sich in die unzaehligen PC basierten Video
> Bearbeitungsframeworks einzuarbeiten.

Es reicht, sich in eine FPGA-Toolchain einzuarbeiten und es reicht, 
sich in ein Bildbearbeitungsframework einzuarbeiten. Schau dich mal 
auf dem Arbeitsmarkt um, was da fähigen Softwareentwicklern rumläuft und 
vergleiche das mit der Anzahl an fähigen FPGA-Entwicklern.

Wenn du FPGA kannst und Software nicht - und so schätze ich dich ein - 
dann bist du ein Paradebeispiel für Hammer, Nägel und Aussehen.

> Sorry, dann wuerde ich ernsthaft mal anfangen ein Praktikum in der
> Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-)

Du scheinst zu glauben, dass ich ein absoluter Anfänger ohne Ahnung bin. 
Ist nicht so. ;-) Bin mit meinem Job auch recht zufrieden, habe bereits 
in der Bildverarbeitungsbranche zu tun und weiß, dass für 
unterschiedliche Anforderungen unterschiedliche Lösungen sinnvoll sind.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine
> Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte
> Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend.
>
> Die meisten Anwendungsfälle benötigen keine maximale Latenz im
> einstelligen ns-Bereich.

Ihr redet so halb aneinander vorbei.

Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel 
dass man damit z. B. keine Shooter mehr sinnvoll zocken kann.

Es geht hier auch nicht um den ns Bereich. Was wirklich sinnvoll ist 
hängt von der Anwendung ab die wir weiterhin nicht kennen. Da bringt das 
ganze Ratespiel nix.

Aber noch zu den Framegrabbern:
Die gibt es in extrem günstig 
Ebay-Artikel Nr. 264798031041? 
aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben 
diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert 
so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch 
USB2.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
>> Sorry, dann wuerde ich ernsthaft mal anfangen ein Praktikum in der
>> Bildverarbeitungsbranche zu machen, man lernt nie aus. ;-)
>
> Du scheinst zu glauben, dass ich ein absoluter Anfänger ohne Ahnung bin.
> Ist nicht so. ;-) Bin mit meinem Job auch recht zufrieden, habe bereits
> in der Bildverarbeitungsbranche zu tun und weiß, dass für
> unterschiedliche Anforderungen unterschiedliche Lösungen sinnvoll sind.

Jetzt nicht mehr, aber du musst auch zugeben dass der jetzige Beitrag 
deutlich mehr Expertise darstellt, als der vorherige. ;-)

S. R. schrieb:
> Bei uns liegt zwischen Sensor und dem fertigen Bild grundsätzlich eine
> Latenz von 8 Frames. Im Highspeed-Modus nutzen wir eine etwas verkürzte
> Pipeline und arbeiten mit 4 Frames. Das ist für uns völlig ausreichend.
>
> Die meisten Anwendungsfälle benötigen keine maximale Latenz im
> einstelligen ns-Bereich.

Das ist schon ein Haufen Holz. Und ich habe auch nie etwas vom 
einstelligen ns Bereich geschrieben. Wenn man keine Daten buffert, dann 
liegt man im Bereich von mehreren Pixel Clockzyklen (da ist man dann 
irgendwo in den 100er ns oder sogar darunter). Sobald man Zeilenspeicher 
braucht ist man im us und wenn ganze Frames gebuffert werden eben im ms 
Bereich. Dort wo es auf Hand / Auge Koordination ankommt hat man haeufig 
die Anforderung dass man unterhalb 2 Frames bleiben muss. Z.B. in der 
Medizintechnik moechte man das weitestgehend druecken, einfach um dem 
Arzt das Gefuehl zu geben dass sich ein digitales Endoskop wie ein 
optisches "anfuehlt". Aehnlich dem Beispiel das ich mit dem Keyboarder 
gegeben habe. Deine 4 Frames sind hier schon 64 ms, da faengt es schon 
an eklig zu werden und 8 Frames mit den 128 ms sind in keinster Weise 
mehr akzeptabel (jeweils bei 60 Hz wohlgemerkt, darunter wirds 
entsprechend schlimmer).

Auch dort wo schnell auf den Bildinhalt reagiert werden muss, z.B. 
Kollisionsdetektion, kann ich mir nicht vorstellen dass 8 Frames 
akzeptabel sind. Ein Auto das mit 30 m/s = 108 km/h unterwegs ist, legt 
in 128 ms eine Strecke von 3.6m zurueck. Das ist ein Haufen Holz wenns 
darum geht den Fussgaenger ueber den Haufen zu fahren oder nicht.

S. R. schrieb:
> Nun, wahrscheinlich ist meine Fachkompetenz einfach an anderer Stelle
> als deine Fachkompetenz. Ich sage ja nicht, dass du Unrecht hast -
> sondern dass du ziemlich enge Scheuklappen trägst.

Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob ein FPGA 
geeignet ist. Ja das ist er und zwar richtig gut. Ohne weitere Infos 
nehme ich erstmal an dass er erstmal harte Echtzeit Bedingungen hat und 
ich impliziere durch die Frage nach dem FPGA dass er ein Embedded System 
moechte (sonst haette er nicht nach nemm FPGA gefragt sondern wohl 
gleich wie er mi den Daten in den PC kommt, soviel Verstand traue ich 
jemanden zu der hier fragt).

Und ich finde es immer wieder verwerflich wenn Leute eine klare Frage 
stellen (in diesem Fall schafft das ein FPGA und welche Leistungsklasse 
braucht er) immer wieder der Einwand kommt es anderst zu machen, obwohl 
die Aufgabe nicht bekannt ist. Es wird doch einen Grund geben warum er 
nach FPGA fragt, ich behaupte das ist eine gute Idee und in dem ganzen 
Topic hab ich eingeworfen dass das auch kein Aufwand ist und er da ein 
Lebenswerk vor sich hat. Nicht mehr und nicht weniger.

Wenn beim Requirements Engineering erstmal keine Fakten vorhanden sind, 
dann geht man eben vom schlimmsten aus, zumal in diesem Fall ein FPGA 
nicht ansatzweise so schlimm ist wie dargestellt. Kantendetektion udn 
Hochpassfilter sind 2 hervorragende Beispiele die sich im FPGA 
implementieren lassen. Da braucht selbst ein Anfaenger nicht davor 
zurueck zuschrecken.

S. R. schrieb:
>> Du machst den gleichen Denkfehler wie Donni, weil du glaubst
>> dass die Entwicklung aufwendig ist.
>
> Oh, das ist sie. Dein Denkfehler ist zu behaupten, dass FPGA-Entwicklung
> ähnlich einfach und effizient ist wie Programmierung.

Naja du beschreibst halt immer noch nicht wo da irgendwelche potentielle 
Huerden sein sollen. Das ist halt auch wieder nur inhaltloses Geblubber 
und zeugt nicht davon, dass du viel Erfahrung in der FPGA Entwicklung 
hast (zumindest nicht in der modernen).

S. R. schrieb:
>> Und Funfact am Rande: Was steckt in diesen KArten drin?
>> Ein FPGA, welch Wunder.
>
> Ich bin mir ganz sicher, dass in den Webcams kein FPGA drin ist, viel zu
> teuer und zu energieintensiv. Die eine Cam hat schon gute 10 Jahre auf
> dem Buckel.

Wuesste nicht wo ich das behauptet habe, eine Webcam ist halt auch keine 
HDMI Grabberkarte. ;-)

S. R. schrieb:
>> Die Beschaffungskosten sind erstmal hoeher als beim FPGA.
>> Ein Evalboard mit HDMI In/Out liegt bei ca. 200€. Dafuer
>> bezahlst du alleine die Grabberkarte.
>
> Aber für die entsprechenden FPGAs sind da die Lizenzkosten für
> Vivado/Quartus noch nicht mit drin. Die IPs für HDMI kommen ebenfalls
> nicht gratis - im Gegensatz zu OpenCV und gcc. Beide mit kommerzieller
> Qualität.

Lizenzkosten fallen fuer das obige Board keine an und die IPs kann er 4 
Stunden frei nutzen bevor sie Offline gehen. Danach muss er das Board 
resetten. Wenn er das ganze verkommerzialisiert dann kann er auch das 
bisschen Kleingeld fuer die IPs berappen.

S. R. schrieb:
>> Und um sich in die FPGA Toolchain einarbeiten geht wahrscheinlich sogar
>> schneller, als sich in die unzaehligen PC basierten Video
>> Bearbeitungsframeworks einzuarbeiten.
>
> Es reicht, sich in eine FPGA-Toolchain einzuarbeiten und es reicht,
> sich in ein Bildbearbeitungsframework einzuarbeiten. Schau dich mal
> auf dem Arbeitsmarkt um, was da fähigen Softwareentwicklern rumläuft und
> vergleiche das mit der Anzahl an fähigen FPGA-Entwicklern.
>
> Wenn du FPGA kannst und Software nicht - und so schätze ich dich ein -
> dann bist du ein Paradebeispiel für Hammer, Nägel und Aussehen.

Ich mache sowohl das eine, als auch das andere, daher kann ich das auch 
ganz gut miteinander vergleichen. Und ich behaupte auch nicht dass man 
mit einem FPGA schneller unterwegs ist, jedoch sind die Zeitskalen nicht 
so dramatisch weit auseinander wie hier gemacht wird. Und wenn das ganze 
in ein Embedded System verpackt wird, dann holt der FPGA auch noch 
deutlich auf, weil der ganze OS Spass mit Yocto oder Buildroot 
wegfaellt. Bis da ein System mal durchkonfiguriert ist und gebaut, geht 
auch einige Zeit ins Land. Nicht zu vergessen der Wartungsaufwand den du 
dir einfaengst weil du ein viel komplexeres System hast (kannst ja mal 
ein Schichtenmodell fuer beide Varianten aufstellen).

Ich bevorzuge halt in allen Bereichen moderne Loesungen und moderne 
Loesungen gehen halt immer mehr in Richtung rapid Prototyping und da hat 
die FPGA Welt in den letzten paar wenigen Jahren extremst aufgeholt. Da 
muss man sich halt mal rantrauen, dann erkennt man auch das Potenzial.

Gustl B. schrieb:
> Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel
> dass man damit z. B. keine Shooter mehr sinnvoll zocken kann.

Immerhin gehen in dem Bereich die Latenzen vom OS Scheduler unter. ;-)

Aber ein interessantes Beispiel mit den Spielen, jedoch in der 
Diskussion nicht ganz passend, weil moderne Grafikkarten (zumindest die 
fuer die Spieler) halt aufs Rendern optimiert sind. Da muessen dann 
deutlich weniger Daten im Speicher geschoben werden was die Latenzen 
auch wieder angenehm nach unten drueckt.

Gustl B. schrieb:
> Aber noch zu den Framegrabbern:
> Die gibt es in extrem günstig
> Ebay-Artikel Nr. 264798031041?
> aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben
> diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert
> so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch
> USB2.

Sicher nicht, aber wie du sagst, da ist nix mit Rohbild. Da wird ein 
kleiner ARM basierter Prozessor mit einem Hardware H.264/265 oder 
aehnlichem Encoder drinnen stecken. Aehnlich wie ein Raspberry Pi nur 
abgespeckt.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Ich behaupte auch nicht das man mit OpenCV langsam ist, sondern dass man
> mit einer FPGA Loesung genauso schnell ans Ziel kommt. Hier kuemmert
> sich auch das SDK um den HDMI In- und Output und den HLS Code fuer einen
> Videofilter schreibst du auch in einem Texteditor und fertig. Und wenn
> man mag auch direkt als HDL, ist etwas aufwendiger aber nicht dass man
> gleich in ganz andere Zeitskalen vorrueckt.

Jetzt aber nicht im Ernst, oder?

Bei der so tollen HLS-Geschichte sind noch einige Dinge nicht sauber 
definiert, wie Rundungen, Dithering, Overflow-Szenarion, etc. - aber aus 
C-Konstrukten HDL zu machen ist auch einfach IMHO broken by design.

Das dann aber in Verbindung mit med. Diagnostik zu bringen? Sehr mutig.
Den jetzigen Status kenne ich nicht, beim letzten Regresstest, nachdem 
das Vivado-Zeug in die Ecke flog, stellte sich raus: Simulation korrekt, 
post-map-Verifikation: Overflow-Szenario moeglich. Ja, man hat ein 
schnelles Ergebnis, aber debuggt sich dann einen Wolf bei den Details.

Als ich das letzte mal beim grossen X am Stand (EW 2018) eine 
HLS-Filter-Demo gesehen habe, stellte sich auf genaue Nachfrage hinaus, 
dass ein Teil auf dem ARM-Core laeuft, aus Zeitgruenden, gemeint war die 
Erstellungsdauer der Demo. Bei einer anderen Bude, die ich hier mal 
nicht nenne, habe ich mit ner blauen LED-Lampe in die Linse geleuchtet. 
Ups, woher kommt das Schwarz?

Lasse mich gerne updaten, aber glaube es nur noch, wenn ich die 
Testbench der vollen Simulation, und zwar im VHDL-Modell gesehen habe 
(es gibt eine Menge kaputter Verilog-Modelle, die signed extension nicht 
richtig machen).

Zum Thema SDK/Linuxkameras wurde wohl schon alles gesagt, man kriegt mit 
einer gstreamer-OpenCV-Pipeline locker unter 30 ms Latenz hin. Geht auch 
drunter (< 1ms mit RT-Erweiterungen wie Xenomai), aber da die Interfaces 
schon gar nicht geklaert sind, sind Ende-Zu-Ende-Erwaegungen erst mal 
voellig irrelevant.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Bei der so tollen HLS-Geschichte sind noch einige Dinge nicht sauber
> definiert, wie Rundungen, Dithering, Overflow-Szenarion, etc. - aber aus
> C-Konstrukten HDL zu machen ist auch einfach IMHO broken by design.
>
> Das dann aber in Verbindung mit med. Diagnostik zu bringen? Sehr mutig.
> Den jetzigen Status kenne ich nicht, beim letzten Regresstest, nachdem
> das Vivado-Zeug in die Ecke flog, stellte sich raus: Simulation korrekt,
> post-map-Verifikation: Overflow-Szenario moeglich. Ja, man hat ein
> schnelles Ergebnis, aber debuggt sich dann einen Wolf bei den Details.

Manche Dinge gehen gut, manche nicht. Von Diagnostik habe ich docht 
nichts geschrieben, wobei auch das Feld Diagnostik riesig ist. Einen 
Hochpass Filter ist Beispielsweise ein gutes Beispiel wo HLS die 
Entwicklung beschleunigen kann, die besser sichtbaren Kanten koennen der 
Diagnostik dienen. Haengt jetzt davon ab was du unter Diagnostik 
verstehst, die Diagnose macht immerhin noch der Arzt. Eine maschinelle 
Tumorerkennung wuerde ich z.B. niemals in einem FPGA realisieren, weil 
viel zu komplex. Aber hier hat man auch keine Echtzeit Bedingung und es 
reicht jeden n-ten Frame zu untersuchen.

Aber ich gestehe: Das "genauso schnell" ist vll. uebertrieben, nenne wir 
es "nur unwesentlich langsamer".

Ich will jetzt hier auch keine HLS Werbung machen, weil ich selbst kein 
Fan davon bin. Fakt ist aber, dass man fuer verhaeltnismaessig einfache 
Applikationen ein Werkzeug hat, mit denen man schnell ans Ziel kommt. 
Leider oft zu Lasten der Qualitaet mit den ganzen Krankheiten die 
dahinter stecken, weswegen ich das nicht unbedingt in 
sicherheitskritischen Applikationen wie Medizintechnik einsetzen wuerde 
(zumindest nicht in Klasse C oder auch B). Aber fuer einen Einsteiger 
zum ein bisschen am ersten Videofilter rumspielen, warum nicht?

Und was anderes habe ich auch nie behauptet. Ich frag mich langsam echt 
was hier immer wieder gelesen wird um es hinterher aus dem Zusammenhang 
zu reissen - das obige HLS Beispiel steht im Kontext zum Vergleich mit 
dem Pythin 10 Zeiler und via HLS hat man eben auch entsprechend 
kompakten Code. Vielleicht sollten alle mal etwas runterfahren und am 
eigenen Textverstaendnis arbeiten. Wuerde allen hier besser stehen. ;-)

Martin S. schrieb:
> Zum Thema SDK/Linuxkameras wurde wohl schon alles gesagt, man kriegt mit
> einer gstreamer-OpenCV-Pipeline locker unter 30 ms Latenz hin. Geht auch
> drunter (< 1ms mit RT-Erweiterungen wie Xenomai), aber da die Interfaces
> schon gar nicht geklaert sind, sind Ende-Zu-Ende-Erwaegungen erst mal
> voellig irrelevant.

Das ist klar, muss ja auch, sonst muss man anfangen Frames zu droppen. 
Unterhalb 1ms klappt dann halt auch schon nicht mehr auf der CPU weil 
die der Scheduler vom OS in die Quere kommt. Deshalb gehen viele 
Hersteller hin und bieten eine Grabberkarte mit FPGA an. Via Software 
lassen sich relativ einfach in einer GUI Videofilter zusammenstellen, 
das wird dann in den FPGA geladen und gut ist.

Wie weit man mit Xenomai kommt weiss ich nicht, ich finde da auf die 
schnelle keine Benchmarks. Wenn ich mir die Latenz von den ganzen USB 
Grabberkarten anschaue, dann gehen aber selbst die 30ms unter und haben 
keine Relevanz mehr. ;-)

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel
> dass man damit z. B. keine Shooter mehr sinnvoll zocken kann.

Für übliche Videoverarbeitung ist das z.B. völlig ausreichend.

> Man findet zwar Bilder vom Innenleben diverser Grabber,
> aber da sind die ICs abgeschliffen. Allerdings liefert
> so ein Grabber ganz sicher kein Rohbild. Das passt nämlich
> nicht durch USB2.

Die Dinger liefern alle ein Rohbild, nur eben mit verminderter 
Auflösung bzw. verminderter Bildwiederholrate. Wie der von mir genannte 
Grabber: 4k60 mit MJPG, 4k30 mit VUY420 oder 720p15 mit YUV420 über 
USB2.

Ich habe noch kein UVC-Gerät gesehen, was nicht mindestens einen 
YUV-Modus hatte. Müsste aber im Standard nachschlagen, ob das garantiert 
ist.

Tobias B. schrieb:
> Das [8 bzw. 4 Frames] ist schon ein Haufen Holz.
> Und ich habe auch nie etwas vom einstelligen ns Bereich geschrieben.

Naja, du schriebst von einzelnen Pixeltakten. Als ob es zwingend 
notwendig sei, dass man die Daten live ohne Pufferung jenseits von ein 
paar Flipflops filtern können müsse.

Und das muss man eben oft genug (meist) nicht.

> Dort wo es auf Hand / Auge Koordination ankommt hat man haeufig
> die Anforderung dass man unterhalb 2 Frames bleiben muss.

Das ist richtig, aber eben - wie gesagt - anforderungsabhängig.
Deswegen haben moderne Fernseher einen "Game Mode" mit möglichst 
geringer Latenz (meist trotzdem 2 Frames oder mehr) und einen normalen 
Modus, der auch deutlich mehr haben kann.

> Aehnlich dem Beispiel das ich mit dem Keyboarder gegeben habe.
> Deine 4 Frames sind hier schon 64 ms, da faengt es schon
> an eklig zu werden und 8 Frames mit den 128 ms sind in keinster Weise
> mehr akzeptabel

Ich weiß, aber wie gesagt, das hängt von den Anforderungen ab. Und in 
der Regel sind 1-2 Frames problemlos tolerierbar - und dazu braucht es 
keinen FPGA. Dass wir meist 8 Frames haben, ist historisch gewachsen.

> Auch dort wo schnell auf den Bildinhalt reagiert werden muss, z.B.
> Kollisionsdetektion, kann ich mir nicht vorstellen dass 8 Frames
> akzeptabel sind.

Naja, so viel schlechter als die menschliche Reaktionszeit ist das 
nicht. Nur mit dem Unterschied, dass maschinelle Bildverarbeitung immer 
das gesamte Bild betrachtet und nicht nur einen kleinen Fokuspunkt.

Und meines Wissens arbeiten viele Algorithmen im autonomen Fahren 
ohnehin nur auf einem Subset aller Frames, in Graustufen und 
zweidimensional. Ist vielleicht besser geworden, weiß ich nicht.

> Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob
> ein FPGA geeignet ist. Ja das ist er und zwar richtig gut.

...und das wiederum hängt davon ab, was er eigentlich mit den Daten 
machen möchte. Und das wissen wir nicht.

> Ohne weitere Infos nehme ich erstmal an dass er erstmal harte
> Echtzeit Bedingungen hat und ich impliziere durch die Frage
> nach dem FPGA dass er ein Embedded System moechte

Das sind so ziemlich die extremsten Annahmen, die du treffen kannst - 
und in diesem Forum so ziemlich immer falsch. Wenn Begriffe wie 
"Echtzeit" auftauchen, dann ist damit ziemlich oft weder harte noch 
weiche Echtzeit gemeint (und auch nicht im Sub-Millisekundenbereich).

> Es wird doch einen Grund geben warum er nach FPGA fragt,
> ich behaupte das ist eine gute Idee und in dem ganzen
> Topic hab ich eingeworfen dass das auch kein Aufwand ist
> und er da ein Lebenswerk vor sich hat. Nicht mehr und nicht weniger.

Ich behaupte, dass er nach FPGA fragt, weil er gelesen hat, dass die 
benutzt werden und wissen wollte, ob das für ihn passt. Weil das ist 
hier die übliche Vorgehensweise. :-)

> Wenn beim Requirements Engineering erstmal keine Fakten vorhanden
> sind, dann geht man eben vom schlimmsten aus, zumal in diesem Fall
> ein FPGA nicht ansatzweise so schlimm ist wie dargestellt.

Wenn man schon ein paar Jahre damit gearbeitet hat, sind FPGAs nicht 
schlimm. Wenn nicht, dann... verbringt man damit erstmal ein paar Jahre, 
bis man ordentliche Ergebnisse (jenseits der Trivialfälle) bringt.

Zu HLS muss ich nichts weiter sagen, das haben andere bereits getan.

> Kantendetektion udn Hochpassfilter sind 2 hervorragende
> Beispiele die sich im FPGA implementieren lassen.

Das ist richtig. Und jetzt bitte noch Objekterkennung dazu, am besten 
mit TensorFlow, weil es da bereits fertige Modelle gibt.

Und schon ist dein FPGA tot.

> Naja du beschreibst halt immer noch nicht wo da
> irgendwelche potentielle Huerden sein sollen.

Die FPGA-Werkzeuge (ich kenne ISE und Vivado, gehe aber davon aus, dass 
sich das alles nichts nimmt) sind wesentlich komplizierter in ihrer 
Bedienung als übliche Programmier-IDEs, weil der grundlegende Workflow 
komplizierter ist. Hat man das einmal verstanden, nimmt sich das nicht 
viel - bis dahin scheitert man an jeder Ecke.

Die verwendeten HDL-Sprachen (Verilog, VHDL) sind wesentlich 
komplizierter als übliche Programmiersprachen und erfordern ein massives 
Umdenken. Ohne das mal von Grund auf gelernt zu haben wird das absolut 
garnix.

Die Dokumentation von FPGA-Entwicklung ist wesentlich schlechter als von 
Programmierung. Einfach bedienbare SDKs und Bibliotheken, wie es sie in 
der Programmierwelt zuhauf gibt (z.B. OpenCV, Python, Matlab) sind in 
der FPGA-Welt entweder nicht vorhanden oder sehr schnell sehr teuer.

Und das meinte ich, als ich schrieb, dass ein Student, der ein 
Bildfilter in einer Woche hingeschrieben bekommt, vorher auch drei bis 
neun Monate Tiefenbespaßung mit FPGAs hatte. Denn sonst kriegt der das 
nicht hin.

> Das ist halt auch wieder nur inhaltloses Geblubber
> und zeugt nicht davon, dass du viel Erfahrung in der
> FPGA Entwicklung hast (zumindest nicht in der modernen).

Nur weil ich nicht alles hinschreibe, weil ich nicht für Romane bezahlt 
werde, ist meine Aussage also wertlos. Interessante Denkweise.

> Wuesste nicht wo ich das behauptet habe, eine Webcam
> ist halt auch keine HDMI Grabberkarte. ;-)

Ich bin mir sehr sicher, dass unser HDMI-Grabber auch kein FPGA ist. Und 
eine Webcam unterscheidet sich von einem HDMI-Grabber jetzt auch nicht 
besonders... vor allem dann nicht, wenn aus beiden ein UVC-Anschluss 
rausfällt.

> Ich mache sowohl das eine, als auch das andere, daher kann ich das
> auch ganz gut miteinander vergleichen. Und ich behaupte auch nicht
> dass man mit einem FPGA schneller unterwegs ist, jedoch sind die
> Zeitskalen nicht so dramatisch weit auseinander wie hier gemacht wird.

Das gilt unter der Voraussetzung, dass man mit FPGAs umgehen kann. Im 
Gegensatz zur normalen Programmierung ist das jedoch nicht der Fall. Die 
Einstiegshürden sind deutlich höher.

> Und wenn das ganze in ein Embedded System verpackt wird, dann
> holt der FPGA auch noch deutlich auf, weil der ganze OS Spass
> mit Yocto oder Buildroot wegfaellt.

In der Regel kommt ein FPGA nicht alleine. Zumindest in der 
Vergangenheit, in der ich mal lebte, klebte da immer ein SoC in der 
Nähe, für den man ein passendes Image brauchte.

Ob ich das Yocto nun für meinen SoC mit Grabberkarte konfiguriere und 
alles in OpenCV entwickle, oder ob ich das Yocto für den Xilinx Zynq 
konfiguriere, um die Daten vom FPGA über Ethernet rauszuschieben, ist 
doch am Ende egal. Oder implementierst du Ethernet, Webserver und 
TLS-Layer auch in HDL?

> Ich bevorzuge halt in allen Bereichen moderne Loesungen und
> moderne Loesungen gehen halt immer mehr in Richtung rapid
> Prototyping und da hat die FPGA Welt in den letzten paar
> wenigen Jahren extremst aufgeholt.

Also in meiner Erfahrung lässt sich Rapid Prototyping wesentlich 
einfacher am PC erledigen... billige USB Webcam ranklemmen, die 
Algorithmen in Python runterschreiben und mal schauen - während der 
Grabber noch bei der Post liegt. Das kriege ich wahrscheinlich schneller 
hin als Vivado zu installieren, ein FPGA-Board zu bestellen und den 
ersten Frame da korrekt einzuspeisen.

> Gustl B. schrieb:
>> Aber noch zu den Framegrabbern:
>> Die gibt es in extrem günstig
>> Ebay-Artikel Nr. 264798031041?
>> aber ob da ein FPGA drinnen ist? Man findet zwar Bilder vom Innenleben
>> diverser Grabber, aber da sind die ICs abgeschliffen. Allerdings liefert
>> so ein Grabber ganz sicher kein Rohbild. Das passt nämlich nicht durch
>> USB2.
>
> Sicher nicht, aber wie du sagst, da ist nix mit Rohbild. Da wird ein
> kleiner ARM basierter Prozessor mit einem Hardware H.264/265 oder
> aehnlichem Encoder drinnen stecken. Aehnlich wie ein Raspberry Pi nur
> abgespeckt.

Das Teil ist ein stinknormales UVC-Device und spricht MJPG (ist 
angegeben) und ziemlich sicher auch YUV (vermutlich YUV422 @ 720p15 oder 
so). Mit H.264 ist da nix, denn damit kann man außer direktem 
Livestreaming nicht viel anfangen. In der Regel will man aber 
zwischendurch bearbeiten (z.B. zusätzliche Informationen einblenden), 
das geht mit H.264 nicht besonders gut.

Außerdem konvertiert das Teil eingangsseitig von 4K (wahrscheinlich 
4K30) auf 1080p30 runter. Das ist heutzutage alles Standard in SoCs, da 
braucht man keinen FPGA für.

In billigen China-Tablets sind oft Kamerasensoren drin, die keine 
Bayerdaten ausgeben, sondern YUV. Entsprechend können die ganzen 
Billigchipsätze damit nativ umgehen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Gustl B. schrieb:
>> Selbst 4 Frames Latenz sind bei 30 Fps 133 ms. Das ist schon so viel
>> dass man damit z. B. keine Shooter mehr sinnvoll zocken kann.
>
> Für übliche Videoverarbeitung ist das z.B. völlig ausreichend.

Was ist denn die uebliche Videoverarbeitung? Gibt es da eine Definition 
was ueblich und unueblich ist?

S. R. schrieb:
> Tobias B. schrieb:
>> Das [8 bzw. 4 Frames] ist schon ein Haufen Holz.
>> Und ich habe auch nie etwas vom einstelligen ns Bereich geschrieben.
>
> Naja, du schriebst von einzelnen Pixeltakten. Als ob es zwingend
> notwendig sei, dass man die Daten live ohne Pufferung jenseits von ein
> paar Flipflops filtern können müsse.
>
> Und das muss man eben oft genug (meist) nicht.

Dann kannst du das doch bestimmt zitieren wo ich das geschrieben habe? 
Oder kann es sein, dass ich nur geschrieben habe, dass ein FPGA dazu in 
der Lage ist und man daher "wirkliche" Echtzeitbedingungen erfuellen 
kann? Es ist schon der Wahnsinn wie sehr du dir einbildest dass ich den 
Software Ansatz verteufle und mir deshalb irgendwelche Worte in den Mund 
legst.

S. R. schrieb:
>> Das hat nichts mit Scheuklappen zu tun. Der TO fragt danach ob
>> ein FPGA geeignet ist. Ja das ist er und zwar richtig gut.
>
> ...und das wiederum hängt davon ab, was er eigentlich mit den Daten
> machen möchte. Und das wissen wir nicht.

Mit den gegebenen Anforderung ist ein FPGA ganz kalr ein Kandidat um die 
Aufgabe zu loesen. HDMI, Datenrate, Echtzeit und seine Beispiel 
Algorithmen. Nichts was der FPGA nicht schafft und auch nichts was 
komplex/teuer zu implementieren ist. Er fragt ob FPGA geeignet ist und 
das ist er.

S. R. schrieb:
> Das sind so ziemlich die extremsten Annahmen, die du treffen kannst -
> und in diesem Forum so ziemlich immer falsch. Wenn Begriffe wie
> "Echtzeit" auftauchen, dann ist damit ziemlich oft weder harte noch
> weiche Echtzeit gemeint (und auch nicht im Sub-Millisekundenbereich).

Mal wieder eine der inhaltslosen Verallgemeinerungen. Fakt ist dass ein 
FPGA fast keine Einschraenkungen mit Echtzeitanforderungen hat. Die 
Loesung mit dem FPGA schraenkt daher erstmal den sehr allgemeinen 
Loesungsraum nicht ein und ist daher auch erstmal eine technologisch 
sinnvolle Loesung. Erst durch deine Verallgemeinerungen greifen deine 
Argumente und das ist wirklich schlechter Diskussionsstil.

S. R. schrieb:
>> Kantendetektion udn Hochpassfilter sind 2 hervorragende
>> Beispiele die sich im FPGA implementieren lassen.
>
> Das ist richtig. Und jetzt bitte noch Objekterkennung dazu, am besten
> mit TensorFlow, weil es da bereits fertige Modelle gibt.
>
> Und schon ist dein FPGA tot.

Auch hier passt du wieder die Anforderungen willkuerlich an. Wenn das 
die Anforderungen waeren wuerde ich zwar auch ein FPGA nehmen, aber 
etwas aus der Ultrascale+ Klasse und eine Mischung aus FPGA, CPU und GPU 
fahren.

Sonst behaupte ich jetzt: Und jetzt noch bitte Latenz unter 1 us und 
schon ist deine Software tot. Aber das merkst du hoffentlich selbst, 
dass dein Argument ein bisschen peinlich war.

S. R. schrieb:
> Die FPGA-Werkzeuge (ich kenne ISE und Vivado, gehe aber davon aus, dass
> sich das alles nichts nimmt) sind wesentlich komplizierter in ihrer
> Bedienung als übliche Programmier-IDEs, weil der grundlegende Workflow
> komplizierter ist. Hat man das einmal verstanden, nimmt sich das nicht
> viel - bis dahin scheitert man an jeder Ecke.
>
> Die verwendeten HDL-Sprachen (Verilog, VHDL) sind wesentlich
> komplizierter als übliche Programmiersprachen und erfordern ein massives
> Umdenken. Ohne das mal von Grund auf gelernt zu haben wird das absolut
> garnix.
>
> Die Dokumentation von FPGA-Entwicklung ist wesentlich schlechter als von
> Programmierung. Einfach bedienbare SDKs und Bibliotheken, wie es sie in
> der Programmierwelt zuhauf gibt (z.B. OpenCV, Python, Matlab) sind in
> der FPGA-Welt entweder nicht vorhanden oder sehr schnell sehr teuer.
>
> Und das meinte ich, als ich schrieb, dass ein Student, der ein
> Bildfilter in einer Woche hingeschrieben bekommt, vorher auch drei bis
> neun Monate Tiefenbespaßung mit FPGAs hatte. Denn sonst kriegt der das
> nicht hin.

Auch das ist ein Block an Verallgemeinerungen und persoenlichen 
Erfahrungen. Warum gehst du davon aus dass der TO da auch Probleme haben 
wird? Weil du es nicht hinbekommst, kann er es auch nicht?

Ich kann mich noch ziemlich genau an mein erstes FPGA Projekt erinnern. 
Auslesen und auswerten von einem 3D Gyrosensor. Das war in 3 Monaten, 
inkl. grafischer Darstellung in Labview und Platinen Fertigung 
(Entflechten, Layouten, Aetzen, Bestuecken) abgeschlossen. Unterschaetz 
mir die Studenten nicht, nur weil du selbst deine Schwierigkeiten hast.

Recht gebe ich dir aber in dem Punkt mit der Informationsmenge. Die ist 
in der FPGA in der Tat deutlich spaerlicher, aber in der Qualitaet 
absolut brauchbar. Muss man sich halt reinarbeiten. Deshalb jemanden 
abzuraten er soll statt einem FPGA was anderes nehmen ist aus diesem 
Grund voellig absurd.

S. R. schrieb:
> In der Regel kommt ein FPGA nicht alleine. Zumindest in der
> Vergangenheit, in der ich mal lebte, klebte da immer ein SoC in der
> Nähe, für den man ein passendes Image brauchte.

Das ist auch wieder eine Verallgemeinerung die ueberhaupt nichts zur 
Sache beitraegt. Sehr wohl kommen in den verschiedensten Bereichen FPGAs 
alleine vor. Ist aber voellig unabhaengig von dieser Diskussion. In dem 
Fall des TO ist die Frage gerade FPGA vs PC, bzw. FPGA vs SoC. Und wenn 
man pro SoC argumentiert, weil das einfacher und schneller entwickelt 
ist, dann muss man auch den Mehraufwand fuer die Bereitstellung des 
zugrundelegenden Systems betrachten.

Habe ich schon angemerkt, dass hier unbedingt etwas mehr Kompetenz zum 
Thema Textverstaendnis noetig waere?

S. R. schrieb:
> Ob ich das Yocto nun für meinen SoC mit Grabberkarte konfiguriere und
> alles in OpenCV entwickle, oder ob ich das Yocto für den Xilinx Zynq
> konfiguriere, um die Daten vom FPGA über Ethernet rauszuschieben, ist
> doch am Ende egal. Oder implementierst du Ethernet, Webserver und
> TLS-Layer auch in HDL?

Auch hier, Verallgemeinerung war nicht das Thema. Selbstverstaendlich 
wuerde ich das nicht in HDL machen (vll. Ethernet noch in absoluten 
Ausnahmefaelle wenn man z.B. aufgrund irgendwelchen Risikomanagements 
keine Software im System haben moechte um die Zulassung zu 
vereinfachen). Habe ich auch nie behauptet. Irgendwie glaub ich langsam, 
dass das ein seltsamer Fetisch ist.

S. R. schrieb:
> Also in meiner Erfahrung lässt sich Rapid Prototyping wesentlich
> einfacher am PC erledigen... billige USB Webcam ranklemmen, die
> Algorithmen in Python runterschreiben und mal schauen - während der
> Grabber noch bei der Post liegt. Das kriege ich wahrscheinlich schneller
> hin als Vivado zu installieren, ein FPGA-Board zu bestellen und den
> ersten Frame da korrekt einzuspeisen.

Aus meiner auch. Wenn ich einen Videofilter selbst entwickeln muss, 
mache ich das auch erst am PC, am liebsten mit Python. Damit kann man 
sich dann auch direkt Testvektoren fuer die HDL Simulation generieren. 
Trotzdem bleibt die Aussage korrekt das die FPGA Industrie immer weiter 
daran arbeitet die Methoden zu verbessern (oder sich neue Auszudenken) 
um das Rapid Prototyping auf FPGA Basis voranzubringen. HLS und SDAccel 
sind da die prominentesten Beispiele aus dem Hause Xilinx (sorry fuer 
die staendige Xilinx Werbung, aber da bin ich nunmal am tiefsten drin).

S. R. schrieb:
> Außerdem konvertiert das Teil eingangsseitig von 4K (wahrscheinlich
> 4K30) auf 1080p30 runter. Das ist heutzutage alles Standard in SoCs, da
> braucht man keinen FPGA für.

Auch hier: Hab ich nie behauptet, lern lesen. Zumal du mir zustimmst da 
du selbst SoCs schreibst (nichts anderes ist ein ARM Core mit einem HW 
Encoder). Und ob H.264/265 oder MJPG ist unerheblich, es wird halt 
komprimiert damit man die Daten via USB 2.0 rausschaufeln kann. Am PC 
kommst du zwar an jedes Pixel zur weiteren Verarbeitung ran in der 
Gesamtheit hat dein Bild halt Informationen aufgrund der Komprimierung 
verloren.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und ob H.264/265 oder MJPG ist unerheblich, es wird halt
> komprimiert damit man die Daten via USB 2.0 rausschaufeln kann.

Richtig, aber irrelevant. Es gibt neben USB 2.0 auch modernere 
Alternativen gibt, für die das nicht mehr gilt. Zum Beispiel das 
inzwischen ziemlich weit verbreitete USB 3.1 oder - weil ich damit 
arbeite - MIPI-CSI.

> Am PC kommst du zwar an jedes Pixel zur weiteren Verarbeitung
> ran in der Gesamtheit hat dein Bild halt Informationen aufgrund
> der Komprimierung verloren.

Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät 
ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will 
ich dich mal in deiner Welt nicht weiter stören.

Auf den Rest deiner Ausführungen gehe ich nicht weiter ein. Das wird ein 
Roman, den du dann wieder mit Nebenkriegsschauplätzen zerfaserst. Da ist 
mir meine Zeit zu schade. Der TO hat eh nur getrollt.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
>> Am PC kommst du zwar an jedes Pixel zur weiteren Verarbeitung
>> ran in der Gesamtheit hat dein Bild halt Informationen aufgrund
>> der Komprimierung verloren.
>
> Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät
> ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will
> ich dich mal in deiner Welt nicht weiter stören.
>
> Auf den Rest deiner Ausführungen gehe ich nicht weiter ein. Das wird ein
> Roman, den du dann wieder mit Nebenkriegsschauplätzen zerfaserst. Da ist
> mir meine Zeit zu schade. Der TO hat eh nur getrollt.

Auch hier wieder, du hast wirklich ein Problem mit Textverstaendnis. Das 
war im Zusammenhang mit dem USB 2.0 Geraet. Wenn du mir erklaerst wie 
man ein 1080p@30 Hz Video ueber USB 2.0 schaufeln kannst ohne 
Komprimierung, waere das sehr spannend zu Erfahren. Kleine Rechenhilfe: 
1920x1080x30Hzx24bit = ca. 1.5 Gb/s. Das sind 3x soviele Daten wie die 
USB 2.0 Spezifikation vorsieht.

So langsam muss es doch auch dir mal peinlich sein? Les doch einfach ein 
zweites mal bevor du schreibst. ;-)

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Wenn du mir erklaerst wie
> man ein 1080p@30 Hz Video ueber USB 2.0 schaufeln kannst

Ich habe nie behauptet, dass dies möglich sei.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Offensichtlich behauptest du dass aus einem UVC Geraet keine 
verlustbehafteten Daten rauskommen. Dann kannst dua uch erklaeren wie du 
ein 1080p bei 30Hz ueber USB 2.0 uebertraegst.

Oder musst du etwa zugeben, dass du mir falsche Worte in den Mund gelegt 
hast? Ala

S. R. schrieb:
> Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät
> ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will
> ich dich mal in deiner Welt nicht weiter stören.

???

Bloed, nich?

Ist aber auch nicht weiter schlimm. Jetzt faellt mir auch endlich wieder 
ein woher ich dein Nutzername kenne. Und wenn man sich alte Diskussionen 
von dir ansieht, sieht man immer wieder das selbe Muster, nahe an der 
Grenze zum Getrolle. Eigentlich schade, haette ich mir viel Lebenszeit 
ersparen koennen. :-(

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Offensichtlich behauptest du dass aus einem UVC Geraet keine
> verlustbehafteten Daten rauskommen.

Dein Textverständnis ist mangelhaft und dein Wissen für jemanden, der 
anderen "mach mal ein Praktikum" empfiehlt, ebenfalls.

Alle mir bekannten UVC-Geräte (das sind einige) bieten sowohl MJPG als 
auch YUV an. Der Treiber entscheidet. Die verfügbaren Auflösungen und 
Bildwiederholraten orientieren sich an der Bandbreite.

Soll ich dir das jetzt noch Waldorfschulengerecht vortanzen?
Muss ich dir, einem Profi vom Fach, erklären, was "720p15" bedeutet?
Kennst du das Konzept "es gibt mehrere Möglichkeiten" oder "Kompromiss"?

Tobias B. schrieb:
> Dann kannst dua uch erklaeren wie du
> ein 1080p bei 30Hz ueber USB 2.0 uebertraegst.

Ich habe noch immer nicht behauptet, dass dies möglich sei.
Dementsprechend werde ich dir auch nicht erklären, wie etwas Unmögliches 
durchgeführt wird.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Tobias B. schrieb:
>> Dann kannst dua uch erklaeren wie du
>> ein 1080p bei 30Hz ueber USB 2.0 uebertraegst.
>
> Ich habe noch immer nicht behauptet, dass dies möglich sei.
> Dementsprechend werde ich dir auch nicht erklären, wie etwas Unmögliches
> durchgeführt wird.

Ein letztes mal, dann ists mir auch egal, du wirst es eh nicht raffen.

Du legst mir Aussagen in den Mund die ich nie behauptet habe ala

S. R. schrieb:
> Naja, wenn du weiterhin der Meinung bist, dass aus einem UVC-Gerät
> ausschließlich verlustbehaftete komprimierte Daten rauskommen, dann will
> ich dich mal in deiner Welt nicht weiter stören.

Ich drehe jetzt den Spiess um und Wende die gleiche Diskussionstaktik 
bei dir an

Tobias B. schrieb:
> Offensichtlich behauptest du dass aus einem UVC Geraet keine
> verlustbehafteten Daten rauskommen. Dann kannst dua uch erklaeren wie du
> ein 1080p bei 30Hz ueber USB 2.0 uebertraegst.

Ich weiss genauso gut wie du, dass die Frage nicht beantwortet werden 
kann. Ich hoffe jedoch dass es bei dir klickt macht und die merkst was 
fuer einen asozialen Diskussionstil du hast. Und ja ich nenne es bewusst 
asozial, weil es nicht angehen kann, dass man sich erst fuer etwas 
vereidigen muss, was man nie behauptet hat, bevor man in der 
eigentlichen Diskussion fortfuehren kann.

Soviel zur Rhetorik (wobei das eigentlich keine Rhetorik sondern 
Kindergarten Diskussionsnveau ist) und das war auch diesbezueglich der 
letzte Beitrag von mir. Vielleicht laesst sich der Thread ja noch noch 
retten. Und dazu ist es auch Wurst ob sich der TO nochmal meldet, das 
Thema ist auch so interessant genug um es zu diskutieren.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Soviel zur Rhetorik

Naja, mit den ganzen Ad-Hominem-Angriffen hast du angefangen. :-)

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Um die Diskussion nochmal mit ein paar Fakten aufzuwärmen:

Die USB Video Class-Spezifikation spezifiziert viele mögliche Formate, 
schreibt aber keines zwingend vor. Was unter welchen Randbedingungen 
möglich ist, entscheidet also ausschließlich das Gerät.

Eine Microsoft VX800 (USB 2.0) unterstützt beispielsweise ausschließlich 
YUY2 (also unkomprimiertes YUV 4:2:2), in allen Auflösungen und 
Bildwiederholraten.

Eine hier rumliegende Logitech Konferenzkamera (USB 2.0) unterstützt 
sowohl MJPEG und YUY2, wobei beide Varianten sämtliche Auflösungen 
unterstützen. Die maximalen Bildwiederholraten unterscheiden sich, bei 
1920x1080 sind es 30fps (MJPEG) bzw. 2fps (YUY2).

Ein im Büro liegender HDMI-Framegrabber (USB 3.1) unterstützt MJPEG 
(komprimiert), YUY2 (unkomprimiert YUV 4:2:2) und NV12 (unkomprimiert 
YUV 4:2:0). MJPEG liefert maximal 4096x2304 bei 30 fps, NV12 maximal 
3840x2160 bei ebenfalls 30 fps. Für YUY2 liegt die maximale Auflösung 
bei 3840x2160 und jeweils geringeren Bildwiederholraten verglichen mit 
NV12. (Consumer)4K-Video ist damit also problemlos drin.

Nachtrag: An einem USB 2.0-Anschluss sind ebenfalls alle Auflösungen 
verfügbar, allerdings mit massiv reduzierten Bildwiederholraten bei den 
höheren Auflösungen.

Ein UVC-Gerät mit MPEG2-TS, H.264 oder VP9 (alle spezifiziert) ist mir 
noch nicht untergekommen. Würden wir ohnehin nicht unterstützen können.

Schlussfolgerung: USB-Kameras lassen sich prima auch ohne 
Kompressionsartefakte betreiben und sind damit für Videoverarbeitung 
grundsätzlich geeignet, egal ob mit oder ohne FPGAs. Hat mich jetzt 
nicht überrascht, schließlich habe ich das vor knapp einem Jahrzehnt 
schonmal gemacht. Man musste dem Treiber nur sagen, dass man YUY2 haben 
will.

: Bearbeitet durch User
von Fitzebutze (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Schlussfolgerung: USB-Kameras lassen sich prima auch ohne
> Kompressionsartefakte betreiben und sind damit für Videoverarbeitung
> grundsätzlich geeignet

Wird ja auch seit Jahren schon mit USB2.0 in der industriellen BV so 
gemacht.
Gäbe auch noch den USBVision-Standard, die Latenzen sind auch da im 
Bereich von Zeilen bei entsprechend designten Video-Queues und 
Rolling-Shutter-Sensoren.
Habe das hier auch schon mit Kameras auf FX3-Basis von LED-Blitz bis 
Monitor (ende zu ende) mit Photosensoren durchgemessen.

Damit hat hoffentlich der akademische Kindergarten jetzt auch 
Sommerferien.

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.

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