Tag Archives: Timecode

cinematography, Shooting Tips, Workflow

Timecode doesn’t synchronise anything!!!

5 Comments

There seems to be a huge misunderstanding about what timecode is and what timecode can do. I lay most of the blame for this on manufactures that make claims such as “Our Timecode Gadget Will Keep Your Cameras in Sync” or “by connecting our wireless time code device to both your audio recorder and camera everything will remain in perfect sync”. These claims are almost never actually true.

What is “Sync”.

First we have to consider what we mean when we talk about “sync” or synchronisation.  A dictionary definition would be something like “the operation or activity of two or more things at the same time or rate.” For film and video applications if we are talking about 2 cameras they would be said to be in sync when both start recording each frame that they record at exactly the same moment in time and then over any period of time they record exactly the same number of frames, each frame starting and ending at precisely the same moment.

What is “Timecode”.

Next we have to consider what time code is. Timecode is a numerical value that is attached to each frame of a video or an audio recording in an audio device to give it a time value in hours, minutes, seconds, frames. It is used to identify individual frames and each frame must have a unique numerical value. Each individual successive frames timecode value MUST be “1” greater than the frame before (I’m ignoring drop frame for the sake of clarity here). A normal timecode stream does not feature any form of sync pulse or sync control, it is just a number value.

Controlling the “Frame Rate”.


And now we have to consider what controls the frame rate that a camera or recorder records at. The frame rate the camera records at is governed by the cameras internal sync or frame clock. This is normally a  circuit controlled by a crystal oscillator. It’s worth noting that these circuits can be affected by heat and at different temperatures there may be very slight variations in the frequency of the sync clock. Also this clock starts when you turn the camera on, so the exact starting moment of the sync clock depends on the exact moment the camera is switched on. If you were to randomly turn on a bunch of cameras their sync clocks would all be running out of sync. Even if you could press the record button on each camera at exactly the same moment, each would start recording the first frame at a very slightly different moment in time depending on where in the frame rate cycle the sync clock of each camera is. In higher end cameras there is often a way to externally control the sync clock via an input called “Genlock”.  Applying a synchronisation signal to the cameras Genlock input will pull the cameras sync clock into precise sync with the sync signal and then hold it in sync. 

And the issue is………..

Timecode doesn’t perform a sync function. To SYNCHRONISE two cameras or a camera and audio recorder you need a genlock sync signal and timecode isn’t a sync signal, timecode is just a frame count  number. So timecode cannot synchronise 2 devices. The camera’s sync/frame clock might be running at a very slightly different frame rate to the clock of the source of the time code. When feeding timecode to a camera the camera might already be part way through a frame when the timecode value for that frame arrives, making it too late to be added, so there will be an unavoidable offset. Across multiple cameras this offset will vary, so it is completely normal to have a +/- 2 frame (sometimes more) offset amongst several cameras at the start of each recording.

And once you start to record the problems can get even worse…

If the camera’s frame clock is running slightly faster than the clock of the TC source then perhaps the camera might record 500 frames but only receive 498 timecode values – So what happens for the 2 extra frames the camera records in this time? The answer is the camera will give each frame in the sequence a unique numerical value that increments by 1, so the extra frames will have the necessary 2 additional TC values. And as a result the TC in the camera at the end of the clip will be an additional 2 frames different to that of the TC source. The TC from the source and the TC from the camera won’t exactly match, they won’t be in sync or “two or more things at the same time or rate”, they will be different.

The longer the clip that you record, the greater these errors become as the camera and TC source drift further apart.

Before you press record on the camera, the cameras TC clock will follow the external TC input. But as soon as you press record, every recorded  frame MUST have a unique new numerical value 1 greater than the previous frame, regardless of what value is on the external TC input. So the cameras TC clock will count the frames recorded. And the number of frames recorded is governed by the camera sync/frame clock, NOT the external TC.  

So in reality the ONLY way to truly synchronise the timecode across multiple cameras or audio devices is to use a sync clock connected to the  GENLOCK input of each device.

