Category Archives: Workflow

cinematography, HDR, PMW-F55, PXW-FS7, Scene Files and Luts, Technology, Workflow

Want to shoot direct to HDR with the PXW-FS7, PMW-F5 and F55?

9 Comments

Sony will be releasing an update for the firmware in the Sony PXW-FS5 in the next few days. This update amongst other things will allow users of the FS5 to shoot to HDR directly using the Hybrid Log Gamma HDR gamma curve and Rec2020 color. By doing this you  eliminate the need to grade your footage and could plug the camera directly in to a compatible HDR TV (the TV must support HLG) and see an HDR image directly on the screen.

But what about FS7 and F5/F55 owners? Well, for most HDR productions I still believe the best workflow is to shoot in S-Log3 and then to grade the footage to HDR. However there may be times when you need that direct HDR output. So for the FS7, F5 and F55 I have created a set of Hybrid Log Gamma LUT’s that you can use to bake in HLG and Rec2020 while you shoot. This gives you the same capabilities as the FS5 (with the exception of the ability to add HLG metadata to the HDMI).

For a video explanation of the process please follow the link to my new Patreon page where you will find the video and the downloadable LUT’s.

cameras, Shooting Tips, Workflow

Why you need to sort out your post production monitoring!

2 Comments

One of THE most common complaints I hear, day in, day out, is: There is banding in my footage.

Before you start complaining about banding or other image artefacts ask yourself one very simply, but very important question: Do I know EXACTLY what is happening to my footage within my computer or playback system? As an example, editing on a computer your footage will be starting of at it’s native bit depth. It might then be converted to a different bit depth by the edit or grading software for manipulation. Then that new bit depth signal is passed to the computers graphic card to be displayed. At this point it will possibly be converted to another bit depth as it passes through the GPU and then it will be converted to the bit depth of the computers desktop display. From there you might be passing it down an HDMI cable where another bit depth change might be needed before it finally arrives at your monitor at goodness knows what bit depth.

The two images below are very telling. The first is a photo of a high end TV connected to my MacBook ProRetina via HDMI playing back a 10 bit ProRes file in HD. The bottom picture is exactly the same file being played back out of an Atomos Shogun via HDMI to exactly the same TV. The difference is striking to say the least. Same file, same TV, same resolution. The only difference is the top one is playing back off the computer, the lower from a proper video player. I also know from experience that if I plug in a proper video output device such as a Blackmagic Mini-monitor to the laptops Thunderbolt port I will not see the same artefacts as I do when using the computers built in HDMI.

And this is a not just a quirk of my laptop, my grading suite is exactly the same. If I use the PC’s built in HDMI the pictures suck. Lots of banding and other unwanted artefacts. Play back the same clip via a dedicated, made for video, internal PCI card such as a Decklink card and almost always all of the problems go away. If you use SDI rather than HDMI things tend to be even better.

So don’t skimp on your monitoring path if you really want to know what your footage looks like. Get a proper video card, don’t rely on the computers GPU. Get a decent monitor with an SDI input and try to avoid HDMI for any critical monitoring.

Shot viewed on a good quality TV via HDMI from the computers built in graphics card. Notice all the banding.
Exactly the same shot/clip as above. But this time played back over HDMI from an Atomos Shogun Flame onto the very same TV. Not how all the banding has gone.

 

cinematography, Technology, Workflow

Thinking about frame rates.

6 Comments

Once upon a time it was really simple. We made TV programmes and videos that would only ever be seen on TV screens. If you lived and worked in a PAL area you would produce programmes at 25fps. If you lived in an NTSC area, most likely 30fps. But today it’s not that simple. For a start the internet allows us to distribute our content globally, across borders. In addition PAL and NTSC only really apply to standard definition television as they are the way the SD signal is broadcast with a PAL frame being larger than an NTSC one and both use non-square pixels. With HD Pal and NTSC does not exist, both are 1280×720 or 1920×1080 and both use square pixels, the only difference between HD in a 50hz country and a 60hz country is the frame rate.

Today with HD we have many different frame rates to choose from. For film like motion we can use 23.98fps or 24fps. For fluid smooth motion we can use 50fps or 60fps. In between sits the familiar 25fps and 30fps (29.97fps) frame rates. Then there is also the option of using interlace or progressive scan. Which do you choose?

If you are producing a show for a broadcaster then normally the broadcaster will tell you which frame rate they need. But what about the rest of us?

There is no single “right” frame rate to use. A lot will depend on your particular application, but there are some things worth considering.

If you are producing content that will be viewed via the internet then you probably want to steer clear of interlace. Most modern TV’s and all computer monitors use progressive scan and the motion in interlaced content does not look good on progressive TVs and monitors. In addition most computer monitors run by default at 60hz. If you show content shot at 25fps or 50fps on a 60hz monitor it will stutter slightly as the computer repeats an uneven number of  frames to make 25fps fit into 60Hz. So you might want to think about shooting at 30fps or 60fps for smoother less stuttery motion.

