Hallo Zusammen Wir sind im Moment an unserer Master-Diplomarbeit dran. Das Thema ist Bildverarbeitung. Wir benützen das tPad DE-115 Eval Board von terasic.com und das i.MX51 Board von Freescale. Auf dem tPad DE-115 Eval Board werden die Vorverarbeitungen mit der Kamera erstellt und die Bilder über Ethernet am i.MX51 Board übertragen. Um die komplexeren Bildverarbeitungen auf dem i.MX 51 Board vornehmen zu können, haben wir OpenCV mit Qt portiert (das funktioniert auch schon recht gut). Nun jetzt hängen wir an der Ethernet Übertragung fest. In NiosII haben wir ein TCP/IP Socket Server implementiert, das im Moment mit dem PC über Telnet auch recht gut funktioniert. Die Video-Daten sind 640(x3 Pixel)x480 gross, entspricht 921,6 kB. Macht das Sinn diese Menge über TCP/IP zu senden? Ich habe gelesen, dass UDP für Video-Daten besser geeignet ist, nur wie kann ich UDP in NiosII implementieren? Das TCP/IP Socket Server basiert auf einem Demo-Projekt. Eine Allgemeine Frage zur Telnet Variante mit TCP/IP: Generell spielt da keine Rolle mit welcher Applikation ich die Verbindung zum tPad Board erstelle. Kann ich auch eine App mit Qt schreiben die sich über z.B 192.168.0.103 30 (ähnlich wie bei Telnet) mit dem tPad verbindet und so die RGB-Video-Daten einlesen würde? Besten Dank für Eure Unterstützung im Voraus. Gruss Antonio
Hi, Antonio Carlucci schrieb: > Die Video-Daten sind 640(x3 Pixel)x480 gross, entspricht 921,6 kB. Macht > das Sinn diese Menge über TCP/IP zu senden? Klar, warum nicht. Fragt sich, was Du für Raten brauchst.. > Ich habe gelesen, dass UDP für Video-Daten besser geeignet ist, nur wie > kann ich UDP in NiosII implementieren? > Das TCP/IP Socket Server basiert auf einem Demo-Projekt. Naja, UDP ist nicht unbedingt besser geeignet. Es bringt halt prinzipiell weniger Overhead mit sich als TCP. Das ist kein Problem, solange du im lokalen Netzwerk mit u.U. speziellen Treibern arbeitest, die keine Pakete wegwerfen. Sonst allerdings bist du mit dem Problem konfrontiert, das TCP loest: Request/Resend und div. Handshaking, Reordern der Pakete etc. implementieren. Andere Variante unter UDP: Fehlertolerantes Protokoll. Es gibt da einen JPEG-Video-Standard, dessen RFC-Nummer mir gerade nicht mehr einfaellt (2453, oder eine Permutation davon :) ) Wenn da mal ein Paket verschuett geht, sieht man nur ne kaputte Zeile, aber das Bild ist nicht komplett zersaebelt. Wenn Echtzeit aber nicht wichtig ist, wuerde ich bei (M)JPEG gleich TCP nehmen (kann man mit dem Webbrowser angucken). Andere Variante: Nur 16 bit YUV anstatt RGB uebertragen, spart 33% Bandbreite :-) Fuer div. Blackfin-basierten Kameraloesungen habe ich obige Spaesse per netpp (Opensource, siehe http://section5.ch/netpp) umgesetzt. Geht mit TCP und UDP, allerdings braucht man für letzteres die genannten modifizierten Treiber für optimalen Speed. Funktioniert dann wie ein Remote-Bildschirm, an den die Kamera den Videostream (aehnlich wie RTP, nur spezielle Rohdaten) schickt. Gruss, - Strubi
Hallo Danke für die rasche Antwort. Strubi schrieb: > Klar, warum nicht. Fragt sich, was Du für Raten brauchst.. Es sollte schon ziemlich Realtime sein, so 15 fps sollten reichen > Wenn Echtzeit aber nicht wichtig ist, wuerde ich bei (M)JPEG gleich TCP > nehmen (kann man mit dem Webbrowser angucken). > > Andere Variante: Nur 16 bit YUV anstatt RGB uebertragen, spart 33% > Bandbreite :-) Ich würde auch eher auf TCP bleiben, da ich ziemlich schon das Meiste lauffähig habe. Im Moment aber eben über Telnet-Verbindung, sollte aber kein Problem sein die Verbindung mit einem anderen Tool (z.B. Qt) zu öffnen und Datenaustausch vorzunehmen, liege ich da richtig? Eine Webbrowser Demo habe ich eigentlich auch, da ist mir aber noch nicht so klar, wie ich den Video-Stream lade. Bei der Demo muss ich ein zip-file im flash auf dem tPad Board laden. Dann wird das zip-file im Browser mit der entsprechende IP-Adresse geladen. Wie ist das mit einem Video? Die RGB Daten in YUV umzuwandeln sollte kein Problem sein. Da müssten die 15 fps kein Problem sein. Die Daten im i.MX51 wieder umzuwandeln sollte ja auch gehen... > Fuer div. Blackfin-basierten Kameraloesungen habe ich obige Spaesse per > netpp (Opensource, siehe http://section5.ch/netpp) umgesetzt. Geht mit > TCP und UDP, allerdings braucht man für letzteres die genannten > modifizierten Treiber für optimalen Speed. Funktioniert dann wie ein > Remote-Bildschirm, an den die Kamera den Videostream (aehnlich wie RTP, > nur spezielle Rohdaten) schickt. Habe mir das Ganze heruntergeladen, werde es noch anschauen. Wie kann ich mir aber das auf meine Applikation vorstellen, müsste ich dies auch das i.MX Board portieren (läuft mit abgespeckter Linux-Version) Danke und Gruss Antonio
Hi Antonio, 15 fps bei VGA bekomme ich im WLAN zumindest nur mit JPEG-Encoder rueber. Kannst ja etwa selber die Bandbreite ausrechnen, vorsichtige Annahme ist jeweils die Haelfte des theoretischen Durchsatzes des Phy. > Eine Webbrowser Demo habe ich eigentlich auch, da ist mir aber noch > nicht so klar, wie ich den Video-Stream lade. Bei der Demo muss ich ein > zip-file im flash auf dem tPad Board laden. Dann wird das zip-file im > Browser mit der entsprechende IP-Adresse geladen. Wie ist das mit einem > Video? Im Falle des JPEG-Encoders oeffnest du einfach ne URL a la: http://kamera:8080 und kriegst in Firefox et al direkt einen Video-Stream. Laeuft unter Stichwort MJPEG. Funktioniert ganz ok bei nicht zu hohen Frameraten, leider ist die Sache ein mittlerer Hack und funktioniert bei jedem Browser ein bisschen anders zuverlaessig. > Wie kann ich mir aber das auf meine Applikation vorstellen, müsste ich > dies auch das i.MX Board portieren (läuft mit abgespeckter > Linux-Version) Genau. Gibt einen Master (Library, für Linux/Windows-PC) und den Slave (Embedded target). Letzteren musst Du mit dem entsprechenden Crosscompiler übersetzen. Beim Remote-Display ist es gerade umgekehrt, da ist der Slave das Display-Frontend (PC). Das ist im .tgz vermutlich nicht drin, schick mir einfach ne PM bei Bedarf, kann dir den Code zustellen. Grüsse, - Strubi
Martin S. schrieb: > Hi Antonio, > > 15 fps bei VGA bekomme ich im WLAN zumindest nur mit JPEG-Encoder > rueber. Kannst ja etwa selber die Bandbreite ausrechnen, vorsichtige > Annahme ist jeweils die Haelfte des theoretischen Durchsatzes des Phy. Das müsste stimmen: 100Mbit/s : 2 = 50Mbit/s : 640 x 3 x 8 x 480 = ~7fps 50Mbit/s : 640 x 3 x 8 x 480 x 0.67 (YUV)= ~10fps Na ja, sagen wir 10fps würden/sollen/müssen reichen... ;) > Im Falle des JPEG-Encoders oeffnest du einfach ne URL a la: > > http://kamera:8080 > > und kriegst in Firefox et al direkt einen Video-Stream. Laeuft unter > Stichwort MJPEG. Funktioniert ganz ok bei nicht zu hohen Frameraten, > leider ist die Sache ein mittlerer Hack und funktioniert bei jedem > Browser ein bisschen anders zuverlaessig. Ich muss mich da mal in der webserver demo in NiosII einarbeiten. Im Moment wird eben ein zip file im flash (fpga-board) gespeichert. Beim Abruf im Browser wird ein grosses Fenster mit einem Foto des FPGA-Boards dargestellt. Ich nehme an, anstatt das Bild, sende ich da kontinuierlich Video-Daten ohne irgend ein zip-file im flash. Stimmt das? >> Wie kann ich mir aber das auf meine Applikation vorstellen, müsste ich >> dies auch das i.MX Board portieren (läuft mit abgespeckter >> Linux-Version) > > Genau. Gibt einen Master (Library, für Linux/Windows-PC) und den Slave > (Embedded target). Letzteren musst Du mit dem entsprechenden > Crosscompiler übersetzen. Beim Remote-Display ist es gerade umgekehrt, > da ist der Slave das Display-Frontend (PC). Das ist im .tgz vermutlich > nicht drin, schick mir einfach ne PM bei Bedarf, kann dir den Code > zustellen. Sorry blöde Frage, was meinst Du mit PM? Danke und Gruss Antonio
Der Faktor 2 bei der Übertragungsrate ist pauschal gesehen quatsch. Meinen Erfahrungen nach hängt es stark davon ab wie groß die Pakete sind die man baut. Wenn man die 1500 Byte die ein Paket üblicherweise maximal haben kann ausnutzt, kommt man schon nahe an die maximale Übertragungsrate. Wenn man jedoch viele sher kleine Pakete baut steigt der Overhead und die Nutzlast sinkt.
Der Sensor auf dem TPAd benutzt doch ohnehin ein Bayer-Pattern wenn ich mich nicht irre (also ein Schachbrett-Graustufenbild welches Grüne, Blaue und Rote Pixel enthält) aus dem man dann durch Interpolation ein Farbbild berechnet. Wie das in Software geht kann man bspw. in der Open Source Bibliothek IVT anschauen (ivt.sourceforge.net). Ich hatte in meiner Diplomarbeit eine HW-Only UPD Übertragung im FPGA implementiert, welche Jumbo-Packets benutzt hat der Größe 3600 KByte (muss dann aber auch die Gegenseite unterstützen). Damit habe ich stabile 880 MBit/s unter Linux erreicht (keine Packet drops), aber ich musste etwas an den Empfangspuffergrößen am Ziel-PC drehen (das geht unter Linux recht einfach).
Antonio Carlucci schrieb: > Ich nehme an, anstatt das Bild, sende ich da kontinuierlich > Video-Daten ohne irgend ein zip-file im flash. > Stimmt das? Genau. Du schickst einfach ein jpeg (mittels ev. optimierter Jpeg-Library encoded) und irgend nen Random-Marker dazwischen. Hab mal n Stück Code angehängt. Micha schrieb: > Ich hatte in meiner Diplomarbeit eine HW-Only UPD Übertragung im FPGA > implementiert, welche Jumbo-Packets benutzt hat der Größe 3600 KByte > (muss dann aber auch die Gegenseite unterstützen). Damit habe ich > stabile 880 MBit/s unter Linux erreicht (keine Packet drops), aber ich > musste etwas an den Empfangspuffergrößen am Ziel-PC drehen (das geht > unter Linux recht einfach). Die Jungs von Pleora machen das auch seit Jahren mit 8k Jumbo packets. Allerdings auch nur mit Spezialtreiber und dem richtigen Intel-Phy. Und am besten nur peer to peer, also kein intelligenter Hub dazwischen. Habe auch festgestellt, dass mein Linux-Setup (womoeglich lags auch am Treiber) keine irregulären Packet-Bursts mag, also, Pakete wurden manchmal weggeschmissen wenn sie so kommen: .... .... ..... anstatt . . . . . . . . . . . . . Gruss, - Strubi
Danke für die Anregungnen bis jetzt Leute... Ein jpeg Encoder in FPGA zu impl. scheint mir ziemlich kompliziert und die Zeit dafür würde eher knapp werden. Daher wollen wir beim TCP/IP Protokoll bleiben und reine RGB Daten versenden, diese evtl. wie schon oben besprochen, in YUV umwandeln. @Strubi, Könntest Du mir noch einige genauere Tips zu netpp für unsere Anwendung geben? Ich weiss nicht, ob Du NiosII kennst, wäre eine Impl. da auch möglich? Danke und Gruss Antonio
Hi Antonio, zu netpp auf Nios: Da gibt's bisher noch keinen Port, soweit ich sehe. Müsstest Du also selber schreiben. Gibt da in devices/platform.mk einige Beispiele. Die Footprints (Binary-Grösse) wird wohl kein Problem sein, mir ist zwar grade nicht mehr klar, ob das alles "bare metal" oder auf einem kleinen Betriebsystem (uClinux?) im Nios läuft. Sonst kannst du mit etwa 20-40 kB (je nach C library und CPU) rechnen. Tips habe ich grade keine, am besten guckst du dir das Howto (englisch) mal an: http://section5.ch/doc/netpp/netpp-howto.pdf Gibt zwei Möglichkeiten zur Übertragung: "push", oder "pull". Erstere Methode schiebt Bilder auf den Display-Server (Nios: client, PC: server), bei letzerer holst du explizit die Bilder vom Target (Nios: Server, PC: client). Gruss, - Strubi
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.