Hallo Leute,
Ich hab vor innerhalb der nächsten Jahre eine Engine für live-Visuals zu schreiben (natürlich Open-GL-basierend).
Nach meinen derzeitigen Konzept plane Ich vier Layer (Szenen) seperat zu rendern (to texture) und danach mittels blending übereinanderzulegen.
Damit man nun diese einzelnen Szenen einstellen kann ist es nötig diese auch getrennt in das UI zu zeichnen(was ja an sich noch kein Problem darstellt).
An meine (sehr beschränkten) Grenzen gestoßen bin ich momentan mit folgenden Problemen:

-Video-Overlay wie bekomm ich die Grafikkarte (bzw Winows)
dazu meine OpenGL Komposition auf den zweiten Monitorausgang
zu spiegeln?

-Audio-Input giebt es eine Möglichkeit direkt auf die Pegelwerte
zuzugreifen (wenn nicht würd Ich die ganze Sache mal als
Winamp-Plugin beginnen und mir das später überlegen)

-Video rendering ist auch noch ganz wichtig da ich bis zu vier layer video
"gleichzeitig" in texturen reinschreiben werde (möchte(wöllte))
ist es nötig das dies auch mit einem affenzahn passiert

Ich hoffe Ihr könnt mir zum einem oder anderem Thema ein paar tipps aufs Aug drücken,
cu
Volker

Hab zwar noch keine Dual-Head OpenGL-Anwendung geschrieben, allerdings bietet dir OpenGL je nach Pixelformat mehrere Pixelbuffer, wie z.B. GL_LEFT und GL_RIGHT bei nem Stereo-Format. In Sachen Dualmonitorausgabe dürfte das also so ähnlich gehen. Du musst dann halt ein passendes Pixelformat angeben und abwechselnd in den Puffer für Monitor 1 und dann in den Puffer für Monitor 2 rendern.


Das geht am einfachsten wenn du eine fertige Sound-Library wie z.B. FMOD nutzt. Diese bietet dir nämlich eine sehr einfache Möglichkeit auf das komplette Pegelspektrum in deinem Programm in Echtzeit zuzugreifen.


Auf Sulaco gibts ein schönes Sample, das ein AVI-Video über DX-Capturefunktionen grabbt und in eine OpenGL-Textur rendert, natürlich mit Quellcode. Bei vier Videostreams gleichzeitig wirds aber zeittechnisch recht problematisch, da du ja dann nicht nur vier Videostreams gleichzeitig laufen, sondern auch gleichzeitig grabben und als Textur an die GPU senden musst. Ich kenn das zu verwendende System zwar nicht, aber selbst auf nem High-End Rechner dürfte das die Anwendung zu stark bremsen wenn du das Frame-per-Frame machst. Also wirste dir da einen halbwegs "intelligenten" Timingmechanismus bauen müssen um die Geschwindigkeit in brauchbare Dimensionen zu bringen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@Video-Overlay: Wie meinst du das mit Spiegeln? Die meisten Treiber unterstützen eine Möglichkeit den Desktop auf beide Monitore zu erweitern bzw. den zweiten Monitor mit dem Ersten zu klonen. Wenn dir das genügt müsstest du nicht einmal etwas in deinem Programm berücksichtigen.

@Audio-Input und Spektrum: Das ganze schimpft sich FFT. Fast Fourier Transformation. Damit kannst du mit recht einfachen Mitteln deinen Soundbuffer in die einzelnen Bestandteile zerlegen. Aber nach Möglichkeit solltest du schon etwas verwenden was bereits existiert. Das wird wohl optimierter sein als der blanke Algorythmus.

@Video rendering: Hast du dir schon einmal DirectShow angesehen? Das ist eine Universalschnittstelle zum Abspielen von Videos und Musik. Und du kannst dort (meines Wissens nach) Frame für Frame die Bilder holen. Diese kannst du dann in eine Textur hochladen. Allerdings wenn ich mir meine Prozessorlast beim Abspielen von einem Video (DivX) anschaue. Und dann noch 3 Videos und OpenGL dazureche bräuchte ich schon 4 Rechner um das Performant hinzubekommen. Wie groß sind denn die Videos und um was handelt es sich denn dabei. Evtl kannst du ja ein wenig tricksen. Also 15 Bilder die Sekunde und 320x240 oder so etwas. Das reduziert die Zeit für das Dekodieren.

