RTSP Inspector Community and Professional License
Community (free)
Basic RTSP stream analysis:
- Connect to RTSP streams
- View DESCRIBE/SETUP/PLAY exchange
- SDP inspection
- Basic RTP packet view
- TCP interleaved transport
Professional
Full RTSP diagnostic workbench:
- Everything in Community
- RTP/RTCP over UDP unicast
- Full RTP packet decode (H.264, H.265, AAC, metadata)
- Session save and replay (.risession)
- Session comparison
- PCAP, PCAPNG, and CAP import through the replay workflow
- Markdown, HTML, PDF, and evidence report export
- RTCP sender/receiver report analysis
- Diagnostic cockpit with timeline
One-time purchase. No subscription. Works offline.
Capability boundary from the current catalog
| Task | Community | Professional |
|---|---|---|
| Inspect RTSP, RTP, and RTCP evidence | Yes | Yes |
| Decode H.264 evidence | Yes | Yes |
| Export JSON | Yes | Yes |
| Decode H.265 evidence | No | Yes |
| Save and replay cases | No | Yes |
| Compare sessions and use the case library | No | Yes |
| Export Markdown, HTML, PDF, and evidence reports | No | Yes |
| Use batch, advanced network, or advanced codec workflows | No | Yes |
The catalog is the capability source of truth. This page does not promise that every camera, payload, transport, codec variation, damaged packet, or encrypted stream will decode perfectly. Professional expands the diagnostic and evidence workflow; it does not turn a network trace into an original media file or make an unsupported protocol automatically supported.
Choose an edition from the job
Use Community when the task is to connect to an authorized RTSP endpoint, inspect negotiation, review SDP, follow RTP/RTCP behavior, decode supported H.264 evidence, and retain a JSON result. That path is enough for many first-pass diagnostics.
Choose Professional when the case must be saved and reopened, replayed, compared with another session, organized in a case library, decoded with H.265 support, processed in a batch or advanced workflow, or handed off as a richer report. Do not upgrade merely because an error exists; first identify which paid capability removes a real boundary.
Review the RTSP Inspector help index and troubleshooting guide before deciding that a license state caused a connection or media problem.
Local use and surrounding network activity
The installed diagnostic workbench and saved case workflow are designed for local use. An RTSP connection itself communicates with the camera or server being tested. Installation, updates, checkout, license activation, support, and optional services can also require a network. “Works offline” should therefore mean that an already prepared local case can use the applicable local capabilities, not that every product lifecycle action or live camera test has no network.
Users remain responsible for authorization to access the stream, credentials, exported evidence, camera addresses, personally identifiable content, retention, and deletion. A paid license does not grant permission to inspect someone else’s system or distribute captured media.
License and workflow QA
- The exact diagnostic job is written down.
- Community and Professional capabilities are read from the current catalog.
- A connectivity or codec failure is not automatically blamed on licensing.
- Sensitive URLs, credentials, payloads, and reports stay in an approved location.
- A saved Professional case is closed and reopened before relying on it.
- A replay or comparison preserves the intended source and time context.
- Exported JSON, Markdown, HTML, PDF, or evidence output is reopened and reviewed.
- The target recipient and retention rule are known before handoff.
- Current checkout and activation terms are checked on the license page.
Frequently asked questions
Is Community only a demo?
No. It contains the core RTSP, RTP, RTCP, H.264, and JSON evidence path defined by the current catalog. Professional adds the advanced persistence, reporting, H.265, comparison, batch, network, codec, and knowledge workflows.
Does Professional fix every “no video” case?
No. Authentication, URL, SDP, transport, firewall, NAT, packet loss, payload mapping, codec, and server behavior can all be responsible. Use the no-video diagnostic guide to identify the failing boundary.
Is the license a subscription?
The current public offer is described as a one-time license. Always verify the live checkout terms before purchase rather than relying on a copied price or an old screenshot.
Can a license be shared with a team?
Use the current Team offer and activation terms when several people or machines need access. Do not copy a single-seat credential beyond its permitted scope.
<!-- multilingual-help-closeout:start -->Direct answer and acceptance boundary
For “RTSP Inspector Community and Professional License”, the short answer is: Understand what the RTSP Inspector Community edition includes and which advanced RTP/RTCP decoding, replay, comparison, and export workflows are optional. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in RTSP Inspector.
Evidence-first operating procedure
Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.
Checkpoint 1: RTSP Inspector Community and Professional License
Treat “RTSP Inspector Community and Professional License” as a separate acceptance gate for “RTSP Inspector Community and Professional License”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.
Checkpoint 2: Understand what the RTSP Inspector Community edition includes and which advanced RTP/RTCP
Verify “Understand what the RTSP Inspector Community edition includes and which advanced RTP/RTCP decoding, replay, comparison, and export workflows are optio” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.
Checkpoint 3: Community (free)
For “Community (free)”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.
Checkpoint 4: Professional
Use “Professional” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.
Checkpoint 5: Capability boundary from the current catalog
When “Capability boundary from the current catalog” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.
Checkpoint 6: Choose an edition from the job
Close “Choose an edition from the job” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.
Checkpoint 7: Local use and surrounding network activity
Treat “Local use and surrounding network activity” as a separate acceptance gate for “RTSP Inspector Community and Professional License”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.
Checkpoint 8: License and workflow QA
Verify “License and workflow QA” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.
Checkpoint 9: Frequently asked questions
For “Frequently asked questions”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.
Checkpoint 10: Is Community only a demo?
Use “Is Community only a demo?” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.
Acceptance matrix
| Checkpoint | Evidence to retain | Pass condition |
|---|---|---|
| RTSP Inspector Community and Professional License | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Understand what the RTSP Inspector Community edition includes and which advanced RTP/RTCP decoding, replay, comparison, | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Community (free) | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Professional | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Capability boundary from the current catalog | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Choose an edition from the job | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
Failure isolation, recovery, and handoff
If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.
Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.
Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.
Questions and answers
What is the fastest reliable way to start?
Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.
What evidence should be saved?
Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.
When should the procedure be repeated?
Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.
When is the task ready for handoff?
It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.
Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-help-closeout:end -->