buffer live video up to 30 minutes


    Jan 17 2008 | 6:41 pm
    ----------------------------------------------------
    Hello good max/jitter people !
    I'm alsow making a live video delay, or buffer (I allready found some very helpful posts) Only I want it to buffer / delay up to 30 minutes... is this possible ?
    What do I need to do so that it doesnt freez after about a coupple of minutes. I have 2Gig of RAM in my computer. Would it work if I had more ?
    Thank you very kind, Charles

    • Jan 17 2008 | 7:04 pm
      the patch I use now
    • Jan 17 2008 | 7:08 pm
      your memory buffer is limited, for 30min its best you use disk based buffer using jit.qt.record
      On Jan 17, 2008 8:41 PM, charles wrote:
      > > > ---------------------------------------------------- > > Hello good max/jitter people ! > > I'm alsow making a live video delay, or buffer (I allready found some very > helpful posts) > Only I want it to buffer / delay up to 30 minutes... is this possible ? > > What do I need to do so that it doesnt freez after about a coupple of > minutes. I have 2Gig of RAM in my computer. Would it work if I had more ? > > Thank you very kind, > Charles > -- > www.charlessarah.com >
    • Jan 17 2008 | 7:09 pm
      a delay of 30min might be outside the realm of possibility, but one could do a setup where one records a file of x length and after 30min begin playing the file from the top while one initiates another file recording. off the top of my head, and without a clue of how to do it. ;-) cheers bruce
      On Jan 17, 2008, at 1:41 PM, charles wrote:
      > > > ---------------------------------------------------- > > Hello good max/jitter people ! > > I'm alsow making a live video delay, or buffer (I allready found > some very helpful posts) > Only I want it to buffer / delay up to 30 minutes... is this > possible ? > > What do I need to do so that it doesnt freez after about a coupple > of minutes. I have 2Gig of RAM in my computer. Would it work if I > had more ? > > Thank you very kind, > Charles > -- > www.charlessarah.com
      bruce tovsky www.skeletonhome.com
      "Sometimes the appropriate response to reality is to go insane." Philip K. Dick
    • Jan 17 2008 | 8:14 pm
      hey btovsky and yair r.
      I'll explain what it is I want to do...
      In a room there are several camera's. Each camera is connected with my max patch on different inputs (right now I'm only using two camera's). Using a motionsencor sending it's information to an arduino device, my max patch gets a "bang" whenever a person comes in front of a camera.
      Now in a second room there would be a projection that shows what is happening in the first room. But it should be that you could see yourself. So it has to record the live video, buffer it for about 30 minutes and then be replaced by the new live images.
      This should result in a 'movie' where the visitor would see himself 'acting'.
      I need to find a way that the video is show'n "live" but with a 30 minute delay or buffer. I don't see how the 'jit.qt.record' object can help because it has to be live...
      Thank you for reading ! anny sugestions are more then welcome.
      Cheers, Charles
    • Jan 17 2008 | 8:26 pm
      On 17-jan-2008, at 19:41, charles wrote: > Only I want it to buffer / delay up to 30 minutes... is this > possible ? > What do I need to do so that it doesnt freez after about a coupple > of minutes. > I have 2Gig of RAM in my computer. Would it work if I had more ?
      when you use jit.matrixset to buffer the video, it is uncompressed. when you would use a ram disk, and record to it and read from it, you may compress the video (provided that you have the CPU power to spare). using a ram disk instead of a hard drive eliminates latency problems that you mey get when reading and writing simultaneously to the same drive. As you cannot read and write from one file at the same time, you have to split the file in chunks smalelr than 30 minutes. this introduces some file name bookkeeping, but is not hard to do. instead of using a ram disk, go for a solid state disk (if you have the $$ to burn)
      It helps to make two separate processes, one for recording, one for playback, to use multi-core CPUS. you can achieve this with max by building a standalone for one of the two processes, and using max for the other When on windows, you may use an application like WinDV to do your recording. it will split the files for you and number them.
      We used a winDV based patch for a 10 minute delay of a DV quality stream. the playback was not linear. we recorded two minute chunks to ram disk, and right after recording copied the chunk to a hard drive. just before playback the chunk was copied back to RAM disk and played from there. the hard drive was there for its storage capacity, the ram disk was there for smoothing the stream. worked reliably, with no dropped frames.
      HtH -jennek
    • Jan 17 2008 | 9:04 pm
      If you're in two different rooms anyway.
      Just have one computer recording inputs to files and saving them to a server which is networked to the other room where you playback those segments. Just as well not to have your playback running on a machine with live inputs and recording anyway. All the file accessing would result in horrid amounts of freeze-ups in Jitter.
    • Jan 17 2008 | 10:18 pm
      On Jan 17, 2008, at 3:14 PM, charles wrote:
      > I don't see how the 'jit.qt.record' object can help because it has > to be live...
      well, a 30 minute delay is definitely not "live"... the record object will help you record 30 min of video and then play it back.... 30 min later! but leo has the best idea i think. b
      bruce tovsky www.skeletonhome.com
      "Sometimes the appropriate response to reality is to go insane." Philip K. Dick
    • Jan 18 2008 | 8:19 pm
      Charles
      as a follow up to our off-line discussion, here are the details of my recipe for XP. you need a RAM disk of at least 4 times the segment size.
      recording: WinDV records to RAM disk. make it write file segments of 25*60 frames or so. in your max patch, [folder] polls the RAM disk and when a segment is completed, [doshack] copies the file to the hard drive and deletes it from the RAM disk.
      playback: two [jit.qt.movie]s alternatingly play a segment from RAM disk. just before a new segment needs to come up, [doshack] copies it from the hard disk to the RAM disk. when the one player has reached the end of its segment, the other player reads the new segment and you begin sending bangs to the other player. [doshack] deletes the previous segment from the RAM disk
      with this set up, the transition from one segment to the other is hardly noticeable, even when the recording is in progress. This was on a dual core machine.
      If you would go for a solid state drive, I expect that you can do without the RAM disk, but I have not yet tried it.
      -jennek