Forum: FPGA, VHDL & Co. Möglichkeiten um Kamerastream zu kodieren


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 Ralf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hallo,
wir sind auf der Suche nach einer "einfachen und günstigen" Möglichkeit 
einen CMOS-Kamerastream zu kodieren.
Eine Kamera mit Parallelinterface oder MIPI-CSI-Interface soll zum 
Einsatz kommen (RAW oder RGB etc. noch unklar; Hersteller: Omnivision, 
Onsemi, Framos etc.).

Dieser Kamerastream, 1080p und 30fps, soll mittels Mikrocontroller über 
eine 100 Mbit Ethernet-Leitung gesendet werden.
Auf den Mikrocontroller möchten wir zunächst nicht verzichten da dieser 
noch andere Aufgaben erledigt.

Ein FPGA wäre jetzt u.a. interessant, weil er zusätzlich noch die 
Schnittstellenwandlung (MIPI-CSI) übernehmen könnte. Die Schnittstelle 
zwischen FPGA und Mikrocontroller könnte dann z.B. SPI sein.
Ein FPGA wird aber für uns schnell uninteressant, wenn man über 45k€ für 
einen H.264-I IP core zahlen muss.
Es muss dazu noch gesagt werden, dass wir zwar unerfahren mit dem Umgang 
von FPGAs sind aber wir hätten die Zeit uns damit tiefergehend (2 
Jahre+) zu beschäftigen.

Welche Lösungen gäbe es denn noch einen Kamerastream zu kodieren?
Möglichst Lösungen mit gut erhältlichen Chips von namhaften Herstellern, 
da dieser später auf einem eigenen Design bestückt werden soll. CMOS 
Kamerachips die selbst schon JPEG kodieren sind auch eher uninteressant, 
da es zu wenige davon gibt.

Meine Frage ist bewusst im FPGA Bereich, da es bestimmt noch andere 
Lösungen als H.264 gibt.

Danke.

Ralf

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


Bewertung
0 lesenswert
nicht lesenswert
Es gibt von Xilinx in der Zynq Ultrascale+ Familie FPGAs mit einem 
Hardware H.264 Encoder. Die Chips sind allerdings nicht ganz billig und 
lohtn sich eigentlich nur wenn du dein komplettes System in den FPGA 
packst. Der hat auch genug CPU Power dank vierer ARM Kerne.

Was fuer Hardewarekosten pro Unit schweben dir denn vor? Das schraenkt 
dann die Auswahl wahrscheinlich am schnellsten ein. ;-)

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Welche Lösungen gäbe es denn noch einen Kamerastream zu kodieren?
Nimm so einen potenten "µC" wie den i.MX8. In der Hardware ist der 
sicher billiger als die FPGA-Lösung und hat soweit alles drin. Inklusive 
des aktuell verwendeten µC... ;-)

https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS

https://www.digikey.de/product-detail/de/nxp-usa-inc/8MMINILPD4-EVK/568-15279-ND/9857774

: Bearbeitet durch Moderator
von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Kosten kann ich ehrlich gesagt noch gar nicht so genau beziffern. 
Blöd gesagt, es wird nachher so teuer wie es teuer wird. Ich denke, was 
ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit 
zu teuer wird. Wir dachten da eher an einen kleinen low-cost FPGA, den 
man bespielt und fertig ist die Schnittstellenwandlung und 
Videokodierung - salopp gesagt.
In dieser Größenordnung kann man sich ja dann schon nach z.B. einem 
i.MX6 oder i.MX8 umsehen. Die haben ja auch schon HW codec und MIPI-CSI 
Schnittstellen und PCIe und und und. Aber der Nachteil für uns wäre dann 
zusätzlich, dass man ein OS wie Linux benötig.

von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da wir keine Erfahrung mit FPGAs haben, kann ich schlecht die Kosten 
abschätzen bzw. nachher das Pro und Contra.

Mal angenommen man würde versuchen die Kodierung in einem preisgünstigen 
FPGA (<10€) zu machen. Für mein System bräuchte ich folgende Funktionen 
in dem FPGA realisiert:
1. Wandlung von MIPI-CSI zu Parallelport
2. Umschaltung zwischen Kamera mit MIPI-Interface oder 
Parallel-Interface
3. Videokodierung (MJPEG oder MPEG-2 oder MPEG-4 AVC)
4. Controller für DDR (evtl. in 3. untergebracht)
5. SPI Schnittstelle zwischen FPGA und µC