24fps or 23.98fps will also stutter slightly on a 60hz computer screen, but the stutter is very even as 1 frame gets repeated in every 4 frames shown.  This is very similar to the “pull-up” that gets added to 24fps movies when shown on 30fps television, so it’s a kind of motion that many viewers are used to seeing anyway. Because it’s a regular stutter pattern it tends to be less noticeable in the irregular conversion from 25fps to 60hz. 25 just doesn’t fit into 60 in a nice even manner. Which brings me to another consideration – If you are looking for a one fits all standard then 24 or 23.98fps might be a wise choice. It works reasonably well via the internet on 60hz monitors. It can easily be converted to 30fps (29.97fps) using the pull-up for television and it’s not too difficult to convert to 25fps simply by speeding it up by 4% (many feature films are shown in 25fps countries simply by being sped up and a pitch shift added to the audio).

So, even if you live and work in a 25fps (Pal) area, depending on how your content will be distributed you might actually want to consider 24, 30 or 60fps for your productions. 25fps or 50fps looks great on a 50hz TV, but with the majority of non broadcast content being viewed on computers, laptops and tablets 24/30/60fps may be a better choice.

What about the “film look”? Well I think it’s obvious to say that 24p or 23.98p will be as close as you can get to the typical cadence and motion seen in most movies. But 25p also looks more or less the same. Even 30p has a hint of the judder that we see in a 24p movie, but 30p is a little smoother. 50p and 60p will give very smooth motion, so if you shoot sports or fast action and you want it to be smooth you may need to use 50/60p. But 50/60p files will be twice the size of 24/25 and 30p files in most cases, so then storage and streaming bandwidth have to be considered. It’s much easier to stream 24p than 60p.

For almost all of the things that I do I shoot at 23.98p, even though I live in a 50hz country. I find this gives me the best overall compatibility. It also means I have the smallest files sizes and the clips will normally stream pretty well. One day I will probably need to consider shooting everything at 60fps, but that seems to be some way off for now, HDR and higher resolutions seem to be what people want right now rather than higher frame rates.

cinematography, PMW-F55, PXW-FS7, shoots, Workflow

Why do I always shoot at 800 EI (FS7 and F5)?

10 Comments
This is a question that comes up time and time again. I’ve been using the F5 and FS7 for almost 5 years. What I’ve discovered in that time is that the one thing that people notice more than anything from these cameras is noise if you get your exposure wrong. In addition it’s much harder to grade a noisy image than a clean one.
Lets take a look at a few key things about how we expose and how the F5/FS7 works (note the same principle applies to most log based cameras, the FS5 also benefits from being exposed brighter than the suggested base settings).
What in the image is important? What will your audience notice first? Mid-range, shadows or highlights?
I would suggest that most audiences first look at the mid range – faces, skin tones, building walls, plants etc. Next they will notice noise and grain or perhaps poor, muddy or murky shadows. The last thing they will notice is a few very brightly highlights such as specular reflections that might be clipped.
The old notion of protecting the highlights comes from traditional gamma curves with a knee or highlight roll off where everything brighter than a piece of white paper (90% white) is compressed into a very small recording range. As a result when shooting with conventional gamma curves ALL of the brighter parts of the image are compromised to some degree, typically showing a lack of contrast and texture, often showing some weird monotone colors. Log is not like that, there is no highlight roll off, so those brighter than white highlights are not compromised in the same way.
 
In the standard gammas at 0dB the PXW-FS7, like the PMW-F5 is rated at 800 ISO. This gives a good balance between noise and sensitivity. Footage shoot at 0dB/800ISO with the standard gammas or Hypergammas generally looks nice and clean with no obvious noise problems. However when we switch to log the native ISO rating of the cameras becomes 2000 ISO, so to expose “correctly” we need to stop the aperture down by 1.3 stops. This means that compared to 709 and HG1 to HG4, the sensor is being under exposed by 1.3 stops. Less light on the sensor will mean more noise in the final image. 1.3 stops is the equivalent of 9dB. Imagine how Rec709 looks if it is under exposed by 1.3 stops or has to have +9dB of gain added in. Well – thats what log at 2000 ISO will look like.
 
However log has lots of spare headroom and no highlight compression. So we can choose to expose brighter than the base ISO because pushing that white piece of paper brighter in exposure does not cause it to become compressed.
If you open the aperture back up by 1.3 stops you get back to where you would be with 709 in terms of noise and grain. This would be “rating” the camera at 800 ISO or using 800 EI. Rating the camera at 800EI you still have 4.7 stops of over exposure range, so the only things that will be clipped will in most cases be specular reflections or extreme highlights. There is no TV or monitor in existence that can show these properly, so no matter what you do, they will never be true to life. So don’t worry if you have some clipped highlights, ignore them. Bringing your exposure down to protect these is going to compromise the mid range and they will never look great anyway.
 
