One of the cameras I used a lot in Norway is the new Sony FDR-X3000 action cam. What’s different about this POV camera is that the lens and sensor are actually mounted in an internal miniaturised gimbal. This really does work and helps stabilise the image.
There is also a tiny bluetooth monitor that you can wear on your wrist to view the pictures and control the camera. The image quality you get from these tiny cameras really is quite amazing. Take a look at the video to find out more and see some sample footage.
Unfortunately every now and again a new term or buzzword comes along that gets taken as a holy grail term. Two that come to mind right now are log and raw. Neither log, nor raw, are magic bullet solutions that guarantee the best performance. Used incorrectly or inappropriately both can result in inferior results. In addition there are many flavours of log and raw each with very different performance ranges.
A particular point in case is the 12 bit raw available from several of Sony’s mid range large sensor cameras, the FS700, FS7 and FS5.
Raw can be either log or linear. This particular flavour of raw is encoded using linear data. If it is linear then each successively brighter stop of exposure should be recorded with twice as many code values or shades as the previous stop. This accurately replicates the change in the light in the scene you are shooting. If you make the scene twice as bright, you need to record it with twice as much data. Every time you go up a stop in exposure you are doubling the light in the scene. 12 bit linear raw is actually very rare, especially from a camera with a high dynamic range. To my knowledge, Sony are the only company that offer 14 stops of dynamic range using 12 bit linear data.
There’s actually a very good reason for this: Strictly speaking, it’s impossible! Here’s why: For each stop we go up in exposure we need twice as many code values. With 12 bit data there are a maximum of 4096 code values, this is not enough to record 14 stops.
If stop 1 uses 1 code value, stop 2 will use 2, stop 3 will use 4, stop 4 will use 8 and so on.
As you can see from the above if we only have 12 bit data and as a result 4096 code values to play with, we can only record an absolute maximum of 12 stops of dynamic range using linear data. To get even 12 stops we must record the first couple of stops with an extremely small amount of tonal information. This is why most 14 stop raw cameras use 16 bit data for linear or use log encoded raw data for 12 bit, where each stop above middle grey (around stop +8) is recorded with the same amount of data.
So how are Sony doing it on the FS5, FS7 etc? I suspect (I’m pretty damn certain in fact) that Sony use something called floating point math. In essence what they do is take the linear data coming off the sensor and round the values recorded to the nearest 4 or 8. So, stop +14 is now only recorded with 2,048 values, stop +13 with 512 values etc. This is fine for the brighter stops where there are hundreds or even thousands of values, it has no significant impact on the brighter parts of the final image. But in the darker parts of the image it does have an impact as for example stop +5 which starts off with 16 values ends up only being recorded with 4 values and each stop below this only has 1 or two discreet levels. This results in blocky and often noisy looking shadow areas – a common complaint with 12 bit linear raw. I don’t know for a fact that this is what they are doing. But if you look at what they need to do, the options available and you look at the end results for 12 bit raw, this certainly appears to be the case.
Meanwhile a camera like the FS7 which can record 10 bit log will retain the full data range in the shadows because if you use log encoding, the brighter stops are each recorded with the same amount of data. With S-Log2 and 10 bit XAVC-I the FS7 uses approx 650 code values to record the 6 brightest stops in it’s capture range reserving approx 250 code values for the 8 darkest stops. Compare this to the linear example above and in fact what you will see is that 10 bit S-Log2 has as much data as you would expect to find in a straight 16 bit linear recording below middle grey (S-Log 3 actually reserves slightly more data for the shadows). BUT that’s for 16 bit. Sony’s 12 bit raw is squeezing 14 stops into what should be an impossibly small number of code values, so in practice what I have found is that 10 bit S-log has noticeably more data in the shadows than 12 bit raw.
In the highlights 12 bit linear raw will have more data than 10 bit S-log2 and S-Log3 and this is borne out in practice where a brightly exposed raw image will give amazing results with beautiful highlights and mid range. But if your 12 bit raw is dark or underexposed it is not going to perform as well as you might expect. For dark and low key scenes 10 bit S-Log is most likely going to give a noticeably better image. (Note: 8 bit S-log2/3 as you would have from an FS5 in UHD only has a quarter of the data that 10 bit has. The FS5 records the first 8 stops in 8 bit S-log 2 with approx 64 code values, S-Log3 is only marginally better at approx 80 code values. 12 bit linear outperforms 8 bit log across the entire range).
Sony’s F5 and F55 cameras record to the R5 and R7 recorders using 16 bit linear data. 16 bit data is enough for 14 stops. But I believe that Sony still use floating point math for 16 bit recording. This time instead of using the floating point math to make room for an otherwise impossible dynamic range they use it to take a little bit of data from the brightest stop to give extra code values in the shadows. When you have 16,384 code values to play with you can afford to do that. This then adds a lot of extra tonal values and shades to the shadows compared to 10 bit log and as a result 16 bit linear raw will outperform 10 bit log across the entire exposure range by a fairly large margin.
So there you have it. I know it’s hugely confusing sometimes. Not all types of raw are created equal. It’s really important to understand this stuff if you’re buying a camera. Just because it has raw it doesn’t necessarily mean an automatic improvement in image quality in every shooting situation. Log can be just as good or possibly even better in some situations, raw better in others. There are reasons why cameras like the F5/R5 cost more than a FS5/Shogun/Odyssey.
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.
I’ve written about this many times before, but still it comes up again and again. Which is better? Which should I use? I hear all kinds of crazy comments and a lot of incorrect information, so first of all lets dispel a few myths:
S-Log2 captures more dynamic range than S-Log3, it goes to a higher level on the waveform, S-Log3 clips the highlights sooner.
On most of Sony’s current cameras S-Log2 and S-Log3 both currently record exactly the same dynamic range as this is limited by the sensors that Sony are using. The S-log3 curve could be used in a future camera to capture up to 16 stops and in fact the new Venice camera records over 15 stops. But as all of Sony’s other cameras sensors can only see 14 stops and the S-Log3 curve is designed to go beyond 14 stops, stop No. 14 is not recorded all the way at the top of the recording range. S-Log2 is a 14 stop maximum curve, so the peak level is recorded right at the top of the recording range. There is no space held in reserve for anything beyond 14 stops.
In Sonys current camera range (other than Venice) the limit is 14 stops whether it’s S-Log2 or S-Log3. The chart that Sony provide showing both S-Log2 and S-Log3 is a little confusing as it shows the entire gamma curve rather than what the camera can actually “see”. In their current implementations both curves stop at +6 stops over middle grey, both capture the same dynamic range, there is no difference.
S-Log2 is brighter than S-Log3 so it must be capturing highlights better.
No, not really, see above. Playback and on screen brightness comes from the levels chosen to record something at and is dependant on the shape and range of the gamma curve. But the actual captured range is dependant on what the sensor can cope with. As we are not changing the sensor, the captured dynamic range, brightness range and shadow range does not change between S-Log2 and S-log3, both of which take the entire sensor range (they just store that same range using slightly different levels or code values). After applying a LUT or other conversion to your normal viewing gamma both S-Log2 and S-log3 will have the same brightness, same highlight and same shadow range.
S-Log3 has noisy shadows.
No, not really. Shadows appear noisy with S-Log3 as the shadow part of the curve is stored using higher code values compared to S-Log2. So when you view S-Log3 uncorrected the shadows are raised and stretched on your conventional monitor and this gives the impression of a noisy picture. In reality once you restore the levels to normal there is no additional noise. See this article for a full explanation.
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-Log record to different peak levels.
S-Log3 is newer than S-Log2 so it must be better.
Newer, perhaps not. Better, no not really. S-Log3 is based on the industry standard Cineon log gamma curve. This curve was developed in the 1980’s to allow the digitising of film using 10 bit data. So S-Log3 matches a curve designed to work with negative film and is capable of storing more than the 14 stops that most of the current cameras sensors can see. In effect it is an old log gamma curve. As it is a curve designed for more than 14 stops, when used in a 14 stop camera some of the available recording data is empty and wasted.
S-Log2 was specifically designed by Sony to work with an electronic sensor with 14 stops of dynamic range and is optimised to match the performance characteristics of video sensors. By using a 14 stop curve with a 14 stop camera almost every bit of available data is utilised, there is no wastage. So S-Log2 makes better use of the data you have available to you,
BUT THERE ARE SOME OTHER FACTORS WE NEED TO CONSIDER.
S-Log2 and S-Gamut:
As well as the gamma curve we also have different Gamuts or color ranges. S-Log2 was originally designed for the F65 camera. The F65 sensor can capture a huge color range beyond the range that most conventional video sensors can see. So as well as S-Log2 Sony introduced S-Gamut which was matched to the very wide color range of the F65 sensor. S-Log2 is designed to be used with S-Gamut. But many of the cameras we use, like the FS7, F5, FS5 cannot see this color range (Sony’s F55 and Venice can). In addition this very large color range can be a little tricky to deal with in post production. Add to this the fact that S-Log2 is quite different to the quite common Cineon gamma curve and behaves differently to other curves in post. The end result was that in the early days of S-Log2 there were a number of complaints and comments that Sony’s S-log2 material was difficult to grade.
S-Log3 and S-Gamut3.
Because some people were struggling a bit with S-Gamut and S-Log2 in post production (Resolve and many of the other tools we have today were not as well developed 4 years ago), Sony introduced S-Gamut3 and S-log3 as well as a further Gamut called S–Gamut3.cine. S-Log3 was based on Cineon as that’s what people were familiar with. Arri’s Log-C is also based on Cineon as are many other log curves. This makes it a more “familiar” grading experience for many colorists. In addition Sony created a modified version of the super large S-Gamut to make it easier to grade. S-Gamut3 is just as big as S-Gamut but some tweaks inside make it easier to grade (fewer color shifts). At the same time Sony realised that most users were producing content for TV, the web or digital cinema that had little use for the huge color range of S-Gamut/S-Gamut3. So S-Gamut3.cine was developed as a smaller, more manageable version of S-Gamut3 and it incorporated a few tweaks to the color science to provide colors closer to those used by other manufacturers. S-Gamut3.cine is also a better match for cameras with sensors that cannot see the full S-Gamut range (like the FS5, FS7, F5, A7).
The end result is that in general most people prefer or find it easier to grade S-Log3/S-Gamut3.cine material than S-Log2/S-Gamut. Plus you can often use LUT’s designed for Log-C or Cineon with S-log3 material (this isn’t optimum, but it can work).
SGamuts Compared.
Getting the data from camera to post.
In terms of getting the data from your cameras sensor in to post production S-Log2 is the better choice (unless you have a Sony Venice which only has S-Log3). S-Log2 is optimised for the way an electronic sensor works. S-log3 is essentially a curve designed for negative film applications, not video and no matter how you look at it, these are electronic video cameras. However, if you are recording 10 bit or greater you have a lot of data whichever curve you use, so in practice it will be rare to see any difference in the final result.
So use the curve you find easiest to work with. It is true that S-Log 3 allocates a little more data to the shadows and less to the highlights than S-Log2, but don’t confuse data and code values with more range. S-Log3 has a few extra code values in it’s darkest stops, S-log2 has a few extra in the bright stops, but the dynamic range, highlight and shadow handling is governed by the sensor not the gamma curve. Overall S-Log3 has fewer code values than S-Log2, S-Log2 makes better use of the data available, but with 10 bit this really isn’t going to make a huge difference.
8 Bit Recording.
But if you are only recording with an 8 bit codec you are already at a disadvantage. When recording 8 bit you really need to maximise the way what little data you have is used. For that reason I will always recommend that S-Log2 is used when recording 8 bit on a camera like the FS5 in UHD or A7s or similar (FS5 is 10 bit in HD). By using S-Log2 you are using as many of the limited code values available as you can. This doesn’t mean you can’t use S-log3, it just wouldn’t be my choice.
The end result should be the same.
At the end of the day, if you were to use matching LUTs, S-log2 and S-log3 material should look more or less exactly the same after grading or application of the LUT, no matter what the scene you are shooting. If they do look significantly different then you are doing something wrong. So your choice of curve, other than for 8 bit recordings will most likely come down to ease of use rather than anything else.
If your camera doesn’t have LUT’s then S-Log2 can be easier to work with as it is more contrasty. This makes it a bit easier to focus and also makes it easier to gauge exposure. If your camera has LUT’s and you use them, then you may decide to use S-Log3 simply because you should find it a little easier to work with in post. Either way both curves capture the same range of picture information and both should give more or less the same end result.
There may be some very, very subtle differences due to the small differences in data distribution, but often these will be hard to really see in the final image.
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.
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.
If you are running the latest Mac Sierra OS the recent Pro Video Formats update, version 2.0.5 adds the ability to play back MXF OP1a files in Quick Time Player without the need to transcode.
Direct preview of an XAVC MXF file in the finder of OS Sierra.
You can also preview MXF files in the finder window directly! This is a big deal and very welcome, finally you don’t need special software to play back files wrapped in one of the most commonly used professional media wrappers. Of course you must have the codec installed on your computer, it won’t play a file you don’t have the codec for, but XAVC, ProRes and many other pro codecs are include in the update.
At the moment I am able to play back most MXF files including most XAVC and ProRes MXF’s. However some of my XAVC MXF’s are showing up as audio only files. I can still play back these files with 3rd party software, there is no change there. But for some reason I can’t play back every XAVC MXF file directly in Quicktime Player, so play as audio only. I’m not sure why some files are fine and others are not, but this is certainly a step in the right direction. Why it’s taken so long to make this possible I don’t really know, although I suspect it is now possible due to changes in the core Quicktime components of OS Sierra. You can apply this same Video Formats update to earlier OS’s but don’t gain the MXF playback.
A very common question that comes up a lot in the workshops that I run is how do I check the calibration of my viewfinder? I wrote up a guide to this some time back, so in case you haven’t seen it, here is a link to the post: https://www.xdcam-user.com/2012/06/calibrating-your-viewfinder-or-lcd/
So, as you should have seen from my earlier post Sony has included Rec-2020 as a colorspace in custom mode on the new FS7 II. But what does this mean and how important is it? When would you use it and why?
Recommendation ITU BT.2020 is a set of standards created by the International Telecommunications Union for the latest and next generation of televisions. Within the standard there are many sub-standards that define things such as bit depth, frame size, frame rates, contrast, dynamic range and color.
The colorspaces that Sony’s cameras can capture.
The Rec-2020 addition in the the FS7 II specifically refers to the color space that is recorded, determining the range of colors that can be recorded and the code values used to represent specific tones/hues.
First of all though it is important to remember that the FS7 II shares the same sensor as the original FS7, the FS5 and F5. Sony has always stated that this sensor is essentially a “709” sensor. The sensor in Sony’s PMW-F55 can capture a much greater color range (gamut) than the F5, FS5 and FS7, only the F55 can actually capture the full Rec-2020 color space, the FS7 II sensor cannot. It’s very difficult to measure the full color gamut of a sensor, but from the tests that I have done with the F5 and FS7 I estimate that this sensor can capture a color gamut close to that of the DCI-P3 standard, so larger than Rec-709 but not nearly as large as Rec-2020 (I’d love someone to provide the actual color gamut of this sensor).
So given that the FS7 II’s sensor can’t actually see colors all that far beyond Rec-709 what is the point of adding Rec-2020 recording gamut as the camera can’t actually fill the recording Gamut? Similarly the F5/FS5/FS7 cannot fill S-Gamut or S-Gamut3.
The answer is – To record the colors that are captured with the correct values. If you capture using Rec-709 and then play back the Rec-709 footage on a Rec-2020 monitor the colors will look wrong. The picture will be over saturated and the hues slightly off. In order for the picture to look right on a Rec-2020 monitor you need to record the colors at the right values. By adding Rec-2020 to the FS7 II Sony have given users the ability to shoot Rec-2020 and then play back that content on a Rec-2020 display and have it look right. You are not capturing anything extra (well, maybe a tiny bit extra), just capturing it at the right levels so it at least looks correct.
As well as color, Rec-2020 defines the transfer functions, or gamma curves to you and me, that should be used. The basic transfer function is the same as used for Rec-709, so you can use Rec-709 gamma with Rec-2020 color to get a valid Rec-2020 signal. For full compatibility this should be 3840×2160 progressive and 10bit (the Rec-2020 standard is a minimum of 10bit and as well as 3840×2160 also includes 7680×4320).
But, one of the hot topics right now in the high quality video world is the ability to display images with a much greater dynamic range than the basic Rec-709 or Rec-2020 standards allow. There is in fact a new standard called Rec-2100 specifically for HDR television. Rec-2100 uses the same colorspace as Rec-2020 but then pairs that bigger colorspace with either Hybrid Log Gamma or ST2084 gamma, also know as PQ (Perceptual Quantiser). As the FS7 II does not have PQ or HLG as gamma curves you cannot shoot material that is directly compatible with Rec-2100. But what you can do is shoot using S-Log2/S-Log3 with S-Gamut/S-Gamut3/SGamut3.cine which will give you the sensors full colorspace with the sensors full 14 stop dynamic range. Then in post production you can grade this to produce material that is compatible with the Rec-2100 standard or the Rec-2020 standard. But of course you can do this with an original FS7 (or F5) too.
So, when would you actually use the FS7 II’s Rec-2020 colorspace rather than S-Log/S-Gamut?
First of all you don’t want to use it unless you are producing content to be shown on Rec-2020 displays. Recording using Rec-2020 color gamut and then showing the footage on a Rec-709 display will result in washed out colors that don’t look right.
You would probably only ever use it if you were going to output directly from the camera to a monitor that only supports Rec-2020 color or for a project that will be specifically shown on a standard dynamic range Rec-2020 display. So, IMHO this extra colorspace is of very limited benefit. For most productions regular Rec-709 or S-Log/S-Gamut will still be the way forward unless Sony add Hybrid Log Gamma or PQ gamma to the camera as well. Adding HLG or PQ however has problems of it’s own as the existing viewfinders can only show standard dynamic range images, so an external HDR capable monitor would be needed.
Rec-2020 recording gamut is a nice thing to have and for some users it may be important. But overall it’s not going to be a deal breaker if you only have a standard FS7 as the S-Log workflow will allow you to produce Rec-2020 compatible material.
The diminutive but incredibly bright Stella 1000 from Light & Motion.
I have been loaned a set of 4 Stella lights to test. I have the Stella 1000, 2000, 5000 Pro and 7000 Pro to play with and test. I’m going to take a quick look at the 1000/2000 now and will write up the 5000/7000 in a later article. These lamps are made by Californian company Light & Motion (www.lightandmotion.com) and I have to admit that this is a new brand to me. The portable lighting market is full of many different lights from different manufacturers, so it’s a tough market to stand out in. However these lights really do stand out from the crowd for many different reasons.
Build Quality: If you are going to stick a light on the top of a news camera it had better be tough. It’s going to get bumped, bashed, knocked and generally have a tough life. The Stella lamps are all beautifully made. The bodies are made from a very robust feeling plastic material while the lamp surround is made out of anodised aluminium that acts as a heatsink to keep the lamps cool. They have been built to withstand being dropped onto concrete from 1m multiple times without breaking and while I haven’t actually tested this, I do believe that they would survive this and the rigours of life on top of an ENG camera.
The slightly larger Stella 2000 lamp.
Power: The lamps have built in high capacity batteries. You don’t need to buy batteries or run the lamps of the cameras batteries. The internal battery in the Stella 1000 will run it for an hour on full power and around 7 hours at low power. The brighter 2000 will give about 50 mins at full power and 6 hours on low power. If you want longer run times you can attach an adapter to run the lamp from an external power source. Re-charging is fast at a little under 2 hours from flat and you can pack these in the hold of an aircraft as the battery is installed internally and under the current restrictions for Li-Ion batts on aircraft.
Control: The lamps have a built in dimmer that allows you to select one of 6 different brightness levels. Being LED units there is no color temperature change as you dim the lamps. The dimmer control can be locked in the off position to prevent accidental operation, plus the lamps have a thermal cutoff to prevent damage if left on by mistake when covered or perhaps packed in your luggage. There are 3 LED’s that indicate the batter state and dimming level.
Dimming and power control of the Stella 2000 portable video light.
High Quality Light: Instead of the more common LED panel design with an array of a large number of small LED’s the Stella’s feature a single high power Chip 5000K LED. This gives a beam angle of 120 degrees and the light is very uniform across this entire spread. The lamp heads are designed to take modifier lenses that can be used to reduce the beam spread to 50 degrees and 25 degrees if you need more of a spot light. I used the 25 degree fresnel adapter to turn the Stella 1000 to a mini spot light and it was very effective.
The high intensity 90 CRI/90 TLCI chip LED of the Light & Motion Stella 2000
The quality of the light from these lamps is very good. The have a CRI of 90 as well as a TLCI of 90. They are also flicker free so suitable for shooting at high frame rate. In use I found the lamps gave great skin tone rendition and I didn’t see any of the green cast that is often common with lower quality LED lamps.
These are surprisingly bright lamps. The Stella 1000 is 1000 lumens and surprise, surprise, the Stella 2000 is 2000 lumens. That’s one heck of a lot of light from such a small and compact unit. Everyone that I have shown these lights to has been impressed by the intensity of the light output. The Stella 1000 is similar to a 75W tungsten lamp and the 2000 close to a 200W tungsten lamp. As the Stella’s are daylight balanced if you are using them as a fill light when shooting into the sun there is no need to gel them as you would with a tungsten light. Add to that the ability to use a clip on fresnel lens to narrow the beam angle and you are approaching the performance of 300W gelled tungsten fresnel fixture but with a compact battery operated lamp. I would consider the Stella 2000 as a replacement for an Arri 300 fresnel in many applications.
Waterproof! The Stella 1000 and 2000 are waterproof! Not just shower and splash proof, but completely waterproof. They can be operated underwater at depths of up to 100m with needing to buy any extra seals or fit any bungs or plugs. I know that when I shooting in adverse weather conditions this will be a big deal as normally the camera will have a nice fitted cover, but the top light is almost always left exposed to the elements. Now I don’t need to worry.
Light and Motion have a wide range of accessories for these lamps including all kinds of different mounts and handles. As well as the usual barn doors there are some clever light modifiers including the clip on 25 degree fresnel lens, a clip on 50 degree lens, a clip on diffuser, gel holder and glo bulb.
So far I have been really impressed by what these small lamps can do. They may not have variable color temperature, but the consistency and quality of the light they produce is amazing. The companies tag line is “Beyond Bright” and I’m inclined to agree.
I’ve also been loaned the Stella 5000 Pro and 7000 Pro to test. I’ll be writing about these beauties in the coming weeks!
Manage your privacy
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
A very common question that comes up a lot in the workshops that I run is how do I check the calibration of my viewfinder? I wrote up a guide to this some time back, so in case you haven’t seen it, here is a link to the post: 
