Four cameras watched the same incident and produced four different accounts of when it happened. Multi camera synchronization breaks in two separate places, and fixing one does nothing for the other.

Something happens in a loading yard. Four cameras cover it: one on the gate, one on the dock, one on the corner of the building, one on the truck lane. You pull all four to reconstruct the sequence — did the vehicle arrive before or after the gate opened? — and the four clips disagree. Not by a frame. By seconds.

This is the multi camera synchronization problem, and the reason it survives in otherwise well-run systems is that it isn't one problem. It's two, they have different causes and different fixes, and solving either one alone leaves you exactly as unable to answer the question.

So separate them before trying to fix anything.

Two Problems Wearing One Name

The first is capture alignment: what instant does this frame actually represent, and can I compare that instant to a frame from another camera? This is a question about clocks and timestamps, and it determines whether you can build a defensible timeline after the fact.

The second is presentation alignment: are the four tiles on my wall showing the same moment right now? This is a question about delivery paths, and it determines whether an operator watching live is seeing a coherent scene or four slightly different times stitched together.

They're independent. Cameras can be perfectly time-synchronised and still display three seconds apart, because the frames took different routes to the screen. And they can display in perfect lockstep while carrying timestamps that are minutes off, because the wall aligned them on arrival rather than on capture. One system is wrong in court; the other is wrong in the moment.

Both start with the same discovery: the protocol carrying your video was never going to solve this for you.

Why RTP Can't Align Your Cameras

Video over RTP carries a timestamp on every packet, so the obvious move is to compare them. RFC 3550 closes that door explicitly: the initial value of the RTP timestamp “SHOULD be random,” and streams “may advance at different rates and usually have independent, random offsets.” The specification's own conclusion is that “directly comparing RTP timestamps from different media is not effective for synchronization.”

An RTP timestamp is a measure of elapsed sampling within one stream. It says nothing about what time it was in the world. Two cameras started at different moments with different random seeds, so their timestamps are two rulers with the zero mark filed off in different places.

The bridge is RTCP. A sender report pairs an RTP timestamp with a wall-clock NTP timestamp, telling a receiver what real-world instant a given stream position corresponds to. That is the mechanism, and there are two things to know about it. Sender reports arrive at a much lower rate than data packets, so alignment is interpolated between them rather than exact per-frame. And the spec assumes “the reference clock is shared by all media to be synchronized” — which holds inside one sender, and is precisely what independent cameras do not have.

Which pushes the whole problem down onto the camera's own clock.

The Clock Underneath Multi Camera Synchronization

A camera is a small computer with a cheap oscillator. Left alone, its clock free-runs and the error accumulates from the moment it was last set — there is no self-correction, and nothing on any dashboard reports the drift. Whatever the camera stamps into the video is what your evidence says happened, and it is wrong by an amount nobody is tracking.

So you give it a time source. NTP is the near-universal answer, and its accuracy is highly situational: the NTP project's own reference material puts typical results between a few microseconds on PPS-assisted primary servers and tens of milliseconds across widely dispersed internet networks. The failure mode worth knowing is asymmetry — when the path to the time server is faster in one direction than the other, the offset that introduces is, per Meinberg's technical documentation, one “which the client software can't determine.” It doesn't show up as an error. It shows up as confident, precise, wrong time.

Where accuracy genuinely matters, PTP (IEEE 1588) is the step up, at roughly 100 nanoseconds — but that figure depends on the network interface capturing hardware timestamps at the physical layer, so it's a hardware capability before it's a configuration option. Most surveillance estates won't have it, and mostly won't need it: for reconstructing a yard incident, low-millisecond LAN-based NTP is comfortably sufficient. The gap that hurts is between milliseconds and minutes, not between milliseconds and nanoseconds.

One caveat about conformance, and it will look familiar to anyone who has read the audio backchannel spec. The ONVIF Core Specification (v26.06) defines the interfaces — GetSystemDateAndTime, SetSystemDateAndTime, GetNTP, SetNTP — and states no accuracy requirement for the device clock at all. ONVIF conformance tells you a camera can be told the time. It does not tell you the camera keeps it.

And even with every clock perfect, the second problem is entirely untouched.

The Delivery Path Adds Its Own Skew