Dazu habe ich noch ein paar Fragen und Fragen genereller Natur:

I. Auch wenn man das Geld für die IP cores zur Verfügung hätte, bliebe 
ja trotzdem noch die Aufgabe diese Module miteinander zu verheiraten. 
Wie seht ihr da den Aufwand für einen FPGA-Anfänger? Oder kann man das 
mehr oder weniger in den FPGA IDEs "zusammenklicken" :| ? Wie gesagt, 
ich habe keine Vorstellung...

II. Es gibt ja auch kostenlose IP-cores. Wie findet man diese, 
insbesondere auf den FPGA Herstellerseiten? Ich nehme mal an, dass die 
Programmierung um einiges schneller ist, wenn IP cores verwendet werden. 
Wenn man sich jetzt für den ein oder anderen Hersteller entscheiden 
muss, dann nimmt man vielleicht auch denjenigen, der viele kostenlose 
IP-cores anbietet. Wie blickt man da durch?

III. Habe ich das richtig verstanden, IP cores kauft man nur, wenn man 
angesichts kurzer Entwicklungszeit keine Möglichkeit hat die benötigten 
Funktionen selbst zu schreiben ? SPI werden bestimmt noch einige 
hinbekommen. Aber bei H.264 bleibt den meisten dann nichts anderes übrig 
als 40k€ zu zahlen?

IV. Oder einfach nochmal anders gefragt. Wo liegt man preislich 
(ungefähre Hausnummer) wenn man 1 bis 5 umsetzen wollte, ohne Stunden?
- IDE
- IP-cores
- sonstiges

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
Hi Ralf,

betr. MJPEG-Streaming-SoCs im FPGA und MIPI kann ich prinzipiell helfen:

https://section5.ch/index.php/documentation/jpeg-encoder-ip-modules-developer/

Gibt fertige 2-Chip (FPGA/Phy) Refdesigns fuer die ueblichen 
Lattice-Plattformen (EVDK, HDR60).
Wird aber eng mit guter Qualitaet bei 1080p@30fps ueber 100Mbit..

Macht auf dem FPGA auch nur unter gewissen Randbedingungen Sinn, wenn's 
kleine Stueckzahlen sind, kopiert man sich besser eins der oben 
erwaehnten imx8-Setups.
Da darf man sich allerdings dann mit Linux-Treibermodellen und dem nicht 
sonderlich eleganten v4l2-Konzept herumschlagen, oder macht 'bare 
metal', was aehnlich viel Aufwand wie auf dem FPGA macht. Einiges an den 
MIPI-Interfaces ist un- oder schlecht dokumentiert und auf dem FPGA 
deutlich leichter zu debuggen.

Es gibt sonst fuer h.264 den hardh264-Encoder, der fuer gewisse Sachen 
auch ganz brauchbar ist. Der Implementations-Aufwand ist aber deutlich 
groesser, und mit 45k EK kommst du da nicht weit.
Wenn du h.264, aber keine low-latency brauchst, guck' dich mal bei den 
imx6 VPU-Loesungen um, da sollte es in der offiziellen gstreamer-Source 
was geben.

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


Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Die Kosten kann ich ehrlich gesagt noch gar nicht so genau beziffern.
> Blöd gesagt, es wird nachher so teuer wie es teuer wird. Ich denke, was
> ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit
> zu teuer wird. Wir dachten da eher an einen kleinen low-cost FPGA, den
> man bespielt und fertig ist die Schnittstellenwandlung und
> Videokodierung - salopp gesagt.

Ja, da liegst du mit deiner Einschaetzung nicht ganz falsch. Die 
Flagschiff FPGA Loesung lohnt sich halt nur, wenn die Stueckzaheln so 
gross sind, dass die FPGA Preise einigermassen ertraeglich sind und die 
Entwicklungskosten dann im Rauschen untergehen. Ausserdem amcht es nur 
Sinn wenn man sein komlpettes System in den FPGA packt, ohne 
zusaetzliche Controller Anbindung.

