RedCine -> ProRes Maximum File Size Issue?

[Dave S]

Hi all,

Please forgive what may be a fairly basic question, but I've not found it covered anywhere on the forum....yet!

We just shot our first Red project and are now in the process of converting out of RedCine to ProRes. Some clips are coming out fine and are looking great, but the longer takes are causing us a problem. As soon as the output file reaches 2GB, RedCine stops compressing. It's not a limit set on the media drive we're exporting to - we even have other footage in there with file sizes over 2GB.

We're running Tiger, 2 x 2.66GHz Dual-Core Xeons, 3GB RAM.

Any ideas or solutions gratefully received!

Dave

 

[Brent J. Craig]

If you're writing to a FAT32 drive, 2GB is the limit for file sizes.

 

[Dave S]

If you're writing to a FAT32 drive, 2GB is the limit for file sizes.

Thanks for the quick response, but as I say, it's not limited by the drive format - we have other files in the same directory that are over 2GB in size.

 

[Chris Kenny]

Are you by any chance writing directly to an AFP (Apple file sharing) network volume? We haven't tested RedCine with output to AFP volumes, but I've seen this problem outputting from Shake directly to AFP volumes, despite the fact that AFP and HFS+ both support files over 2 GB and most other apps have no problem creating and working with such files on AFP volumes. I think it depends on which API an app is using to write its files.

 

[Dave S]

Are you by any chance writing directly to an AFP (Apple file sharing) network volume?

Yes - we're running an EditShare here.

I'll try exporting locally then transferring back to the ES. Thanks for the advice!

 

[Christopher Michael]

Having the same problem and we're writing to a local SATA raid.

 

[Dave S]

Well, the good news is that Chris Kenny was right - it was writing to the afp volume that was causing the problem, which means that exporting from RedCine to a local drive works as expected.

Admittedly, this does mean you've got to copy it across to the network drive, but it's a small inconvenience in the grand scheme of things.

Probably worth trying to export to an internal / firewire drive, Chris M.

 

[Christopher Michael]

The internal export gave us one frame rendered out, woohoo for cascading bugs. Anyway, the editor is in a crunch...aren't they always...I'll try to do another test later today.

We broke the shot into two sections from redcine as a workaround. Shouldn't cause any problems...right?

 

[holograph]

Are you by any chance writing directly to an AFP (Apple file sharing) network volume? We haven't tested RedCine with output to AFP volumes, but I've seen this problem outputting from Shake directly to AFP volumes, despite the fact that AFP and HFS+ both support files over 2 GB and most other apps have no problem creating and working with such files on AFP volumes. I think it depends on which API an app is using to write its files.

yup, same problem rendering over AFP here, but with RedAlert! The strange thing is that the render status still framecounts, AND Activity Monitor still shows redalert takes almost all the cpu power, but the files are not going over 2GB.. I wonder if this creates a black hole

 

[Trevor Meier]

Just ran into the same issue with AFP using Redline. Drat. Any solutions in the next version of RedAlert?

 

[Alex Carr]

Instead of using a Edit Bay to do the conversions, use the server to initiate Redline Commands. Then its Local, or just use SMB instead. Its very easy to set up a SMB share from any Mac, Leopard or Tiger.

 

[holograph]

ill try SMB the next time rendering over network arises. Thanks

 

[sublimefilms]

Its not just AFS, rendering to any network volume quits after 2GB.

SMB, CIFS, NFS.

They are not using the current file i/o api in redcine, at least on the mac side.

 

[Jeremy Neish]

Red folks... Any progress on this bug? We have a large multi camera RED shoot that needs to be output to our Mac OS X Server and we are having the same problem. It seems to affect any program that uses Redline (Clipfinder, RedRushes, etc).