Forum

Filestream2 - trouble on changing files

vvvv beta question
#1

hi, all !

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.

normal test patch for filestream2 (15.2 kB)
test patch for usage with OSC commands (35.5 kB)

#2

Filestream2 can be a bit touchy so my first suggestions would be:

  • debounce the incoming filename so that it can’t switch too fast.

  • check if it only happens on certain codecs or any other stuff specific to the videos where the node stops working.

#3

hi, thanks for replying

“debounce the incoming filename”

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 ?

best

oliver

#4

hey dobyhal,

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.

cheers,
chris

#5

hi, m4d

great ! i didn’t know that a PLAYER node for DX11 existed !
i will sure try my luck there !

(the VLC node of the DX11 package is great, but not suited for random seeking - at least this is the result of my tests)

thanks for all the insight !

best

oliver

#6

update !

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…

did anybody here experience a similar problem ?

maybe i should open a new thread …

best

oliver

#7

hej oli,

have you tried enabling vsync on renderers?

cheers!

#8

yes, i did !

no difference ;-(

best

oliver

#9

Oh, too bad. I’m afraid it’s dx9 time then…

Opening a new thread like you suggested specific to the dx11 player problem might be a way to go though to get this fixed in the future.

cheers,
chris

#10

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

#11

YEP ! that did the trick !

thank a lot, readme, for pointing that out.

© vvvv group