4:4:4 10bit single CMOS HD project

[Jason Rodriguez]

The 15K Cheetah's are very nice drives, but for my purposes (or anybody doing portable), they're power hogs (and loud), so I won't be messing with those.

I think then for right now I'm going to start out with my original idea of up to 6 laptop hard-drives (across 3 IDE channels), using the 7K60's from Hitachi which spin at 7200RPM. I'll start out by testing three drives on three channels first, and see if that is fast enough. I'll then start adding drives to see when I can hit that magic 120MB/s sustained number (hopefully I'll get there). If I'm not making it by 4 drives across the 3 channels, then I'll just return the drives, and go with SCSI. But I'm thinking that 6 drives on all those IDE channels should be enough.

Actually, if worst comes to worst, I can stripe a five-drive array using 3 IDE channels, and then another 2 across the SATA channels (with PATA-SATA adapters).

OK. Anyways, 7K60's it'll be for now until further notice :)

[Obin Olson]

hmm I am going with 2 SATA 10,000rpm disks for now..easy cheap fast stable..should work fine for 24p 1080 I hope. I know I can use it with 720p no problem, I have done that with 2 ata disks at 55fps 720p

[Juan M. M. Fiebelkorn]

So you can tell that if your are moving fast with your camera, the two 10,000 rpm disks won't suffer any damage?

[Magnus Andersen]

Hello All.

Thanks Steve.
Do you know at what fps and such that the images were taken?

Best, Magnus Andersén.

[Wayne Morellini]

Steve, the 1920HD lighting range looks a lot better, almost natural. I also found a bright whitish pixel west north west of the top of the picture frame. But barely noticable, very good.

I was wondering, with that auto gain feature (or was that the Pana), how it goes in a ambiently lit room with a clear (no tint film) window in the background showing a bright sunlit day. A good test of range.


Thanks

Wayne.

[Steve Nordhauser]

Magnus:
Sorry, we try to put some information about the image capture in the file name but that is all I have. Frequently our test images are generated for specific potential customers or situations and are not meant to be universal.

Wayne:
Remember, that these Altasens sensors we are experimenting with are pre-release, engineering only units. Blown pixels and columns are part of the deal.

There is no auto gain. There are independent color gains (analog), a global gain (analog) and a global gain (digital).

Juan:
I think that cameras with disks are like racing cars - it is not the moving fast that gets you, it is the sudden, unexpected stops. ;-} Don't drop cameras with disks?

[Jason Rodriguez]

Hey guys, have another question, especially for Obin and Rob:

Does disk access speed mean as much as disk transfer speed?

I'm actually now thinking of incorporating the small 1.8" Toshiba drives like the ones used with the iPod, etc. Toshiba has a new one that is only 5mm thick, and is the size of a credit-card. I'm planning on cramming 8 of these drives into my case design, and then striping those across four IDE channels as RAID 0. The only hestiancy I'm having is that that disks only rotate at 4200RPM, so the disk access time is 15 msec average, almost twice as slow as a 7200RPM disk. RAID configurations do not help disk-acess time, but they do greatly speed up the disk transfer-rate. Jeff Kreines, for example, is using 12 iPod drives in his Kinetta, and those "magazines" are rated at up to 72fps at 1920x1080 (for future chips). But he told me that he's using sequential writes, because the disk-access times are too slow for anything else-which it totally understandable.

So what I'm worried about is dropped frames, not because the disks aren't fast enough (eight of them definitely will be), but because they can't handle the capture-to-disk, or can't spin up fast enough, etc. for sequential writes to occur when I click on capture-to-disk. In other words, with these capture programs, is there a momentary "spin-up" time like many NLE's have, where space is allotted for a sequential write, and the disks allowed to get up to full speed? Or is it simply a "crash record", and the disks just have to keep up, and there is no concept of trying to keep sequential writes?