Aber wie Lothar (und Martin) schon schrieb, es gibt echt tolle 
Prozessoren auf dem Markt die MIPI faehig sind und die Kodierung auch 
beherrschen. Das ist preislich sicherlich interessanter. Sogar der 
Raspberry Pi kann schon MIPI, ich weiss nur nicht ob der auch einen 
Hardware Encoder hat oder nur einen Dekoder.

Sollte es nur um MIPI gehen und die Video Enkodierung wird ausgelagert, 
dann sind die Crosslinks von Lattice ein toller lowcost FPGA.

Ralf schrieb:
> In dieser Größenordnung kann man sich ja dann schon nach z.B. einem
> i.MX6 oder i.MX8 umsehen. Die haben ja auch schon HW codec und MIPI-CSI
> Schnittstellen und PCIe und und und. Aber der Nachteil für uns wäre dann
> zusätzlich, dass man ein OS wie Linux benötig.

Ich weiss nicht ob eine OS Schicht mit Linux hier wirklich ein Nachteil 
ist. Die kannst halt fertige Bibliotheken nutzen, damit ist die 
Entwicklungszeit kaum mehr zu druecken.

: Bearbeitet durch User
von Tobias N. (technick2)


Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Ich denke, was
> ich definitiv sagen kann ist, dass ein FPGA-System samt Entwicklungszeit
> zu teuer wird.

Wenn du es selber machst ja. Aber es gibt ja Leute, die das schon 
gemacht haben und daheim herumliegen haben. Einen MPG-Dekoder muss man 
auch nicht nehmen, wenn man nur das Format komprimieren will. Muss es 
denn ein Video-format sein?

Wir nehmen einen ZIP-ähnliche Kompression.

Tobias B. schrieb:
> Die kannst halt fertige Bibliotheken nutzen, damit ist die
> Entwicklungszeit kaum mehr zu druecken.

Wenn man ins Linux eingearbeitet ist, ja. Aber auch das ist ein großer 
overhead.

Eine Sensordatenanbindung hat man in Tagen programmiert und den Decoder 
reingeworfen. Es gibt schließlich auch solche zum Einkaufen. Für 30fps 
braucht es auch keine große Bandbreite. Woher kommt denn dein 
Horrorpreis von 45k?

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


Bewertung
1 lesenswert
nicht lesenswert
Tobias N. schrieb:
> Wenn man ins Linux eingearbeitet ist, ja. Aber auch das ist ein großer
> overhead.

Das stimmt allerdings auch wieder. Wenn ich aber davon ausgehen wuerde 
er kennt sich in beiden Welten nicht aus und wuerde die Dienstleistung 
einkaufen, dann wuerde die Linux Variante im Preis wahrscheinlich 
gewinnen. Kosten und Zeit sind ja faktisch in fixer Relation zueinander

Vielleicht koennen wir Ralf ja noch ein bisschen aus der Reserve locken 
und herausfinden was er vor hat. Vielleicht finden wir dann eine ideale 
Loesung. :-)

von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dank für eure Antworten, hilft schon etwas weiter.

Bevor wir auf eine komplette FPGA Lösung gehen, wären iMX6 deutlich 
interessanter. Ein System aus FPGA und µC wäre ein schöner Kompromiss 
gewesen. Dafür müsste man eben noch den Aufwand und Kosten abschätzen 
können.

Tobias B. schrieb:
> Sollte es nur um MIPI gehen und die Video Enkodierung wird ausgelagert,
> dann sind die Crosslinks von Lattice ein toller lowcost FPGA.

Wir haben noch ein, zwei andere Lösungen gefunden, wenn es nur um MIPI 
geht. TI und Maxim haben IC um MIPI zu LVDS und LVDS zu Parallel 
wandeln. Und es gibt noch ein IC von ST Micro, das eine direkte 
Umwandlung von MIPI zu Parallel kann. Wenn FPGA dann, dann sollte er 
auch noch die Videokodieren machen.

Tobias B. schrieb:
> Ich weiss nicht ob eine OS Schicht mit Linux hier wirklich ein Nachteil
> ist. Die kannst halt fertige Bibliotheken nutzen, damit ist die
> Entwicklungszeit kaum mehr zu druecken.