@2. Video Ausgang: Wenn du ein VCL-fenster verwendest, musst du ihm nur mitteilen, dass es auf dem 2. Monitor plaziert werden sollst. Dannach musst Du für dieses Fenster eigentlich nur noch OpenGL initialisieren und die Renderings dort ausgeben. Theoretisch zumindest...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Danke für die Antworten!
Ich mach mich grade drann ein Layout für das User-Interface zu zeichnen(Ich glaub das sich damit eine ganze ecke leichter drüber reden läßt)
bis dann
Volker

Ich hoffe Ihr könnt meine Ideen hinter dieser Skizze ein wenig nachvollziehen. Ich reiß jetzt kurz die einzelnen Bereiche an und versuch mein Konzept relativ tiefgreifend zu erklären (mit ansätzen wie ich das zu implementieren gedenke).
Na dann mal los (wens interessiert)
Links Oben:
Status der kompletten Umgebung
Links Unten:
Auswahl für Objekte, Texturen, Moves und FX
Hier kann mann die Elemente für den Aktiven Layer auswählen
(war zu faul da previews reinzumalen)
Rechts unten:
die einzelnen Layer und Ihr aktueller Status & blending optionen(fehlt noch)
Vorschau der Layer (möcht ich nur jedes 3. bis 5. frame zeichnen)
Rechts Oben:
Vorschau für den Output (das würd ich gern auf den zweiten Monitor spiegeln)
Mitte Oben:
Einstellmöglichkeit für das aktive Element z.B.: geschwindigkeit einer Bewegung, iterationen eines Effekts, helligkeit einer textur....