You should also be extremely cautious about ever using an EI higher that 2000. The camera is not becoming more sensitive, people are often misslead by high EI’s into thinking somehow they are capturing more than they really are. If you were to shoot at 4000 EI you will end up with footage 15dB noisier than if you were shooting the same scene using 709 at 800 ISO. That’s a lot of extra noise and you won’t necessarily appreciate just how noisy the footage will be while shooting looking at a small monitor or viewfinder.
 
I’ve been shooting with the F5 and then the FS7 for almost 5 years and I’ve never found a situation where I going to an EI higher than 800 would have resulted in a better end result. At the same time I’ve seen a lot of 2000 EI footage where noise in the mid range has been an issue, one particular example springs to mind of a high end car shoot where 2000 EI was used but the gloss and shine of the car bodywork is spoilt because it’s noisy, especially the darker coloured cars.
 
Of course this is just my opinion, based on my own experience, others may differ and the best thing you can do is test for yourself.
cameras, cinematography, Technology, Workflow

Will a bigger recording Gamut give me more picture information?

26 Comments

The short answer is it all depends on the camera you are using. With the F55 or F65 then S-Log2/S-Gamut and S-Log3/S-Gamut3 will give you a larger range of colours in your final image than S-Log3/S-Gamut3.cine. But if you have a PMW-F5, PXW-FS7 or PXW-FS5 this is not going to be the case.

What is Gamut?

The word Gamut means the complete range or scale of something. So when we talk about Gamut in a video camera we are talking about dynamic range and color range (colorspace) taken together. Then within the Gamut we can break that down into the dynamic range or brightness range which is determined by the gamma curve and the color range which is determined by the colorspace.

Looking at the current Sony digital cinema cameras you have a choice of 3 different gamuts when the camera is in log mode plus a number of conventional gamuts you get when shooting rec-709, rec-2020 or any other combination of rec-709 color with cinegammas or hypergammas.

Log gamma and gamuts.

But it’s in the log mode where there is much confusion. When shooting with log with the current cameras you have 3 recommended combinations.

S-Gamut (S-Gamut colorspace + S-log2 gamma).

S-Gamut3 (S-Gamut3 colorspace + S-Log3 gamma).

S-Gamut3.cine (S-Gamut3.cine colorpace + S-Log3 gamma).

The S-log2 and S-log3 gamma curves both capture the same dynamic range – 14 stops, there is no difference in the dynamic range captured.

In terms of the range of colors that can be recorded S-Gamut and S-Gamut3 are the same size and the largest recording colorspaces the cameras have. S-Gamut3.cine is a smaller colourspace but still larger than P3 (digital cinema projection) or rec-709.

But those were all designed for the F55 and F65 cameras that have extremely high quality (expensive) colour filters on their sensors. The reality is that the F5/FS7/FS5 sensor cannot see the full range of any of the S-Gamut colorspaces so in reality you gain very little by using the larger versions. Don’t expect to see a noticeably greater range of colours than any of the other colour modes if you have the F5/FS7/FS5. But all the LUT’s designed for these cameras are based on the S-Gamuts and if you want to mix an FS5 with an F55 in one production it helps to use the same settings so that grading will be easier. It is worth noting at this point that most natural colors do fall within Rec-709, so while it is always nicer to have a bigger color range it isn’t the end of the world for most of what we shoot.

S-Log3 is a great example of what it means to have a bigger recording range than the camera can “see”. S-log3 is based on the Cineon film transfer log gamma curve developed back in the late 1980’s. Cineon was carefully tailored to match film response and designed around 10 bit data (as that was state of the art back then). It allows for around 16 stops of dynamic range. Much later, Arri and many others then adapted Cineon for use in video cameras – The “C” in Arri’s LogC stands for Cineon.

When Sony started doing wide dynamic range cameras they developed their own log gammas starting with S-Log, then S-Log2. These curves are matched very precisely to the way a video sensor captures a scene rather than film. In addition they are matched to the sensors actual capture range, S-Log can record 13 stops as that’s what the sensors in the cameras with S-Log can see. Then S-Log2 is 14 stops as the second generation cameras can all see 14 stops. As a result of being purpose designed for a video sensor, when using S-Log2 you maximise the entire recording range because the sensor is matched to the log which is matched to the record range.

But, these curves drew much criticism from early adopters and colorists because they were very different from the Cineon curve and all the other log curves based on this old school film curve. Colorists didn’t like it because none of their old Cineon LUT’s would work as expected and it was “different”.

Chart showing S-Log2 and S-Log3 plotted against f-stops and code values. Note how little data there is for each of the darker stops, the best data is above middle grey. Note that current sensors only go to +6 stops over middle grey so S-Log2 and S-Log3 record to different peak levels.