Das Ziel ist es eine Lösung ohne Linux zu finden. Wenn es diese nicht 
gibt, ohne hohe Kosten (FPGA), dann muss es sicherlich ein iMX6 o.ä. mit 
all seinen VOR- und Nachteilen sein.

Tobias N. schrieb:
> Einen MPG-Dekoder muss man
> auch nicht nehmen, wenn man nur das Format komprimieren will. Muss es
> denn ein Video-format sein?
>
> Wir nehmen einen ZIP-ähnliche Kompression.

Kannst du das bitte etwas näher erläutern? Wir sind da noch nicht 
wirklich festgelegt. Hauptsache die Auflösung wird nicht verändert und 
die optische Qualität bleibt in vernünftigen Grenzen. Welchen 
Kompressionsfaktor erreicht ihr mit der ZIP-ähnlichen Kompression? Auf 
welchem System läuft diese? Gibt es da eine bessere Bezeichnung als 
"ZIP-ähnliche Kompression".


Tobias N. schrieb:
> Eine Sensordatenanbindung hat man in Tagen programmiert und den Decoder
> reingeworfen. Es gibt schließlich auch solche zum Einkaufen. Für 30fps
> braucht es auch keine große Bandbreite. Woher kommt denn dein
> Horrorpreis von 45k?

Das war ein Angebot von Visengi für Zynq UltraScale+
H264E-I Netzliste: 45k€
H264E-P Netzliste: 60k€

Martin S. schrieb:
> Es gibt sonst fuer h.264 den hardh264-Encoder, der fuer gewisse Sachen
> auch ganz brauchbar ist. Der Implementations-Aufwand ist aber deutlich
> groesser, und mit 45k EK kommst du da nicht weit.

Wenn man jetzt den hardh264 nehmen könnte, dann weiß ich immer noch 
nicht was da noch so an Kosten auf einen zukommt.

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
Ralf schrieb:
> Für mein System bräuchte ich folgende Funktionen[...]
> in dem FPGA realisiert:
> 1. Wandlung von MIPI-CSI zu Parallelport
> 2. Umschaltung zwischen Kamera mit MIPI-Interface oder
> Parallel-Interface
> 3. Videokodierung (MJPEG oder MPEG-2 oder MPEG-4 AVC)
> 4. Controller für DDR (evtl. in 3. untergebracht)
> 5. SPI Schnittstelle zwischen FPGA und µC

1. würde ich heutzutage in die andere Richtung machen. Also Parallelport 
zu MIPI-CSI. Vielleicht sogar direkt beim Sensorchip, dann sind die 
Kameraköpfe austauschbar. Ob man dazu einen FPGA braucht oder ob es dazu 
ASSP ICs müsste jemand recherchieren.

Wie schon empfohlen wurde die Punkt 3 bis 6 (6 ist Streamen über 
Ethernet) würde ich auch eher auf einem Mikroprozessor sehen. Encodieren 
wohl über eine GPU beschleunigt (da meistens in Hardware nur ein Decoder 
verfügbar ist). Bei Mikroprozessoren bekommt man heute so extrem viel 
Leistung und Features für fast kein Geld.

Kurz: Nimm ein Raspberry Pi Compute Module :-)
https://stackoverflow.com/a/50854229

Martin S. schrieb:
> Wird aber eng mit guter Qualitaet bei 1080p@30fps ueber 100Mbit..

Ja, wir haben bisher keine Angaben zur geforderten Qualität.

1080p@30fps macht mein Smartphone (Xperia Z3C) von 2014 mit 8000kbit/s 
via WLAN. Braucht dann aber mehr Strom als vom Ladegerät kommt :-)

Tobias B. schrieb:
> Ja, da liegst du mit deiner Einschaetzung nicht ganz falsch. Die
> Flagschiff FPGA Loesung lohnt sich halt nur, wenn die Stueckzaheln so
> gross sind, dass die FPGA Preise einigermassen ertraeglich sind und die
> Entwicklungskosten dann im Rauschen untergehen.

