Jump to content

Shooting at 48 FPS


Recommended Posts

I've been reading with interest on Peter Jackson's The Hobbit, and that he is shooting at "48 frames per second" - a process that Jim Cameron has also embraced to create a hyper realism in 3D shoots. It started me thinking of what the discussion would be on the correct audio time code rate.

The expectation is that eventually enough theaters could project those films at 48fps. Here is what PJ said on his shoot:

"I thought I’d address the news that has been reported about us shooting THE HOBBIT at 48 frames per second, and explain to you what my thoughts are about this.We are indeed shooting at the higher frame rate. The key thing to understand is that this process requires both shooting and projecting at 48 fps, rather than the usual 24 fps (films have been shot at 24 frames per second since the late 1920′s). So the result looks like normal speed, but the image has hugely enhanced clarity and smoothness. Looking at 24 frames every second may seem ok–and we’ve all seen thousands of films like this over the last 90 years–but there is often quite a lot of blur in each frame, during fast movements, and if the camera is moving around quickly, the image can judder or “strobe.”

Shooting and projecting at 48 fps does a lot to get rid of these issues. It looks much more lifelike, and it is much easier to watch, especially in 3-D. We’ve been watching HOBBIT tests and dailies at 48 fps now for several months, and we often sit through two hours worth of footage without getting any eye strain from the 3-D. It looks great, and we’ve actually become used to it now, to the point that other film experiences look a little primitive. I saw a new movie in the cinema on Sunday and I kept getting distracted by the juddery panning and blurring. We’re getting spoilt!

Originally, 24 fps was chosen based on the technical requirements of the early sound era. I suspect it was the minimum speed required to get some audio fidelity out of the first optical sound tracks. They would have settled on the minimum speed because of the cost of the film stock. 35mm film is expensive, and the cost per foot (to buy the negative stock, develop it and print it), has been a fairly significant part of any film budget.

So we have lived with 24 fps for 9 decades–not because it’s the best film speed (it’s not by any stretch), but because it was the cheapest speed to achieve basic acceptable results back in 1927 or whenever it was adopted.

None of this thinking is new. Doug Trumbull developed and promoted a 60 frames per second process called ShowScan about 30 years ago and that looked great. Unfortunately it was never adopted past theme park use. I imagine the sheer expense of burning through expensive film stock at the higher speed (you are charged per foot of film, which is about 18 frames), and the projection difficulties in cinemas, made it tough to use for “normal” films, despite looking amazing. Actually, if anybody has been on the Star Tours ride at Disneyland, you’ve experienced the life like quality of 60 frames per second. Our new King Kong attraction at Universal Studios also uses 60 fps.

Now that the world’s cinemas are moving towards digital projection, and many films are being shot with digital cameras, increasing the frame rate becomes much easier. Most of the new digital projectors are capable of projecting at 48 fps, with only the digital servers needing some firmware upgrades. We tested both 48 fps and 60 fps. The difference between those speeds is almost impossible to detect, but the increase in quality over 24 fps is significant.

Film purists will criticize the lack of blur and strobing artifacts, but all of our crew–many of whom are film purists–are now converts. You get used to this new look very quickly and it becomes a much more lifelike and comfortable viewing experience. It’s similar to the moment when vinyl records were supplanted by digital CDs. There’s no doubt in my mind that we’re heading towards movies being shot and projected at higher frame rates.

Warner Bros. have been very supportive, and allowed us to start shooting THE HOBBIT at 48 fps, despite there never having been a wide release feature film filmed at this higher frame rate. We are hopeful that there will be enough theaters capable of projecting 48 fps by the time The Hobbit comes out where we can seriously explore that possibility with Warner Bros. However, while it’s predicted that there may be over 10,000 screens capable of projecting THE HOBBIT at 48 fps by our release date in Dec, 2012, we don’t yet know what the reality will be. It is a situation we will all be monitoring carefully. I see it as a way of future-proofing THE HOBBIT. Take it from me–if we do release in 48 fps, those are the cinemas you should watch the movie in. It will look terrific!

Time to jump in the car and drive to Bag End for the day. Video coming soon."

Perhaps Tony Johnson, who is mixing that project can offer his insight.

You can follow the progress on the shooting of The Hobbit as Peter Jackson does a video blog through out right up to the mix. He did the same thing for King Kong. Here it is http://www.facebook.com/video/video.php?v=10150223186041807&oid=141884481557#w400-h224&comments



post-284-130815095091_thumb.jpg

