MJPEG Stream anzeigen

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

[TiGü]

Delphi-Quellcode:

uses 
  System.Diagnostics
...
var
  LStopWatch : TStopwatch;
begin
   LStopWatch := System.Diagnostics.TStopwatch.StartNew;

   jpeg.LoadfromStream(jpegstream);
   image1.Picture.Bitmap.assign(JPEG)
   // oder 
   image1.canvas.draw(0,0,jpeg);

   LStopWatch.Stop;
   Caption := IntToStr(LStopWatch.ElapsedMilliseconds);

Was kommen denn da so wie Zeiten bei rum?

[philiph]

Leider lässt sich die Laufzeit so einfach nicht messen, dafür geht es zu schnell das Ergebnis ist immer Null. Wenn man wirklich nur einen Durchlauf messen will, müsste man wohl den Assembler bemühen.
Wenn man es in einer for-Schleife mehrfach ausführt, dann steigt die Ausführungszeit linear mit der maximalen Anzahl der Durchläufe unabhängig von der Art es zu zeichnen.

Das Problem scheint wirklich, dass das eigentliche Dekodieren der Jpegs bei TJPEG CPU basiert arbeitet, was bei einer so hohen Wiederholrate nicht mehr klappt.

Leider habe ich auch noch keine vernünftigen Wrapper für LibVCL gefunden, bei der man ohne weiteres Streams laden kann.
Kennt vielleicht jemand eine Möglichkeit mit DSPack ein Jpeg aus einem Stream zu laden.

[TiGü]

Zitat von philiph:

Leider lässt sich die Laufzeit so einfach nicht messen, dafür geht es zu schnell das Ergebnis ist immer Null.

Das kann nicht sein, da muss dir ein Fehler unterlaufen sein.
Bitte kontrolliere das nochmal.
Ggf. schreibe per OutputDebugString ins Event Log, anstatt per Formular-Eigenschaften die Zeit auszugeben.

Da müssen mindestens 1 bis 15 ms bei rum kommen.

Denn wenn die verstrichene Zeit um die 0 ms betragen würde (also sich im Bereich von Nanosekunden bewegt), dann hättest du auch keine Probleme bei einer Bildrate von 30 FPS -> 33 ms von Bild zu Bild.