Documentation Center

Service Host Administrator Guide

Version 2.1 | Published July 20, 2021 ©

Recording Accuracy

Recording accuracy in this context means the expected duration of the recorded clip in relation to the requested recording done via commands. The following points are important to take into account to understand how Channel Recorder works in relation this topic:

  • There are two possible clocks that can be configured for Channel Recorder: INPUT and GENLOCK.

    • The clock defines the rate at which the frames are received by Channel Recorder.

    • INPUT should never be used if accuracy is important and a GENLOCK signal is available.

  • There are three possible timecode sources: TIME_OF_DAY, VITC, and LTC.

    • VITC and LTC do not get affected by recording accuracy since the timecode can be found contained in the frames that Channel Recorder received to start or stop a recording.

    • TIME_OF_DAY is calculated from the system time (which is why it is important to have Windows NTP correctly configured to avoid sync issues).

Channel Recorder deals with recording in TIME_OF_DAY as follows:

  • During first start up, Channel Recorder gets the current system time, convert it to timecode and use this as reference to start and stop recording.

  • Channel Recorder still attempts to get the system time in every frame fetch, however this value is not used until a certain threshold is surpassed.

  • Channel Recorder increases the timecode it gets during start up by one frame and compare it to the current system time. If a threshold is exceeded, it uses the system time (instead of the previous TC increased by 1). This is called a resync.

  • There are two thresholds:

    • During idle the threshold is 2 frames in both directions.

    • During crash and scheduled recordings, the threshold is 25 frames in both directions plus a configurable threshold: trigger-threshold. The bigger threshold during recording is to allow for back-to-back recording in a less than ideal set up in which small drifting is expected.

    • During loop recording there is no threshold and a resync never happens.

  • A resync usually means that the end recording has more or less frames than expected depending on the direction of the drift.

Regarding the TC that is contained within the frames. The TC is continuous (unless the option discontinuous-tc is enabled). The TC of each frame starts at the defined START_TC which can be configured for each recording. This means that even if there is a jump due to resync, the recorded frames have continuous TC. The purpose of the resync is to start and stop at the correct local time.

Summary of Resync Behavior

CR timecode is derived from the Windows system time (when using TIME_OF_DAY) and is initialized at the beginning of starting CR. Every time Matrox gives CR a frame the CR timecode is increased by one frame. So, if CR is configured with 720p50. This means that every 50 frames, one second should have passed. If this is not the case then there is a drift. CR guarantees (best effort) that it records for the amount of time it is instructed to do: A recording for one hour means that it records for one hour (of system time); however, if the amount of frames that it receives within that hour is less/more than 180000 then… that is what the duration of the recordings are.

When CR is not recording the correction happens when +2/-2 drifting from the system time is detected. This is to ensure that the scheduled recordings happen when the user instructed it to happen as precise as possible even in the presence of drift in the input clock / genlock.

When CR is recording the correction happens when +25+trigger_threshold/-25-trigger_threshold (configurable) drifting from the system time is detected. This is to ensure that b2b recording works even if the current recording is sync to the future, overlapping the next one. The current one is stopped and the next one is triggered immediately due to being in the trigger_threshold range. When b2b you should not lose any frames, however the frames could be in the next file instead of the previous one or vice versa.

Daylight Saving Time

Since CR uses the system local time. Daylight Saving Time (DST) is provided automatically. If during a recording DST occurs the recording is one hour longer or shorter. Timecode is not affected since it is continuous. It is possible to reflect the change of DST in the timecode by using the configuration discontinuous-tc. Discontinuous TC puts the current system time converted to TC to the frames, so if a jump appears such as during DST, the jump is reflected in the clip TC.