In response to this Sony then developed S-Log3 and surprise, surprise – S-log3 is based on Cineon. So S-log3 is based on a 16 stop film transfer curve, but the current cameras can only see 14 stops. What this means is that the top 14% of the gamma curve is never used (that’s where stops 15 and 16 would reside) and as a result s-Log3 tops out at 92% and never gets to the 107% that S-Log2 can reach. If Sony were to release a 16 stop camera then S-Log3 could still be used and then it would reach 107%.

Coming back to colorspace. If you understand that the sensor in the F5/FS7/FS5 cannot see the full colour range that S-Gamut or S-Gamut3 are capable of recording then you will appreciate that like S-log3 (that is larger than the camera can see and therefore part empty) many of the possible code values available in S-Gamut are left empty. This is a waste of data. So from a colourspace point of view the best match when shooting log for these cameras is the slightly smaller colorspace S-Gamut3.cine. But S-Gamut3.cine is meant to be matched with S-Log3 which as we have seen wastes data anyway. If the camera is shooting using a 10 bit codec such as XAVC-I or XAVC-L in HD there are plenty of code values to play with, so a small loss of data has little impact on the final image. But if you are recording with only 8 bit data, for example XAVC-L in UHD then this does become much more of a problem and this is when you will find that S-Gamut with S-Log2 is going to give a better result as S-Log2 was designed for use with a video sensor from day 1 and it maximises the use of what little data you have.

cameras, cinematography, PXW-FS5, Technology, Workflow

Raw and the PXW-FS5

41 Comments

This isn’t a “how to” guide. There are many different recorders that can be used to record raw from the FS5 and each would need it’s own user guide. This is an overview of what raw is and how raw recording works to help those that are a bit confused, or not getting the best results.

First of all – you need to have the raw upgrade installed on the FS5 and it must be set to output raw. Then you need a suitable raw recorder. Just taking the regular SDI or HDMI output and recording it on an external recorder is not raw.

Raw is raw data direct from the cameras sensor with very little image processing. It isn’t even a color image, it won’t become color until some external processing, often called “De-Bayer” is done to convert the raw data to a color image.

For raw to work correctly the camera has to be set up just right. On the FS5 you should use Picture Profile 7. Don’t try and use any other profile, don’t try and shoot without a profile. You must use Picture Profile 7 at it’s factory default settings. In addition don’t add any gain or change the ISO from 3200 (2000 ISO from version 4.02 firmware). Even if the scene is a dark one, adding gain will not help and it may in fact degrade the recorded image.

White balance is set using the appropriate SGamut + color temperature preset chosen from within Picture Profile 7, there are only 3 to choose from for S-Gamut, but with a raw workflow you will normally fine tune the white balance in post. No other color matrix or white balance method should be used. Trying to white balance any other way may result in the sensor data being skewed or shifted in a way that makes it hard to deal with later on.

All of the above is done to get the best possible, full dynamic range data off the sensor and out of the camera.

If you are viewing the S-Log2 (ie don’t have viewfinder gamma assist enabled) then the exposure level that Sony recommend is to have a white card at 60%. So consider setting the zebras to 60%. Don’t worry that this may look a bit dark or appear to be a low level, but that’s the level you should start with… More about exposure later on.

This raw data is then passed down the SDI cable to the external recorder. The external recorder will then process it, turn it into a color signal (de-bayer) and add a gamma curve so that it can be viewed on the recorders screen. Exactly what it will look like on the monitor screen will depend on how the recorder is set up. IF the recorder is set to show S-Log2, then the recorders screen and the FS5’s LCD should look similar. However you might find that it looks very different to what you are seeing on the FS5’s LCD screen. This is not unexpected. If the recorder is setup to convert the raw to Rec-709 for display then the image on the recorder will be brighter and show more contrast, in fact it should look “normal”.

Under the surface however, the external raw recorder is going to be doing one of two things (normally at least). It’s either going to be recording the raw data coming from the camera as it is, in other words as raw. Or it will be converting the raw data to S-Log2 and recording it as a conventional ProRes or DNxHR video file. Either way when you bring this footage in to post production it will normally appear as a flat, low contrast S-Log2 image rather than a bright, contrasty rec-709 image. So understand that the footage will normally need to be graded or have some other changes made to it to look nice.

Recording the actual raw data will give you the best possible information that you can get from the FS5 to work with in post production. The downside is that the files will be huge and will take a fair amount of processing power to work with. Recording a ProRes or DNxHR video file with S-Log2 gamma is second best. You are throwing away a bit of image quality (going from 12 bit linear down to 10 bit log) but the files should still be superior to the 8 bit UHD internal recordings or even an external recording done via the HDMI which is also limited to 8 bit in UHD.

