Erik Lindahl
Forum Replies Created
-
It really depends on the clip.
-
If would also be nice with image sequence support.
-
I think the main question was to “deliver files as Quicktime Component Y’CbCr 10-bit 4:2:2″. Otherwise I’d tend to agree, ProRes 422 / ProRes 422HQ works in 90% of the cases.
-
Render in 16-bit, possibly add some noise or grain.
-
Well, there is a legacy codec called “Component Video”. This should probably be avoided always. The codec called “Uncompressed 10-bit” is probably what you’re after.
-
Uncompressed 10-bit 422 YUV is as the name notes not compressed.
ProRes 422HQ is visually lossless but is at its core still compressed. It does require quite a lot of generations and specific cases to really notice it though. ProRes 422HQ tends to be fine in most cases. Depending on what the source material is and what kind of post you do – ProRes 422 might be good enough
It can be added – not everyone can read ProRes or create proper ProRes files. Uncompressed is a bit more common from my experience.
-
Another note on this subject is working in 8- or 16-bit will give you very similar image results aside from the fact 16-bit won’t normally introduce banding or deteriorate greater than 8-bit codecs.
Working in 32-bit or floating point can often change how a scene is rendered – sometimes quite drastically. Good to keep in mind so you don’t just edit your comp in 8-bit and switch to 32-bit during your final output.
-
It’s true that AE could use an enhanced engine but on the other hand I’d prefer it remains a useful tool in any circumstance and doesn’t go from amazing real time goodness to unusable after you reach some breaking-point (yes, looking at you Motion!). And the mentioned frame-sizes would be the same in any app being relatively intelligent in it’s rendering.
-
I don’t think you normally work in real time when doing these kinds of work no. Most comp-apps aren’t built for it. However, i/o can be a limiting factor for sure even if you’re not working in real time. AE for example has very aggressive caching to speed rendering / workflow up which frees the CPU but strains the I/O. If TB2 would be “limiting factor” I’m not sure about though. But seeing you have to potentially load X GB of frames before the CPU or GPU can process anything and some features requires temporal data… It can for sure be a limiting factor.
Going from internal HDDs to SSDs and a new external raid made a HUGE difference on my old 2008 MacPro even with limiting buss- and PCI-speeds. I/O matters but it depends on what you’re doing and how much.
-
When working in heavy 2D or 3D compositions you’ll have multiple passes of each scene. This means you’re working in, normally, 16 or 32bpp and X passes. It’s not hard reaching the insane figures noted above since you’re working lossless compressed at best.
1080p25 @ 16-bpp RGB we’re talking over 300MB/s per pass. Jumping to 4K we’re talking over 1.3 GB/s per pass. A normal scene can easily have 4-5 passes – i.e. saturating a few GB/s isn’t all that hard even at HD resolution.
However, most often other things end up being the bottleneck. And these are quite extreme cases.