Comment by lefra
2 days ago
In what situation would nanosecond accuracy be needed between cameras? Millisecond accuracy should be enough to get camera feeds in sync, even when looking at videos frame by frame.
2 days ago
In what situation would nanosecond accuracy be needed between cameras? Millisecond accuracy should be enough to get camera feeds in sync, even when looking at videos frame by frame.
To ensure each camera is scanning the same line of each frame at the same time.
This aids in switching without tearing, and if you’re using things like LED video walls, you want to synchronise the refresh rate of the video wall to the camera’s scan rate to eliminate “rolling” and other horrible visual artifacts.
Thanks, I didn't think synchronizing the pixel clock would be needed, but this makes sense.
That's a really good question. I hope I'm able to answer it.
The closer multiple sources of video can come to showing up at exactly the right time, in lockstep with eachother, the less need there is for buffers at any step.
When buffers are reduced at any step, latency is reduced at each of those steps.
When latency is reduced, it accumulates slower as steps are added, removed or different workflows are switched in and out.
And that makes getting continual coherency between processing workflows easier, instead of harder. Easy is good, innit?
---
There's other ways to get it done, but tight clocks are a Keep It Simple, Stupid method. The tighter, the better.
And, sure: I hear you. There's usually just 60 frames per second, or ~16ms per frame.
But video isn't necessarily a sequence of fixed frames like film is. It's (still!) often rasterized as scanlines, even just to transmit it from a camera to the next stage.
We can therefore process video as scanlines, instead of individual frames. We can switch between them and even mix them together without even buffering a whole frame first.
Or at least: We can do this if the clocks are tight-enough so that the lines themselves show up at the right time.
And that's useful: If we can get rid just 1 frame worth of input buffer and 1 frame of output buffer at a given step, then we save 2 frames worth of latency for that step, or ~32ms. That's 32ms that we don't need to figure out how to compensate for elsewhere, but we can only get there if the video sources (eg, live cameras) are tightly synchronized.
With 4k60 video, we get new raster lines at a rate of around 65KHz. That's not seeming like a very fast rate, but it's beyond the rate of integer milliseconds and well into the realm where microseconds are a better unit.
---
"So, fine. Microseconds can make sense. Why nanoseconds, then?"
With nanosecond resolution, it may be possible to go beyond clocking individual scanlines and can clock individual pixels instead.
"But seriously. Nanoseconds?"
Sure. Why not?
Maybe we can eventually get to the point where all this latency malarkey that got introduced with the transition from analog to digital signalling just ceases to matter. We didn't need framebuffers or jitter control or anything like that in strictly-analog world. That wasn't an issue at all.
Analog signals went in one end, and came out the other without any deliberate delay. Signals were switched and mixed without delay. Overlay graphics were inserted without delaying the signal they were overlaid upon. The (limited) processing we had occurred without delay. There was no frame judder because there wasn't enough complexity to introduce frame judder. We didn't have to consolidate different system latencies because we didn't have system latencies to consolidate. It was a simpler time.
With tight-enough clocks, perhaps we can get back to that kind of simple flow while maintaining the rote precision of working in digital number-land.