Most raw recorders have the ability to add a LUT – Look Up Table – to the image viewed on the screen. The purpose of the LUT is to convert the S-Log2/raw to a conventional gamma such as Rec-709 so that the picture looks normal. If you are using a LUT then the normal way to do things is to view the normal looking picture on the recorders screen while the recorder continues to record S-Log2 or raw. This is useful as the image on the screen looks normal so it is easier to judge exposure. With a 709 LUT you would expose the picture so that the image on the recorders screen looks as bright as normal, skin tones would be the usual 70% (ish) and white would be 90%.

There is a further option and that is to “bake in the LUT”. This means that instead of just using the LUT to help with monitoring and exposure you actually record the image that you see on the recorders screen. This might be useful if you don’t have any time for grading, but… and it’s a big BUT…. you are now no longer recording S-log2 or raw. You will no longer have the post production grading flexibility that raw or S-Log2 provide and for me at least this really does defeat the whole point of recording raw.

Exposure: Raw will not help you in low light. Raw needs to be exposed brightly (there are some data limitations in the shadows with 12 bit linear raw compared to 16 bit raw and possibly even 10 bit log). If viewing S-Log2 then Sony’s recommendation is to have a white card or white piece of paper at 60%. I consider that to be the absolute minimum level you can get away with. The best results will normally be achieved if you can expose that white card or piece of paper at around 70% to 75% (when looking at an S-Log2 image). Skin tones would be around 55%. If you expose like this you may need to use a different LUT on the recorder to ensure the picture doesn’t look over exposed on the recorders monitor screen. Most of the recorders include LUT’s that have offsets for brighter exposures to allow for this. Then in post production you will also want a LUT with an exposure offset to apply to the S-Log2 recordings. You can use the search function (top right) to find my free LUT sets and download them. Exposing that bit brighter helps get around the shadow data limitations of 12 bit linear raw and pushes the image up into the highlights where there is more data.

SEE ALSO: https://www.sony.co.uk/pro/article/broadcast-products-FS5-raw-shooting-tips

 

Workflow

San Francisco/Bay Area Private Workshop, 4th of March, 2 places left.

Leave a comment

I’m looking to fill the last 2 places on this intermediate to high level full day workshop. Please note: All participants signed up so far are seasoned pros with at least a decade of professional experience. Topics covered will be:

Scene Files and Paint Settings – Gamma Curves, Dynamic Range, Matrix and Color.
Gain and ISO, what do these really mean. Understanding the signal to noise ratio.
S-Log, S-Gamut and Exposure Indexing.
LUT’s and Looks, LUT creation and LUT use.
File handling and backup.
Grading introduction including color managed workflows such as ACES.
HDR – Introduction to HDR, what we need to know and how will it effect us.

This is a private workshop and there is a fee to attend. Please use the contact form if you are interested.

cameras, cinematography, PMW-F55, Technology, Venice, Workflow

What is XOCN? Why is it so good, why do we need it?

2 Comments

This time last year I was just starting to earn about a new codec from Sony called XOCN (eXtended Original Camera Negative). XOCN is currently only available with the Sony F5/F55 and the new AXS-R7 raw recorder. Sony’s original R5 raw recorder takes 16 bit sensor data and applies a very mild amount of compression before recording the sensor data as linear raw. I have never seen any compression artefacts when using the 16 bit linear raw and it really is an amazing format to work with. So much so that I will always use it whenever possible.

But now as well as 16 bit linear raw the R7 can record 16 bit linear XOCN. Now, I’ll be completely honest here, I’m really not sure what the difference is between raw and XOCN. As far as I can tell XOCN is very, very similar to raw but sufficiently different to raw to avoid infringing on patents held by other manufacturers for compressed raw. XOCN is more highly compressed than Sony’s raw, but in every test I’ve done I have found it hard to spot any compression problems or any significant difference between XOCN and the original 3:1 raw.

So, I hear you ask…. “If it’s really that good what don’t we just do away with XAVC and use XOCN?” Well that is a good question. It all depends on processing power. XAVC is a traditional codec so inside the codec is a normal video image, so the only thing a computer has to do to play it back is uncompress the codec. XOCN is a compressed wrapper that contains sensor data, in order to view the image the computer has to uncompress the data and then it has to construct the image from the data. So you need a really good graphics card in a decent computer to work with XOCN. But if you do have a decent edit or grading workstation you should find XOCN straight forward to work with, it doesn’t require specialist cards to accelerate the decoding as Red raw does.

The key benefit that XOCN brings over traditional video is that it is 16 bit. 10 bit video is pretty good. In a 10 bit video you have almost 1000 tonal values, not bad when you consider that we have been using 8 bit for decades with only 235 shades. But 16 bit brings the potential for a whopping great 65,535 shades. This starts to make a big difference when you are extensively manipulating the image in post production. Any of you that are in to photography will know that you can push and pull a 16 bit raw photograph far, far further than an 8 bit jpeg. 16 bit video is no different.

