Jump to content

Can a digital camera tc drift WHILE rolling?


MartinTheMixer

Recommended Posts

  • Replies 109
  • Created
  • Last Reply

Top Posters In This Topic

Well, If you set the timecode in the camera, and you come back after X amount of time, and that time is no longer accurate, that would be what I would call a "drift".

 

1 minute ago, Johnny Karlsson said:

Because Time Code does not specify the speed of the camera, nor of any other device. 

Don't call it time code, just call it time. 

Link to comment
Share on other sites

17 minutes ago, MartinTheMixer said:

Well, If you set the timecode in the camera, and you come back after X amount of time, and that time is no longer accurate, that would be what I would call a "drift"

That sounds like you are comparing time code to the wall clock, correct?   Unless you're running drop frame the Tc value will always differ from the wall clock.

Link to comment
Share on other sites

5 minutes ago, Wandering Ear said:

That sounds like you are comparing time code to the wall clock, correct?   Unless you're running drop frame the Tc value will always differ from the wall clock.

That's a good response. In a real world event that did happen, I had Red Dragon that was gaining many frames in way under an hour. That was while NOT rolling. I have no idea what the drift was while it was rolling. I was afraid to look.

But I hope you understand hear what the issue is. Inside any digital camera that has time code, apparently, if you rolled let's say for an hour, you could have and ending timecode that does NOT compute with how much timecode has elapsed.

 

Link to comment
Share on other sites

5 minutes ago, MartinTheMixer said:

That's a good response. In a real world event that did happen, I had Red Dragon that was gaining many frames in way under an hour. That was while NOT rolling. I have no idea what the drift was while it was rolling. I was afraid to look.

But I hope you understand hear what the issue is. Inside any digital camera that has time code, apparently, if you rolled let's say for an hour, you could have and ending timecode that does NOT compute with how much timecode has elapsed.

The ending time code would compute with how much TIMECODE has elapsed, but not how much TIME has.  After a 1 hour clip, you would have time code that does not equal 1 hour, because NTSC time code runs at a rate that is .1% slower than real time.  At 23.98, if you roll a clip for an hour your finishing TIMECODE would be 00:59:56:09, while the wall clock has elapsed exactly 1 hour.

So it sounds like you are confusing elapsed TIMECODE with elapsed TIME.

What frame rate were you at when you were checking?

Link to comment
Share on other sites

7 minutes ago, Wandering Ear said:

The ending time code would compute with how much TIMECODE has elapsed, but not how much TIME has.  After a 1 hour clip, you would have time code that does not equal 1 hour, because NTSC time code runs at a rate that is .1% slower than real time.  At 23.98, if you roll a clip for an hour your finishing TIMECODE would be 00:59:56:09, while the wall clock has elapsed exactly 1 hour.

So it sounds like you are confusing elapsed TIMECODE with elapsed TIME.

What frame rate were you at when you were checking?

I'm aware of everything you just typed. Is your question "What frame rate were you at when you were checking?" In relation to my statement about the Red Dragon that I mentioned above being many frames out in under an hour?

Link to comment
Share on other sites

4 hours ago, MartinTheMixer said:

Phillip, Thank you. That is my point. Let's forget about code being time for a minute. Let's say the camera assigns just frame numbers 1-20000. Ok, so the camera also know it shot at 24 fps. Why is it so hard for that camera to properly assign numbers correctly?

I don't think it would be all that hard for a programmer if that's all you wanted.  But no one seems to want this re post, and if you did it you would end up with nonstandard files....  An NLE can tell you how many frames long a shot is, if you want to know, and I think some of the DIT apps like Shotput or Resolve might too?

Link to comment
Share on other sites

I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed.

Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second.

Link to comment
Share on other sites

14 minutes ago, Derek H said:

I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed.

Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second.

Because the accuracy of measuring the incoming timecode signal would be no better than the accuracy of the camera free-running.

If you do it once just to get the speed, how long do you measure over? - you'll need many (tens of) seconds of stable TC to get a good lock.

If you can design the camera to modulate its frame rate in real time to keep up with the tiny variations as time goes on, you could get it to work, but the rest of the camera is not going to behave well...    

At TASCAM we designed such systems in the MMR series and X-48 recorders, because there is a niche need to lock to analogish and film systems, but the future is in (rock) stable frame rates.  

Also, black burst or trisync video is usually fed in as well, negating the need to rely on the LTC input's jitter.  For a camera system without BB, you just create more problems.

Link to comment
Share on other sites

42 minutes ago, Derek H said:

I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed.

Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second.

Ok, we're getting somewhere. This is more like it.