Oder du nicht darum herum kommst weil z. B.:
- low-latency gefragt ist
- viele parallele Kameras synchron und aufeinander kalibriert laufen 
sollen
- Es strahlungsfest (Weltraum) sein soll
- (mir gehen die Ideen aus...)

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


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Kurz: Nimm ein Raspberry Pi Compute Module :-)
> https://stackoverflow.com/a/50854229

Geht nicht, darf ja kein Linux sein. :-(

Christoph Z. schrieb:
> Oder du nicht darum herum kommst weil z. B.:
> - low-latency gefragt ist
> - viele parallele Kameras synchron und aufeinander kalibriert laufen
> sollen
> - Es strahlungsfest (Weltraum) sein soll
> - (mir gehen die Ideen aus...)

Das beisst sich wieder mit den lowcost Anforderungen, daher gehe ich mal 
stark davon aus, dass keiner dieser Punkte zutrifft. Andernfalls haette 
man wohl andere Kostenvorstellungen. ;-)

Ralf schrieb:
> Das Ziel ist es eine Lösung ohne Linux zu finden. Wenn es diese nicht
> gibt, ohne hohe Kosten (FPGA), dann muss es sicherlich ein iMX6 o.ä. mit
> all seinen VOR- und Nachteilen sein.

Duerfte ich da mal nachhaken, warum Linux ausgeschlossen ist? Dadurch 
verbaust du dir halt enorm viele Moeglichkeiten, vor allem im unteren 
Preissegment.

Ich habe keine Ahnung von den iMXen, bekommt man da wirklich Video 
Encoding und Streaming ohne eine OS Schicht hin? Das kann ich mir fast 
nicht vorstellen, wuerde mich aber freuen wenn ich mich da irre. :-)

von Hauke Haien (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Auch wenn ich solche stumpfen Gegenfragen eigentlich selbst hasse: Warum 
wollt ihr das quasi "koste es was es wolle" selbst machen?
Es gibt ja durchaus Firmen wie IDS Imaging, die genau sowas schon sehr 
lange und recht gut machen und neben ihrem Baukasten auch 
Sonderentwicklungen anbieten, falls man da wirklich nichts passendes 
findet.

https://de.ids-imaging.com/customised-cameras.html

https://de.ids-imaging.com/store/products/cameras/ids-interface-group/ethernet/sort-by/position/sort-direction/desc.html

Meiner Erfahrung nach lohnt es, sich auf das zu konzentrieren, was man 
wirklich selbst einschätzen und erledigen kann und andere komplexe 
Aufgaben an spezialisierte Firmen zu vergeben bzw. sich eine fertige 
Lösung rauszupicken und ggf. seine eigene Hardware darauf anzupassen.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Geht nicht, darf ja kein Linux sein. :-(

Dann nimmt er halt Android, ist ja kein "richtiges" Linux oder Windows 
10 IoT core ;-) (JA, das soll ein schlechter Witz sein...)

Na gut, dann halt mal weitergucken. Vielleicht kann QNX da was anbieten, 
wird ja in genug Krempel im Auto eingesetzt wo auch Kameras drinstecken 
und billig sein muss.

von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Christoph Z. schrieb:
>> Oder du nicht darum herum kommst weil z. B.:
>> - low-latency gefragt ist
>> - viele parallele Kameras synchron und aufeinander kalibriert laufen
>> sollen
>> - Es strahlungsfest (Weltraum) sein soll
>> - (mir gehen die Ideen aus...)
>
> Das beisst sich wieder mit den lowcost Anforderungen, daher gehe ich mal
> stark davon aus, dass keiner dieser Punkte zutrifft. Andernfalls haette
> man wohl andere Kostenvorstellungen. ;-)

Stimmt Tobias B.! Keine geringe Latenz und nur eine Kamera pro Modul. 
Sorry mein Fehler.

Tobias B. schrieb:
> Duerfte ich da mal nachhaken, warum Linux ausgeschlossen ist? Dadurch
> verbaust du dir halt enorm viele Moeglichkeiten, vor allem im unteren
> Preissegment.

Es geht um Zertifizierung. Je weniger Codezeilen desto besser.

Tobias B. schrieb:
> Ich habe keine Ahnung von den iMXen, bekommt man da wirklich Video
> Encoding und Streaming ohne eine OS Schicht hin? Das kann ich mir fast
> nicht vorstellen, wuerde mich aber freuen wenn ich mich da irre. :-)

