Realtime video buffer with variable speed access
Hello,
A question about time. Could it be possible to record live video with
a jit.qt.grab, and store it in real time in a variable access buffer,
which would be read at variable speed rates ?
For example we would read this buffer at the same speed than the
incoming live video (= no delay), then we would read it slower, at
different speeds (=> creating an increasing delay compared with the
realtime), and then for example accelerate again the lecture speed of
the buffer, in order to re-synchronise it with the incoming realtime
video.
I tried to make it with the "video delay" example published by
Jonathan Lee Marcus on the list (thanks again), using matrix
dimensions to store frames read with the srcdimstart and srcdimend
cmds, but I didn't get it : I can't read these stored matrix at
different speed rates. Sorry if it's obvious, I'm not very
comfortable with this method. I post the patch again for reference.
Thanks & best regards,
Thierry Fournier
For variable speed access, all you have to do is move an index up or
down at different rates. You can play around with a floating point
index and take the 2 closest frames which you would then blend in some
fashion according to the fractional amount of the index.
wes
Inspired by this discussion I was playing with time buffers a bit, I thought you might like this one.
(save and load to fire the loadbangs)
Mattijs
Hello,
Thank you again, a lot, for these explanations and the example.
>> But theorically I could (in "thru 0") recall the last frame with
>> "matrixoutput 0", or 1 or 2, etc and increase progressively my
>> delay- but apparently these frames can be read only when the
>> entire cycle is filled again. Did I miss someting ?
>>
>
> perhaps i misunderstand, but i think you are confusing the way
> matrixoutput and index works.
> thru should be off, so that we only see what we call for using
>
>
> jit.matrixset stores the incoming matrix at the position you
> specify in the buffer through
> the "index " message.
Yes, that was clear for me.
>
> "matrixoutput 0" outputs zeroth position of the buffer, not
> exactly previous frame as you mention.
> we need to keep track at which frame we just wrote into, so that we
> can think on more or less
> delay depending on that position. that's why i used the + and %
> operator. it ensures the result
> wraps around the max num frames, while keeping the same distance
> from the frame just written.
But I didn't get this point - I believed that the last frame was
always at index 0. Though it's obvious that it can't be...
I'm going to have a serious look at your patch, at timecube too (I
downloaded it yesterday), and I come again when all these questions
will be absolutely clear for me :-)
Thanks very much again Andre
Best
Thierry
hi
>
>>
>> "matrixoutput 0" outputs zeroth position of the buffer, not
>> exactly previous frame as you mention.
>> we need to keep track at which frame we just wrote into, so that
>> we can think on more or less
>> delay depending on that position. that's why i used the + and %
>> operator. it ensures the result
>> wraps around the max num frames, while keeping the same distance
>> from the frame just written.
>
> But I didn't get this point - I believed that the last frame was
> always at index 0. Though it's obvious that it can't be...
>
this would be true for a fifo like behaviour, but the way the object
works,
it builds an internal array of matrices, that you can write to
position x (index x)
and read from position x-1, which gives you one frame delay (with
message 'outputmatrix (x-1)')
because x-1 might fall off the 0-maxframes interval (think on the
case writing to array pos 0,
reading would be pos -1) the + and % are the objs are used to make
sure if you write to pos 0,
you'll read from pos max, in a 1 frame delay scenario..
it took me a long time to figure out this stuff, but its quite simple
in the end..
look at this in slow motion, it helped me a lot too. remember to use
max num for 0
frames delay, and decrease the number to increase the delay
> I'm going to have a serious look at your patch, at timecube too (I
> downloaded it yesterday), and I come again when all these questions
> will be absolutely clear for me :-)
>
have fun!:)
> Thanks very much again Andre
> Best
>
welcome, and thank you Mattijs for a very cool patch!
a
> Thierry
>
Hi Mattijs,
Thanks a lot ! The effect is nice... I have to enter the spider now ;-)
Thierry Fournier
http://www.thierryfournier.net
Hello,
Just a (late) message for thanking Andre Sier, Mattijs Kneppers and
Wesley Smith for your wise advices about realtime video buffer, one
month ago. I worked again on this project after some weeks of
interruption. Everything's was conceptually clear enough to define
the functions of the patches. Mathieu Chamagne will work with us, on
the project software.
This small installation, which is called "Point d'orgue" ("Fermata"),
will be premiered in Montpellier (France), in November, and I'll keep
you informed.
Best & thanks again,
Thierry
----------------------------------------
Thierry Fournier
http://www.thierryfournier.net
hey Mattijs, that is a great Patch!