Link to comment
Share on other sites

Remember Showscan?  That was Douglas Trumbull's 70mm 60 fps system over 20 years ago.  The concept was that your eye doesn't see flicker at 24 but your brain does... and the more information you can feed the brain, the more realistic the imagery.  I saw a demo at Trumball's place in Marina Del Rey back in the 80's and it was pretty amazing.  It's a gimmick, just like 3D, and no gimmick can replace a good story, but the demo was pretty cool.

Laurence

Link to comment
Share on other sites

Petros,

Yes, that is exactly what I said in my original post: "Perhaps Tony Johnson, who is mixing that project can offer his insight."

The thread you refer to is strictly about the fan noise and the fan speed setting on the Red Epic.

I'll go out on a limb and assume that Tony is recording at 23.98TC and 48K.  The exact number is 23.976fps so shooting at "48" fps is really 47.952fps.

I'd also like to hear from Courtney Goodin on this too.

Link to comment
Share on other sites

Petros,Yes, that is exactly what I said in my original post: "Perhaps Tony Johnson, who is mixing that project can offer his insight."

The thread you refer to is strictly about the fan noise and the fan speed setting on the Red Epic.

I'll go out on a limb and assume that Tony is recording at 23.98TC and 48K.  The exact number is 23.976fps so shooting at "48" fps is really 47.952fps.

I'd also like to hear from Courtney Goodin on this too.

Hi Richard,

Yup, sorry about that. Will delete my repetitive post. Read the whole PJ bit but skipped the last lines.

Thanks for taking all the time to re-post and share that though, fascinating stuff and so nice to see such a wonderful open process.

Link to comment
Share on other sites

There was an article featuring noted VFX expert Doug Trumbull has some interesting things to say about 48fps and other frame rates in Daily Variety that commented:

There is some pushback, however, because many feel the look of 24p, film grain and other artifacts of filmmaking actually help the audience suspend their disbelief. Without this "proscenium effect," the argument goes, auds see actors in makeup on a set instead of characters in a story, or, at least, everything starts to look like a soap opera, so those picture improvements may be counter-productive to dramas.

That's my fear as well -- that the higher-than 24fps frame rates could look kinda weird. The other issue for post is that one 4K frame of material is 52 megabytes. Two frames (for 3D) is 104 megs. When you double the frame rate, you double the data -- meaning you now have 208 megabytes. Start adding that up, and the post staff is going to have to deal with many terabytes a day. I see that as a logistical nightmare, especially if you weigh in with lots of footage, multiple cameras, and so on. It could potentially be hundreds of petabytes by the time they finish shooting in a year or so.

--Marc W.

Link to comment
Share on other sites

I'll go out on a limb and assume that Tony is recording at 23.98TC and 48K.  The exact number is 23.976fps so shooting at "48" fps is really 47.952fps.

Hi yes I am recording at 23.976 48k . The Red Epics can record at 47.952fps and hold sync , they even claim they can hold sync at higher frame rates . We tested to higher rates but settled on 47.952. What does not work so well is the timecode is out by up to 2 frames between timecode on my Fusion and timecode on the Epic . We cannot decide exactly why but between Editorial and me we are thinking that the timecode stamp is less accurate with doubling the frame speed but someone else maybe able to enlighten me on the exact reason . The cam speed does not really make any difference to the fan speed although you could argue the cams get hotter at that speed but I know that John Pritchett is having the same issues with cam fans and his project is at 23.976fps .

The focus pullers are finding it challenging as there is no motion blur so you can see instantly if part of a shot is soft .

I think the aim for these sort of projects is to get above 60fps frame rate to eliminate motion blur altogether as per showscan .

Tony

Link to comment
Share on other sites

