warum bilderstapel und nicht video?

• bilderstapel sind einfacher zu handeln. wenn einzelne bilder kurzfristig getauscht werden müssen muss nicht das ganze video neu gemacht werden
• bilder sind einfacher mit alphakanal zu versehen
• man kann da auch speziellere codecs verwenden, etwa L8A8, wenn man nur einen animierten schwarzweiss layer hat

also durchaus nachvollziehbar, dass es explizit um einen bilderstapelplayer geht.

kann das nicht der vlc player?

er hat den vlc-player nicht auf bilderstapelplayback getestet, aber diese avisynth sache: http://avisynth.org/mediawiki/Main_Page
damit geht das natürlich grundsätzlich, aber das handling is verkompliziert durch die tatsache, dass da wieder .txt files geschrieben werden müssen wo die bilder adressiert werden. (bin mir grad nicht sicher, ob das das einzige problem war, aber die methode entsprach jedenfalls nicht den anforderungen).

auftragsdefinition

im grunde also gilt, wir brauchen einen node Player (EX9.Texture) mit folgenden inputs:

• Directory
• File Extension
• FPS (gibt die original fps des bilderstapels an)
• Reload (um verzeichnis mit gegebener fileextension neu zu scannen)
• Time
• Preload Count (default 1, aber je nach overall system load/stability könnte experimentell auch festgestellt werden, dass hier eine höhere zahl sinn macht)

und outputs:

• Texture
• Directory Loaded

alle pins spreadable, isklar.

aktuelle implementierungsidee

wir wollen den FileTexture (EX9.Texture) nicht mit der neuen funktionalität belasten, weil die dort vorhandene spreading und library-logic nur schwer mit den anforderungen in einklang zu bringen wäre. trotzdem könnte die ladeperformance des nodes verbessert etwas werden, wenn das threading anders gelöst würde.

der Player (EX9.Texture) würde versuchen jeweils "Preload Count" filestreams im hintergrund geladen zu haben und nur im moment von Evaluate das eine aktuell gewünschte bild in eine textur kopieren.

optional future

3 neue themen sind im telefonat aufgetaucht, die interessant scheinen, aber ganz klar nicht im aktuellen auftrag enthalten sind:

• timestretching: er will den stapel nicht nur in originalgeschwindigkeit abspielen, sondern mglw. auch in zeitlupe, das heisst dass je nach eingehender zeit 2 aufeinanderfolgende frames auch mit einander verblendet werden könnten, bevor eine textur ausgegeben wird
• clipblending: in dem fall müsste das spreading des nodes ganz anders funktionieren: mehrere directories sind clips, die nur nacheinander gespielt werden können. dafür könnte man über einen Input-Index wählen, welche clip gespielt wird und wenn sich dieser index ändert blenden die clips ineinander über. mglw. sollte diese option aber eigentlich lieber zu patchen sein.
• nachladen von verzeichnissen zur laufzeit: dauert das länger als das laden einer zahl von "Preload Count" frames, da ja erstmal das verzeichnis mit 30k .jpgs gescannt werden muss?

todo

• time/preload count pins umstellen auf frame/frames to preload
• weg finden um texturen im ersten frame zu laden (device erst im 2. frame vorhanden)
• wird knoten gelöscht führt es manchmal zu freeze. genaue ursache noch nicht völlig klar. muss ich noch weiter debuggen.
• device handling auf managed seite überarbeiten (allgemeineres problem). führt derzeit zu memory leaks und invalid directx calls.
• andere datenformate testen / laden können

vorteile von dds?

    dxt compression?

• fall: 1 frame pro v4 frame abspielen
• bin sized visible und preload frames