Link to comment
Share on other sites

1 hour ago, MartinTheMixer said:

Ok, we're getting somewhere. This is more like it.

Hi Martin,

puts on pedants hat. When a recorder (be it a recorder of pictures, or sound) makes a file - it puts a bunch of info in the file header. This info is referred to as metadata. In the case of audio files, the 'time' value, at the start of the file, is actually calculated from a counter that counts the samples after midnight, so, the first sample that the recorder counts, at midnight on the dot, is number 1, and the sample number about a second later is number 48001 (forty eight thousand and one), assuming you are running the recorder at 48k, ie forty eight thousand samples per second. I say the value at 'about' a second later, as the recorder runs its internal clock at 'a speed'. Its idea of a second might be slightly longer or shorter than that of any other piece of kit, or of an actual second.

So - a camera might be running slightly faster than a recorder, or vice versa. If they both run for what each of them thinks is an hour, one may have recorded slightly more material than the other. If you subsequently play both back at the same speed, then one will drift with respect to the other.

If the camera is running slightly faster or slower than 'actual' time, then when you play back the footage at a different rate (the difference may look tiny, like 0.001%) it will take a different amount of time to play it back than it did to record it.

Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames.

To my knowledge a modern video camera does not 'record' a TC value for each frame of video. It calculates the value for each frame, using the frame value at the start, and the number of frames into the clip that you are interested in. That value may be different to the real world if the camera 'counts' seconds at a different rate to other devices around it.

Say you and I each save a similar sized pizza. Say I cut mine into 10 slices and you cut yours into 8. If we each swap one slice of pizza, and try to fit the swapped slice into each others' pizzas, your pizza will now have a gap, and mine will have an overlap - the slices don't fit. If the camera and the audio recorder (or another camera, or an edit suite, or whatever device) do not run their own clocks at the same speed/rate, then they are shooting different 'sized' slices of time.

Hence the whole genlock thing - genlock allows us to get all the different clocks to tick at the same rate, they all start a sample, or frame, or second, at the same time, and then they count at the same 'rate'. in this way all the seconds, frames, slices, etc.. are the same 'size', and the world turns effortlessly ;-)

I hope that some of the above helps......

Simon B

Link to comment
Share on other sites

 

5 hours ago, Derek H said:

I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed.

Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second.

There are some devices that can use TC to drive their sample clocks, but in general it is frowned on as being not a very accurate way to go.  Per several discussions here over the years, SD and Zax recorders, for instance, do not allow this, Tascam HDP2 and I believe Zoom F8 do (as do some MOTU interfaces like Traveler).   It's been a handy thing for me when it was avail.  I would like to see that article re the Alexa allowing its clock to be really driven by external TC--I hadn't heard about this and it would be very unusual (unprecedented) for a video camera to work this way.  So far the tout on Arri video cams is that their clock is as accurate as the clock in a pro file based audio recorder, so feeding the camera genlock in addition to TC is unnecessary (in a pure non-combat sense).

Link to comment
Share on other sites

3 hours ago, Bash said:

Hi Martin,

puts on pedants hat. When a recorder (be it a recorder of pictures, or sound) makes a file - it puts a bunch of info in the file header. This info is referred to as metadata. In the case of audio files, the 'time' value, at the start of the file, is actually calculated from a counter that counts the samples after midnight, so, the first sample that the recorder counts, at midnight on the dot, is number 1, and the sample number about a second later is number 48001 (forty eight thousand and one), assuming you are running the recorder at 48k, ie forty eight thousand samples per second. I say the value at 'about' a second later, as the recorder runs its internal clock at 'a speed'. Its idea of a second might be slightly longer or shorter than that of any other piece of kit, or of an actual second.

So - a camera might be running slightly faster than a recorder, or vice versa. If they both run for what each of them thinks is an hour, one may have recorded slightly more material than the other. If you subsequently play both back at the same speed, then one will drift with respect to the other.

If the camera is running slightly faster or slower than 'actual' time, then when you play back the footage at a different rate (the difference may look tiny, like 0.001%) it will take a different amount of time to play it back than it did to record it.

Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames.

To my knowledge a modern video camera does not 'record' a TC value for each frame of video. It calculates the value for each frame, using the frame value at the start, and the number of frames into the clip that you are interested in. That value may be different to the real world if the camera 'counts' seconds at a different rate to other devices around it.

Say you and I each save a similar sized pizza. Say I cut mine into 10 slices and you cut yours into 8. If we each swap one slice of pizza, and try to fit the swapped slice into each others' pizzas, your pizza will now have a gap, and mine will have an overlap - the slices don't fit. If the camera and the audio recorder (or another camera, or an edit suite, or whatever device) do not run their own clocks at the same speed/rate, then they are shooting different 'sized' slices of time.

