Andrew Kimery
Forum Replies Created
-
[Jeremy Garchow] “I literally think we are having different conversations on timecode. “
This.^
I’m going to try to hit the reset so everyone can hopefully get on the same page.
Let’s just start with a single camera out in the field that is capable of generating SMPTE timecode. Your options are free run (user definable start time and the TC runs constantly once started), rec run (user definable start time and the TC only runs while the camera is recording) and time of day (TC matches the time of day and constantly runs). No matter which option you choose it will always be displayed as HH:MM:SS:FF where FF obviously corresponds to the frame rate your camera is set to record in. TC drift in this situation isn’t that big of a deal because it’s a single device so it only has to be accurate relative to itself.
If we upgrade the complexity though to say two cameras and one audio recorder in the field then we have to be more mindful of TC accuracy because three devices need to be put into sync and then kept in sync. This is where an external device comes into play. The two ways to go about this is either with a constant connection to an external clock (either with wires or wirelessly) or by jam syncing (temporarily connecting an an external clock multiple times a day to establish/maintain sync before the devices drift apart). So how accurate do we need to be to keep everything frame accurate? If we are shooting 60p then the devices have to maintain accuracy of at least 0.016666666666667 seconds.
This is where my first point of confusion comes in, Bill. With your GPS idea is it meant to replace the device’s internal clock for TC (i.e. if there is no GPS connection there is no TC ability) or is your idea meant to be another way to provide external sync to multiple devices (ex. instead one local box sending out the same signal to multiple devices you would just have all the devices to connect to a GPS satellite to get the time)?
From what I’ve read about how computers, smart phones and GPS-enabled watches, etc., keep time it doesn’t sound like going the same route to enable cameras/audio gear to maintain sync would work. There’s just too much wiggle room allowed (and it’s also a lot to ask of camera manufacturers to make their devices with WiFi, cellular and GPS radios like smartphones have). It might be any okay alternative to jam syncing though (a bit more info here, https://watch.camp/2014/11/apple-watch-timekeeping-accuracy/ ). An Apple Watch might drift a few fractions of a second over the course of a day and then ‘snap back’ to the right time when it gets a GPS update a few times a day and that won’t be noticeable to anyone. But if you have three pieces of A/V gear that all ‘drift and snap back’ at different rates that’s probably not going to turn out well.
Sure, you could possibly use one iPhone, for example, as the time source and then attach receivers to the all the A/V gear so that the are all getting time from the iPhone, but then you not only have to worry about the iPhones accuracy but also the strength of the signal going out to each device (what if Cam A accidentally wonders out of range for a few seconds but Cam B and Audio stay w/in range)? This is already one of the short comings of using a wireless setup for syncing such as the WifiMaster.
Like i said in a previous post, I think it’s an interesting idea Bill, but I don’t think the tech is there yet to make really make it happen. Maybe as an additional alternative to what we currently use in some situations, but certainly not as a viable and robust replacement.
As Jeremy has mentioned TC in post production isn’t quite the same beast in part because media generation in post doesn’t usually happen in real time. If you are on the broadcast side of things or still have a lot of tape I/O in your workflow then you probably need to multiple devices (NLEs, decks, etc.,) locked to the same clock, but if you otherwise it’s doubtful you would need to have a central point of sync for everyone to tap into. In post I think maintaining TC continuity throughout the project becomes the key point. For example, if an interview is shot ToD in the field and I export it for transcription it behooves me to export it with the exact same ToD as opposed to having it start at 00:00:00:00 (unless of course I have good reason for wanting the ‘official’ TC of that interview to change to 00:00:00:00). Or If I make an export for color grading then the TC I originally give them should be consistently used throughout the process.
And to a point that I think Oliver made (if not others) TC is one of the few pieces of metadata that is pretty much universally understand by all NLEs *and* is easily human readable.
If anyone is bored they can go to Time.is ( https://time.is/ ) and see how their computer/phone/tablet time compares to that of an atomic clock. Note that anything down to 1/10 of a second comes back as “exact” yet for our needs we would need accuracy down to at least 1/60th of a second.
[Bill Davis] ” FCP X doesn’t CARE if the sources ALL have SMPTE or not.”
What NLE does? I used to digitize VHS into various NLEs nearly 20yrs ago.
-
I just started using it the other day with CC2015 and ZXPInstaller to install it. It shows up under Window->Extensions along with the rest of my extensions. Is this the only extension you have that doesn’t want to install?
-
[Bill Davis] “Presuming the GPS time signal is embedded into the footage in exactly the same way 00:00:00:00 based timecode is today – it’s going to do you precisely the same good that VITC and tape track based timecode did back in the day. There’s literally NO functional difference if the camera manufacturers support it.”
So instead of a quartz crystal inside the camera driving the clock to generate the TC there is a GPS receiver inside the camera driving the clock to generate the TC? I think the GPS idea is nifty and could be a nice addition to what already exists (possibly an alternative to things like LockIt boxes), but I don’t see as being an either/or situation (GPS *or* Quartz). I feel like this is a recurring question in this forum, but what’s wrong with having multiple options since the breadth and scope of production and post production is so broad?
[Bill Davis] “Are you saying that modern timepieces lose accuracy if they aren’t hooked up to a reliable constant timing source?”
Yes.
According to this watch enthusiast site, your typical quartz clock can drift between 2 seconds (worst case scenario) and 1/10th of a second per day (best case scenario) depending on quality of the components, wear on the components, and environmental factors (heat, humidity, etc.,) (https://www.chronocentric.com/watches/accuracy.shtml).
And here’s a link from a blog at B&H talking about syncing cameras and second system sound. Drift can start happening inside of 30min and I’ve personally seen it happen inside of an hour. I’ve also seen gear jam synced in the morning and by the afternoon they weren’t that far off so how quickly and how much can change on a case by case basis.
https://www.bhphotovideo.com/explora/video/tips-and-solutions/timecode-versus-sync-how-they-differ-and-why-it-matters#comments[Bill Davis] “Perhaps on location in the middle of nowhere. But even there, there are satellite radios and other mobile GPS readers that can grab a reset signal from a satellite, so I’m just not worried about it. “
Think more like a structure/environment that blocks the signal (inside a building, a tunnel, a canyon, etc.,). So what’s plan B if you are shooting in a place where you can’t get a GPS signal or the signal might not be reliable? Hopefully the A/V gear still supports TC the ‘old fashioned’ way and has it’s own internal clocks and/or can accept a signal from a local source. Maybe there is a way for the internal clocks to keep going on their own until the GPS signal comes back, but what happens if the internal clocks have already started to drift even just a hair? Will they ‘snap’ back in sync with the GPS signal and possibly cause a break in the TC? Is the lesser of two evils just to keep going on the internal clocks (even if that means drifting out of sync) until someone yells ‘cut’ and then the link to the GPS signal can be reestablished?
I have a Garmin GPS bike computer and it loses contact with the satellites if I go under a freeway overpass and it takes forever to get a signal if it’s sitting in my garage. Smartphones use the cell networks and WiFi alongside GPS signals so even if they lose the satellites they have something to try and fall back on. My Garmin also only poles the GPS satellite every three seconds I think in order to save battery life (it has low power black and white screen and one charge will last about 8hrs). I was also reading about a new GPS watch by Seiko and it can only get GPS signals if it can ‘see the sky’.
Keeping a single watch or clock from drifting a second here or there by occasionally updating it with a GPS signal seems much less complicated than keeping multiple pieces of A/V gear in perfect lockstep down to 1/60, 1/120, etc., of a second.
These are more rhetorical type questions because I know we aren’t engineers, but if it requires a GPS signal to work I think the first natural question is, “Well what happens if there is no GPS signal?” If the whole model hinges on always having an unbroken link to the GPS signal I don’t think it sounds very robust or practical.
[Bill Davis] “Has nothing to do with frame identification for editing. If the clock time is right to GPS standards, Math can convert it into whatever division you’re working with. It’s pretty basic. “
But it does. Different frame rates for PAL and NTSC countries were chosen for various technical reasons and a few decades later someone pondered, “Hey, anyone think it would be useful if video frames could be numbered like pages in a book?”. Whether the TC is generated from an internal clock, from an external box or from a GPS satellite I still have to worry about flickering lights if I mismatch frame rate and local power frequency.
So, if I’m following you, If I’m in an NTSC country, for example, I’ll still shoot 60p and if I’m in a PAL country I’ll still shoot 50p but instead of using an internal clock for TC (or something like a Lockit Box for syncing multiple pieces of gear) the camera(s)/audio gear will rely on a GPS signal for accurate time keeping and then convert the time from the GPS signal into the correct frame rate?
[Bill Davis] ” And simply LESS useful today because the systems are changing and cameras have superb on-board timekeeping that’s cheap and widely available “
Less useful to who? You? Me? Oliver? Everyone?
[Bill Davis] “Now you’re just being silly.”
All I did was rephrase your question.
[Bill Davis] “that everyone HAS to keep thinking that timecode needs to continue to be dealt with like it was in 1979. “
Who said that? Some of us are just trying to figure out why it’s necessary to blow up ‘A’ in order to have ‘B’? I’m not seeing how having an internal clock, syncing externally to a local clock and syncing via a GPS time signal are mutually exclusive technologies? They seem more complimentary than competing to me.
-
[Tim Wilson] “I’m doing better with digital, but I found film projected at 24fps to be as physically nauseating as some people find 3D.”
Interesting. Projected film in a theater is usually projected at 48Hz (each film frame is flashed twice to help reduce flicker) but I’ve read that digital project is usually done at 72Hz (each frame is flashed three times) so I wonder if that increased refresh rate is what makes it easier on your eyes? Maybe the lack of gate weave in digital has something to do with it as well?
-
[Bill Davis] ” So what does timecode really provide in the modern era that couldn’t be supplanted over time with video systems moving to GPS based clock time with local offsets applied? “
So your suggestion is basically to make everything Time of Day TC and using GPS as the ‘master clock’ that everything syncs to? What do you do when you can’t get/maintain a reliable GPS signal?
[Bill Davis] “Now we don’t have to depend on a dozen different flavors of AC. You can work in DC all day long. Yes we still map it to TC standards for convenience – I’m just asking why?”
I thought you’d get light flicker/roll if you shot 60Hz in a 50Hz country and vice versa.
[Bill Davis] “24fps made scientific sense for persistence of vision.”
24fps made sense because film was expensive, studios were cheap and 24fps was the slowest they could get away with. For a host of technical and aesthetic reasons I hope you aren’t suggesting that all cameras shoot at just 24fps.
[Bill Davis] “Yes it’s important for broadcast. But what if in 15 years broadcast is WAY smaller a market than web files?”
So X shouldn’t get a useful feature today because it might be a slightly less useful feature in 15yrs?
-
[Tim Wilson] “Exactly. I think they already HAD gotten started, in work that was bearing fruit in iMovie first, simply because iMovie didn’t have any baggage to carry.”
iMovie had some baggage, but not as much as FCP. With iMovie ’08 (released in 2007) Apple completely rewrote it and redesigned it. iMovie ’06 was a mature product and had a brushed metal theme similar to FCP. iMovie ’08 changed the visual style to what we see in iMovie, and X, today and it also went over like a lead balloon because it was barebones compared to iMovie ’06. The reaction was so negative that Apple made iMovie ’06 a free download for anyone that purchased iMovie ’08. Over the next two versions iMovie mostly regained all the features that iMovie 06 had.
[Tim Wilson] “Simon is right, though, that Motion had those already.”
The world may never know… 😉
According to Wikipedia Apple acquired Silicon Grail (which made compositing software) and Nothing Real in 2002. Was Motion an existing product at Autodesk Tim, or was it a prototype in a lab when Apple got its hands on it? Since Apple didn’t release Motion until 2004 that seems like enough time for them to take cherry pick the parts they wanted from the different acquisitions and roll them into a new product.
-
[Tim Wilson] “You know what always mystified me: exactly what IP did Apple take?”
I think Shake’s implementation of Optical Flow and SmoothCam were probably the two most well know. How many ‘smaller’ things found their way into Motion I have no idea.
[Tim Wilson] “My guess about selling the product on Macs is that Steve saw it as low-hanging fruit. It was fairly easy to port, people in that market were already using Macs, so why the hell not? Remember, as an inducement to convert from Linux, he offered to double your number of licenses for free.”
Apple also kept the Windows license the original price ($12k or $15k, I can’t quite remember) even though the Mac license eventually went down to $500.
[Tim Wilson] “That’s also why I’ve always felt that Apple didn’t go very far in making Final Cut very Apple-like. It was in some ways the least Apple-like product they ever shipped. Other than some colored dots for minimize/maximize/close windows, the actual interface didn’t change substantially at all.”
In the early/mid 2000’s Apple was all about the brushed metal look and FCP fit in with that. All the iApps from that era (iTunes, iMovie, iDVD, iPhoto) had a matching visual style as did DVD SP, Compressor and QT 7 Pro. FCP never got a facelift, but that’s probably because by the time the facelift was needed they knew they were going to start from scratch anyway so why bother?
[Tim Wilson] “Nothing particularly controversial about that, I hope — but I can imagine the shock at the time for a bunch of VFX pros who’d relied on Shake to be told that their needs would no longer be the ones driving development, when in fact their original love for Shake was driven precisely be the product absolutely being tailored to meet their needs.”
This is what I meant by Apple not wanting to go too far down the post production rabbit hole (too much effort for too few users). I thought about bringing up Ron Brinkmann’s post as a case-in-point, but every time I have it’s turned into a firestorm. 😉
-
[Shawn Miller] “It was still a viable piece of software that didn’t directly compete with any of Apple’s offerings… why destroy it? “
It’s a product that goes too far down the post-production rabbit hole for Apple, IMO. I think it was originally acquired for parts, prestige, and with the hopes that it would be picked up by a much broader user base. After Apple took the IP from Shake that it wanted, and the potential market didn’t seem much broader than the existing market, is when Apple probably decided that it was Done with Shake. Interesting thing about it is that Apple EOL’d Shake in ’06 but kept selling it until ’09.
-
[Tim Wilson] “I’m not sure exactly when “customizability” became such a dirty word.”
Well, you see Tim…
[Tim Wilson] “Maybe because Apple de-prioritized it, which by default made anyone who wanted to re-prioritize it somehow anti-Apple?”
Oh, never mind. You answered your own question.
In the immortal words of Henry Ford, “”Any customer can have the UI configured anyway they want so long as it is the factory default configuration.” 😉
-
[batya lewbel] “Hey so I looked into the render options. It just shows Mercury Playback Engine Software only and it’s grayed out and unclickable.
What does that imply and can I fix it?”It means your GFX card isn’t supported and they only way to fix that is to get a new GFX card.