But what’s really amazing about XOCN is you get almost all the benefits of linear raw but in a file size smaller than the same resolution 10 bit ProResHQ. If you use XOCN-LT the files are roughly half the size of ProResHQ. This means your media lasts a sensible amount of time and backups, transfers and archiving are all much easier, much faster than with uncompressed raw. Sony’s 3:1 compressed raw from the R5 has always been pretty easy to deal with. XOCN is even easier. Using XOCN-LT you can squeeze well over 2 hours of 16bit 4K on to a 512GB AXS card! In fact the file sizes are only marginally larger than XAVC class 480.

The reduction in data rates becomes really significant if you shoot at high frame rates. As 50p and 60p productions become more common XOCN allows production companies to shoot 60fps with the benefits of 16 bit data but with files sizes barely any bigger than 24fps ProResHQ. If you have a Sony PMW-F55 you can shoot at 120fps in 4K using XOCN and the files are twice as big as 24fps raw.

For further information on XOCN please take a look at this page from Sony, it’s very informative and has a very good example of why 16 bit data is important, especially if you are shooting for HDR.

https://pro.sony.com/bbsc/ssr/show-highend/resource.solutions.bbsccms-assets-show-highend-f55xocn.shtml

cameras, Shooting Tips, Technology, Workflow

Notes on Timecode and Timecode Sync for cinematographers, part 2.

7 Comments

In the first part of this 2 part article we saw how at some frame rates timecode will drift relative to a real time clock (Click Here for part 1). As well as drifting relative to real time due to the way timecode can only count the actual whole frames recorded,  the internal clocks that govern the timecode generators in many devices may drift slightly over time.

For single camera operation this drift is rarely significant but as soon as you start using multiple cameras or recording sound separately to the camera, even very small differences of just a frame or two between each device can cause problems. A one frame error is enough to cause a visible lip sync error, by two frames the sync error is pretty obvious to most people.

So, very often we need to synchronise the timecode across multiple devices so that the audio timecode matches the camera timecode or multiple cameras all have the same timecode so that it’s easy to re-align everything in post production. Most professional video cameras will have a timecode in or timecode out connector and the simplest way to sync two cameras is to feed the timecode from one cameras timecode out to the other cameras timecode in. For this to work both cameras must be set to “Free Run” timecode.

BUT YOU ALSO NEED GENLOCK OR SYNC LOCK

This is the part that often gets overlooked. If you read the first part you should understand that when a video camera is recording the timecode is generated by counting the number of frames recorded. As a result the precise frame rate of the camera will determine how many frames are recorded in any given time period and as a result the timecode for that clip. When you press the record button to start a recording the cameras timecode will match any external timecode fed to the camera. But from that point forward until the end of the recording the timecode just counts the frames recorded and will ignore any external timecode.

So the only way to ensure 100% accurate timecode sync between multiple cameras or between a camera and some other external timecode source is by providing not only a common timecode source but also a sync source that is locked to the timecode. By feeding the camera sync that is locked to the timecode into the cameras genlock input the cameras frame rate will be locked to the master frame rate so you will not get any timecode drift.

It’s amazing how many people overlook the fact that a cameras timecode generator counts frames while recording, so if the cameras frame rate is a tiny bit off, even with an external timecode source it will drift. It’s only by synchronising the camera through sync and genlock that you can be sure to eliminate any timecode drift.

SYNC SOUND:

If you are recording sound remotely from the camera you need to keep the camera and audio recorders timecode in sync. The timecode in a camera is dependant on the actual frames recorded while the timecode on an audio recorder is often nothing more than a data or audio track that records the timecode signal. It is rarely locked to the recorders sampling or recording rate. Because of this the correct way to link the timecode in this scenario is from the camera to the recorder.

If you do it the other way around (which for some reason appears to be the most common way) you cannot be sure that you won’t get timecode drift unless the audio recorder is also sending sync to the cameras genlock input. Normally a small amount of drift will go un-noticed on shorter shots. The cameras timecode will re-sync with the external timecode when you stop recording, so the beginning of each shot will have the correct timecode. As a result you will normally get away with feeding timecode only from an audio recorder.  But on longer takes, say shooting a music event it can become a significant issue as the camera and recorder drift apart over longer takes.

23.98fps.

As you should have learnt from part one, 23.98fps timecode can be particularly difficult to deal with as the timecode in a camera shooting at 23.98fps will always drift by 3.6 seconds an hour relative to real time. So be very, very careful if shooting 23.98fps but using an audio recorder that uses a real time clock. There is no way to satisfactorily sync a real time clock with a camera shooting 23.98fps. Over the course of a 1 minute clip you will see the timecode drift by over 1 frame. If you wish to do sync sound at 23.98fps you need to ensure your audio recorder supports either 23.98fps timecode or at a push Non Drop Frame 29.97fps timecode. You can only sync 23.98fps tmecode with 23.98fps timecode, but a free running, Non Drop Frame 29.97fps recorder should stay closer in sync than a real time clock.