Da habe ich mich falsch ausgedrückt. Auf so einem iMX läuft schon ein 
Linux. Wenn wir unser Vorhaben mit einfachen Mitteln nicht hinbekommen, 
dann muss es eben ein Gerät mit OS Schicht sein. Momentan ist es noch 
Recherche und abwägen..

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ralf schrieb:
> Das Ziel ist es eine Lösung ohne Linux zu finden.

Das hat aber schon was von: Ich muss einen Nagel in ein Brett schlagen, 
darf aber keinen Hammer nehmen.
Es ist ja nicht nur die nackerte encodierung (ist da h264 schon fix 
gesetzt, haut das von Latency, Qualitaet, Lizenzgebuehren, ... hin?). 
Aus dem Encoder(IP-Core) faellt ein Elementarstrom raus. Der sollte aber 
noch irgendwie aufgehuebscht und verpackelt werden (z.b. RTSP, RTMP, 
MPEGTS, DASH, ...) damit der "schoen" uebers Ethernet geht...

Gruss
WK

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


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Tobias B. schrieb:
>> Geht nicht, darf ja kein Linux sein. :-(
>
> Dann nimmt er halt Android, ist ja kein "richtiges" Linux oder Windows
> 10 IoT core ;-) (JA, das soll ein schlechter Witz sein...)
>
> Na gut, dann halt mal weitergucken. Vielleicht kann QNX da was anbieten,
> wird ja in genug Krempel im Auto eingesetzt wo auch Kameras drinstecken
> und billig sein muss.

Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz 
vll. der Schluessel zur Loesung. :-D

Ralf schrieb:
> Es geht um Zertifizierung. Je weniger Codezeilen desto besser.

Um welche Zertifizierung handelt es sich denn. Ich kenne mich leider nur 
im Medizin Bereich aus, aber hier im Forum gibt es zu eigentlich jedem 
Bereich jemanden der dir da weiterhelfen kann. Wenn du das noch 
preisgibst, bin ich mir ziemlich sicher, dass da eine vernuenftige 
Loesung gefunden wird. :-)

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
>
> Wenn man jetzt den hardh264 nehmen könnte, dann weiß ich immer noch
> nicht was da noch so an Kosten auf einen zukommt.

Ohne Erfahrung und gemachtes Nest baust du da ev. erst mal ein Jahr das 
Nest auf, bis die Sache laeuft, je nachdem ob ihr besser Software oder 
Hardware koennt. Auf was wollt ihr Euch fokussieren/was ist das 
eigentliche Ziel?

Zu einer fertigen Streaming-Loesung mit VLC/gstreamer laesst sich schon 
eine Hausnummer hinschreiben (sowohl MJPEG auch hardh264, erstere ist 
niedriger). Muss allerdings noch mehr Fleisch an den Knochen (Typ 
Sensor, Latenzanforderungen, Simulationsmodell ja/nein, ...).
Die niedrigsten EK bietet sonst halt nur die embedded-Linux-Loesung.

Die letzte Option, naemlich eine bestehende Industriekamera fuer seine 
Anwendung zu 'hacken' ist auch noch offen.

Zur MIPI-Thematik solltet ihr euch auf jeden Fall sehr frueh Gedanken 
machen, bzw. den Sensor gut aussuchen. Die Hersteller der entsprechenden 
Sensoren verhalten sich da typischerweise verschlossen, und wenn's mal 
mit dem Timing hakt, ist man ewig am reverse-engineeren (und das nur mit 
Crosslink/LIFMD wirklich effektiv). Regel Nr. 4: Den LIFMD im ersten 
Design niemals einsparen :-)

von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz
> vll. der Schluessel zur Loesung. :-D

"Witz"? Schön zu wissen, dass du mein Anliegen gleich als Witz abgetan 
hast. Seh' das jetzt mal nicht so genau. Wenn möglich kein Linux, wenn 
nicht, dann eben nicht.


