Archives for December, 2012 | Main

December 17, 2012

On 48fps

I got the opportunity to see The Hobbit this week in mini-IMAX, 48fps 3D, and I think I’ve figured out what I both love and hate about this new format.

First, my take is that some of it works beautifully at 48fps. The scenes with Gollum make him look so incredibly real, I half expected him to come out at the end of the screen and answer questions from the audience. He’s actually there in every scene – no hint of being a digital character.

But, some of it doesn’t work well. Too often, there are scenes that pull you completely out of the moment. People have described it as “suddenly watching Masterpiece Theatre from 1978″ or “everything looks fake,” but no one can put their finger on why. I think I figured it out.

Camera motion.

I felt most immersed in the 3d and the movie when the camera was static. Simple cuts between shots allowed my brain to process what was going on, and made me feel like I was standing, watching the action unfold. And it looked beautiful. But, as soon as a jib arm or dolly began making my point-of-view float away, something deep in my brain called BS on everything. Suddenly, the magnificent Shire looked like nothing more than a well-crafted set. I suddenly knew I was looking through a camera lens on a jib arm at a set in a sound stage. That’s what people are trying to articulate here – the experience, made using film techniques developed for 24p, aren’t going to work the same in the hyper-real world of 48p. It’s going to need to develop a language and style all its own, and that’s going to take time. Just as 3D requires a language, and even B&W and Color require different tools and techniques, this new world of High Frame Rate (HFR) will require a re-learning of filmmaking techniques to make it go. And I think we need to start looking at how we move the camera. I think it necessitates a “reality” perspective on the scene. What we think of as “high production value” at 24p (cranes, jibs, dollys) work against us at 48p. And, we associate it with videotaped shows of the 1970’s because that’s where we first saw it.

We may also have to revisit set dressing, making the sets as absolutely “real” as possible. Maybe, maybe not.

BTW – the 3D on this film was flawless. Beautiful. You don’t even think about it.

I want to see the movie in 2D, 24p as well, just to compare and contrast. I’ve seen on Twitter that at 24p, there’s motion blur, and it looks like a “normal” movie.

December 13, 2012

4k presets for Adobe Media Encoder

I was asked the other day when Adobe will offer a 4k output from the H.264 encoder. The answer is simple – it’s there today!
Currently, the Media Encoder (and, by association, Premiere Pro) doesn’t ship with presets for 4k H.264 output, simply because it’s not a common enough format. But it’s reasonably simple to make your own.
I won’t go into all the details of H.264 encoding here, but the key thing to know is that the encoder settings include something called Profile and Level. These settings set limits for what type of file you can create.

I’ve created some sample presets for you to play with – these use a really small bit rate, so you may want to tinker with the quality some and make your own presets accordingly, but these will get you started.

Click here to get ‘em:
4k Presets

Install them in Adobe Media Encoder by going to the Preset Browser, and clicking the button to Import Presets:

December 9, 2012

Avoiding RAM Starvation: Getting Optimum Performance in Premiere Pro

Something I wanted to share for all you “build-it-yourself” users. Recently, I helped a customer build out a really beefy system – 16 physical cores, plus hyperthreading, 24 GB of RAM, Quadro 5000, etc.

The system wasn’t rendering well at all. Bringing up the task manager was showing each processor only hitting about 19% – 20%. My MacBook Pro was actually handling the same tasks MUCH faster.

This was a classic case of Processor RAM Starvation. With Hyperthreading turned on, the system was showing 32 processors, and there wasn’t enough RAM to drive all those processors! Some processors had to wait for RAM to free up, and the processors that finished their calculations had to wait for THOSE processors to catch up. It’s a really bad state to be in. With multiple CPU’s, everything has to happen in parallel, so when some threads take longer to finish, everything comes to a screeching halt.

I turned off hyperthreading, and suddenly, the system started to just FLY – all the CPUs were being utilized effectively and roughly equally. Render times were over 10-20x faster.

I can’t stress enough the need to ‘balance’ the system to get proper performance. There’s never a danger of having “Too much RAM”, but too many processors is not necessarily a good thing!

You can check this on your system – using the stock effects, when you render previews or render your output files, you should see all the CPU cores being utilized. They won’t exactly be used the same amount, but roughly, they all should be about the same for common tasks.

