@@ -184,4 +184,117 @@ controls:
184
184
This control returns performance metrics for the CNN processing stage.
185
185
Two values are returned in this span, the runtime of the CNN/DNN stage
186
186
and the DSP stage in milliseconds.
187
+
188
+ - SyncMode :
189
+ type : int32_t
190
+ direction : in
191
+ description : |
192
+ Enable or disable camera synchronisation ("sync") mode.
193
+
194
+ When sync mode is enabled, a camera will synchronise frames temporally
195
+ with other cameras, either attached to the same device or a different
196
+ one. There should be one "server" device, which broadcasts timing
197
+ information to one or more "clients". Communication is one-way, from
198
+ server to clients only, and it is only clients that adjust their frame
199
+ timings to match the server.
200
+
201
+ Sync mode requires all cameras to be running at (as far as possible) the
202
+ same fixed framerate. Clients may continue to make adjustments to keep
203
+ their cameras synchronised with the server for the duration of the
204
+ session, though any updates after the initial ones should remain small.
205
+
206
+ \sa SyncReady
207
+ \sa SyncTimer
208
+ \sa SyncFrames
209
+
210
+ enum :
211
+ - name : SyncModeOff
212
+ value : 0
213
+ description : Disable sync mode.
214
+ - name : SyncModeServer
215
+ value : 1
216
+ description : |
217
+ Enable sync mode, act as server. The server broadcasts timing
218
+ messages to any clients that are listening, so that the clients can
219
+ synchronise their camera frames with the server's.
220
+ - name : SyncModeClient
221
+ value : 2
222
+ description : |
223
+ Enable sync mode, act as client. A client listens for any server
224
+ messages, and arranges for its camera frames to synchronise as
225
+ closely as possible with the server's. Many clients can listen out
226
+ for the same server. Clients can also be started ahead of any
227
+ servers, causing them merely to wait for the server to start.
228
+
229
+ - SyncReady :
230
+ type : bool
231
+ direction : out
232
+ description : |
233
+ When using the camera synchronisation algorithm, the server broadcasts
234
+ timing information to the clients. This also includes the time (some
235
+ number of frames in the future, called the "ready time") at which the
236
+ server will signal its controlling application, using this control, to
237
+ start using the image frames.
238
+
239
+ The client receives the "ready time" from the server, and will signal
240
+ its application to start using the frames at this same moment.
241
+
242
+ While this control value is false, applications (on both client and
243
+ server) should continue to wait, and not use the frames.
244
+
245
+ Once this value becomes true, it means that this is the first frame
246
+ where the server and its clients have agreed that they will both be
247
+ synchronised and that applications should begin consuming frames.
248
+ Thereafter, this control will continue to signal the value true for
249
+ the rest of the session.
250
+
251
+ \sa SyncMode
252
+ \sa SyncTimer
253
+ \sa SyncFrames
254
+
255
+ - SyncTimer :
256
+ type : int64_t
257
+ direction : out
258
+ description : |
259
+ This reports the amount of time, in microseconds, until the "ready
260
+ time", at which the server and client will signal their controlling
261
+ applications that the frames are now synchronised and should be
262
+ used. The value may be refined slightly over time, becoming more precise
263
+ as the "ready time" approaches.
264
+
265
+ Servers always report this value, whereas clients will omit this control
266
+ until they have received a message from the server that enables them to
267
+ calculate it.
268
+
269
+ Normally the value will start positive (the "ready time" is in the
270
+ future), and decrease towards zero, before becoming negative (the "ready
271
+ time" has elapsed). So there should be just one frame where the timer
272
+ value is, or is very close to, zero - the one for which the SyncReady
273
+ control becomes true. At this moment, the value indicates how closely
274
+ synchronised the client believes it is with the server.
275
+
276
+ But note that if frames are being dropped, then the "near zero" valued
277
+ frame, or indeed any other, could be skipped. In these cases the timer
278
+ value allows an application to deduce that this has happened.
279
+
280
+ \sa SyncMode
281
+ \sa SyncReady
282
+ \sa SyncFrames
283
+
284
+ - SyncFrames :
285
+ type : int32_t
286
+ direction : in
287
+ description : |
288
+ The number of frames the server should wait, after enabling
289
+ SyncModeServer, before signalling (via the SyncReady control) that
290
+ frames should be used. This therefore determines the "ready time" for
291
+ all synchronised cameras.
292
+
293
+ This control value should be set only for the device that is to act as
294
+ the server, before or at the same moment at which SyncModeServer is
295
+ enabled.
296
+
297
+ \sa SyncMode
298
+ \sa SyncReady
299
+ \sa SyncTimer
187
300
...
0 commit comments