Jump to content

Can a digital camera tc drift WHILE rolling?


Recommended Posts

Hello all, my question is this. Can a digital tc camera, let's pick Red Dragon, or Weapon, tc drift after the record button has been pushed and before the stop button is pushed? So if you are on 25fps, for easier math, then frame 1 gets stamped 0, is there any way for frame 3 to get stamped something other than 74? And yes, I have searched this. If you know of a link that answers this question, please post it. Thank you. If you need to increase the roll time to an hour for discussion purposes, that's fine. 

Link to post
Share on other sites
  • Replies 109
  • Created
  • Last Reply

Top Posters In This Topic

Ambient recently created a very helpful video series on timecode and it's relationship to synchronization. I think the main stumbling block in your scenario above is the use of the term "stamp". In typical application, the timecode stamp exists functionally as a start time in metadata for both audio and video files. So there IS no stamp at frame 3. Drift, however, can and does happen. That issue is discussed in the Ambient video "Synchronization Tutorial".

 

Link to post
Share on other sites
22 minutes ago, Nathaniel Robinson said:

Ambient recently created a very helpful video series on timecode and it's relationship to synchronization. I think the main stumbling block in your scenario above is the use of the term "stamp". In typical application, the timecode stamp exists functionally as a start time in metadata for both audio and video files. So there IS no stamp at frame 3. Drift, however, can and does happen. That issue is discussed in the Ambient video "Synchronization Tutorial".

 

Hello, The second video in that series is the one that discusses this issue. The first one is a basic tutorial on tc. In that second video, ambient states, that in my given scenario, frame 3 IS stamped. I still think that's the damndest  thing that a digital device, one that knows how many frames it just shot, can't properly mark a correct ending tc. Where's Howy? I mean, the camera knows the frame rate. The camera knows how many frames it just shot. How hard can this be?

Link to post
Share on other sites
20 hours ago, MartinTheMixer said:

Hello, The second video in that series is the one that discusses this issue. The first one is a basic tutorial on tc. In that second video, ambient states, that in my given scenario, frame 3 IS stamped. I still think that's the damndest  thing that a digital device, one that knows how many frames it just shot, can't properly mark a correct ending tc. Where's Howy? I mean, the camera knows the frame rate. The camera knows how many frames it just shot. How hard can this be?

Per your example, Frame 3 isn't "stamped". The NLE assumes what the timecode marker for "frame 3" is based on what the start timecode is on the file. This is still irrelevant when it comes to the "speed" at which each frame is created in a camera. Only the camera's internal clock can control that. Hence genlock / tri-level sync. You use an external, master clock, which can control the speed upon which cameras and recorders run, so that they all run with the exact same timing. Timecode still is only an "address," as Ambient cleverly points out, used as a reference to sync all media from that specific point.

 

21 hours ago, MartinTheMixer said:

So if you are on 25fps, for easier math, then frame 1 gets stamped 0, is there any way for frame 3 to get stamped something other than 74?

I don't understand this question. In a 25fps video file, if the start timecode for the file is 01:00:00:00, then once we get to frame 3 on the video file, the timecode marker will be 01:00:00:03. Now, if you mean second 3, then the timecode marker would be 01:00:03:00 (which is 75 frames from the start timecode).

Link to post
Share on other sites

This is the difference between Timecode and GenLock (Blackburst aka Bi-Level sync for SD or Tri-level sync for HD)

Let me give you an analogy of how this works:

Lets say you have a musician, Steve the tuba player, listen to a metronome (LTC timecode) for a few beats to get a feel for the tempo of a song. It is a real durdge and the tempo is 24bpm When he starts playing he no longer listens to the metronome and plays at his best guess of what 24bpm is. When he reaches the end of the song he will not have hit the length of the song perfectly, as Steve's internal 24bpm isn't exact.

Another musician, Lisa the saxophonist, will play the same song but she will listen to the metronome the entire time as a click track (GenLock). Each beat she will hear a click and know when the next beat is supposed to start. Every time Lisa plays the song with a click track it will be the same length. If her friend Eddy, the French horn player, also plays with a clicktrack (GenLock) their parts will sync up.

Sadly, because Steve didn't use a click track (GenLock) his part drifts and doesn't perfectly line up.

Link to post
Share on other sites
2 minutes ago, Shastapete said:

This is the difference between Timecode and GenLock (Blackburst aka Bi-Level sync for SD or Tri-level sync for HD)

Let me give you an analogy of how this works:

Lets say you have a musician, Steve the tuba player, listen to a metronome (LTC timecode) for a few beats to get a feel for the tempo of a song. It is a real durdge and the tempo is 24bpm When he starts playing he no longer listens to the metronome and plays at his best guess of what 24bpm is. When he reaches the end of the song he will not have hit the length of the song perfectly, as Steve's internal 24bpm isn't exact.

