Extreme Pro CF for Uncompressed on Nano?

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark,

It is too early to tell which method we will be using to record uncompressed.

Turning on the Firewire, which was original intended for outputing a HDV signal to a backup HDV recorder, is lower in priority that other features that we have planned.

Our original thoughts were not to make the Flash XDR a computer mountable drive.
We have to weigh both the time to develop and the amount of memory available for our firmware. This feature is not high on our priority list.

We like the idea of taking the CompactFlash cards out of the Flash XDR and inserting them into a low cost CompactFlash card reader for the transfer to a computer or storage device. This allows the Flash XDR to be available for other capture work.

Transfering full uncompressed over a Firewire interface would be very time consuming, so this is not in our plans.

....My request to turn on the FireWire interface was not so much an argument in favor of servicing the HDV format as it is one to support the function of uncompressed Raid 0 CF card array recording on the XDR. As I mentioned on another thread, you would not, and possibly *must* not remove a set of striped CF cards from the XDR/nano. If folks want to use an uncompressed feature for recording, then they will have to accept certain limitations which come along with it. But being stuck with four cards striped in the XDR is not such an inconvenience if we are talking about 4 x 64 GB CF card meda or greater capacities which may also come along sooner than we think.

How can you impliment raid 0 CF card uncompressed recording anyway if you have to remove the cards from the device ?? THe Raid 0 will fail if it's removed. You would have to impliment Raid 5, then allow Windows or MAC OS to rebuild the array there.

[Dan Keaton]

Dear Mark,

For uncompressed recordings, the CompactFlash cards will become a set of two or four.

One set can be removed, and another set can be inserted into the recorder.

For uncompressed playback, the set will have to be re-inserted into the Flash XDR / nanoFlash.

[Emmanuel Plakiotis]

Originally Posted by Dan Keaton

Dear Mark,

For uncompressed recordings, the CompactFlash cards will become a set of two or four.

One set can be removed, and another set can be inserted into the recorder.

For uncompressed playback, the set will have to be re-inserted into the Flash XDR / nanoFlash.

In that case in a future version maybe you should consider a removable cartridge to hold all the CF cards in one place and a lower cost unit sitting in the editing room.

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark,

For uncompressed recordings, the CompactFlash cards will become a set of two or four.

One set can be removed, and another set can be inserted into the recorder.

For uncompressed playback, the set will have to be re-inserted into the Flash XDR / nanoFlash.

...Oh ! Very ingenious ! So in this way, then, the device is not *tied up* in dumping the data to computer instead of shooting. Still, the FW option could assist in transfer operations. If we're talking about large capacity CF cards with 90 MB/s record and playback times, then we're not really looking at that much transfer time to computer via FW 400 MB per sec interface. In practice, this option might even be faster than playing the footage out in real time via the HD-SDI port.

[Dan Keaton]

Dear Mark,

Firewire 400 (IEEE 1394a) is 400 Megabits per second, not Megabytes per second.

This is a maximum of 50 Megabytes per second, not enough for 120 to 150 Megabytes per second that we need for full uncompressed in real time.

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark,

Firewire 400 (IEEE 1394a) is 400 Megabits per second, not Megabytes per second.

This is a maximum of 50 Megabytes per second, not enough for 120 to 150 Megabytes per second that we need for full uncompressed in real time.

....Yep. My bad. You are quite correct. FireWire 1394a is only 400 Megabits NOT 400 Megabytes per second ! Oh well. Only good for HDV data transfer, or other Long GOP data. Anyway. You put it on the XDR box and I paid for it, so I hope you folks at CD will enable this interface in the near future :-)

[Aaron Newsome]

Hi Dan. RAID-0 recording sounds complicated. Couldn't you just record complete uncompressed files to each of the 4 XDR cards.

That is:

Slot 1: Y
Slot 2: Cr
Slot 3: Cb
Slot 4: Uncompressed Audio

or

Slot 1: R
Slot 2: G
Slot 3: B
Slot 4: Uncompressed Audio

I think these would be a lot easier to manage and combine in post than file fragments spread across CF cards. Each file could be a complete standalone Quicktime/MXF

What do you think.

[Dan Keaton]

Dear Aaron,

That is an interesting idea.

We do want to engineer something that will work in our Flash XDR as well as our nanoFlash. This limits us in that we only have two slots in the nanoFlash.

Do you know if any NLE will currently support your plan?

Another issue is that we have to limit the processing of the incoming data to a reasonable level. The data is coming at us at around 185 Megabytes per second, approximately 1.485 Gigabits per second.

I will bring up your idea to our engineers.

[Mark Job]

Originally Posted by Dan Keaton

Dear Aaron,

That is an interesting idea.

We do want to engineer something that will work in our Flash XDR as well as our nanoFlash. This limits us in that we only have two slots in the nanoFlash.

Do you know if any NLE will currently support your plan?

Another issue is that we have to limit the processing of the incoming data to a reasonable level. The data is coming at us at around 185 Megabytes per second, approximately 1.485 Gigabits per second.

I will bring up your idea to our engineers.

...Hey Aaron and Dan: Isn't RAW data recording *less* CPU intensive than codec recording ?

[Dan Keaton]

Dear Mark,

While it may seem so, it is not.

In Aaron's example, he wanted us to separate the incoming stream into separate colors and audio.

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark,

While it may seem so, it is not.

In Aaron's example, he wanted us to separate the incoming stream into separate colors and audio.

....Yeah, I understood what Aaron was saying Dan, but I didn't quite catch what you were trying to say. Were you trying to say RAW was indeed NOT less processor intensive, or were you meaning Aaron's proposed solution was NOT less processor intensive, or were you saying RAW is MORE processor intensive, or were you meaning Aaron's proposed solution was MORE processor intensive ?

[Dan Keaton]

Dear Mark,

It is very difficult to predict, but I feel that separating each color into a separate file will be more processor intensive that what we are doing now.

[Aaron Newsome]

He Dan. I don't think the NLE support combining the different channels of video in separate files natively. I use Apple Shake so I would do this in that application if I had these type of files. I suppose it could also be done in Apple's Motion or Adobe After Effects. I'm sure there's more generic and freely available ways to do this but I haven't researched any since I just use Shake.

[John Mitchell]

Hi Dan

I think trying to split out the video signal for data recording would be a waste of time. Some channels carry more information than others and there would be no easy way to re-combine them at the other end. I can't see NLE makers rushing to support that.

I think instead the original plan of streaming data makes more sense, and I think you could then work out a way of mounting them with software as a "virtual" drive through a normal CF reader with multiple slots. It may not be possible but I think mounting of paralleled data drives (RAID) is fairly well established technology provide you can write an interpreter.

Good luck with the uncompressed!

John