decoding video using GPU - newbie question
Hi,
I've just started learning Max/MSP and Jitter in order to build a video installation project. I am anticipating that this will be a *very rudimentary* application of Max/MSP and Jitter.
What I want to do is play 4 videos from hard-drive to 4 separate displays. These videos would be synchronised to each other and to prerecorded stereo sound. This is strictly playback, everything is prerecorded, with no realtime manipulation. I'm hoping the video can be at least 640x480 at 30fps, higher resolution would be even better.
My questions:
1. Can I use my video cards' GPU to decode the video? I read through the Jitter tutorial documentation, and I didn't find a way to do this. Am I missing something?
2. If decoding on GPU is impossible, what kind of windows PC should I be looking at building (RAM, CPU, disk performance) that would be able to play back these videos at full frame?
3. Is there an environment other than Max/MSP + Jitter that would be suitable, considering the simplicity of the proposed application?
thanks in advance!
cameron
P.S. Thanks to Mattijs for answering my previous question!
You can use the message 'directtowindow' (I think thats it, something
like that), to circumvent any matrix output and get the 'fastest'
path to the screen possible. basically, just like quicktime player
does. That will make life easier patching wise, as well as CPU load
wise. Any fairly modern PC should be able to handle that, as long as
you encode in something that isnt uncompressed, otherwise you'd need
pretty good disks to sustain 4x uncompressed VGA. Motion Jpeg seems
to be the preferred codec.
Jitter cannot, afaik, do GPU accelerated video decoding. Jitter uses
the GPU for openGL and texture processing, using shaders and vertex/
fragment programs.
On Jan 22, 2007, at 1:34 AM, Cameron wrote:
>
> Hi,
>
> I've just started learning Max/MSP and Jitter in order to build a
> video installation project. I am anticipating that this will be a
> *very rudimentary* application of Max/MSP and Jitter.
>
> What I want to do is play 4 videos from hard-drive to 4 separate
> displays. These videos would be synchronised to each other and to
> prerecorded stereo sound. This is strictly playback, everything is
> prerecorded, with no realtime manipulation. I'm hoping the video
> can be at least 640x480 at 30fps, higher resolution would be even
> better.
>
> My questions:
>
> 1. Can I use my video cards' GPU to decode the video? I read
> through the Jitter tutorial documentation, and I didn't find a way
> to do this. Am I missing something?
>
> 2. If decoding on GPU is impossible, what kind of windows PC should
> I be looking at building (RAM, CPU, disk performance) that would be
> able to play back these videos at full frame?
>
> 3. Is there an environment other than Max/MSP + Jitter that would
> be suitable, considering the simplicity of the proposed application?
>
> thanks in advance!
> cameron
>
> P.S. Thanks to Mattijs for answering my previous question!
v a d e //
www.vade.info
abstrakt.vade.info
Hi Vade,
Adding the @window attribute to the movie object dramatically boosted playback performance. Now I'm in business! Thanks for your quick and helpful response!
cw
Hi,
I was experimenting with jit.op and jit.gl.videoplane and it gave me
results I can't understand.
The patches I used were the jit.op.help and jit.gl.videoplane.help
connected. I sent the result of the jit.op into the input of the videoplane.
I tested the the arithmetic, bitwise and logical operator of jit.op.
Here is a list of operator that are not working with jit.videoplane
(means that the video disappears when passing through jit.gl.videoplane)
- subtraction
-m subtraction modulo
absdiff absolute difference
!/ right input/left input
!- right input-left input
!% right input/left input
^ bitwise xor
~ bitwise compliment
>> right shift<< left shift
! logical not< less than
The think is that there is many ways to deal with this problem
(using jit.gl.slab instead of jit.op, ...).
But i'd like to understand what's going on with this operators. Is video
premultiplied by this operators ?, ....
Any idea ?
Patrick
What do you mean premultiplied? All of the operators you listed work
but can have very odd visual effects. Try looking at say a 5x4 matrix
passing through the op in a jit.cellblock to get an idea for what
they're doing. A good number of them or bit operators, so break out
your binary math.
wes
On 1/22/07, patrick suchet wrote:
> Hi,
>
> I was experimenting with jit.op and jit.gl.videoplane and it gave me
> results I can't understand.
> The patches I used were the jit.op.help and jit.gl.videoplane.help
> connected. I sent the result of the jit.op into the input of the videoplane.
> I tested the the arithmetic, bitwise and logical operator of jit.op.
> Here is a list of operator that are not working with jit.videoplane
> (means that the video disappears when passing through jit.gl.videoplane)
> - subtraction
> -m subtraction modulo
> absdiff absolute difference
> !/ right input/left input
> !- right input-left input
> !% right input/left input
> ^ bitwise xor
> ~ bitwise compliment
> >> right shift
><< left shift
> ! logical not
>< less than
>
>
>
> The think is that there is many ways to deal with this problem
> (using jit.gl.slab instead of jit.op, ...).
> But i'd like to understand what's going on with this operators. Is video
> premultiplied by this operators ?, ....
> Any idea ?
> Patrick
>
On Jan 22, 2007, at 2:55 AM, patrick suchet wrote:
> I was experimenting with jit.op and jit.gl.videoplane and it gave
> me results I can't understand.
> The patches I used were the jit.op.help and jit.gl.videoplane.help
> connected. I sent the result of the jit.op into the input of the
> videoplane.
> I tested the the arithmetic, bitwise and logical operator of jit.op.
> Here is a list of operator that are not working with jit.videoplane
> (means that the video disappears when passing through
> jit.gl.videoplane)
I believe they are working fine. Keep in mind the math is applied to
*all* channels. So if you don't want a zero alpha channel, you need
to accommodate by either not enabling alpha blending in the
videoplane object, shoving another value into the alpha channel with
something like the alphaglue or planemap shaders shader or adding an
offset with the math operator's "outoffset" param.
If you have results that are not explained by the fact that the alpha
channel is processed along with the RGB channels, then please let us
know.
-Joshua