Skip to content
RimwardDocumentation
Rimward.ai

Understand the result

Think of video as a delivery. The endpoint must answer. It must allow access. It must send useful video data. The receiving computer must decode the data.

Four separate questions: can the device answer, does it allow access, can this computer read video, and does video keep arriving?

Scroll the diagram to see all steps. Open diagram at full size

Each question has its own result. One Pass does not pass all four checks.

Each stage provides different evidence. A successful connection does not establish working video.

States

StateMeaningExample
PassThe tested condition succeeded.A received H.264 frame was decoded.
FindingThe test observed a problem.The endpoint rejected the supplied viewing account.
UnknownThe available evidence is insufficient.The sample ended before reception could be verified.
Not checkedThe check was not performed.Video could not be tested after a connection failure.
Not applicableReserved for a condition that does not apply to a test.The four current checks do not emit this state.

An agent must keep these states when it explains the report. It can suggest a cause or next test, but it must label that suggestion. Missing evidence is not a pass.

Checks

IDEvidenceLimits
reachabilityWhether this computer opened the supplied TCP connection.A pass does not identify the service. A failure does not establish power state or the failed network component.
accessThe response to the requested video access.A protected feed without supplied credentials needs further access information.
mediaSupported media description and actual decoded video frames.A decoder dependency failure is local to the runner. Unsupported video is outside this method.
receptionReceived media and measured gaps during the bounded sample.It does not establish long-term uptime or site capacity for concurrent feeds.

For JSON fields and measured values, read Advanced commands and structured output.

Comparison

Before comparing reports, use the same feed configuration, receiving computer, intended network viewpoint, and sampling settings. Corrected approved credentials can differ; they are intentionally excluded from the fingerprint. Record any network/VPN or account changes with the repair. Glassknock rejects mismatched target fingerprints, runner IDs, or rules versions. The after report must start strictly later than the before report. The tool cannot detect every network or account change.

BeforeAfterInterpretation
FindingPassResolved in this repeat test.
FindingFindingPersistent problem.
PassFindingNew problem.
FindingUnknown or not testedNot reverified.
Any stateMissing or incompatible reportThe reports cannot establish a fix.

The tool also checks basic report evidence. Requested durations must be valid and match. A media or reception pass needs a positive observation duration, received packets, and decoded frames. A completed reception pass must cover the requested duration. A reception pass cannot include media decode errors or local queue drops. An incomplete after run cannot resolve a prior finding, even when one earlier step passed. These checks detect inconsistent data; they do not authenticate a hand-edited report.

“Resolved” refers to the tested condition. It does not certify the camera, the whole site, recording, or security. For example, restoring a feed to this computer does not prove the remote monitoring provider receives it.

Words used in these guides

WordSimple meaning
EndpointThe address and video path that the receiver requests.
Runner/viewpointThe computer running the test and its network position.
RTSPA protocol used to request and control a video feed.
RTSPSRTSP carried through an encrypted connection.
TCPThe connection used to carry this release’s video data.
H.264The video coding method supported by this release.
DecodeTurn received video data into frames that software can read.
GapA period without received media data.