If your audio recorder only has a real time clock I strongly suggest shooting at 24fps rather than 23.98fps where you can. 24fps is a whole number so 24fps timecode does not drift by 3.6 seconds per hour compared to real time. So any sync issues should be much reduced at 24fps compared to 23.98fps. If shooting 29.97fps (often mistakenly referred to as 30fps/60i) then you should use Drop Frame Timecode when working with recorders with a real time clock.

WHAT IF THE CAMERA DOESN’T HAVE TC IN?

There are a few pro cameras that don’t have a dedicated timecode in or timecode out port. The very popular Sony PXW-FS7 does not have timecode in and can’t be genlocked unless you add the optional extension unit to the camera. For cameras such as these, if you need to record sync sound on a separate recorder one option is to record the timecode output from the audio recorder as an audio signal on one of the cameras audio tracks. Timecode recorded on an audio track like this will rarely line up perfectly with the cameras own internal timecode so it should never be used as the main timecode for the recorded video. But there are plenty of software tools that will allow you to read this timecode in post production so that you can use it to line up your audio recordings with the video recording. This isn’t an ideal solution, but it’s better than relying on two different clocks, one in the camera, one in the recorder possibly running at quite different rates.

MULTICAMERA SHOOTS.

If you have multiple cameras or audio recorders it may be possible to loop the time code (and hopefully sync too) from camera to camera, so that every device is connected. Another option is to use a single master timecode and sync source and hard wire every camera to that. The problem with either of these is that if the venue is large you need a lot of cable. Sometimes it simply isn’t possible to use cables to connect everything together so instead of cables we connect the cameras wirelessly.

WIRELESS.

Wireless timecode connections normally work OK. If you momentarily loose the wireless timecode link the cameras timecode clock will just keep counting the frames recorded without issue. But as we have already seen, for true drift free timecode lock we also need to synchronise the camera via genlock. Sending genlock wirelessly is not normally a good idea. Any interruption of the sync signal will cause the cameras frame rate to jitter and that’s really bad. In practice it is quite common to link the timecode of several devices wirelessly without sync. Again for shot takes this is often perfectly OK. The lack of sync however can be an issue on longer takes. A good example of this would be a music concert where it really is vital that all the cameras and recorders run in sync.

Companies such as Ambient have wireless timecode and sync devices where each of the sync boxes (lockit box) has it’s own very high precision, temperature compensated sync clock.  All the boxes then sync to one master device, should the wireless signal drop out the internal sync clocks will continue to provide both a genlock sync pulse and timecode that is so precise that you should not see any timecode or sync drift over several days.

If you missed part 1 you can find it by clicking here.

cameras, Shooting Tips, Technology, Workflow

Notes on Timecode and Timecode Sync for cinematographers.

4 Comments

This is part 1 of two articles. In this article I will look at what timecode is and some common causes of timecode drift problems. In part 2 I will look at the correct way to synchronise timecode across multiple devices.

This is a subject that keeps cropping up from time to time. A lot of us camera operators don’t always understand the intricacies of timecode. If you live in a PAL/50Hz area and shoot at 25fps all the time you will have few problems. But start shooting at 24fps, 23.98 fps or start trying to sync different cameras or audio recorders and it can all get very complicated and very confusing very quickly.

So I’ve written these notes to try to help you out.

WHAT IS TIMECODE?

The timecode we normally encounter in the film and video world is simply a way to give every frame that we record a unique ID number based on the total number of frames recorded or the time of day.  It is a counter that counts whole frames. It can only count whole frames, it cannot count fractions of frames, as a result the highest accuracy is 1 frame. The timecode is normally displayed as Hour:Minute:Second:Frame in the following format

HH:MM:SS:FF

RECORD RUN AND FREE RUN

The two most common types of timecode used are “Record Run” and “Free Run”. Record run, as the name suggests only runs or counts up when the camera is recording. It is a cumulative frame count, which counts the total number of frames recorded. So if the first clip you record starts with the time code clock at 00:00:00:00 and runs for 10 seconds and 5 frames then the TC at the end of the clip will be 00:00:10:05. The first frame of the next clip you record will continue the count so will be 00:00:10:06 and so on. When you are not recording the timecode stops counting and does not increase.

With “Free Run” the timecode clock in the camera is always counting according to the frame rate the camera is set to. It is common to set the free run clock so that it matches the time of the day. Once you set the time in the timecode clock and enable “Free Run” the clock will start counting up whether you are recording or not.

HERE COMES A REALLY IMPORTANT BIT!

In “Free Run” once you have set the timecode clock it will always count the number of frames recorded and in some cases this will actually cause the clock to drift away from the actual time of day.