Presentation alignment fails for reasons that have nothing to do with clocks. Frames stamped at exactly the same instant reach the screen at different times because they took different routes.

The biggest offender is an uneven pipeline. If one camera's H.264 stream passes through untouched while another's H.265 stream has to be decoded and re-encoded to reach the browser, the transcoded path carries the full cost of that work and the passthrough one doesn't — the two tiles are now permanently offset by however long the transcode takes. That codec split is the subject of why RTSP cameras still can't talk to browsers, and here it shows up as a synchronisation bug rather than a cost one.

Then the smaller contributors stack. Cameras with different keyframe intervals start displaying at different points after a subscribe. Each stream gets its own jitter buffer sized to its own network conditions. Different physical paths through the estate have different latencies. None of these are faults; every one of them is a component doing its job independently, which is exactly why the result is four independent timelines.

Scale that across buildings and it gets worse rather than better, because each site's relay adds its own hop and its own buffering — the site-edge relay and central SFU pattern is where cross-site timing has to be handled deliberately, since two cameras in different cities share nothing but the clock you gave them.

Source of skew	Magnitude	What fixes it
Free-running camera clock	Unbounded — accumulates continuously from the last time it was set	A common time source, checked
NTP across a WAN with an asymmetric path	Milliseconds, and the client cannot detect the offset	Keep the time source on the LAN
NTP on a local network	Microseconds to low milliseconds	Usually good enough for review
PTP with NIC hardware timestamping	~100 nanoseconds	The ceiling, if your hardware supports it
RTP timestamps compared across streams	Arbitrary — the offsets are random by design	Use RTCP sender reports instead
Transcoded stream alongside a passthrough one	A full decode-and-re-encode on one path only	Keep the pipeline uniform
Mismatched keyframe intervals	0–4s at stream start	Align GOP settings across cameras
Independent jitter buffers per stream	Tens to hundreds of milliseconds	Sync playback to the slowest stream

The cost of leaving this alone is larger than a slightly untidy video wall.

What Drift Actually Costs You

The timeline stops being defensible. Reconstructing a sequence across cameras is the core forensic use of a multi-camera estate, and it rests entirely on comparing timestamps. If nobody can say how well the clocks agreed, the ordering of events becomes an assertion rather than a record.
Cross-camera analytics degrade quietly. Following a subject from one camera to the next depends on temporal alignment as much as visual matching. Feed a tracker two views that disagree by seconds and it will confidently produce a wrong path, with no error to catch.
Live decisions get made off the wrong tile. An operator comparing the gate camera to the dock camera to decide whether to intervene is comparing two different moments, and nothing on screen says so.
Nothing alerts you. Drift produces no dropped frames, no failed health check, no logged error. It is invisible until the first time someone needs the answer, which is the worst possible moment to discover it.

All of which is fixable with a handful of deliberate decisions.

Designing for Multi Camera Synchronization

One time source, on the local network. Every camera, the recorder and the analytics host point at the same server, reachable over the LAN rather than across a WAN whose path asymmetry you can't measure. Use PTP where the hardware supports it and the application justifies it.
Verify the clocks, don't assume them. Poll each camera's reported time on a schedule and alert on divergence. It's a few lines of ONVIF and it converts an invisible failure into a monitored one.
Record capture time, never receipt time. If the recorder stamps frames when they arrive, you have baked every network delay into your evidence permanently. Carry the camera's capture timestamp through the pipeline and store it.
Align streams via RTCP, not RTP. Use sender reports to map each stream onto wall clock, exactly as the specification intends, and treat raw RTP timestamps as stream-internal only.
Keep the pipeline uniform. Same codec handling, same keyframe interval, same delivery transport across cameras that will be viewed together. A synchronised group should be a deliberate configuration, not an accident of which cameras happened to be bought together.
For synchronised playback, buffer to the slowest. A multi-view that aligns properly is one that holds every stream back to match the laggiest, and tells the operator the group is running a known delay. Say the number in the interface — a synchronised view that silently costs a second is a trap in a live-response context.

And measure it before you trust it: put a running clock display in frame, view it on every camera at once, and photograph the wall. Whatever disagreement you can read off that image is your real synchronisation error, and it is the only number that isn't an assumption.

Which leaves the question of what you're building it on.

Build, Buy, or Deploy