Für die Programmstruktur des Main loops hab ich grob folgenden ablauf vorgestellt:
massage-dispatcher
for i:=1 to 5
begin
Die layer (wenn aktiv) to texture rendern
die 4 layer-texturen auf den output rendern
end;
wobei das rendern eines layers folgendemaßen strukturiert ist:
drawtexture (macht die jeweils aktive textur-routine)
calcmov (setzt die modelviewmatrix für die Szene (layer)
fx -->drawobject (effectprogramm ruft das objectprogramm (eventuell mehrmals)auf)

Ich weis das ganze ist noch sehr dünn aber ich sagte ja schon das ich davon ausgehe das ich mich ein paar Jahre damit beschäftigen möchte(wenn ich daran glaube das was weitergeht).
Ich hoffe Ihr könnt mir rechtzeitig auf die füße steigen wenn ich jetzt schon konzeptionelle fehler gemacht habe.
bis bald,
Volker

Also vom Prinzip her steht deinem Vorhaben eigentlich nichts im Wege. Woran es allerdings im Endeffekt scheitern könnte, wäre die Hardware.

Auf keinen Fall wirds mit brauchberen Frameraten ablaufen wenn du in jedem Frame gleichzeitig vier Videos von Platte streamst (da müssten dann schon mehrere Platten her und die Dekompression dauert je nach Format ja auch recht lange) und diese dann auch noch in jedem Frame in eine Textur rendern willst. Das würde dann nämlich grundlegend folgenden Ablauf bedeuten, der vier mal pro Frame ausgeführt werden muss (unter 25FPS darf es ja wohl kaum laufen) :
Videodaten von Platte streamen (HD) -> Videodaten dekomprimieren und in den Videospeicher streamen (CPU) -> Videodaten grabben (GPU) -> Videodaten als Textur hochladen (GPU) -> Videostreams miteinander kombinieren (GPU).
Bei 25fps würde das bedeuten, das du für obigen Vorgang nur 10 ms (x4 Streams=40ms=25fps) Zeit hättest, was allerdings kaum machbar sein wird.

Für dein Vorhaben musst du dir also wie gesagt entweder nen intelligenten Ablauf einfallen lassen, der so viele Operationen wie möglich unterlässt sofern diese nicht nötig sind und du brauchst v.a. moderne Hardware. Ich schätze mal das bei deinem Projekt unter ner 2.5Ghz CPU+Radeon9800GPU+min. 2 HDs kaum was Brauchbares bei rauskommt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Da muss ich zustimmen. Ich glaube auch, dass Du das ganze in Realtime wahrscheinlich vergessen kannst. Was aber NICHT bedeuted, dass Dein Projekt sterben muss. Du könntest die 4 Movies ja auslesen und in einen 5. Movie rendenr. Denn kannst Du dann als finales ergebnis problemlos ablaufen lassen!

BTW, For i := 1 to 5 lässt die Schleife 5mal durchlaufen. Wollte das nur anmerken (da Du ja nur 4 Layer hast!)

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich sehe das allerdings auch als sehr Problematisch an. Es gibt eine Software die macht so etwas in der Art jetzt schon. Dort kannst du Videos schneiden zusammensetzen mit einer Unzahl an Effekten belegen. Allerdings können die nur eine kleine Vorschau (in echtzeit) und das noch mit geringerer Qualität. Sie werden wissen warum.

@ SOS: ich denke an ca 1/2 -1 jahr entwicklungszeit bis dahin sind bei den leuten die solche programme ernsthaft benutzen wollen 3 GH prozessoren mit 1-2MB cache standard (ich werkel zur zeit auf einem dual XEON 2.8)
Außerdem muß ja nicht auf jedem Layer ein video laufen, es kann ja auch mal eine statische oder prozedurale textur sein
@lossy eX: Ich weis daß es schon ein paar zum teil ganz ordentliche programme giebt (z.b.: www.resolume.com) aber die einen können nur video, die nächsten sind schweinelangsam und dann giebt es noch die kategorie visual-jokey die vom funktionsumfang so aufgeblasen sind das kaum noch ein zugang zu finden ist das ding LIVE zu kontrollieren
@schodMC: die Schleife sollte heißen daß alle layer und der output 5 mal gerendert werden und dann erst der dispatcher und das UI zum zug kommen
@ alle: danke für eure tips und unterstützung --> finde das eine tolle plattform
werd mich am abend oder morgen in einem neuen thread mit neuen fragen wieder melden!
cu
Volker

Wie gesagt (und an meiner Beschreibung ablesbar) bilden hier weder die Platten, noch die CPU das größte Problem, sondern die Grafikkarten. Wenn du Frame für Frame vier Texturen in brauchbarer Auflösung erstellen willst (also mindestens 512x512) und diese dann auch noch Frame für Frame zur GPU hochladen und von dieser kombinieren lassen musst (würde man eh am besten über ein Fragmentprogramm machen), dann sollten selbst in 1 bis 2 Jahren aktuelle GPUs noch ins Schwitzen kommen. Deshalb hab ich auch gesagt, das du dir hier was Schlaues einfallen lassen musst.

P.S. : Hast du auch vor die so kombinierten Videos wieder zurück auf Platte zu schreiben? Wenn ja, dann wirds wirklich schwierig, da besonders dieser Vorgang so ziemlich das langsamste ist was man einer GPU antun kann.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Zunächst hab ich das ganze nur als live-tool geplant. Sinn und Zweck ist es einfach die möglichkeiten von openGL zu nutzen um heftige graphik zur allgemeinen belustigung über einen projektor auf eine wand zu werfen.
Dabei geht es (mir) nicht einmal hauptsächlich um videos sondern mehr um die kombinationsmöglichkeit verschiedener elemente wie zum beispiel als hintergrund (layer 1) einen tunnel mit statischer textur die die farben ändert. darüber dann ein würfel mit einem live video-stream drauf der sich zur musik bewegt (Layer 2) lann noch ein plasma mit chromakeying drüber (Layer 3) und dann noch einen text drübergemalt (layer 4)

Ich hoffe euch ist jetzt klarer worauf ich abziele aber bis dahin hab ich eh noch einen verdammt langen weg vor mir.
cu
Volker

Wenn das nur zur Vorführung geplannt ist ,dann könnte man probieren die Frames nicht als Video sondern einzeln als komprimierte Textur zu speichern.
Die Extension ARB_pixel_buffer_object soll Streaming in Texturen auch ausdrücklich für Videos erlauben.

Lars: meinst du etwas WGL_ARB_pbuffer?

Aber in dem zusammenhandg solltest du dir dann auch einmal WGL_ARB_make_current_read. Damit soll es möglich sein Texturen ohne umweg über den Clientbuffer zu kopieren. Glaube habe das so mal gelesen.

Ne, das ist so eine ganz neue Extension im Stil von ARB_vbo. Die soll ab dem Detonator 55 enthalten sein. Was mit ATI Karten ist weiß ich nicht. Das stand mal in dem ARB_vbo PDF was vor einigen Tagen in den News war.