Another musician, Lisa the saxophonist, will play the same song but she will listen to the metronome the entire time as a click track (GenLock). Each beat she will hear a click and know when the next beat is supposed to start. Every time Lisa plays the song with a click track it will be the same length. If her friend Eddy, the French horn player, also plays with a clicktrack (GenLock) their parts will sync up.

Sadly, because Steve didn't use a click track (GenLock) his part drifts and doesn't perfectly line up.

Nice analogy.

Link to post
Share on other sites
8 minutes ago, Jose Frias said:

Per your example, Frame 3 isn't "stamped". The NLE assumes what the timecode marker for "frame 3" is based on what the start timecode is on the file. This is still irrelevant when it comes to the "speed" at which each frame is created in a camera. Only the camera's internal clock can control that. Hence genlock / tri-level sync. You use an external, master clock, which can control the speed upon which cameras and recorders run, so that they all run with the exact same timing. Timecode still is only an "address," as Ambient cleverly points out, used as a reference to sync all media from that specific point.

 

I don't understand this question. In a 25fps video file, if the start timecode for the file is 01:00:00:00, then once we get to frame 3 on the video file, the timecode marker will be 01:00:00:03. Now, if you mean minute 3, then the timecode marker would be 01:00:03:00 (which is 75 frames from the start timecode).

I am using the wording from the Ambient video, so it is whatever their definition is of "stamp". I adopt their meaning of the word "stamp". Thank you.

 

12 minutes ago, Shastapete said:

This is the difference between Timecode and GenLock (Blackburst aka Bi-Level sync for SD or Tri-level sync for HD)

Let me give you an analogy of how this works:

Lets say you have a musician, Steve the tuba player, listen to a metronome (LTC timecode) for a few beats to get a feel for the tempo of a song. It is a real durdge and the tempo is 24bpm When he starts playing he no longer listens to the metronome and plays at his best guess of what 24bpm is. When he reaches the end of the song he will not have hit the length of the song perfectly, as Steve's internal 24bpm isn't exact.

Another musician, Lisa the saxophonist, will play the same song but she will listen to the metronome the entire time as a click track (GenLock). Each beat she will hear a click and know when the next beat is supposed to start. Every time Lisa plays the song with a click track it will be the same length. If her friend Eddy, the French horn player, also plays with a clicktrack (GenLock) their parts will sync up.

Sadly, because Steve didn't use a click track (GenLock) his part drifts and doesn't perfectly line up.

That is a wonderful analogy, but Lisa and Steve are not digital. I just got off the phone with Red. All someone has to do is come up with a program inside the camera, that says, we just shot 20,000 frames, the start tc was x, we divide the number of frames by the fps, Bam. There is perfect timecode stamps. You might still have a sync to audio problem, because audio is not locked to frames, because there are no frames, but you would have perfect tc inside the camera.

 

Link to post
Share on other sites
20 minutes ago, MartinTheMixer said:

That is a wonderful analogy, but Lisa and Steve are not digital. I just got off the phone with Red. All someone has to do is come up with a program inside the camera, that says, we just shot 20,000 frames, the start tc was x, we divide the number of frames by the fps, Bam. There is perfect timecode stamps. You might still have a sync to audio problem, because audio is not locked to frames, because there are no frames, but you would have perfect tc inside the camera.

I think you are fundamentally confused about what drift is.

Frames don't get lost or disappear, drift occurs because of the "disagreement" between the length of a frame between different pieces of equipment. The tiny clock inside our recorders, timecode boxes, and slates are typically of better quality (more precise) than those in cameras. Yet we still re-sync everything at lunch because of the inherent limitation of precision electronics. When something "loses 3 frames in a day" it just means the cumulative error in 24 hours puts it 3 frames behind.

The reason cameras are notorious for slipping as they roll is because they only reference the precise clock from the LTC timecode box they are jammed with for information when they press record.

This isn't a digital vs. analog issue, this is a precision issue

Link to post
Share on other sites

May I ask why you care about TC stamps for frames after the first one of a given roll?  NLEs don't--they do the calc from that first frame to where a cut etc is automatically.  And has been pointed out, those TC stamps have nothing to do with maintaining sync to other devices at all.

Link to post
Share on other sites
41 minutes ago, MartinTheMixer said:

I am using the wording from the Ambient video, so it is whatever their definition is of "stamp". I adopt their meaning of the word "stamp". Thank you.

You are still stumbling here. Precision of language is critical to this discussion. Watch the video again, note that it only refers to a STAMP at the file start and end of the file.

Link to post
Share on other sites