Build on open source. go2rtc and MediaMTX handle RTSP ingest and WebRTC delivery, and give you direct control over the passthrough-versus-transcode decision that causes most presentation skew. You own the timestamp handling end to end, which is the part that matters here. Right when you have the team to operate a media pipeline.
Use a managed cloud relay. Quick to a working multi-view, but the pipeline is a black box — whether it preserves capture timestamps or restamps on ingest is a question you have to ask explicitly, and the answer determines whether your archive is evidentially useful.
Deploy a commercial platform. A full stack — ingest, uniform passthrough, low-latency fan-out, recording — on-premise or as a managed cloud deployment under a flat license. Samvyo is one such option: based on SFU architecture, with the media path and recording under your control, so capture timestamps stay yours rather than being restamped in somebody else's cloud. Where it doesn't fit: a handful of cameras, or a single-view deployment where cross-camera timing never comes up.

Three routes, one requirement — somebody has to own the clock.

The Bottom Line

Four angles drift apart for two unrelated reasons, and you have to fix both. The capture side fails because RTP timestamps carry random offsets by design and cannot be compared across streams, so alignment depends on RTCP sender reports and on cameras genuinely sharing a reference clock — which ONVIF conformance does not guarantee, since the spec sets no accuracy requirement for a device clock at all. The presentation side fails because a transcoded stream, a longer keyframe interval and an independently sized jitter buffer each add delay to some paths and not others. Give every camera the same time source, carry capture timestamps rather than arrival times, keep the pipeline uniform across cameras that get viewed together — and then put a clock in frame and photograph the wall, because that photograph is the only measurement in this whole article that isn't an assumption.

What's Next?

Feeding many synchronised views to one workstation runs into a separate ceiling — watching 500 cameras is a decode problem, not a bandwidth problem, and a machine dropping frames under load will break alignment no matter how good your clocks are.

For what happens to a live view at the moment an operator expands it — a related timing failure with a different cause — see The Blind Five Seconds.

And for why any of this timing precision matters operationally, Talk-Down at Ten Seconds Is Theater covers the response loop it feeds.

Frequently Asked Questions

Why are my security camera timestamps different across cameras?

Because each camera keeps its own clock and free-runs unless it's synchronised to a shared time source. Error accumulates from the moment the clock was last set, produces no alert, and gets written permanently into recorded video. Point every camera at the same NTP server on the local network and poll their reported times to catch divergence.

Can RTP timestamps be used to synchronise multiple cameras?

No. RFC 3550 specifies that RTP timestamps start from a random value and that streams have independent, random offsets, and states directly that comparing RTP timestamps across streams is not effective for synchronisation. Alignment requires RTCP sender reports, which map each stream's RTP timestamps onto wall-clock time.

What is multi camera synchronization in video surveillance?

It's two separate problems: capture alignment, meaning frames from different cameras carry comparable timestamps so a timeline can be reconstructed, and presentation alignment, meaning multiple live views on screen show the same instant. Clock configuration fixes the first; a uniform delivery pipeline fixes the second.

Is NTP accurate enough for CCTV, or do I need PTP?

NTP on a local network is normally sufficient — reconstructing an incident needs millisecond-level agreement, not nanoseconds. PTP reaches around 100 nanoseconds but requires network interfaces that capture hardware timestamps. The damaging gap is between milliseconds and minutes, which is what unsynchronised cameras produce.

Does ONVIF conformance guarantee accurate camera time?

No. The ONVIF Core Specification defines the interfaces for reading and setting device time and NTP configuration, but states no accuracy requirement for the device clock. Conformance means a camera can be told the time; it says nothing about how well it keeps it.

Why do my live camera tiles show different moments?

Because the streams took different routes. A transcoded H.265 stream carries decode-and-re-encode delay that a passthrough H.264 stream doesn't, keyframe intervals differ, and each stream gets its own jitter buffer. Keeping codec handling, GOP settings and transport uniform across a viewing group removes most of it.

How do I measure camera synchronisation error?

Display a running clock where several cameras can see it, pull all of them up simultaneously, and photograph the screen. The spread you can read across the tiles is your actual error. Samvyo is based on SFU architecture with uniform low-latency delivery and keeps the media path and recording under your control, so capture timestamps survive the pipeline rather than being restamped elsewhere.

Subscribe to Samvyo blogs