A clear daytime clip is not representative evidence. Build a footage set that covers target visibility, normal operation, difficult conditions, failures, and the stream metadata needed to reproduce the test.
A PoC should test the conditions the deployed system will face, not the conditions that make the model look best. One clean clip can confirm that a file opens and a target class exists. It cannot represent camera angle, target size, night operation, crowded scenes, compression changes, or site-specific failure cases.
A useful footage set contains normal, difficult, and failure conditions from the actual or representative camera points. It preserves the original stream characteristics and includes enough scene metadata for the team to explain why the model passed, failed, or needs a different view.
Footage validation answers whether the scene supplies usable evidence for the AI task. It does not prove long-running RTSP stability, select an edge box configuration, or guarantee production accuracy.
Write the desired output before collecting video. Name the object or state, the relevant zone or line, the minimum event duration, and the action the result should support. “Detect people” is not enough. “Count people crossing this entrance in each direction while excluding staff” gives the footage review a concrete purpose.
Inspect the image after it is decoded, resized, and cropped for the candidate model. A target that looks adequate in a large VMS window may lose the detail needed after preprocessing. Record the target dimensions in pixels across near, middle, and far regions of the scene.
There is no universal pixel threshold for every model and task. Plate characters, helmets, people, vehicles, and occupancy states require different evidence. Use measurements to compare scene regions and then validate the actual model on those samples.
| Check | What to Record | Typical Failure |
|---|---|---|
| Target size | Width and height at the model input across the scene | Far targets lose class or attribute detail. |
| Angle and pose | Approach direction, rotation, visible surfaces, body pose | The required feature faces away from the camera. |
| Occlusion | Frequency, duration, and source of blocked views | People, vehicles, racks, or columns hide the event. |
| Motion | Blur, frame interval, and shortest event | Fast targets appear in too few usable frames. |
| Image quality | Compression, noise, glare, shadows, and night mode | Detail disappears when the scene becomes difficult. |
Build a small matrix instead of one long unstructured recording. Include the conditions that affect the decision and enough examples of each to avoid drawing conclusions from a single event.
| Sample Group | Include | Purpose |
|---|---|---|
| Normal | Typical traffic, lighting, target types, and camera operation | Establish the common workload and baseline behavior. |
| Difficult | Night, glare, weather, crowding, occlusion, distant targets, motion | Test the conditions most likely to reduce useful evidence. |
| Failure | Known misses, false positives, empty scenes, look-alike objects | Expose model and rule boundaries instead of hiding them. |
| Transitions | Day to night, scene changes, restarts, stream profile changes | Check recovery and state continuity around system changes. |
Keep original clips whenever possible. Transcoding can change resolution, frame timing, GOP structure, bitrate, and compression artifacts. If the footage is exported from a VMS, record how it differs from the live stream the edge device will consume.
Use stable file names or a manifest so each result can be traced to the source camera and condition. That traceability matters when a model version or camera configuration changes.
Offline footage is useful for comparing model behavior on repeatable evidence. It is not a substitute for the live system test. A production pipeline must also decode the actual RTSP stream, handle timestamps and reconnects, run concurrent cameras, and deliver events and evidence.
Use two linked test tracks. The model track measures detections, misses, false alerts, and condition-specific behavior. The system track measures decode stability, end-to-end timing, compute, memory, storage, outputs, and recovery. The edge AI box sizing guide covers the second track in detail.
Reuse the point when representative footage preserves the required evidence and the live stream passes access and stability checks. Reconfigure the stream or camera when a tested change to profile, exposure, focus, lens, angle, or lighting solves a measured problem.
Change or add the camera point when the target remains too small, hidden, backlit, or visible at the wrong stage of the workflow. Model tuning cannot recover evidence that the image never captured. For help with that decision, see when to add an edge AI camera to existing CCTV.
If you can provide the task definition, sample matrix, original clips, and stream metadata, ask CamThink to review the footage set and NG4500 PoC path.
Use enough footage to contain several representative events and the context around them. Coverage across conditions matters more than producing one very long file.
Yes for initial model review, provided the export method is documented. The live system still needs to be tested because the VMS export may differ from the RTSP stream in timing, codec, resolution, or compression.
No. Keep and label them. Failure and ambiguous samples reveal whether the camera view, model, business rule, or review workflow needs to change.
No. Footage can help define the workload, but capacity must be measured with concurrent decode, inference, analytics, storage, outputs, and operating headroom.
A Jetson Orin edge AI box for evaluating local video analytics pipelines across selected IP camera streams.
