What codec to use for premiere pro cs6?

[jfharper]

I've recently upgraded my os from xp64 to win 7 64bit and ppro to cs6(64 bit) from 1.5(32 bit) and used to use the PICVideo MJPEG codec for rendering previews and exporting to movie, on very high settings. I then would use handbrake to encode to h.264. I cannot figure out how to install my old PICVideo codec to cs6 and do not want to buy a new copy if I don't have to.

I import targa sequence files into ppro from 3d software, so the source is lossless...is there a good codec included with ppro cs6 that would work well for my pipeline mentioned above? Sometimes I would use avi uncompressed to encode before handbrake, but that was slow and large file size. PICVideo was quick and file size was manageable. Thanks for any help.

I don't like quicktime because I would always notice keyframe stutter, thus the reason for using avi.

[poisondeathray]

picvideo isn't lossless

If you want truly lossless RGB compression from a targa image sequence, UT Video codec in RGB mode is the recommended intermediate on the Adobe forums

If the filesizes are too large for you, you can use a high quality visually lossless codec such as cineform

(Picvideo will still work in CS6, but you need the 64bit version, since Adobe suite is 64bit)

[jfharper]

Does UT Video codec and cineform work well with handbrake, do you know?

Also, do you know if I need handbrake now that I have cs6? I actually bought the master collection, so I'm learning all the new software inlcuded and am a bit overwhelmed (and excited) with the options. Problem is I just don't know what everything does.

[jfharper]

Also, I will be rendered now to EXR instead of targa, if that makes a difference for the codec choice.

[poisondeathray]

Yes handbrake works with ut video . An open source cineform decoder made it into ffmpeg, so handbrake should be able to decode it soon if not already. But the open source decoder is very slow compared to the native decoder. Most people would use the native cineform decoder and another x264 or x265 commandline or GUI if going that route

There are many different EXR variants, but most common are 32bit float and 16bit . So those intermediates won't be "lossless" because of the bit depth difference, but they will still work

Rough ballpark for UT Video 8bit RGB would be ~1/2 the size compared to 8bit uncompressed RGB that you used to export before. You can use more compressed lossless codecs as well, like lagarith, but their playback speed isn't as fast as UT. UT is optimized for decoding speed , not as much compression

[poisondeathray]

You didn't mention what your final destination format was eg. if it was "vanilla" 8bit AVC using x264 or something else (handbrake can encode 10bit video now) , but UT video also has 10bit RGB and YUV422 variants . So if it was higher bit depth encoding, most people would retain higher bit depth intermediate until the end (another popular option is 16bit png sequence) . But there isn't as much control over the colorspace and bit depth and intermediate conversion in handbrake

[jfharper]

Well, I'm not sure just yet what my destination will be. I need to give the client either an HD 1080p (or 4K if they ask for it) which they can play somehow. I haven't done those before so I need to figure that out...let me know if you have a suggestion.

Up till now, clients have been fine with 480p which I just used mpeg-2 or I think I've used vanilla 8bit avc using x264 out of handbrake for 720p once or twice...I've been a little out of the loop for a while, work had been slow and I mainly did still images for print for a while...animations are coming back around though.

I will be using 32 bit (half float) exr, as 3D artists recommend...they say 32 bit full float isn't necessary unless you really need that extra exposure control in post, so half float gives enough options for post.

[poisondeathray]

Honestly, even 16bit out of a 3d application is more than enough for most pipelines . Unless you're doing something very specific or deep compositing

For end delivery, most compatible right now is still 8bit AVC. This will be playable almost anywhere, including devices (like phones, tablets, etc...), web, BD players, many newer TV players

But newer sets, UHD, UHD blu-ray are using HEVC now - that's a bit future looking but it's gaining ground very quickly.

[jfharper]

Great. Thanks for your help.

[SameSelf]

You do know that PP CS6 does not support openEXR, right? AFAIK, there is only a single plug-in available, and it costs $. http://www.fnordware.com/ProEXR/.

However, AE CS6 supports openEXR OOTB and can even render to openEXR. I am not sure why PP CS6 doesn't, but AE has always been much more powerful and advanced than PP. So unless you are doing some really fancy editing with lots of cuts, multicam, etc., maybe you can avoid PP and use AE as your primary editor. PP is designed to operate in YUV space without an intermediate conversion of YUV to rgb. AE color science is much more advanced. Presumably since you are working with linear rgb sequences, I would think you would want a program that operates natively in rgb space like AE and save the conversion to YUV for the final encode.