The Tilde - a most profound character

Every single character in a technical specification means something. Sometimes, the character is rather significant. The Tilde (~) is one of those rather significant characters often found in DVR / NVR spec sheets.

Take this specification from a typical Dahua DVR.

The video frame rate is an approximate value (e.g. ~30f/s for NTSC). It's not an exact value. It's a $7 box of random parts, not a Swiss chronometer. Thus, the folks at Dahua are hedging by saying - we're going to try to get each channel to the specified frame rate, but don't hold us to it.

We know that the Tilde does not mean "between" in this document. The clue is in the bit rate. The bit rate is given as a range. For the 4-Ch version, the rate is 2048Kbps-4096Kbps. Read aloud, it's "between 2048Kbps and 4096Kbps."

Thus, in building a performance model of a specific DVR for case work, one will need to find the range of values in which the approximate FPS for the specific DVR falls.

Basic condition of the DVR

For the 4-Ch, what happens inside the evidence (FPS / camera) DVR when:

• A single channel is recording normally but none of the others is recording (no motion detected / no alarm). (test for each channel)
• Two channels are recording normally and two are not. (test for each combination of two channels)
• Three channels are recording normally and one is not. (test for each combination of three channels)
• All four channels are recording normally.
• All four channels are set to record on motion only. Repeat the above but instead of pressing the record button for normal recording, cause a motion trigger recording.
• If alarm functionality is present: all four channels are set to record on alarm only. Repeat the above but instead of pressing the record button for normal recording, cause an alarm trigger recording.

How reliable is the Basic Condition? Better put, how variable are the results? Given the signal path inside the average Chinese DVR, like Dahua, will the four channels feed into a single encoder? How does the signal path prioritize data when all channels are feeding it data? Same question for when the data is headed across the bus to the HDD? What does it's error state look like? To find out, you need a proper / valid sample set of tests. How big will that sample set be? How does 164 complete run throughs of the above scenario work for you?

Usually, when a number this large is quoted, folks will complain about the cost. But, there's another cost to factor - the cost of being wrong. You see from the graph below that under about 50 test sets, your chances of being wrong are greater than your chances of being right. Put another way, under 50 test sets, you're better off flipping a coin. This is something, the calculation of sample sizes, that I cover in my class - Statistics for Forensic Analysts.

Back to the evidence file. I've seen some DVRs insist upon producing a container that had an even distribution of 30 FPS every time. But, an examination of the frames within that container proved that many of the frames within a GOP were exact duplicates of other frames. Meaning? The machine got overwhelmed and padded the container such that it could maintain the specified rate? For this determination, frames were extracted from the container and Similarity Metrics were calculated. Correlation coefficients were 1 - match, no difference.

All of this information is a bit expensive in time and technology to discover. But, it's vital to know this information in certain types of cases involving video - reconstruction of police uses of force, traffic investigations, and etc.

If you'd like to know more, shoot me an email.