Hence the whole genlock thing - genlock allows us to get all the different clocks to tick at the same rate, they all start a sample, or frame, or second, at the same time, and then they count at the same 'rate'. in this way all the seconds, frames, slices, etc.. are the same 'size', and the world turns effortlessly ;-)

I hope that some of the above helps......

Simon B

Simon, that was all great. I will read that a few more times after I have slept. Thank you.

P.S. Not that we what you wrote is making me sleepy.

Link to comment
Share on other sites

9 hours ago, MartinTheMixer said:

Simon, that was all great. I will read that a few more times after I have slept. Thank you.

P.S. Not that we what you wrote is making me sleepy.

This (quite excellent) explanation has been given before, and similar analogies made, in this very same thread, particularly by Peter (shastapete). To break down some of the terms further:

Timecode = value or "address" assigned to the file being created indicating a particular moment in time, usually the very start of the file.

Drift = the difference in speed between two or more devices after a certain length of  time.

Genlock = a mechanism used to control the speed of two or more devices so that they run at the exact same speed, and so that there is no drift.

Link to comment
Share on other sites

12 hours ago, Bash said:

Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames.

Everyone keep your hats on for one more moment! Within Simon B's excellent and thorough explanation is one simple mathematical error. 90 frames out of 90,000 would be 0.1% drift (or a multiplication factor of 0.001, which is likely the mix up).

Link to comment
Share on other sites

14 hours ago, Philip Perkins said:

 

 I would like to see that article re the Alexa allowing its clock to be really driven by external TC--I hadn't heard about this and it would be very unusual (unprecedented) for a video camera to work this way.

Hi Phil, 

I'm bad at screenshots but download the Alexa mini user manual and read page 70. Seems to indicate that you can use LTC as a genlock signal. The mini does not have a dedicated genlock input connector.

https://www.arri.com/support/downloads/?suchoption1_id=Camera/35_Format_Digital_Camera/ALEXA_Mini

Link to comment
Share on other sites

8 hours ago, Jose Frias said:

This (quite excellent) explanation has been given before, and similar analogies made, in this very same thread, particularly by Peter (shastapete). To break down some of the terms further:

Timecode = value or "address" assigned to the file being created indicating a particular moment in time, usually the very start of the file.

Drift = the difference in speed between two or more devices after a certain length of  time.

Genlock = a mechanism used to control the speed of two or more devices so that they run at the exact same speed, and so that there is no drift.

Jose, I am ok with everything you just said, except the "drift" part. I call a device that can't maintain its own time code, drifting. What do you call that?

 

7 hours ago, Nathaniel Robinson said:

Everyone keep your hats on for one more moment! Within Simon B's excellent and thorough explanation is one simple mathematical error. 90 frames out of 90,000 would be 0.1% drift (or a multiplication factor of 0.001, which is likely the mix up).

Thanks for that. I am going to digest his message when I have time. I liked it the first time I read it.

Link to comment
Share on other sites

1 hour ago, Philip Perkins said:

No it doesn't.  I will ask my cam rental house buds about this--I'd really like to know.  Thanks for the link.

Page 127 & 128 also elaborate on setting the Genlock source to timecode in.

Maybe this means the timecode Lemo can be double duty and serve as a genlock input if you feed the Lemo tri-level signal but the way the manual reads it seems to want you to input LTC timecode to the Lemo for this option. 

Maybe I'll email Arri to clarify what the implications of this are. The manual also states that a hardware modification is required to use the RET/SYNC IN genlock option. I'm guessing that means if you want to use a real tri-level signal they need to modify one of the BNC connectors to be a dedicated genlock input.

Link to comment
Share on other sites

5 minutes ago, al mcguire said:

>I call a device that can't maintain its own time code, drifting. What do you call that?<

I call it a machine doing it's own thing.  

I really do not know what this discussion is about, if you want the devices to stay in sync use a sync box, simple.

 

Al, I don't think that you were here for the part. If that were the case then two devices don't match are they each doing their "own thing". If a clock is not keeping the correct time I would call that drifting. 

Link to comment
Share on other sites

Al, I don't think that you were here for the part. If that were the case then two devices don't match are they each doing their "own thing". If a clock is not keeping the correct time I would call that drifting. 

But how would you know it's drifting?

If you compare to another clock, how would you know it's not the other one drifting? If you only have one clock, would the drift matter?

Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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


×
×
  • Create New...