MJPEG Stream anzeigen

[philiph]

Hi,

ich versuche gerade einen MJPEG Stream einer FullHD Industriekamera anzeigen zu lassen und frage mich, was ich dafür am besten nutze.
Da die Kamera die MJPEG Daten als RAW UDP-Pakete verschickt, kann ich keine der "normalen" MJPEG Lösungen nutzen.
Ich hatte bisher versucht, die Daten in einem Thread zu empfangen und die einzelnen Bildpakete zusammenzusetzen und dann in einem zweiten Thread die fertigen Bilder in ein TJPEGImage zu laden und auf das Canvas eines TImage zu zeichnen. Leider braucht diese Methode sehr viel CPU-Leistung, besonders weil die Kamera FullHD Bilder mit 30fps liefert.
Es liegt auch wirklich nur am Zeichnen, dass Empfangen und zusammensetzten der Bilder braucht kaum Leistung, das habe ich schon getestet.

Was kann ich zum anzeigen nutzen, um möglichst wenig CPU Last zu verursachen bzw. könnte ich hier auf Hardwarebeschleunigung zurückgreifen?

Vielen Dank

[Medium]

Wie machst du es denn bisher?

[philiph]

Wie bisher?

Zitat von philiph:

Ich hatte bisher versucht, die Daten in einem Thread zu empfangen und die einzelnen Bildpakete zusammenzusetzen und dann in einem zweiten Thread die fertigen Bilder in ein TJPEGImage zu laden und auf das Canvas eines TImage zu zeichnen.

Ansonsten gibt es vom Hersteller zwar ein eigenes Programm zum Anzeigen der Bilder, das aber leider nicht hilft, weil die Bildanzeige direkt in ein anderes Programm eingebunden werden soll. Leider wird die Kamera auch vom Hersteller aus Altersgründen nicht mehr aktiv unterstützt.

Ich könnte mir vorstellen, dass man hier vlt. auf OpenGL oder DirectX zurückgreifen könnte, aber ich habe damit leider keine Erfahrung und habe ich bei Google nichts dazu gefunden.

[himitsu]

MJPEG?

Ist ja nicht so, als wenn das Andere nicht auch schon versucht hätten.
http://www.delphipraxis.net/176863-b...-auslesen.html

Normale JPEG-Lösungen gehen schon, da das ja einzelne JPEGs sind, welche einfach nur aneinander gehängt wurden.
Aufteilen und dann einzeln anzeigen ist also problemlos möglich.


OK, die VCL-Komponenten erzeugen ein klein bissl CPU-Last, beim Decodierung und Anzeigen der JPEGs.

[philiph]

Wie bereits zu Anfang geschrieben funktioniert es ja im Prinzip auch.

Es handelt sich hier nur leider nicht um ein "normale" billig IP Webcam.
Die Kamera liefert 1920x1080 bei 30fps, das führt leider zu etwas mehr als ein "klein bissl CPU-Last" wenn man es einfach nur auf das Canvas eines Images zeichnet.
Dabei ist wie schon gesagt gar nicht das Dekodieren an sich das Problem, sondern die meiste Rechenzeit geht für das eigentliche Zeichnen drauf.
Nicht umsonst besitzen die meisten "echten" Videostream-Programme eine entsprechende Anbindung an OpenGL/DirectX (so z.B. auch die Originalsoftware des Herstellers).

Ich will nicht sagen, dass es nicht im Prinzip möglich ist, einfach einen MJPEG Stream über ein normales TImage anzuzeigen, es ist aber bestimmt nicht die eleganteste und schnellste Variante. Mir geht es daher um entsprechend performante Alternativen.

[Medium]

Meine Frage war schon ernst gemeint. TJPEGImage auf ein TImage ist ja schön und gut, aber auch dafür gibt es etliche Wege. Mir schwob hier ein Fetzchen Code vor, dass du zeigen könntest. (TImage an sich ist schon eher wenig optimal, da dieses intern auch immer sein Puffer-Bitmap mit führt. Eine Paintbox könnte daher zumindest schon mal ein klein wenig helfen, vermutlich aber nicht genug. Je nach dem wie du bisher zeichnest eben.)