SOME OF THE PROBLEMS.

An old problem is that in the USA and other NTSC areas the frame rate is a really odd frame rate, it’s 29.97fps (this came about to prevent problems with the color signal when color TV was introduced). Timecode can only count actual whole frames, so there is no way to account for the missing 0.03 frames in every second. As a result timecode running at 29.97fps runs slightly slower than a real time clock.

If the frame rate was actually 30fps in 1 hour there would be 108,000 frames. But at 29.97fps after one real time hour you will have only recorded  107,892 frames, the frame counter TC, won’t reach one hour for another 3.6 seconds.

DROP FRAME TIMECODE.

To eliminate this 3.6 seconds per hour (relative to real time) timecode discrepancy in footage filmed at 29.97fps a special type of time code was developed called “Drop Frame Timecode“. Drop Frame Timecode (DF) works by: every minute, except each tenth minute, two timecode numbers are dropped from the timecode count. So there are some missing numbers in the timecode count but after exactly 1 real time hour the time code value will increment by 1 hour. No frames themselves are dropped, only numbers in the frame count.

WHEN TO USE DROP FRAME (DF) OR NON DROP FRAME (NDF).

Drop Frame Timecode is only ever used for material shot at  29.97fps, which includes 59.94i. (We will often incorrectly refer to this as 60i or 30fps – virtually all 30fps video these days is actually 29.97fps). If you are using “Rec Run” timecode you will almost never need to use Drop Frame as generally you will not by syncing with anything else.

If you are using 29.97fps  “Free Run” you should use Drop Frame (DF) when you want your timecode to stay in sync with a real time clock. An example would be shooting a long event or over several days where you want the timecode clock to match the time on your watch or the watch of an assistant that might be logging what you are shooting.

If you use 29.97fps Non Drop Frame  (NDF) your cameras timecode will drift relative to the actual time of day by a minute and a half each day. If you are timecode syncing multiple cameras or devices it is vital that they are all using the same type of timecode, mixing DF and NDF will cause all kinds of problems.

It’s worth noting that many lower cost portable audio recorders that record a “timecode” don’t actually record true timecode. Instead they record a timestamp based on a real time clock. So if you record on the portable recorder for lets say 2 hours and then try to sync the 1 hour point (01:00:00:00 Clock Time) with a camera recording 29.97fps NDF timecode using the 1 hour timecode number (01:00:00:00 NDF Timecode) they will be out of sync by 3.6 seconds. So this would be a situation where it would be preferable to use DF timecode in the camera as the cameras timecode will match the real time clock of the external recorder.

WHAT ABOUT 23.98fps?

Now you are entering a whole world of timecode pain!!

23.98fps is a bit of a oddball standard that came about from fitting 24fps films into the NTSC 29.97fps frame rate. It doesn’t have anything to do with pull up, it’s just that as NTSC TV runs at 29.97fps rather than true 30fps movies are sped up by 0.1% to fit in 29.97fps.

Now 23.98fps exists as a standalone format. In theory there is still a requirement for Drop Frame timecode as you can’t have 0.02 frames in a timecode frame count, each frame must have a whole number. Then after a given number of frames you go to the next second in the count. With 23.98fps we count 24 whole frames and the increment the timecode count by one second, so once again there is a discrepancy between real time and the timecode count of 3.6 seconds per hour. The time on a camera running at 23.98fps will run fast compared to a real time clock.  Unlike 29.97fps there is no Drop Frame (DF) standard for 23.98, it’s always treated as a 24fps count (TC counts 24 frames, then adds 1 to the second count), this is because there  is no nice way to adjust the count and make it fit real time as there is with 29.97fps. No matter how you do the math or how many frames you drop there would always be a fraction of a frame left over.

So 23.98fps does not have a DF mode. This means that after 1 hour of real time the timecode count on a camera shooting at 23.98 fps will be 00:01:03:14. If you set the camera to “Free Run” the timecode will inevitably drift relative to real time, again over the course of a day the camera will be fast by almost one and a half minutes compared to a real time clock or any other device using either drop frame timecode, 24fps or 25fps.

So, as I said earlier 23.98fps timecode can be painful to deal with.

24fps timecode does not have this problem as there are exactly 24 frames in every second, so a video camera shooting at 24fps should not see any significant timecode drift or loss of timecode sync compared to a real time clock.

It’s worth considering here the problem of shooting sync sound (where sound is recorded externally on a remote sound recorder). If your sound recorder does not have 23.98fps timecode the timecode  will drift relative to a camera shooting at 23.98fps. If your sound recorder only has a real time timecode clock you might need to consider shooting at 24fps instead of 23.98fps to help keep the audio and picture time codes in sync. Many older audio recorders designed for use alongside film cameras can only do 24fps timecode.

In part 2 I will look at the correct way to synchronise timecode across multiple devices.

CLICK HERE FOR PART 2