It varies between 1 to 2 frames plus or minus . The timecode for the set is generated from an Evertz signal pulse generator , the cameras and myself take a cable feed from it , and anything else that requires timecode . The cameras are gen locked , that is vital with 3D as there has to be perfect phase between the left and right eye on the camera rigs . I then send the timecode to the slates from my IFB100 to erxtcd on denecke slates with a 2 frame delay set on the erxtcd . This gave us perfect timecode sync across the fusion epic and slates when we were testing at 23.976FPS but not now at 48fps . We are not sure where the anomally is or that the epic timecode is accurate at 48fps . I am wondering if its at the point the epic sniffs the incoming timecode to stamp it and at 48fps it is more likely it does not stamp on the first frame ( I don't know ) .

Tony

Link to comment
Share on other sites

It varies between 1 to 2 frames plus or minus . The timecode for the set is generated from an Evertz signal pulse generator , the cameras and myself take a cable feed from it , and anything else that requires timecode . The cameras are gen locked , that is vital with 3D as there has to be perfect phase between the left and right eye on the camera rigs . I then send the timecode to the slates from my IFB100 to erxtcd on denecke slates with a 2 frame delay set on the erxtcd . This gave us perfect timecode sync across the fusion epic and slates when we were testing at 23.976FPS but not now at 48fps . We are not sure where the anomally is or that the epic timecode is accurate at 48fps . I am wondering if its at the point the epic sniffs the incoming timecode to stamp it and at 48fps it is more likely it does not stamp on the first frame ( I don't know ) .

Tony

My experience with all RED shoots is that there is a 1-2 frame difference (plus or minus) with TC.  There is no drift of any kind throughout.  It's the same offset at the beginning and the end of takes.  It varies per file, so it's not a gradual drift over time.  All I was able to guess is that the time stamp is not always frame accurate to picture, but the clock is steady.

Most editors/post just deal with the difference and don't make a big deal out of it.  I'm guessing it's a much bigger deal now with 3D.

Question is, that if cameras are in phase and genlocked, does the time stamp matter if it's off a couple of frames?  Can't they somehow be resolved in software somewhat easily?  It might be a pain to do this for every take, but not a huge deal in the broad cope of things, I would think.

Robert

Link to comment
Share on other sites

Was it tested for real 24 or 25 , aka  48 or 50  and had same problem ?

No the native timecode rate for HD is 23.976 so to maintain sync the camera frame rate has to be a multiple of that as in 2 x so its actual rate is 47.952fps . Editorial work in a 23.976fps workflow so that governs the timecode rate , they also edit at 23.976 so they have to convert the picture down to 23.976 just for editing . There are a variety of codecs that they can use I am not sure how they do it .

Tony

Link to comment
Share on other sites

I'm very happy Tony has found the time to jump in to this thread. That was my hope in the first place, so thank you Tony.

I started this topic because it is inevitable that this will be a growing trend and the workflow will have to adapt to 48 frame per second HD recording.

New software will have to be written by all the 'flavors' of HD cameras, Avid, ProTools and of course Sound Devices and Zaxcom, Ambient, Denecke etc.

Wether we go to a native 47.952 TC rate is all dependent on if they can fix the offsets in the down-convert and then the up-convert in the final mix.

So Tony, consider yourself the proverbial guinea pig, along with the camera department, editorial and Peter Jackson himself.

Please update us with your new discoveries, it helps all of us enormously and good luck on the project and enjoy.

Regards,

RL

Link to comment
Share on other sites

It varies between 1 to 2 frames plus or minus . The timecode for the set is generated from an Evertz signal pulse generator , the cameras and myself take a cable feed from it , and anything else that requires timecode . The cameras are gen locked , that is vital with 3D as there has to be perfect phase between the left and right eye on the camera rigs . I then send the timecode to the slates from my IFB100 to erxtcd on denecke slates with a 2 frame delay set on the erxtcd . This gave us perfect timecode sync across the fusion epic and slates when we were testing at 23.976FPS but not now at 48fps . We are not sure where the anomally is or that the epic timecode is accurate at 48fps . I am wondering if its at the point the epic sniffs the incoming timecode to stamp it and at 48fps it is more likely it does not stamp on the first frame ( I don't know ) .

Tony

Tony,

One thing to check.  When you find the TC offset error to be the greatest what time of Day is the Time Code?

Is the offset greater at later hours?  Like 2 frames at  20:00:00:00  and less offset at timecode in the early morning 1 am to 10 am?

I have found calculation errors in many companies machines and software that reads out the time code, because of the fact that the timecode is calculated based on samples since midnight.  The pull down of non-integer rates is usually applied in the calculation as -.1% and then pulled back up for display.  If they don't take into account the reciprocity of this calculation (you don't increase by .1% to return to normal if you pull down by subtracting .1%) This creates an error that is equal to about .001% which is about 2 frames after 20:00 hours.  When shooting at double speed sample rate (47.952) the reciprocity error will double making the error fluctuate more and be more visible when the time of day gets past noon.

The way to test is to shoot some at integer rates and see if the discrepancy disappears.  Then shoot at non-integer rates (23.976) at 01:00:00 time code and at 20:00:00 time code and see what the offsets are at each.  If you find the time code in sync on the integer rates and out by 2 or more frames at the 20 hour code takes, the problem is in calculation of the time code in either the camera or the viewing device when comparing them against sound.  It is not problem that can be fixed by Genlock or tuning the accuracy of the crystal.  It is an algorithmic math error that needs to be fixed in the firmware or editing software.  Some may apply the reciprocity correction in pull up and some may apply in Pull down.  there is no accepted standard on where to apply the correction which means that the same time code can be different depending on what machine plays back the digital video or sound.

---Courtney

Link to comment
Share on other sites

you are totally wrong , the post have the same amount of files as in regular 24 frame rate .

the only thing what will happen, the computer will be twice faster and the storage twice cheaper .

The data is moving twice as fast, therefore there's now twice as much data to deal with in a 24th of a second. Part of post will definitely deal with 48fps material; they still have to store it while the workpic edit is being done at 24 (23.976).

Put it this way: normally, you have 2496 megabytes (2.5GB) of data per second for 3D 4K:  52 megs a frame, times 2 (for 3D), times 24. But if you're now running 48fps, then you have 5GB per second of data. This is similar to sound engineers that run at 96kHz 24-bit -- the file sizes are much larger.

We hope that the computers will eventually be twice as fast, but the data sizes won't get smaller. The storage is definitely getting cheaper, but the big enemy in post is the network, which only runs so fast. Try to send somebody a copy of a 5GB DVD in email, and watch how long it takes, even on a fast connection.

But Jackson and his guys at Weta Digital are very bright guys -- I have no doubt they've planned out all the workflows and so on. Still, this is a massive, massive amount of data to ponder. I can see where converting to 23.976fps for editing makes it a lot simpler. All they have to do is make all the effects work 48fps (47.952) and replace all the files. Still, that means doing a lot of the work twice...

On timecode offsets: this is par for the course in post. Assuming all the cameras are genlocked and referenced, all the shutters will be in phase for 3D and there won't be any problems. It's the job of the assistant editor to make sure the sync claps are all good, no matter what the numbers say.

--Marc W.

Link to comment
Share on other sites

Tony,

One thing to check.  When you find the TC offset error to be the greatest what time of Day is the Time Code?

Is the offset greater at later hours?  Like 2 frames at  20:00:00:00  and less offset at timecode in the early morning 1 am to 10 am?

I have found calculation errors in many companies machines and software that reads out the time code, because of the fact that the timecode is calculated based on samples since midnight. 

---Courtney

Thanks Courtney thats something I did not know and is a theory worth checking out . Although it is no an offset rather a random amount out . Its often in sync to the timecode as well just unreliable . They are syncing off the clapper until we get to the bottom of it . One thing I have not had confirmed yet is whether the Epic sniffs the incoming timecode then displays that code on the picture files or does its own internal generator instead pick up the code and run from there . We are not exactly sure where the error is .

Could you not get Denecke to try adding a 47.952 frame rate?  To test it out?

This is the thing we have been discussing is that we are getting to a stage were we need a new timecode standard !!! or in fact what would that standard be , can it be tied to a frame rate as such . I think that the shooting and projection rates for HD and 3D will be higher than 48fps in the future . To get rid of motion blur I think 60fps or above would be desired . Of course how do you get the information from the projectors to the screen at those higher frame rates , processors are not fast enough to deal with that as yet .

Its a great big learning curve down here and I hope to have more answers to things as the weeks progress .

Tony

Link to comment
Share on other sites

That's an interesting question: if the camera is running at 47.952fps, then it must be using timecode at the same rate. How it would cross-jam off a 23.976 timecode source is open to interpretation, since this is a very loose "standard."

I can see where sometimes, the camera might internally roll over to the next frame number, so precise sound sync would be unpredictable. I don't see a reliable way of doing it other than checking the claps manually in post.

--Marc W.

Link to comment
Share on other sites

Then the question must arise: how do you use 24-frame timecode with a 48-frame show? Now, you have one timecode number assigned to two completely different frames. Seems to me this will present many problems with editorial, effects, and sync. You could potentially create a new kind of timecode (non-SMPTE), writing it from scratch, but I'd be surprised if they did this.

The only thing that makes sense is that they're just treating it as if the footage was high-speed film: no timecode at all. But that means that all the syncing would have to be done by eye, and they're going with just raw frame numbers. Very difficult for a project with a massive amount of footage.

Back to ink numbers! 

--Marc W.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...