Gut, ich dachte man könnte einen kleinen FPGA (RAM etc.) rein nur für 
die Videokompression und Schnittstellenwandlung nehmen. Die Kosten für 
FPGA Tools und IP cores sind zu hoch. Bis auf die eine genannte Zahl von 
Martin S. konnte ich keine grobe Hausnummer genannt bekommen. Es wird 
dann wohl mindestens im 45k Bereich liegen. Und natürlich noch höher, 
wenn man man auf nicht-freie IP cores zurückgreifen muss.

Martin S. schrieb:
> Ohne Erfahrung und gemachtes Nest baust du da ev. erst mal ein Jahr das
> Nest auf, bis die Sache laeuft, je nachdem ob ihr besser Software oder
> Hardware koennt. Auf was wollt ihr Euch fokussieren/was ist das
> eigentliche Ziel?
Die Erfahrung ist bis auf ein FPGA Praktikum ziemlich Null. Ziel: 
recherchieren ob folgendes geht:
Ein µC basiertes System mit FPGA als Kamerainterface und Kodierung. 
Streaming über 100 Mbit Ethernet. Max 1080p @ 30fps (20fps vielleicht 
auch ok). Keine besonderen Latenzanforderungen. Qualität: so, dass wenn 
man auf den Bildschirm schaut, man nicht denkt es wäre 1990.
Wie gesagt, Zeit für FPGA Einarbeitung ist theoretisch da.

Martin S. schrieb:
> Zur MIPI-Thematik solltet ihr euch auf jeden Fall sehr frueh Gedanken
> machen, bzw. den Sensor gut aussuchen. Die Hersteller der entsprechenden
> Sensoren verhalten sich da typischerweise verschlossen, und wenn's mal
> mit dem Timing hakt, ist man ewig am reverse-engineeren (und das nur mit
> Crosslink/LIFMD wirklich effektiv). Regel Nr. 4: Den LIFMD im ersten
> Design niemals einsparen :-)
Danke für den Tipp!

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


Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Tobias B. schrieb:
>> Und ploetzlich wird durch das Stichwort "Zertifizierung" aus dem Witz
>> vll. der Schluessel zur Loesung. :-D
>
> "Witz"? Schön zu wissen, dass du mein Anliegen gleich als Witz abgetan
> hast. Seh' das jetzt mal nicht so genau. Wenn möglich kein Linux, wenn
> nicht, dann eben nicht.

Bitte richtig lesen und zitieren, das empfinde ich jetzt doch als 
beleidigend mir gegenueber und ich wuesste jetzt nicht warum das sein 
muss? :-/

Der Witz war auf Christophs Beitrag bezogen, der seine Aussage selbst 
als Witz gekennzeichnet hat. Und da es hier um Zertifizierung geht, hat 
er nicht nur einen Witz gerissen, sondern evtl. sogar ins Schwarze 
getroffen. Das konnte er zum Zeitpunkt seines Posts noch nicht wissen.

: Bearbeitet durch User
von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oh ja Tobias B., da hab ich zu schnell gelesen und falsch reagiert. 
Entschuldige bitte!

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


Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> Oh ja Tobias B., da hab ich zu schnell gelesen und falsch reagiert.
> Entschuldige bitte!

Vergeben und vergessen.

Magst du uns vielleicht trotzdem noch mitteilen um was fuer eine 
Zertifizierung es geht? Diese Info koennte vll. wirklich das fehlende 
Puzzleteil sein.

Ich bin mir sicher da findet sich jemand hier im Forum der wirklich aus 
erster Hand berichten kann, weil er die gleiche Zertifizierung / 
Zulassung schonmal mitgemacht hat.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Der Witz war auf Christophs Beitrag bezogen, der seine Aussage selbst
> als Witz gekennzeichnet hat. Und da es hier um Zertifizierung geht, hat
> er nicht nur einen Witz gerissen, sondern evtl. sogar ins Schwarze
> getroffen.

Wieso, das Wort Zertifizierung und Android bzw. Windows in einem Satz, 
macht doch den Witz noch besser :-)

Darum auch der ernst gemeinte Hinweis auf QNX. Da weiss ich, dass die 
Multimedia können. VXworks, Integrity, PikeOS sind nach meinem Wissen 
nicht gedacht auf GPUs Video zu encodieren, dicke GUIs anzuzeigen oder 
ähnliches.

