-
Can we perhaps hold the triumphalism …?
-
A person who enjoys discussing Expressionism does not necessarily want to burn all the works of the Old Masters.
As usual, some just wanted to push back – which is fine. Others were more interested in looking at what it might mean to push forward.
To me that’s more interesting because I know what’s always worked – but discussing what might work even better in the future is how progress starts to happen.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
[Bill Davis] “A person who enjoys discussing Expressionism does not necessarily want to burn all the works of the Old Masters.
As usual, some just wanted to push back – which is fine. Others were more interested in looking at what it might mean to push forward.
“I think people are just trying to figure out what exactly you are talking about because other than SMPTE TC is old, GPS is new and we can do better than using something that’s old, you haven’t added much depth to the discussion other people are trying to have with you about a topic that you brought up.
[Bill Davis] “If that’s where I’ve got to work, there is nothing wrong with realizing that it would be swell if there was a higher level time signal available that made them ALL easy to deal with without the modern version of blacking and pre-striping tapes as I wasted hours doing in the 80s.”
Okay, so how do you envision this higher level time signal working out? Do the devices have internal clocks capable of generating SMTPE TC and GPS can be used an alternative way to jam sync them? Do the devices have *no* internal clocks and are solely reliant on GPS to give them a clock signal which is then converted, by the device, into SMPTE TC? Is SMTPE metadata no longer part of the picture at all and some other form of metadata is created to take its place?
-
My heavens this is NOT that difficult to understand.
You presumably carry a device in your pocket called a cel phone. It keeps perfect time. It does that by internal time chips that might drift fractionally, but the central system resets them as needed. So they are always scrupulously accurate – providing they are anyplace on the planet that gets a carrier signal. So the ENTIRE developed world is good to go. They also largely have attendant tech like Bluetooth and nearfield – that makes it trivial to TALKbto other devices.
If camera manufacturers do nothing else than what a GoPro or iPhone already does and enable wifi or Bluetooth or something similar, the whole problem disappears!
You want classic SMPTE? Just have the powered up camera take a time reset from whatever device is nearby every 10 min and BINGO – TC drift is GONE. Everybody can free run and the world goes on. If you have a fetish for having your little encampment reset to some arbitrary Zero – have at it. Jam sync your socks off and work old school. That’s FINE. Nobody cares. Every device works EXACTLY as it does right now – except it’s easier and more accurate since SOMETHING is keeping ALL the cameras, phones and devices precisely to the same standard.
And those of us flying into a time zone in the afternoon that’s 3 hours ahead of the one we woke up in? Who cares? The phones already are smart enough to understand that and reset themselves! Which means they are already smart enough to apply offsets to capture time sync data that is FLEXIBLE.
Nobody is trying to take away your precious 1950s flashing numbers dude.
I just want the system to grow up into perhaps where we’ve been in time management since my cable box could reset itself for accuracy? Which its been doing for maybe a decade now?
Like most people I cut the cord on land line personal telephony some years ago.
Perhaps it’s time to consider the feasibility of cutting the “house clock” BNC cable as well?
Not because it’s stopped working at all, but because maybe there is actually a better way to link into the changes society already has in their pockets and purses?
Is that too much to ask?
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
[Bill Davis] “providing they are anyplace on the planet that gets a carrier signal. S”
Would that involve a contract with a carrier to get your timecode $20 a month for 1000 timecode minutes or $50 for unlimited 🙂
-
[Bill Davis] “Perhaps it’s time to consider the feasibility of cutting the “house clock” BNC cable as well? “
One thing that I haven’t heard come up, and forgive me if I missed it, but tc and clock time are different. Tc and cameras do not run in real time. An hour of 23.98 video is not really an hour. An hour of 29.97 video is not really an hour. The real time is closer to an hour and three seconds. If you were to introduce a clock running at a different speed than the video, how do you keep sync? What if you start a recoring, and two hours later, you’re six seconds off of ‘real time’? How do you keep sync with other devices? If you have multiple cameras, one runs for two hours straight, another is starting and stopping, their timing is going to be off, how do you sync them? If you want have a ‘global house clock’ you have to make sure all devices are running st that speed, which means you have to get rid of fractional frame rates and all that it entails, which I would imagine would halt all of NTSC broadcast.
Eng P2 camera have had GPS modules for a long time. P2 has GPS metadata built in (although it’s for position data, not time). As far as I know, there’s no way to sync two of those cameras together via GPS because it is an inaccurate clock for NTSC based video, and woefully inadequate for 23.98 productions as there’s no DF standard on most 23.98 devices.
I’m all for a better system which I hope would also be reliable, but you have to take in to account the entire infrastructure. We will drag the NTSC legacy for a long while yet.
-
[Steve Connor] “Would that involve a contract with a carrier to get your timecode $20 a month for 1000 timecode minutes or $50 for unlimited :)”
Cell phone networks use various sources (not just GPS) of extremely accurate time. It’s called mobile backhaul synchronization. I don’t know how much of that is available via cellular metadata, however there are various internet-based sources of highly accurate time. Any location with WiFi could query those and preset the camera TC or periodically update a drift correction algorithm. Even my Seiko quartz wristwatch receives radio-based time correction signals. Those would not be reliable for a camera but it shows in principle how straightforward the concept is.
There are mobile apps which query atomic time standards. We commonly use Bluetooth and WiFi links from mobile devices to cameras. Many cameras have built-in GPS and some (like Sony) even run apps. Camera vendors commonly have apps for mobile devices which add functionality to the camera.
So there are multiple pathways using well-established affordable technology for a camera to either periodically or continuously update its TC. This need not cause a jerk or disruption in the TC; smooth continuous correction based on periodic updates is possible, for the same reason that camera clocks drift slowly. So it would not necessarily require a lot of data, even if delivered via a cellular network.
It has just not been a design or feature priority for camera manufacturers. On the low end there is audio sync and using PluralEyes this is very capable. Just above that is Tentacle Sync, which is not very expensive. Above that are more expensive wireless TC systems. So there are already solutions which work across mixed camera brands.
For GPS or WiFi TC pre-set/correction to work in a mixed environment, it might require some type of standardization, however rudimentary. E.g, one camera brand might support GPS-driven presets to a user-entered TC at a specific wall clock time, but another brand might only support continuous correction. It is likely manufacturers would favor their own products in terms of standardization but not collaboratively devise a universal standard for such a niche feature area.
It is frustrating that cheap still cameras commonly have GPS geotagging which in principle can access nanosecond-precision time data, yet video camera manufacturers don’t use that to enhance TC.
-
[Bill Davis] “You presumably carry a device in your pocket called a cel phone. It keeps perfect time. It does that by internal time chips that might drift fractionally, but the central system resets them as needed. So they are always scrupulously accurate – providing they are anyplace on the planet that gets a carrier signal. So the ENTIRE developed world is good to go. They also largely have attendant tech like Bluetooth and nearfield – that makes it trivial to TALKbto other devices. “
But that’s not the case Bill. Go back and read my other posts (and the other pages I linked to). iPhones and iPads, for example, have very poor internal clocks (relatively speaking) and rely heavily on GPS, cell towers and/or WiFi connections to correct the their drift multiple times a day. A time piece jumping forward/back a fraction of a second at different points during the day isn’t a big deal because no one is going to notice that their watch jumped back 1/15th of a second between 12:01:01 and 12:01:02 or that it jumped forward 1/45th of a second between 11:30:59 and 11:31:00. Devices trying to stay in sync while writing continuous metadata every 1/60th of a second (or higher) don’t have the same amount of wiggle room. Just as an example of the level of accuracy needed, Tim Cook has said the Apple Watch is accurate down to 50ms yet if you are shooting at 60p you need constant accuracy of at least 16.666666666666667 milliseconds (1/60th of a second).
Like I’ve said over and over again throughout this thread, for jam syncing using a GPS clock signal could be another option to coexist with what’s already out there, but given the current state of tech I don’t see GPS as viable replacement for the functional equivalent of a single box sending out constant sync (wired or wirelessly) to multiple recording devices.
[Bill Davis] “Nobody is trying to take away your precious 1950s flashing numbers dude.”
Wow. Epic response, Bill. You either haven’t read (or are just ignoring) the questions other people are asking and/or points they are raising so it’s pretty preposterous for you to cop an attitude in lieu of having an actual conversation.
-
[Joe Marler] ” Those would not be reliable for a camera but it shows in principle how straightforward the concept is.”
I think this the gist of the whole thing. Conceptually it’s straightforward but in practice the time needs of our smart phones, computers, etc., aren’t the same as our time needs for our video cameras and audio recording devices so since the needs are different the solutions will be different as well.
One of the biggest differences between the GPS idea and how sync is current done is that with the current implementation of sync we have a single box (wired or wireless) that all the other devices slave to (either through a constant connection or just periodically in the case of a jam sync). With the GPS idea we remove that that single box concept and it’s up to each device to create their own GPS connection, maintain/refresh their own GPS connection and convert that independently collected GPS clock data into HH:MM:SS:FF (all in sync and with accuracy of at least 1/60 of a second).
That seems like a lot of variables in play, especially if there are no standards across the board, and even something as minor as Brand X rounding up nanoseconds vs Brand Y truncating nanoseconds would result in different HH:MM:SS:FF results and thus drift. Again, maybe fine for another way to jam sync, because jam syncing is already a compromised approach, but it would depend of course on how quickly the devices drifted of sync. Not to mention this ‘always on’ connection would probably put a load on the battery.
An obvious fix to this is to still use the single box method but now the single box can use GPS, wifi, and/or cellular as a clock source (which might be cheaper than a high quality quartz crystal clock source), do the conversion to HH:MM:SS:FF, and then push that signal out to the devices. The general pros/cons of this method would presumably be similar to already existing wireless sync options which may or may not make this GPS route a superior solution compared to ones that already exist.
And this doesn’t even get into the TC needs of post but I figure we’ll talk about one element at a time. 😉
-
[Andrew Kimery] “[Joe Marler] ” Those would not be reliable for a camera but it shows in principle how straightforward the concept is.”
I think this the gist of the whole thing. Conceptually it’s straightforward but in practice the time needs of our smart phones, computers, etc., aren’t the same as our time needs for our video cameras and audio recording devices so since the needs are different the solutions will be different as well.”
This is exactly why I keep coming back to the question, why are we talking about this for camera SYNC.
It’s a nifty idea as an IDEA, and GPS absolutely works for geotagging, and hey, why shouldn’t that be in high-end cameras too? I think that mfrs assume that, if you bought a Canon C500 or are renting an Alexa your shoots are at least organized enough to know where the hell you are when you shot this particular footage.
But there are currently NO devices that are frame accurate, and if it’s jam sync to time of day, welp, time of day is already well understood, metadata fields are already in place for every aspect of production and post, so no need to get metadata standards committees involved, no need to change manufacturing processes, no need for camera manufacturer standards committees to come up universal schemes for GPS polling timetables, and on and on and on.
[Andrew Kimery] “Just as an example of the level of accuracy needed, Tim Cook has said the Apple Watch is accurate down to 50ms yet if you are shooting at 60p you need constant accuracy of at least 16.666666666666667 milliseconds (1/60th of a second).”
Great example.
CONSTANT accuracy, at intervals non-trivially smaller than typically available today. And as Oliver points out elsewhere in the thread, unless every device in the sync matrix is polling GPS at exactly the same time, each device will be snapping itself out of sync every time.
It’s like the old principle that a stopped clock is right at least twice a day, but one whose time keeps shifting in relation to other devices means that none of them is EVER in reliable sync.
Hmmm….how could we make it so that every device polls the satellite at the same time? How about…an internal clock!!! Which, uhm, we could use to generate timecode. Which we already have, and we already do.
So we don’t need a manufacturer to figure out how to add a GPS radio, we don’t need them to figure out how to charge us for this, we don’t need to figure out how to keep multiple devices from different manufactures polling satellites simultaneously, etc etc etc.
I keep coming back to this, that adding GPS timekeeping creates problems that don’t currently exist, in trying to address a problem that doesn’t exist.
I entirely concede, it sure is fun to talk about…but I want to be clear, it goes into the same “straightforward in principle, not reliable in practice” bucket that so many other threads here do, including of course, plenty of threads of my own.
Which is to say, I’m not arguing against the concept of conceptual threads, but practical is practical, usable is usable, and right now, no protocols or devices exist that make this practical or usable.
-
“Wow. Epic response, Bill.”
Thank you. I seek epicness in all that I do – sadly falling short 99.9999999999 % of the time. (Without genlock)
My response to all is that if EVERY smart phone and many consumer cams, watches and devices can keep universal, dependable time as described elsewhere in this thread, it’s fair to ask why ALL modern cameras can’t as well.
The professional response in this forum appears to be a version of Tims beloved mantra “”stay off my timecode lawn!”
Fine. (And not unexpected.) I appreciate that it works wonderfully for those with the budgets and knowledge to deploy it (“…now where was that menu that lets me set the user bits?”) and those with the audacity to work TC free are clearly noobs in the grand tradition and must be marginalized STAT!
I just believe that since ALL technology evolves, it’s strange that we must carve out and freeze TC with its functionally exactly as it was when I was a teenager.
But whatever.
I’ve gotta go color grade some of my totally impractical timecode less iPhone shots from the Florida shoot – I know, silly me.
And so it goes.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
Reply to this Discussion! Login or Sign Up