MartinTheMixer Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Nathaniel Robinson Posted June 27, 2016 Report Share Posted June 27, 2016 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". Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
Ze Frias Posted June 27, 2016 Report Share Posted June 27, 2016 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). Quote Link to comment Share on other sites More sharing options...
Shastapete Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Ze Frias Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Shastapete Posted June 27, 2016 Report Share Posted June 27, 2016 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 Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 I'm sorry. But I don't understand you response. You talk about lost frames. I don't know how lost frames fit in this conversation. I understand the camera doesn't lose frames. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
Nathaniel Robinson Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
Shastapete Posted June 27, 2016 Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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.? Quote Link to comment Share on other sites More sharing options...
Johnny Karlsson Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
T_will Posted June 27, 2016 Report Share Posted June 27, 2016 (edited) Gold star Edited June 29, 2016 by T_will post #4 was corrected. #19 comment is no longer relevant Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 Your not being pedantic. Pedantic would be "How many people are their?" and someone says, "I don't know what you mean, do you mean how many people are there?" Another example of pedantic would be explaining a good real world example of the word pedantic. Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 I still don't understand what issue you are addressing? What has happened to bring this up? Do you have an example of a camera not calculating the Tc values correctly when you know they should be different? Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 1 minute ago, MartinTheMixer said: If the frames are accurate, how can there be "drift" inside the camera? How are you seeing "drift" inside the camera? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.