Realtime video buffer with variable speed access


    Dec 17 2007 | 7:14 pm
    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

    • Dec 17 2007 | 9:36 pm
    • Dec 17 2007 | 10:48 pm
      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
    • Dec 20 2007 | 9:37 pm
    • Dec 21 2007 | 7:38 pm
      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
    • Dec 22 2007 | 7:51 am
      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
    • Dec 22 2007 | 1:49 pm
      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 >
    • Dec 22 2007 | 7:06 pm
      Hi Mattijs,
      Thanks a lot ! The effect is nice... I have to enter the spider now ;-)
    • Dec 22 2007 | 7:19 pm
    • Feb 09 2008 | 1:43 pm
      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
    • Aug 09 2011 | 10:55 pm
      hey Mattijs, that is a great Patch!