60 fps at 4K idea

[Jack Wester]

For those of us who has ordered two RedOne's, an potential solution would be to transfer uncompressed data to the second camera. You could send every other frame to the other camera. I dont know the specifics of the RedCode, but if it compresses each frame individually this shouldn't be hard to accomplish.

Red only needs to manufacture one camera and you will sell more cameras to demanding users and still enable an overcranking option.

And even if frames are not compressed individually, a small frame buffer would allow for a set of frames to be processed sequentually by each camera all the same.

By the way, I've applied for a patent for this ;-)

[Gavin Greenwalt]

Hahaha that's actually pretty brilliant. Send every nth frame out on the serial port.

Unfortunately, the stopper on this ever working is the lack of a serial *in* port. I believe it's a mono-directional interface: out.

[Jack Wester]

Hahaha that's actually pretty brilliant. Send every nth frame out on the serial port.

Unfortunately, the stopper on this ever working is the lack of a serial *in* port. I believe it's a mono-directional interface: out.
Use the harddrive interface. The second read encodes and stores back to the first, so the second does not need to write to disk.

This is obviously also in my patent application :-)

[Gavin Greenwalt]

But how do you get the uncompressed 4k frame into the second RED so that it can compress the image?

Firewire 800 is way too slow even at 30fps.

[Jeff Kilgroe]

...Jack originally posted this in another thread, then deleted it to start a new thread, so I'm moving my reply over.


For those of us who has ordered two RedOne's, an potential solution would be to transfer uncompressed data to the second camera. I dont know the specifics of the RedCode, but if it compresses each frame individually this shouldn't be hard to accomplish. Red only needs to manufacture one camera and you will sell more cameras to demanding users.

Hehe... I don't know if you'll get a patent on that one. Using multiple systems to split up processing isn't a new concept. :bleh:

Not a bad idea though, but both cameras will have to be equipped with something like the RAW Port in order to get the uncompressed data from one to another. But you could have a master camera and a slave camera. The master shoots at 60fps and delivers the stream to the slave camera. Master camera encodes the even frames and records them to onboard media (so just handling 30fps). Secondary camera does the same with the odd frames. Then the two video files are joined and frames interleaved in post to get the proper 60fps back.

[Gavin Greenwalt]

Or RED just releases a software version of the DSPs that runs on windows and mac. Hook the raw port up to one beefy workstation/laptop and save to an external drive.

For RED being so pro-redcode, I'm a little suprised there isn't any desktop solution announced to do just that. Just because you need 60fps 4k doesn't mean you need uncompressed.

[Jeff Kilgroe]

Since we're going down this road, I may as well suggest something else...

