Traversing a lot of frames through a lot of movies.. ?
Hi,
imagine something like 30 movies, 4K, each one 1 minutes.
I'm starting to design a system that could basically read and blast frames to the screen.
by read I mean take a frame and display it.
I don't need to read a whole movie smoothly. I'll divide them (for other aesthetic purpose) into 360 frames. (1 min = 360 frames)
I need to read frames from a movie, then from another, combining part of frames of one movie and another different one at the same time (I think as soon as I'll have one system for that I'll multiply it one or two times in order to be able to combine)
I was thinking about using jit.movie & hap or viddll (for random access purpose) but basically, I do not need smooth but only 360 frames per movie.
So my system could be based on a "kind of" frames buffer/matrices.
Being able to have my all 30x 360 pictures reachable/accessible at the same instant could be the goal/target.
I'll have some processes that could grab that frame from that movie and the other one etc VERY fast.
Any ideas/leads ?
I can code fast and furious, use jit.gen jit.gl.pix then, or java accessing jitter too.
thanks in advance :-)
To do buffering on the graphics card, I use the poly~ object to create a large (and variable) number of texture objects - this allows for extremely quick random access to these textures. However, I think you're going to run out of video memory very quickly if you want to get 30*360 frames of 4k video into the system...
for GPU i would use jit.gl.textureset JS (example found via the file browser). alternatively you can store in CPU RAM using either viddll engine loadram feature, or just jit.matrixset.
you're going to need a lot of RAM.
As I'm still in architecturing the system, I can also :
- reduce the number of instantly available set of frames (I mean 5 instead of 30)
- reduce the number of frames per set (180 instead of 360)
For the first prototype commissioned, 2K will be enough. That's already less definition.
And I can also do asynchronous loading like:
- I load 3x 180 frames somewhere (jit.matrixset maybe)
- I play with that, in the "end" I load 3 other sets
etc.
BUT, is jit.matrixset the best bet for storing 360 (or 180, or less) frames and access them fast ?
basically, the "real question" is: what could be the best bet for doing this ?
- extracting each 180 or 360 still per video (not at performance time but before) & loading them into n matrixsets ?
- extract stills for each movie, render all movies again (those would have 180 or 360 frames) and use many jit.movie, each one with a movie loaded
- use video as they are
I tried to load these amount of frames into a matrixset.
It takes a long time and I just realized my best bet, if I reduce the amount of frame that much (I mean : 180 or even 360 frames per movie), it would reduce a lot the whole movie (actually, it is 12s and 30fps which means 360 frames). Maybe it would be enough to load a lot of movie in many jit.movie.
I made a basic test.
original are 3840x2160 and about 12s. Files are about 700Mb.
I need "only" 2K, so 2048*1152 (respecting the ratio) and 180 frames are enough.
I used ffmpeg for downsizing + splitting the resulting video into 180 PNGs files. Then, used them for doing a video again. (UGLY process but apparently not degrading as I keep maximum quality encoding in the end)
Seems fast.
Still not sure about my architecture btw ////