Für eine Ausstellung soll eine in Processing geschriebene App, welche ein Video und ein USB-Kamerabild mischt, per Beamer in HD als Endlos-Loop gezeigt werden. Entwickelt habe ich das ganze auf einem I7-Macbook mit 8GB RAM und da läuft es noch etwas zu ruckelig. Ich schätze mal mit 8 Frames/s, wünschenswert wären so mindestens 16 Frames/s. Am meisten Rechenzeit frisst ein Blur-Filter (Filter-Library), der die Bilddaten für die Kamera "glättet", bevor diese in reines SW gewandelt und mit dem Video gemischt werden. Also geht es mehr um die reine Prozessor-Power als um die Fähigkeiten der Grafikkarte. Ohne Blur läuft es auf dem Macbook zufriedenstellend. Nun soll in der Ausstellung aber nicht mein Macbook stehen, sondern irgend ein bezahlbarer Mini-PC, so vom Kaliber Nuc oder Gigabyte Brick. Processing fühlt sich zwar wie C++ (ähnl. Arduino) an, "Hinten" kommt aber Java raus - welche Prozessoren in gängigen Mini-PC wie Nuc oder Gigabyte können denn besonders gut mit Java? Nehme ich Windows oder besser Linux und welches? Danke für Tips.
Frank E. schrieb: > welche Prozessoren in gängigen Mini-PC wie Nuc oder Gigabyte können denn > besonders gut mit Java? Nichts davon. Wenn bereits Dein i7 "ruckelt", dann tut es alles, was in irgendwelchen langsameren(!) Mini-PCs steckt, erst recht.
Wenn selbst ein i7 nicht reicht, und es primär Prozessorlast ist, dann könnte man darüber nachdenken, die Job nicht dem dafür nur beschränkt geeigneten Prozessor aufzuhalsen, sondern dem von der Hardware her vielleicht wesentlich besser geeigneten Grafiksystem. Man kann die Leistungsfähigkeit von Grafiksystemen längst auch für Aufgaben nutzen, die davon nicht direkt in Videos umgesetzt werden. Verteilt sich die Software auf alle Threads des Prozessors, oder ist das ein Achter mit Rudermann, d.h. ein Core rudert und die andere sieben kommentieren die Leistung.
:
Bearbeitet durch User
Frank E. schrieb: > Nun soll in der Ausstellung aber nicht mein Macbook stehen, sondern > irgend ein bezahlbarer Mini-PC, so vom Kaliber Nuc oder Gigabyte Brick. Kannste knicken. Die sind nicht viel besser als Dein MAC, falls der nicht schon etliche Jahre alt ist. Hier wäre die genaue Bezeichnung der CPU interessant gewesen. Signifikante CPU (Mehr-)Leistung gäbe es beim 9900K nur mit WaKü, denn der saugt bei Vollast ohne Drosselung >150W aus den 12V. Das geht aus thermischen Gründen nicht wirklich in kleinen Gehäusen. Frank E. schrieb: > Am meisten Rechenzeit frisst ein Blur-Filter (Filter-Library) Den sollte besser die Grafik Hardware rechnen. Dann wäre eins der NUC mit Kaby Lake-G interessant, weil da eine halbwegs rechenstarke Vega GPU mit drin ist.
Das Problem wird sein, dass ich bei Processing nicht bestimmen kann, welcher Thread auf welcher CPU/GPU läuft.
Frank E. schrieb: > Das Problem wird sein, dass ich bei Processing nicht bestimmen kann, > welcher Thread auf welcher CPU/GPU läuft. Die GPU kann nur Aufgaben übernehmen, die speziell für sie geschrieben wurden. Ebenso muss die Aufteilung parallelisierbarer Aufgaben in parallele Thread vom Programm selbst vorgenommen werden. Wenn die eingesetzte Software keine Aufteilung der Leistung auf viele Threads vorsieht, oder eine GPU einsetzen kann, dann solltest du warten, bis die Single Thread Performance entsprechend hoch ist. Was in absehbarer Zeit nicht der Fall sein wird, da sind keine grossen Sprünge mehr zu erwarten. Das wäre dann eine Aufgabe, die mit dem falschen Werkzeug angegangen wurde und mit diesem nicht adäquat lösbar ist.
:
Bearbeitet durch User
Ich würde das anders lösen: 1) Video von UV4L per DMABUF exportieren: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-expbuf.html#vidioc-expbuf 2) In einer OpenGL oder Vulkan Anwendung Importieren (geht nicht mit proprietären nvidia treibern). siehe EGL_EXT_image_dma_buf_import OES_EGL_image_external, etc. 3) Mit GLSL fragment und compute shadern den Stream bearbeiten. Das wäre aber linux spezifisch, recht komplex, wenig dazu online zu finden, und wie das mit dem Kernelsupport aussieht weiss ich nicht, ich habs noch nie ausprobiert. Dank zero copy sollte es aber schneller sein.
DPA schrieb: > Video von UV4L per DMABUF exportieren Ich hab da jetzt mal noch ein Minimalbeispiel gemacht, für all jene, die daran interessiert sind, wie sowas geht: https://gitlab.com/DanielAbrecht/egl-gles2-linux-dmabuf-camera-texture-example https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example Das ganze Initialisierungszeug kann schon aufwendig sein...
Frank E. schrieb: > Am meisten Rechenzeit frisst ein Blur-Filter (Filter-Library), der die > Bilddaten für die Kamera "glättet", bevor diese in reines SW gewandelt > und mit dem Video gemischt werden. Also geht es mehr um die reine > Prozessor-Power als um die Fähigkeiten der Grafikkarte. Ohne Blur läuft > es auf dem Macbook zufriedenstellend. Bezüglich dem Vorschlag die GPU zu verwenden schließe ich mich an. Aber vielleicht kann man noch weiter optimieren: Wenn die Bilddaten in Schwarz Weiß bzw. Graustufen vorliegen müssen (SW), was spräche dann dagegen eine Kamera zu verwenden, die direkt SW liefert? Damit wäre die Datenmenge für einen nachfolgenden Blur-Effekt deutlich kleiner. Oder anders gesagt, warum muss der Blur Effekt auf ein Video in Farbe angewendet werden, ehe das Video nach SW umgewandelt wird? Bevor man da jetzt mit schierer Brute Force Leistung das Problem zu lösen versucht, wäre es doch erst einmal sinnvoll, zu überlegen, ob man die Datenmenge reduzieren kann. Hierzu könnt man auch einen Blick auf das chrominance subsampling bzw. Farbunterabtastung werfen, bei dem im YUV Farbraum die Auflösung für die beiden Farbkanäle U und V reduziert wird, während die Helligkeit, die in der Y Komonente steckt, bei der vollen Auflösung bleibt. Siehe dazu auch: http://www.virtual-horst.de/Uni/Bildformate/Ausarbeitung.html#farbtiefe https://de.wikipedia.org/wiki/Farbunterabtastung
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.