Ralf schrieb:
> Es geht um Zertifizierung. Je weniger Codezeilen desto besser.

Jaja, aber dann Video Kompression und Ethernet mit TCP/IP wollen...

Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als 
Hardware und darum als sicher. Fragen und Diskussionen in diese Richtung 
hatten wir hier schon ein paar mal.

Das letzte mal z. B. hier auch mit Blick auf die nötige Arbeit zur 
Zulassung vom eingesetzen RTOS:
Beitrag "Re: Xilinx Zynq 7000: IEC 62304 + OS"

von Videoman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
By the way: (wir bauen Kameras) es gibt auch IP-Core-Anbieter die zu den 
fertigen eval kits Module und Encoder als Netzliste kostenlos anbieten. 
Die laufen dann ein paar Stunden, dann man muß das System reseten.
Für proof of concept reicht das. Mir bekannte Anbieter sind u.a. auch 
Visengi oder Helion Vision. Man muß einfach nur mal anfragen und 
vielleicht NDA unterzeichen.

Und Zertifizierung kostet mehr als ein  JPEG codec!

von Ralf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Vergeben und vergessen.

Puh, da bin ich aber froh :)

Tobias B. schrieb:
> Magst du uns vielleicht trotzdem noch mitteilen um was fuer eine
> Zertifizierung es geht? Diese Info koennte vll. wirklich das fehlende
> Puzzleteil sein.

Sorry aber ich glaube nicht. Wir stehen nicht kurz vor einer 
Zertifizierung und auch nicht in 5 Jahren. Es ist auch nicht so, dass 
Linux auf garkeinen Fall nicht geeignet wäre. Es geht erst mal nur um 
Prototypen. Momentan schreit alles einfach nach einem CPU-basierten 
System. Es ist aber dennoch nicht so, als wäre das generell nicht 
machbar:

https://www.st.com/en/automotive-adas-devices/stv0991.html

Aber nur als Automotive-Kunde.

Christoph Z. schrieb:
> Jaja, aber dann Video Kompression und Ethernet mit TCP/IP wollen...

Hab ich nicht gesagt.

Christoph Z. schrieb:
> Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als
> Hardware und darum als sicher. Fragen und Diskussionen in diese Richtung
> hatten wir hier schon ein paar mal.

Nein.

Videoman schrieb:
> By the way: (wir bauen Kameras) es gibt auch IP-Core-Anbieter die zu den
> fertigen eval kits Module und Encoder als Netzliste kostenlos anbieten.
> Die laufen dann ein paar Stunden, dann man muß das System reseten.
> Für proof of concept reicht das. Mir bekannte Anbieter sind u.a. auch
> Visengi oder Helion Vision. Man muß einfach nur mal anfragen und
> vielleicht NDA unterzeichen.

Das war auch im Angebot von denen, 10k so rum.

Videoman schrieb:
> Und Zertifizierung kostet mehr als ein  JPEG codec!

Ja das denk ich doch auch. Trotzdem kann man doch mal links und rechts 
fragen. Und hier im Forum bekommt man sein erstes Gefühl ;)

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Lass mich raten, in deiner Branche gelten FPGA Designs immer noch als
> Hardware und darum als sicher.
Das wundert mich auch.
Wo doch so ein FPGA-Design aus viele tausenden Codezeilen bestehen kann. 
Und was ein schlechter "Programmierer" aus einem FPGA machen kann, das 
sieht man hier allenthalben...   ;-)

Ich würde auf jedem Fall einem Komprimierer im i.MX8 locker die selbe 
Qualität zutrauen wie einem FPGA-Core.

Ralf schrieb:
> Es ist auch nicht so, dass Linux auf garkeinen Fall nicht geeignet wäre.
Dann würde sich doch generell eine Einarbeit dort lohnen. Und es muss 
ja nicht mal Linux sein.

> Aber nur als Automotive-Kunde.
Das ist ein "Versatile imaging processor" und da steckt ein "ARM® 
Cortex-R4 CPU @500 MHz" dahinter. Der braucht auch Software. Und ich 
könnte mir gut vorstellen, dass da von Haus aus ein Linux drauf läuft:
https://www.google.com/search?q=STV0991+linux

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]
  • [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.