Instead of linking two cameras, how about just an external recorder. But this external recorder isn't a large RAID. Rather it's a truly portable device that has similar, but more powerful processors in it compared to the RED One. Can run off battery power and record to internal drives or maybe even RED DRIVES and or RED RAM. Should be able to be made for the same price or a bit less than a second camera body (doesn't need that expensive mysterium sensor). It connects via the RAW port and takes the uncompressed stream and processes it into REDCODE RAW at up to 4.5K @ 60fps and you can strap it to your back or hang it over your shoulder.

[Jeff Kilgroe]

Yeah, or what Gavin said too... I've thought of that before -- just let a powerful workstation do the processing. This is actually what I was thinking would be the ideal solution for shooting 4.5K @ 60fps via the RAW port rather than some massive RAID trying to record 1GB/s sustained. After all, it will have to be processed into REDCODE or other usable format before it can be edited anyway.

[Jack Wester]

But how do you get the uncompressed 4k frame into the second RED so that it can compress the image?

Firewire 800 is way too slow even at 30fps.
The RedOne already can transfer 60 fps raw data out. Look and the format chart of www.red.com.

[Gavin Greenwalt]

Out. Out isn't the problem. In to the second RED is the bandwidth bottleneck.

Does the new Codex Jpeg2k box handle 60fps 4k? That would be exactly what you want.

http://www.fxguide.com/qt/51/codex-digital-announces-ground-breaking-portable-field-recorder

[Jack Wester]

Out. Out isn't the problem. In to the second RED is the bandwidth bottleneck.

Does the new Codex Jpeg2k box handle 60fps 4k? That would be exactly what you want.

http://www.fxguide.com/qt/51/codex-digital-announces-ground-breaking-portable-field-recorder
It should not be a problem. The second RedOne does not need its harddrive so the suggested RedDuo module would read the raw data out and serve it via the harddrive interface of the current flavor.

[Jack Wester]

Camera or secondary PC makes no difference. As disk speed is an issue, even when sending the raw out there should be an option just to send every other frame and processing half of the frames in the camera. This would cut the disk write requirements of your computer in half.

[Jack Wester]

So its decided then. Red makes a RedTwin module and I get one for free.

:greedy:

[Antoine Fabi]

So its decided then. Red makes a RedTwin module and I get one for free.

:greedy:

brilliant and affordable.

[Jack Wester]

Someone still needs to figure out what the easiest way to exchange data between the two cameras would be though. It would be awkward if the second camera still have to access its hard drive to write those 27 MB/sec. It would be better to transfer those back to the first camera.

[Jeff Kilgroe]

But then you're asking the first camera to not only encode 4K at 30fps, but also take an additional incoming data stream, integrate the frames and output over 50MB/s to onboard storage. With the exception of the RED RAM, I don't think any current onboard storage option can handle that and I don't even know if the RED RAM can either.

[Gavin Greenwalt]

It should not be a problem. The second RedOne does not need its harddrive so the suggested RedDuo module would read the raw data out and serve it via the harddrive interface of the current flavor.


AghhhhH!!! Nonononono. There is no port on the RED camera that can take data in fast enough for Uncompressed 4k. It doesn't matter if there is a HDD attached or not. The eSata port is still too slow of an interface for 30fps 4k uncompressed RAW. It would take a whole new internal design to have an input that can handle those kinds of bandwidths.

[Jack Wester]

If the RedOne can encode 4K to 27 MB/s in real time, reading and writing and additional 1.125 MB per frame should be a breeze. And the first camera could go down in frame rate to allow for the additional overhead of writing a ready made megabyte of data from the second camera after each frame.

[Jeff Kilgroe]

AghhhhH!!! Nonononono. There is no port on the RED camera that can take data in fast enough for Uncompressed 4k. It doesn't matter if there is a HDD attached or not. The eSata port is still too slow of an interface for 30fps 4k uncompressed RAW. It would take a whole new internal design to have an input that can handle those kinds of bandwidths.

This whole thread is wild-ass guesstimation anyway. But the only way to transfer this amount of data from a camera is via the RAW port. Hence, the only way to get this amount of data back into a camera would *theoretically* be through the RAW port. We have no way of knowing if the camera is capable of receiving that sort of data as input through the RAW interface and whether or not it could be made to feed it into the internal data pipeline to compress the necessary frames to REDCODE.

To put a realistic lock-down on this whole discussion I will just say we're all being kinda stupid here. With the current feature list, I'm hoping that 1080p @ up to 60fps scaled from the whole 4K sensor area stays. But even with that, there will no doubt be times I could really use full 4K at 60fps. And for that, I'll go rent a RED with the RAW port and a Codex box or capable RAID/recorder that can allow me to record what I want.

[Jack Wester]

AghhhhH!!! Nonononono. There is no port on the RED camera that can take data in fast enough for Uncompressed 4k. It doesn't matter if there is a HDD attached or not. The eSata port is still too slow of an interface for 30fps 4k uncompressed RAW. It would take a whole new internal design to have an input that can handle those kinds of bandwidths.
Well the second camera would just be served the number of frames it can cope with. The reason we can't have 60 fps at 4K is the processing power it would require, so at any rate you would increase framerate by whatever amount of data you would be able to push through the RedTwin or RedDuo module.

Another option might be, though I doubt it, to use a low efficiency and thus CPU friendly compression when transferring RAW data. But at 10 bits of color, simple compression based on repetetive data would not work, right? Maybe dropping the least significant bits per color channel. Would consume CPU, but as I don't have the specs this is just guessing.

Well, its not for me to investigate annyways...

What say you Jim? Can we have a RedTwin cable? There would be even more cameras on demand. Not that that seems to be an issue though.

[Jack Wester]

But even with that, there will no doubt be times I could really use full 4K at 60fps. And for that, I'll go rent a RED with the RAW port and a Codex box or capable RAID/recorder that can allow me to record what I want.
One reason to do every other frame is that you would cut the need for speed to half at the RAW port as this would be a bottle neck for most portable solutions. I don't want a big Raid rack on location. This can be done on the RedOne and not on traditional Video cameras as most does not compress frames individually. Right?

[Jeff Kilgroe]

If the RedOne can encode 4K to 27 MB/s in real time, reading and writing and additional 1.125 MB per frame should be a breeze. And the first camera could go down in frame rate to allow for the additional overhead of writing a ready made megabyte of data from the second camera after each frame.

But that's making a blind assumption that running 4K @ 30fps isn't already pushing the internals to their limits. There may not be enough room left for that extra 1.125MB of compressed data. If you're shooting 60fps and encoding between two cameras, they will both have to handle 30fps each or one will have to shift to say 32fps while the other does 28fps, but we don't even know if that's possible. Now I could see this being more realistic if shooting 48fps and one camera handled 30fps while the other only handled 18fps plus dual output streams to onboard media.

Anyway, who knows if chaining a second camera on there is even possible? If it is, and since the RAW port uses 10G Ethernet over single-mode fiber, why not plug 4 or 5 cameras into a 10G switch and let one do the shooting and broadcast of the uncompressed RAW stream, two or three cameras will work on processing appropriate frames and sending them back out while a final camera assembles the compressed frames in proper order and writes them to a RED DRIVE... To me that seems completely impractical and a massive waste of resources. But then again, an external processor system or recorder seems a better solution than two cameras. We already know the Codex box is intending to support RED and 4K (don't know what frame rates yet), but I'm sure someone will support 4K @ 60fps in an external recording solution before this is all over.

[Jack Wester]

But that's making a blind assumption that running 4K @ 30fps isn't already pushing the internals to their limits. There may not be enough room left for that extra 1.125MB of compressed data.

You would not need to go down to 15fps to allow for the headroom to write the incomming 1.125 MB, so, although not scaling linearly, the second unit would still offload the first one allowing for a higher total framerate. As I see it its a matter of how much and how easily communication between the two units could be accomplished.

[Jack Wester]

Anyway, who knows if chaining a second camera on there is even possible? If it is, and since the RAW port uses 10G Ethernet over single-mode fiber, why not plug 4 or 5 cameras into a 10G switch and let one do the shooting and broadcast of the uncompressed RAW stream, two or three cameras will work on processing appropriate frames and sending them back out while a final camera assembles the compressed frames in proper order and writes them to a RED DRIVE... To me that seems completely impractical and a massive waste of resources.


I agree, but I will be using two cameras with a genlock frequently annyway, but I would not bring my local network and rack mounted RAID system and Mac Pro to a set.

Think possitive! Overcranking is cool!

[Gavin Greenwalt]

Jack what you're asking the RAW port to do is like asking why you can't capture a DVI signal using your Video card. "But it's the same plug!"

[Jack Wester]

Jack what you're asking the RAW port to do is like asking why you can't capture a DVI signal using your Video card. "But it's the same plug!"
No its not. The whole purpose of the Raw port is to output a stream of bits. Unless 60 fps uncompressed will be dropped all together, we will be reading that stream at the other end of the cable. Once any device has hold of the bits and there is software compatible with the architecture of that device (OS and CPU) that encodes RedCode, it will not have a problem encoding it given that RedCode is an intraframe compression codec. The issue is ofcourse to have an interface that puts the incomming stream in a read buffer. Thats why you would need additional hardware.

[Gavin Greenwalt]

oh ok. Yeah I didn't think you were implying the addition of a RAW-Capture module on the side of the slave RED. Yeah if there was a RED Slave Module which interfaced with the RED RAW module then you'd be peachy.

[Rocco Schult]

Jack what you're asking the RAW port to do is like asking why you can't capture a DVI signal using your Video card. "But it's the same plug!"

Dou you know something we don't ? Like how the port is built ?
We know the camera has be modified, assumably because the internal bus is tapped. Why should this route not be able to be tapped vice versa ?
Of course it would be custom, but not unthinkable.
Don't get me wrong, I doubt this is workable concept just because of its odds (a good idea nonetheless), but we are not even closely talking about DVI-like.
Until now, this is of no known standard, other than "optical raw".

[Gavin Greenwalt]

I only know as much as you do but I highly doubt RED is developing an extremely highspeed bidirectional interface. The engineering that would have to go into it would not be insignificant. On the other hand it's relatively trivial to just throw an enormous amount of data at a 'dumb' port.

Now it would theoretically be possible to hack into a point right after the ADC and just pipe in another ADC's signal along with some peripheral synchronization danglies but again it would be a dumb connection and only take in data.

The problems start arising when a single port needs to start routing data, evaluating what it is and what direction it's coming from and pass it along. Then we're looking at a 10+GigE connection. At which point a lot of other options become cheaper.

[Jaime Vallés]

So its decided then. Red makes a RedTwin module and I get one for free.

:greedy:
Twin redheads! mmmm...:innocent:

[Anarri]

I think the Red Team has encouraged too many "wants" and "it is never enough" type of people. :ranting2:

Don't get me wrong, but 3-5 Red one's daisy chained is not the smartest suggestion and even 2 reds slaved together is a waste of resource.

Are we really expecting more and more "wants" without first addressing the "needs"

That said... one man's meat is another man's poison..


Wait... Shields UP! ok flame me now.... :bleh:

[luis bustamante]

Glad to read this post. I also dream of the possibility of 4k@60fps/2k@120fps RCRAW.

I don't believe that using a second camera is such a good idea though.

The most simple solution might be to record to RED raid (or codex or colorspace or whatever can maintain the capture data rate) and add a feature to Redcine in which it can process RAW into RCRAW after the images have been acquired.

This is of course with the main objective of gaining all the advantages of RCRAW (easier workflow and lower storage requirements) after the shoot, but this option still has the huge disadvantage of needing a cumbersome fast and big storage solution on set (not so cumbersome with the new codex portable but still pricey)

If I'm allowed to stat dreaming, the RED RAID should have the ability to transcode RAW to RCRAW onboard and on the fly, it should be small and lightweight (a formfactor similar to the colorspace DDR would be more than acceptable) and ideally it would record RAW to a small high speed RAID (storage capacity sufficient for maybe 10 or 20 min. of 4k60fpsRAW) and output RCRAW to the 320GB RED drive.

I think that would be an elegant solution to this problem. I apologize if it doesn't make real sense, just my suggestion on how Red could solve this necessity for us RED users.

The best,

[luis bustamante]

ups! seems like I killed the thread! arghhh!! the horror!

No, really I'm sorry for hijacking this healthy and interesting discussion into exposing my ideas of how RAW data could be wrangled.

My bad.

[Jack Wester]

The most simple solution might be to record to RED raid (or codex or colorspace or whatever can maintain the capture data rate)

That would be very nice. It would require somthing like 14 to 28 striped hard drives hard drives to achieve around 900 MB/sec and battery power to mach it.


If I'm allowed to stat dreaming, the RED RAID should have the ability to transcode RAW to RCRAW onboard and on the fly, it should be small and lightweight

That would be really nice. It would require an onboard computer of some dignity. Hardware to store a gig a second and a good CPU would probably not be lightweight. But I would want one still.

[luis bustamante]

That would be very nice. It would require somthing like 14 to 28 striped hard drives hard drives to achieve around 900 MB/sec and battery power to mach it.

Supposedly the Codex Portable (link) (http://www.codexdigital.com/) and the Colorspace DDR (link) (http://www.colorspaceinc.com/) can do it in really compact and lightweight enclosures.


That would be really nice. It would require an onboard computer of some dignity. Hardware to store a gig a second and a good CPU would probably not be lightweight. But I would want one still.

If Red were doing it, they could use the same technology as in the camera but running slighty under real time, so it could be roughly the same size as the RED01, add a recorder like the ones mentioned above and it could be a very manageable device, I think.

Ah! It's nice to dream...