Also, a BARE MINIMUM amount of RAM I recommend for Premiere Pro is 1GB per core. If your budget can afford it, 2GB per core is pretty optimal for a Premiere Pro system. 3GB per core isn’t required, but isn’t a bad thing. If you are trying to decide between 4 cores, 8 cores, 12 cores, or 16 cores, let the amount of RAM be your guide – look at the cost of 2GB per core, and pick the CPU accordingly.

UPDATE: Some of the feedback I’m getting on Twitter seems to believe that this points to Premiere Pro needing extreme amounts of RAM. No – that’s not it at all. RAM needs to be balanced with number of Cores. The days of just “getting the best CPU” are past. Modern processors are actually multiple CPUs on a single chip, and each one needs to allocate its own chunk of RAM to operate at peak efficiency.

On a dual core processor, 4GB of RAM is a reasonable amount of RAM to have, and 6-8 GB would be pushing into that “it ain’t a bad thing” category. A 4-core processor runs great on 8GB of RAM, which is what I have in my MacBook Pro. RAM is really cheap nowadays – I think I just paid about USD$40 for 8 GB on my son’s computer, and 16GB is less than $80 right now for a desktop system. Remember, it’s about balance, people…

SECOND UPDATE: If you’re an old Classic Auto tinkerer, like I used to be, think of it this way – the CPU is like the engine block, and the cores are the number of cylinders. Each cylinder needs fuel and air delivered to it. RAM is like the carburetor – it provides what the cylinders need. But, you have to match the right carburetor for the size of the engine. A wimpy carburetor on a V8 engine is a disaster – low horsepower, and because it’s heavier, it’ll be outperformed by a properly tuned 4-cylinder engine.

Clear as mud? :-)

December 2, 2012

Premiere Pro and QuickTime and Nikon, OH MY!

This post is going to get a little techy and geeky – I want to take a minute and explain the relationship between Premiere Pro and QuickTime for a minute. I feel it’s important to understand it, so that you’ll also understand why it’s sometimes necessary to change file extensions on some .MOV files in order to get them to play properly in Premiere Pro. This mostly seems to affect Nikon owners, but can be a workaround for certain other types of cameras as well.

Premiere Pro actually has its own built-in system for decoding files, and Adobe works with the camera manufacturers and codec owners to ensure that the majority of cameras and codecs are supported directly.

For certain codecs, like H.264, there are a number of wrappers for the file – an H.264 file can come in a QuickTime .MOV file, an .AVI file, or an .MP4 file.

In the case of a QuickTime .MOV file, Premiere Pro will generally let QuickTime handle the decoding of the file, unless there’s metadata in the file header that suggests otherwise. If there’s nothing in the header, it just hands off the file to QuickTime, and the performance is reliant on QuickTime for decode and playback. This is required for a number of codecs, since there are many QuickTime codecs that only exist inside of the QuickTime framework. (ProRes, for example.) And, the performance can be very good with QuickTime files. However, it’s not the case with certain codecs. For example, decoding H.264 files with  QuickTime can sometimes cause less-than-ideal performance in Premiere Pro. Some of the QuickTime codecs are really more optimized for viewing and playback, rather than editing.

In the case of Canon DSLR files, there’s something in the file header. Premiere Pro can recognize that the clips came from a Canon camera, and bypass QuickTime. This enables Premiere Pro to have smooth playback of DSLR files, and get better dynamic range from the clips. Premiere will use its own built-in decoder, which is optimized for editing, and respects the extended color used by the Canon cameras.

For this reason, it’s sometimes necessary to force Premiere Pro to bypass QuickTime for a certain set of files. I tend to see this the most with certain types of Nikon DSLR cameras. For whatever reason, Premiere Pro cannot detect what camera these .MOV files come from, and it just hands off the decoding of the files to QuickTime, usually with less-than-stellar results.

For this reason, when I see a problem with a .MOV file performing badly within Premiere Pro, I first determine the codec used. If it’s some type of MPEG/H.264 derivative, I rename the file extension manually in Finder or Windows to .MPG. This will force Premiere Pro to use the built-in MPEG decoders to decode the file, and will usually help playback/performance a great deal.

If you run into this problem, and deduce it’s from an H.264 file in a .MOV wrapper, you can use Adobe Bridge to batch rename files very quickly, and without re-encoding the files. All bridge does is change the 3-letter extension of the existing files, so it can plough through hundreds of files in minutes.

In Bridge, select all the files you wish to rename, and go to Tools – Batch Rename. Then, set up the Batch renaming tool something like this:

 

Copyright © 2014 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)