I'm hoping that eight drives (two seperate IDE channels on two different busses for a total of 4 IDE channels, so I'm not limited to 32-bit PCI bandwidth) should give me the bandwidith to record at up to 48fps, 1920x1080.

[Rob Lohman]

I think it's a bit too early to exactly tell what will work and what
will not. The software Rob S. is developing with some assistance
from myself will write sequential to each disk and just gives the
frame to the next drive in the queue that is available. So in theory
it will probably work. But till will tell how well such systems will
work and whether somethings need to change in the architecture
or not.

[Rob Scott]

Jason Rodriguez wrote:
Does disk access speed mean as much as disk transfer speed?

As Rob Lohman said, it's difficult to tell until someone actually benchmarks a system. But with enough RAM to buffer the frames, I expect that throughput will dominate for the most part. During capture, the writes happen continuously -- there are no explicit seeks.

On the other hand, if the drive has to seek very often (due to fragmentation, OS stupidity, bad sectors, etc.), that will reduce throughput.

[Jason Rodriguez]

I was planning on software RAID 0 though, so there's no disks to "que", there's only one very fast, massive disk. But again, it would only be fast for data transfer, not actual disk access times. Because of the slower 4200RPM nature of the drives, random access wouldn't be all that great.

And again, I'm also wondering about frames writing to disk-is there a slight "buffer" time, or time to spin up the disks, or does it simply try to dump to disk, and you might get dropped frames at the begginng as it's trying to access the disks and bring them up to full speed?

[Rob Lohman]

Jason: we are doing a software form of RAID, therefore you
really do NOT want to setup an OS RAID. The advantage of this
is that you can dynamically add or remove disks (while not
recording at least) and faster drives will do more than slower
drives to lower the chance of dropouts (which a normal RAID
cannot do, it always is sequential).

[Obin Olson]

frame buffers - that is what we are doing - you can set it from 10 - 40 frames

also we are writing to each and every disk like a raid without the RAID from the OS or hardware so frame 1 writes to disk 1 frame 2 disk 2 frame 3 disk 1 frame 3 disk 2 etc

more disks would = higher framerate of capture

[Rob Scott]

Jason Rodriguez wrote:
And again, I'm also wondering about frames writing to disk-is there a slight "buffer" time, or time to spin up the disks, or does it simply try to dump to disk, and you might get dropped frames at the begginng as it's trying to access the disks and bring them up to full speed?

You can set the buffer to as much RAM as you like -- it will fill up RAM until the disks are ready and then start writing. You should not have any dropped frames unless the RAM buffer filled up before the disks were ready.

If you think a delay is a good idea, I could probably implement one, but my thinking is that most people want to start recording as soon as they hit the button.

And as Rob Lohman said, we are doing a form of software RAID 0, but you can use it with a "true" RAID 0 if you really want to. I suppose there might be some benefit to it, such as if the RAID controller had on-board RAM as well, to provide a second buffer. As Rob (and Obin) mentioned, though, software RAID makes it easier to add more drives later.

[Jason Rodriguez]

No, delay is a bad thing, but I just wasn't sure how you guys were implementing RAM buffers, etc. What you guys have going sounds very good.

BTW, since you are using a RAM buffer, how about a method where, depending on the amount of RAM you had, there was a mode that had a continuous loop capture, and when you hit "record" it first layed down the RAM buffer, and then started recording to disk-so the RAM loop is always being refreshed every, say 5 seconds (again depends on the amount of RAM you have), and then when you press record you get the previous five seconds before you press record plus the footage you're currently capturing. The Panasonic SDX900 has a similar capability for documentarians who don't want to roll, roll, roll trying to capture a "moment", or for that sports guy that only wants to record the home runs :)

[Rob Scott]

Jason Rodriguez wrote:
BTW, since you are using a RAM buffer, how about a method where, depending on the amount of RAM you had, there was a mode that had a continuous loop capture, and when you hit "record" it first layed down the RAM buffer...

That's a very good idea. In fact I think it would be doable with very few changes to the code.