buffer live video up to 30 minutes

Jan 17, 2008 at 6:41pm

buffer live video up to 30 minutes

—————————————————-

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

#35424
Jan 17, 2008 at 7:04pm

the patch I use now

max v2;
#N vpatcher 108 120 1813 1017;
#P button 656 74 38 1;
#P user gswitch 656 130 41 32 0 0;
#P window setfont “Sans Serif” 9.;
#P number 874 241 50 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user jit.pwindow 853 407 162 122 0 1 0 0 1 0;
#P user jit.pwindow 655 408 162 122 0 1 0 0 1 0;
#P message 820 345 121 9109513 outputmatrix $1;
#P number 820 319 52 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 823 292 64 9109513 % 10000;
#P newex 823 268 60 9109513 + 10000;
#P message 702 330 70 9109513 index $1;
#P number 702 304 49 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 0 10000;
#X flags 0 0;
#P newobj 702 212 124 9109513 counter 0 0 10000;
#P newex 656 374 222 9109513 jit.matrixset 10000 4 char 320 240;
#P newex 656 173 56 9109513 t s s b;
#P message 553 89 65 9109513 snd_settings;
#P message 444 89 59 9109513 getvdevlist;
#P message 506 89 44 9109513 settings;
#P flonum 369 70 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 335 70 15 0;
#P newex 335 89 44 9109513 metro 2;
#P message 411 89 31 9109513 clear;
#P newex 426 217 25 9109513 iter;
#P newex 521 235 38 9109513 t clear;
#P message 426 280 58 9109513 vdevice $1;
#P user ubumenu 426 259 145 9109513 0 1 1 0;
#X add “Creative WebCam Notebook Ultra”;
#X add “Trust 150 Spacecam Portable”;
#X add “Creative WebCam Notebook Ultra (VFW)”;
#X prefix_set 0 0 0;
#X pattrmode 1;
#P newex 426 235 75 9109513 prepend append;
#P newex 426 187 168 9109513 route vdevlist inputlist formatlist;
#P user jit.fpsgui 341 439 60 9109513 0;
#P message 356 138 28 9109513 open;
#P message 397 138 31 9109513 close;
#P newex 341 166 95 9109513 jit.dx.grab 320 240;
#B color 5;
#P user jit.pwindow 340 303 162 122 0 1 0 0 1 0;
#P window setfont “Sans Serif” 18.;
#P comment 35 32 119 9109522 video buffer;
#P window setfont “Sans Serif” 9.;
#P newex 125 217 25 9109513 iter;
#P newex 220 238 38 9109513 t clear;
#P message 125 283 58 9109513 vdevice $1;
#P user ubumenu 125 262 145 9109513 0 1 1 0;
#X add “Creative WebCam Notebook Ultra”;
#X add “Creative WebCam Notebook Ultra (VFW)”;
#X prefix_set 0 0
0;
#X pattrmode 1;
#P newex 125 238 75 9109513 prepend append;
#P newex 125 187 168 9109513 route vdevlist inputlist formatlist;
#P user jit.fpsgui 41 439 60 9109513 0;
#P message 258 89 65 9109513 snd_settings;
#P message 55 138 28 9109513 open;
#P message 96 138 31 9109513 close;
#P message 149 89 59 9109513 getvdevlist;
#P message 211 89 44 9109513 settings;
#P flonum 74 70 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 40 70 15 0;
#P newex 40 89 44 9109513 metro 2;
#P message 116 89 31 9109513 clear;
#P newex 40 166 95 9109513 jit.dx.grab 320 240;
#B color 5;
#P user jit.pwindow 39 303 162 122 0 1 0 0 1 0;
#P comment 704 76 111 9109513 jump to other video;
#P connect 5 0 4 0;
#P fasten 9 0 2 0 101 161 45 161;
#P fasten 10 0 2 0 60 161 45 161;
#P fasten 16 0 2 0 130 302 34 302 34 162 45 162;
#P fasten 11 0 2 0 263 115 45 115;
#P connect 4 0 2 0;
#P fasten 8 0 2 0 154 115 45 115;
#P fasten 7 0 2 0 216 115 45 115;
#P fasten 3 0 2 0 121 115 45 115;
#P fasten 2 0 1 0 45 244 45 244;
#P connect 1 0 12 0;
#P connect 6 0 4 1;
#P connect 2 1 13 0;
#P connect 13 0 18 0;
#P connect 18 0 14 0;
#P fasten 17 0 15 0 225 258 130 258;
#P connect 14 0 15 0;
#P connect 15 0 16 0;
#P fasten 13 0 17 0 130 211 225 211;
#P connect 33 0 32 0;
#P fasten 37 0 21 0 558 115 346 115;
#P fasten 35 0 21 0 511 115 346 115;
#P fasten 36 0 21 0 449 115 346 115;
#P fasten 31 0 21 0 416 115 346 115;
#P fasten 32 0 21 0 340 117 346 117;
#P fasten 28 0 21 0 431 299 335 299 335 159 346 159;
#P fasten 23 0 21 0 361 158 346 158;
#P fasten 22 0 21 0 402 158 346 158;
#P connect 21 0 20 0;
#P connect 20 0 24 0;
#P connect 34 0 32 1;
#P connect 21 1 25 0;
#P connect 25 0 30 0;
#P connect 30 0 26 0;
#P connect 26 0 27 0;
#P fasten 29 0 27 0 526 255 431 255;
#P connect 27 0 28 0;
#P fasten 25 0 29 0 431 208 526 208;
#P connect 51 0 50 0;
#P connect 50 0 38 0;
#P connect 38 0 39 0;
#P fasten 46 0 39 0 825 367 661 367;
#P fasten 42 0 39 0 707 359 661 359;
#P connect 39 0 47 0;
#P fasten 1 0 50 1 45 429 600 429 600 122 676 122;
#P fasten 20 0 50 2 346 430 600 430 600 122 691 122;
#P connect 38 2 40 0;
#P connect 40 0 41 0;
#P connect 41 0 42 0;
#P connect 44 0 45 0;
#P connect 45 0 46 0;
#P fasten 41 0 43 0 707 242 828 242;
#P connect 43 0 44 0;
#P fasten 38 1 48 0 684 367 859 367;
#P connect 49 0 43 1;
#P pop;

#120715
Jan 17, 2008 at 7:08pm

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
> –
> http://www.charlessarah.com
>

#120716
Jan 17, 2008 at 7:09pm

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
> –
> http://www.charlessarah.com

bruce tovsky
http://www.skeletonhome.com

“Sometimes the appropriate response to reality is to go insane.”
Philip K. Dick

#120717
Jan 17, 2008 at 8:14pm

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

#120718
Jan 17, 2008 at 8:26pm

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

#120719
Jan 17, 2008 at 9:04pm

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.

#120720
Jan 17, 2008 at 10:18pm

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
http://www.skeletonhome.com

“Sometimes the appropriate response to reality is to go insane.”
Philip K. Dick

#120721
Jan 18, 2008 at 8:19pm

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

#120722

You must be logged in to reply to this topic.