Completed file size.
I'm looking for some professional insight.
I am using AE CS6. and wondering if my final file size is excessive, at 8.5GB for 2 Mins of non audio motion graphics. The content was for a very long video wall. My render settings are as follows:
Render Settings: Quality Best | Frame blending On for Checked Layers. | Size 6400 x 192 | Duration 3600 frames @ 30 fps. | Color Depth 32 bpc (uses alpha and light effects).
Output Module: Custom QuickTime | Format- Quick Time | Output Info- Animation with Spatial quality = 100 | Channels- RGB | Depth- Millions of colors | Pre-multiplied | Preserve RGB.
The file took 7 hours + to render. All content was created by me, in house. I used no actual film footage in the composition.
If this is indeed excessive, I am wondering why & how to decrease for future projects, keeping quality at its best while providing smooth motion.
Any advice is most welcome.
Thank you in advance.
Sounds pretty reasonable to me. 2 mins with alpha at 32bits will give you a big file for sure.
6400x192 is still a pretty big area of video even though its very narrow. Im not sure what a video wall is but depending on the effects and amount of layers you used that will add to the render time too. I would recommend straight alpha instead of premultiplied but if you don't have a bunch of feathered edges or drop shadows you might not see much of a difference. I don't think that would affect your render time or file size though.
Thank you for the speedy reply Mr Haller.
In short, whew! I thought I had gone way over board.
Im a one man show, here and have no one to bounce these sorts of things off so again, thank you.
In your opinion, would it have served me better to render out as before, but to frames & then bring the frames back in and re render at 8 bpc for a smaller file size or would it make a negligible difference for a long render?
Hang on, is it the AE file size? or the size of the movie that AE is spitting out that you're wondering about?
Final movie size is pretty easy to figure out.
NumberOfFrames * FrameXPixels * FrameYpixels * 3RGBChannels (or 4 if there's an alpha) * 8bits per channel gives you total number of bits in the file. Then divide by 8bits in a byte to get bytes (then divide by 1000 to k's and then by a thou again to get MB etc). So really, the 8's cancel each other out and you can stop the math after you multiply by 3 (but I thought I'd show my work).
Now this only works with an 8 bit RGB uncompressed file. (use 10s in place of the 8bits per channel when its a 10 bit file of course).
Also, with Animation best you are going to have some Run Length Encoding (RLE) which losslessly compresses some of this size down. But this only really makes a difference when you have an alpha channel or if you have lots of flat color with no noise and keyframes spread far apart. But at least the math can get you in the ball park so you know you aren't crazy.
Keep in mind very few systems will play back a file at those pixel dimensions in AND in Animation Best AND in real time, so its probably going to have to be compressed or subdivided for the video wall processor at some point. Or perhaps the player sucks it in and compresses it as it does so.
As for the sluggishness in the render, the frame blending will certainly add a significant amount of time (do you really need that?) FB will only make previously rendered footage smoother if you are making it last longer than it did originally and usually there are better ways of stretching time than frame blending.
Large frame sizes take longer to render, and its exponential - generally a frame size twice as big will take 4 times longer to render (all of this really depends on what it is and what frame size you are doubling - its all about what fits in RAM).
More layers take longer to render.
More frames take longer to render and this can be exponential too depending on what's got to be held in ram from beginning to end of timeline. So 10 frames might render in 2 minutes but the next ten frames might take 20 minutes as the RAM gets used up. It also depends on what's happening in those frames. AE's render time guess doesn't know what it's going to have to do 20 frames later. The guess is based on what it's done so far and AE assumes all the frames to come will be like the one's its seen already.
Certain effects take much longer to render than others.
Certain source elements take longer to calculate than others (EXR's with motion blur and depth channels take much longer than a motion blur put on a jpg sequence)
Higher bit depth comps take longer than lower bit depth comps to render.
Not having gobs of RAM will take longer than having more RAM (the more you can keep in RAM the faster it will render, so the more RAM you have the more you can keep there) All else gets shunted to the disk cache which is usually slower especially with all the swapping going on.
As for the AE file size, number of layers or comp length doesn't really increase the file size that much - its the keyframes and number of files in the project panel that really add to file size. Size of comp really has nothing to do with AE file size.
When you get into minute long (or longer) AE projects, consider doing some of the work in an NLE. Longer elements usually rip out of NLE's faster (but they are of course simpler). Having a bunch of prerendered "element" movies stacked inside AE usually runs faster than doing all the work in AE - at least at those lengths.