Connecting an external TC source to a cameras TC input is likely to  result in much closer TC values for both the audio recorder and camera(s) than no connection at all. But don’t be surprised if you see small 1 or 2 frame errors at the start of clips due to the exact timing of when the TC number arrives at the camera relative to when the camera starts to record the first frame and then possibly much larger errors at the ends of clips, these errors are expected and normal. If you can’t genlock everything with a proper sync signal, a better way to do it is to use the camera as the TC source and feed the TC from the camera to the audio recorder. Audio recorders don’t record in frames, they just lay the TC values alongside the audio. As an audio recorder doesn’t need to count frames the TC values will always be in the right place in the audio file to match the cameras TC frame count. 

Everything Else, Shooting Tips

Beware multiple power supplies!!

7 Comments

From time to time someone will pop up on a forum or user group with tales of fried SDI boards, dead monitors or dead audio devices. Often the reason for the death of these units seems obscure. One day it all works fine, the next time the monitor is plugged in it stops working.

A common cause of these types of issue is the use of individual power supplies for each device. Most modern power supplies use a technology called “switch mode”. Most “wall wart” power supplies are switch mode. Computers use switch mode power supplies, they are probably the most common type of power supply in use today.

The problem with these power supplies is that the voltage they produce is not tied to a common earth or ground connection. A 12 volt power supply may have an output voltage that measures 12 volts across it’s positive and negative terminals, which is great. But the negative terminal might be many volts above “ground”. Used singly this is not normally a problem but if you use a couple of different power supplies with negative terminals floating at different voltages, if you connect them together current will flow from one to the other as the establish a common base voltage.

As an example if you have a monitor powered by one power supply and a camera powered by another, when you connect the monitor to the camera current may flow down the SDI or HDMI cable from one power supply to the other causing damage to the chips that process the SDI/HDMI signals.

Even if there is no damage this current can lead to audio hum or other electrical noise.

How can you prevent this?

First use only high quality power supplies. Wherever possible try to run everything off a single power supply. Powering the camera from a high capacity power supply and then feeding any connected accessories via D-Tap or Hirose outputs on the camera is good practice. Also powering everything by batteries helps. If you must use separate power supplies then connect everything together before connecting anything to the mains and before turning anything on. This should ensure that any current runs through the shield and ground paths in the cables rather than possibly travelling down the delicate signal part of a connection as you connect things together.

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

 

Workflow

Notes on Timecode sync with two cameras.

Leave a comment

When you want two cameras to have matching timecode you need to synchronise not just the time code but also the frame rates of both cameras. Remember timecode is a counter that counts the frames the camera is recording. If one camera is recording more frames than the other, then even with a timecode cable between both cameras the timecode will drift during long takes. So for perfect timecode sync you must also ensure the frame rates of both cameras is also identical by using Genlock to synchronise the frame rates.

Genlock is only going to make a difference if it is always kept connected. As soon as you disconnect the Genlock the cameras will start to drift. If using genlock first connect the Ref output to the Genlock in. Then while this is still connected connect the TC out to TC in. Both cameras should be set to Free-run timecode with the TC on the master camera set to the time of day or whatever time you wish both cameras to have. If you are not going to keep the genlock cable connected for the duration of the shoot, then don’t bother with it at all, as it will make no difference just connecting it for a few minutes while you sync the TC.

In the case of a Sony camera when the TC out is connected to the TC in of the slave camera, the slave camera will normally display EXT-LK when the timecode signals are locked.

Genlock: Synchronises the precise timing of the frame rates of the cameras. So taking a reference out from one camera and feeding it to the Genlock input of another will cause both cameras to run precisely in sync while the two cameras are still connected together. While connected by genlock the frame counts of both camera (and the timecode counts) will remain in sync. As soon as you remove the genlock sync cable the cameras will start to drift apart. The amount of sync (and timecode) drift will depend on many factors, but with a Sony camera will most likely be in the order of a at least a few seconds a day, sometimes as much as a few minutes.