How about this? Momma looks in the egg basket for the mornin. She knows she has 4 kids, and she knows each kid got the same amount of eggs from the hens this morning. But the kids didn't tell her how many eggs they each got that morning. So, she looks in the basket and sees 16 eggs. So she now knows each kids got 4 eggs from the hen house. She took 2 known numbers to determine the missing 3rd number. Why can't the camera do that?

4 minutes ago, Nathaniel Robinson said:

You are still stumbling here. Precision of language is critical to this discussion. Watch the video again, note that it only refers to a STAMP at the file start and end of the file.

Yes. That is also my use of the word stamp. Thank you.

 

Link to post
Share on other sites

I haven't explored other video wrappers, but QuickTime supports as many Tc stamps as the creator wishes to write to it.  In other words a QuickTime video will work just fine with a single Tc stamp at the beginning of the file, and the nle will calculate the rest of the frame numbers, but the camera could also stamp a unique Tc value for every frame if it was designed to, and the nle would reference those.   While this does not create drift, if there was a discrepancy between the camera clock and the external Tc clock, or the camera was being fed a  Tc stream that jumps around, it could  cause the camera to essentially skip frame numbers every so often, or re stamp the video file with different tc.  This is of course depending on how the camera software is written. I thought I remembered a black frame issue caused by this on the first gen Alexa's, bu t I could be remembering wrong.

Are you asking about theory?  Or do you have a specific problem you are trying to understand? 

Link to post
Share on other sites
1 minute ago, MartinTheMixer said:

How about this? Momma looks in the egg basket for the mornin. She knows she has 4 kids, and she knows each kid got the same amount of eggs from the hens this morning. But the kids didn't tell her how many eggs they each got that morning. So, she looks in the basket and sees 16 eggs. So she now knows each kids got 4 eggs from the hen house. She took 2 known numbers to determine the missing 3rd number. Why can't the camera do that?

How is this related to the question that you original asked and that we all answered? 

Quote

Can a digital tc camera, let's pick Red Dragon, or Weapon, tc drift after the record button has been pushed and before the stop button is pushed?

 

Link to post
Share on other sites
5 minutes ago, Wandering Ear said:

I haven't explored other video wrappers, but QuickTime supports as many Tc stamps as the creator wishes to write to it.  In other words a QuickTime video will work just fine with a single Tc stamp at the beginning of the file, and the nle will calculate the rest of the frame numbers, but the camera could also stamp a unique Tc value for every frame if it was designed to, and the nle would reference those.   While this does not create drift, if there was a discrepancy between the camera clock and the external Tc clock, or the camera was being fed a  Tc stream that jumps around, it could  cause the camera to essentially skip frame numbers every so often, or re stamp the video file with different tc.  This is of course depending on how the camera software is written. I thought I remembered a black frame issue caused by this on the first gen Alexa's, bu t I could be remembering wrong.

Are you asking about theory?  Or do you have a specific problem you are trying to understand? 

Wandering,, thank you that was a good response. I am not solving a particular problem. Rather I am addressing an issue, that being the camera knows the frame rate, the camera knows what number of frames that it just shot. Using that math one could easily calculate what the current time code SHOULD be. You and I can do that math, why can't a big fancy, expensive, software-driven camera do it.?

 

Link to post
Share on other sites

One thing to keep in mind is that one second of TC is not the same as one second on the atomic clock.

As has been posted out several times above (and in previous other threads on JWS), TC does not control the speed of of the recording, therefore several devices with the same start time code address will drift over time. To remedy this, you need to use gen-lock and word clock, which will keep each frame, no matter how long the recording, aligned with each other.

Link to post
Share on other sites

Johnny, I don't have any reason to doubt any of what you just said. What I am saying is that to solve this equation, which is what the ending time code SHOULD be, the camera should be able to do the math of this is how many frames the camera shot and this is how many frames per second were shot, based on the start tc, here is the ending tc. I asked Red about this, my guess is we are 4 years away from that. Their opinion is that it may not be that long.

Link to post
Share on other sites

Wandering, What I am addressing, is that the computer we call a camera, should be capable of stamping start and stop timecode slate and be accurate. As mentioned earlier, in my conversation with Red, when I guessed that we are four years away from having this technology the Red guess it was possibly less than that. Does this make sense?

Link to post
Share on other sites

No, I still don't get what the "issue" is.  As Phillip correctly pointed out, all you need for accurate Tc is a stamp at the beginning of the file, and whatever device, be it the camera, an nle, or any playback software will calculate accurate frame numbers for every frame of the video.

Link to post
Share on other sites
3 minutes ago, Wandering Ear said:

No, I still don't get what the "issue" is.  As Phillip correctly pointed out, all you need for accurate Tc is a stamp at the beginning of the file, and whatever device, be it the camera, an nle, or any playback software will calculate accurate frame numbers for every frame of the video.

If the frames are accurate, how can there be "drift" inside the camera?

Link to post
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...