Forum

VLC multiple video switch

vvvv beta question
#1

In a spread of 80 video textures on 80 quads - all runs smooth at 30fps. Now, I want to switch some of the videos. So far, I am doing this by switching the Filenames that are fed into VLC Filestream DX11. Whenever I do this switch, whole vvvv framerate drops down fare below 30fps for just one or two frames. At that exact moment, the PerfMeter green bar is becoming very large.
I am not quite sure why the switch of a single video causes a performance drop of the whole patch. Considering that I am using a fast machine with SSD that is basically able to playback this stuff smoothly, I am not sure where the problem can be located. Tried different video compressions and filesize (QT Animation, PhotoJPG).

Any ideas?

#2

use getslice node and switch slices, for seamless switching u gonna need a tex array

#3

Do you mean the GetSlice (DX11.Texture Array) node? I guess it has to be connected somehow to the Filestream Texture out, but it can’t. How goes the patching pipeline in this case?

#4

nope nope nope first of all it is a wonder you can play 80 videos at 30 fps without any other problem than a little hickup during load. how much RAM you have? second of all a plain GetSlice (Node) will be enough (you don’t want to write to 80+ layers of a TextureArray) so load all of your videos (if your system can take it) group the ones together you’d like to switch with a binsize pipeline, use GetSpread (Node Advanced) (see attached patch) so you can easily switch the videos you want without the need to take care of slice offsets, using your binsize list connected to advanced GetSpread’s Input Bin Size pin.

TextureArrays are created on GPU and they are only efficient if you write your own shader for handling them. Individual layers of a TextureArray are not represented as slices as they are part of the GPU resource and they are not exposed to vvvv (witch is a good thing btw). So GetSlice (Texture2DArray) and SetSlice (Texture2DArray) are not operating on slices and the output of filestream are individual Texture2D’s not a Texture2DArray note the difference ;)

GetSpread (Node Advanced).v4p (5.8 kB)

#5

The videos have a relatively low resolution, I guess that’s why they are playing smooth altogether simultaneously. They are only using 3GB of the available 16 GB RAM. However, the CPU usage is already 60% and, if I cache another 80 videos (160 total) CPU get on its limit and framerate drops significantly.

If I understood right, with the GetSpread method, I need to load more than two sets of 80 videos, at least 160 or more, as I want to switch between the whole 80 video sets by 0.3 second interval for each video. Having 100 videos in VLC already gets the CPU at its limit, even if I only use 1 of them with the GetSlice node. So it seems that the selection has to happen somehow inside the VLC node as caching to many videos is beyond its capacity.

I am wondering if someone run in this problem earlier. Seems some people are using vvvv to build VJ engines or similar things. So there should be a way to load videos without vvvv getting hick up every time.

Any suggestions?

#6

if the videos are at the same lengths when i faced similar task on a much worse hardware i baked a grid of lot’s of videos into fewer higher resolution videos with after effects and placed them on quads with texture transforms so individual quads were addressing different parts of the same baked video. that saved much performance however it is the best when all the videos are more or less have the same length. also you might want to write a little metadata file which video is positioned in which video-grid and where on that grid.

if only the set of videos have the same length which you want to switch, you might use baking on them on their individual video-grid so you end up with 80 baked videos with a little metadata so texture transforms know where to look. if none of the videos have the same length then you have to tolerate or account for the framerate-drop when switching between them

#7

what about avisynth? maybe this one from elektromeier elektromeier avsavijoiner

#8

Thanks for the suggestion. I tried the Avisynth workaround. The script generation patch is indicating “Some Problem with Avi’s” and produces an empty script. Tried different video compressions, no luck.

Btw, it is really fun to play around with vvvv, but whenever I want to use it in a professional production, this kind of flaws make it impossible.

#9

if you shared the patch, you could get tips on how to improve it

#10

well you will face similar problems with €3 000-€10 000 media servers minus all the diversity of vvvv which is only €500 for commercial, anyways with the trick i’ve mentioned above you can overcome the switching problem, fewer higher resolution videos take up less resource and cpu than lot’s of low resolution videos. I’m using vvvv professionally for years now and as i said i solved a similar problem to yours couple of years ago on a much worse hardware (4 GB RAM for example) with the 32 bit vvvv with the vlc node.

avisynth is a very oldschool stuff with other oldschool mostly abandoned/deprecated dependencies so be careful with it

#11

Attached the patch. It shows the original attempt switching the filenames. The original videos are too many and too large (real footage) for an upload. So I prepared two dummy videos with simple graphics. It seems that it doesn’t really matter in terms of performance if 80 difference videos or only two videos with 80 instances are used in VLC. So it still should give a good reference of the problem. The yellow graphic is a placeholder for transition effects.

Thank you Microdee for the AE suggestion. I used AE initially. But became curious if there would be a more elegant solution in vvvv, to avoid render time and preserve more flexibility in updating video content on the fly.

Many thanks for any suggestion!

video-switch.zip (142.4 kB)

#12

Looking at your patch I would approach it from a different way, actually there are two options.

A. do everything in vvvv, looking at the content of the videos, it would be super simple to render that in real time, ensuring that you can have buttery smooth playback at 60fps.

B. in case you feel that patching that in vvvv is too hard, I would render your videos to an image sequence, (perhaps even dds if you want it super fast)and use FileTexture (DX11 2d.pooled) to getslice the textures from that. this way you will have significantly lower load to play back your videos as you load each frame of the video just once.

#13

I know, patching this graphics would be much faster than using video. But, as mentioned, this are dummy videos I created to keep the size of the ZIP small. The original videos are much longer and showing real footage sequences…

#14

ok, but as long as you are just working with 3 videos, I would suggest working with imagesequences, loading videos on the fly like that is a real performance killer.

#15

Thanks for the suggestion. I’ll give the image sequences a try. But I am a bit concerned, as some videos a quite long (movie length) and there will be much more than two of them. Thus, keeping them in movie containers would make things much more easier to handle.

© vvvv group