i am having constant trouble with the FILESTREAM2 node, when i try to change video files per filename spread or with a remote call (from OSC). at some point, the node doesn’t respond to my selections anymore and keeps the last selected video in its memory.
looking at the node, it displays the new file name alright, doesn’t do anything anymore (no playing, no searching etc… as if it’s being blocked)
the big problem is, that this error is not reliably reproducable. instead it only seems to do this “blocking” at random occurances. vvvv has then to be closed and restarted to make it works again.
i know that this is probably the worst case scenario - a bug only occuring “sometimes”. for the moment the normal FILESTREAM node works just fine for my needs but i would like to ask if somebody else here has experienced similar problems with FILESTREAM2 ?
or, to be more precise, with FILESTREAM2 and OSC messages sent to its pins ?
maybe there’s something i’m doing wrong here. attached is an example patch.
not sure what you mean by that ? how would i do that ?
it might be possibly an OSC message related problem, but the “blocking” also occurs with “playlists”, i.e. a spread of filenames that are selected with a numberbox, as seen in the test patch.
all my video files have the same codec - photojpeg .avi, encoded with ffmpeg.
(as i do a lot of jumping, seeking, etc…, this proved to be the most suitable and reliable codec for my needs). also they all have the same aspect ratio and framerate.
as i already said, that problem doesn’t occur with the normal “FILESTREAM” node. but isn’t “Filestream2” supposed to support fast and hickup-less file changing ?
with debouncing i meant limiting the amount of times the value of the incoming filename string to the filestream2 node can change in a certain amount of time. The directshow based video nodes (filestream and filestream2) are easily thrown off by switching videos too fast. For your scenario you could try the vlc node from the directx11-nodes-alpha or the player-(dx11.texture) contribution which is probably the best choice for heavy scrubbing and clip changing like in classic videobased vjing.
PLAYER (DX11) works great but i noticed another bad thing that unfortunately makes DX11 stuff not useable for live performances yet:
with DX11 textures i get “tearings” on my rendering window (bad v-sync), that i don’t get with DX9 textures. i already noticed this with the Filestream-VLC node, but hoped that single image playing could improve this problem
no idea why this is happening, maybe it’s my graphics card (NVIDIA NVS 5400M on a not too old LENOVO with Win7/64bit), but as i said: all works well if i stay in the good/bad old DX9 realm. too bad, i would really like to switch…
Enabling Aero on Win7 systems might help, otherwise desktop applications running in a window aren’t vsync’d (which DX11 Renderer in “Fullscreen” is). This might only be a solution for a very simple setup (I haven’t even tested if that still works for 2+ screens).