Die Hardwarebeschleunigung umfasst, so wie der Begriff üblicherweise verwendet wird, übrigens nicht nur das bloße Zeichnen. Hier wird vor allem auch das Dekodieren in für GPUs (bzw. den diversen Media- und Streaming-Extensions der CPUs) optimierter Weise verlagert. Nur muss man sich dafür dann komplett vom Komfort der VCL verabschieden, und so weit ich das überblicke entweder herstellerspezifische APIs der Treiber nutzen, oder aber sich den "Spaß" gönnen die Dekodierung komplett selbst entweder über Shader oder GPGPU-Frameworks (OpenCL, Cuda, ...) machen. Da sprechen wir dann aber schon über Mannwochen bis das sauber ist.
Selbst wenn man einen Decoder scheiben will, der "nur" MMX, SSD und Konsorten nutzt, muss man zumindest unter Delphi mit handgemachtem Assembler ans Werk rücken, da Delphi nicht für die Extensions optimiert und imho auch erst gar nicht kompiliert.

Was recht viele Videoprogramme nutzen, ist die freie libavcodec.dll des FFmpeg-Projektes. Leider habe ich da auf die Schnelle keine Infos zu einer API gefunden, und ob es da eventuell schon einen fertigen Wrapper für Delphi zu gibt. Es könnte sich da durchaus lohnen nach zu suchen, da hier ein riesen Batzen an Arbeit bereits getan ist.

Falls du das Video wirklich nur anzeigen willst, ohne die Einzelbilder weiterzuverarbeiten, könnte man sich auch noch den VLC-Player genauer anschauen. Ich glaube mal etwas davon gelesen zu haben, dass es da Wrapper gibt, um die Videoausgabe in eigene Fenster zu lenken. Sicher bin ich da aber nicht. Der Player lässt sich prinzipiell recht einfach mit einem Stream direkt aus einer Kamera füttern, und übernimmt alles bis zur Darstellung.

[mkinzler]

Zitat:

Ich glaube mal etwas davon gelesen zu haben, dass es da Wrapper gibt, um die Videoausgabe in eigene Fenster zu lenken.

Das Videolan-Team entwickelt nicht nur den Player, sondern auch das dazugehörende LibVLC SDK

https://wiki.videolan.org/LibVLC/

welches in eigene Anwendungen eingebettet werden kann

[philiph]

Bisher habe ich es mit

Delphi-Quellcode:

jpeg.LoadfromStream(jpegstream);
image1.Picture.Bitmap.assign(JPEG)

und

Delphi-Quellcode:

jpeg.LoadfromStream(jpegstream);
image1.canvas.draw(0,0,jpeg);

versucht. Zum Testen habe ich auch schon versucht es auf das Canvas eines DSPack VideoWindows zu zeichnen, das war aber auch nur marginal schneller, es liegt also nicht an dem TImage. Das ganze wird dann in einem eigenen Thread erledigt, um den eigentlichen Empfang der Daten nicht zu behindern. Wenn es hierfür natürlich eine schenllere Variante gibt, wäre ich für jeden Hinweis dankbar.

Von CUDA/OpenCL würde ich gerne Abstand halten, weil man sich entweder an NVIDIA Hardware bindet oder bei OpenCL damit rechnen muss, dass entweder der Treiber noch keien richtige OpenCL Anbindung hat oder bei einfacheren Grafikkarten die OpenCL Unterstüzung ganz fehlt und dann der OpenCL Kernel auf dem CPU ausgeführt wird. Außerdem wüsste ich auch nicht, dass es bisher einen guten Delphi Wrapper für OpenCL gibt, ich habe bisher immer C++ verwendet, wenn ich was mit OpenCL gemacht habe.

FFmpeg hatte ich auch schon gesehen, leider aber nur recht teure kommerzielle Wrapper(FFVCL) gefunden.

LibVLC sieht aber ganz gut aus, das werde ich mir mal anschauen. Vielen Dank!

[Medium]

Du könntest spaßeshalbar noch versuchen das Bild einfach mit BitBlt() auf den Formular-Canvas zu schubsen. So wahnsinnig große Verbesserung vermute ich da aber leider auch nicht.
Bei so großen Bildern in so schnell wird das Dekodieren an sich vermutlich zumindest auch ein merkbarer Faktor sein, so dass die für Video eigentlich kaum optimierte Variante von Delphis JPEGImage da etwas ins Pumpen kommt.

Ein komplettes SDK für VLC ist natürlich Sahne, damit holt man sich den formatfreudigsten und robustesten Player ins Boot den ich kenne. Hatte da nur vor Jahren mal am Rande aufgeschnappt, dass es da was gäbe, aber mangels Bedarf nie weiter verfolgt.

[himitsu]

Das Die Jpeg-Komponente im Delphi, besitzt ein interes TBitmap.
Vor Ausgabe wird das Jpeg dahin decodiert und das Bitmap wird dann angezeigt.

Und grade dieses Decodieren schreint recht langsam zu sein.