Timecode: Connecting the TC out of one camera to the TC in of another will cause the time code in the receiving camera to sync to the nearest possible frame number of the sending camera when the receiving camera is set to free run while the camera is in standby.  When the TC is disconnected both cameras timecode will continue to count according to the frame rate that the camera is running at. If the cameras are genlocked, then as the frame sync and frame count is the same then so too will be the timecode counts. If the cameras are not genlocked then the timecode counts will drift by the same amount as the sync drift.

Timecode sync only and long takes can be problematic. If the timecodes of two cameras are jam sync’d but there is no genlock then on long takes timecode drift may be apparent. When you press the record button the timecodes of both cameras will normally be in sync, forced into sync by the timecode signal. But when the cameras are rolling the timecode will count the actual frames recorded and ignor the timecode input. So if the cameras are not synchronised via genlock then they may not be in true sync so one camera may be running fractionally faster than the other and as a result in long clips there may be timecode differences as one camera records more frames than the other in the same time period.

Uncategorized

The RIGHT way to get good timecode sync with multiple cameras.

6 Comments

So, you have a multi camera shoot and you want to have the timecode in perfect sync between all of the cameras. For a start lets assume we are talking about pro cameras that actually have timecode in and out, because without a way to connect an external timecode source, getting truly accurate TC sync is all but impossible. The other thing you need if you want REAL timecode sync is genlock (or an Arri Alexa with an Ambient Lockit box).

The most common way used to get timecode sync across multiple cameras is to simply connect a timecode source to the timecode in of the cameras. This can be done with cables or wirelessly. This is a method I’ve used many times and it works….. kind of. Actually this is NOT the best way to get good timecode sync, but it’s probably the most commonly used method. It is especially problematic when you have very long takes, say shooting a rock concert without stopping between songs.

Here’s the problem.

When you hit record on the camera the timecode MUST increment by 1 frame every time you record a new frame, regardless of what the timecode on the TC in is doing. Every frame MUST have a unique TC number. So, if the cameras sync clock is running a tiny bit faster or slower than the TC clock of the external source, the cameras TC will slowly drift out of sync with the external TC until you stop recording at which time the cameras TC will re-sync with the external TC. On long takes this may result in a loss of sync between the external TC and the TC generated by the camera. Often this isn’t more than a few frames, but on a music shoot or where you have sync sound, being a few frames out can be a real pain.

Timecode will not synchronise a camera, it will not pull the cameras frame rate into sync with the external TC clock. Unless it is an Arri Alexa and you are using an Ambient Lockit box as Ambient can pull the Alexa’s clock into sync via a special “Tune” pin. The only thing that will alter the cameras actual frame or sync rate is genlock. So if you want the cameras to truly stay in sync you must genlock them to a common sync source.

Now I know that very often this is not possible, especially with remote or mobile cameras. That’s why companies such as Ambient include a sync output that you can connect to the cameras genlock in on their wireless TC boxes, so you can genlock the camera to bring it in to true sync with the external clock as well as feeding it sync TC.

If your working with a single camera and a sound recordist, rather than having the soundie feed TC to the camera, the more accurate way is to use the camera as the TC source and send the TC to the sound recorder. The sound recorder doesn’t have a frame rate as such so the TC does not need to be in sync with the sound recorder in the same way as it should be in sync with the cameras actual frame rate. A sound recorder can have time periods shorter or longer than a frame, a video camera cannot. By sending the TC from the camera to the sound recorder you will eliminate sync drift between the TC and the actual video frame count during longer takes.

I know this is not how it’s done in practice. In most cases TC is sent to the camera and in most cases genlock isn’t used. Probably because this is the easiest way to do things. Most of the time, if the takes are shorter than 10 minutes or so, you won’t see any issues. But if you really want accurate TC over long takes you need to do it properly and either genlock the cameras or use the camera as the TC source on a single camera shoot.