Quick answer: “ONVIF compatible” is not a complete feature specification. Check the official conformance record for the exact product and firmware/software version, identify the functions required on both device and client, then test the actual integration before promising it.
On this page
What do profiles S, T, G and M cover?
A camera can be the device sending information and a recorder or application the client using it. Profiles group interface requirements; they do not mean every product has every optional feature. Read the profile documentation and the actual implementation scope on both sides.
| Profile | Main scope | What still needs checking |
|---|---|---|
| S | Basic video streaming/configuration. | Actual device/client conformance and supported optional functions; plan the announced move toward Profile T. |
| T | Advanced video streaming, including H.264/H.265-related features, imaging/events and metadata interfaces. | The exact mandatory/conditional capabilities on both sides; do not promise every optional feature or encryption mode. |
| G | Recording control and retrieval, including edge-storage-related workflows. | Whether the camera and client implement the required recording/retrieval path and actually recover the footage you need. |
| M | Analytics metadata and events. | The data a producer exposes and a consumer can interpret/use; the profile does not add an analytic the device lacks. |
What is changing for Profile S?
ONVIF states that the last date for Profile S product-conformance submissions is March 31, 2027 and recommends Profile T as its replacement. This is not a date when all installed Profile S systems automatically stop working. ONVIF’s deprecation Q&A distinguishes existing conformance/integrations from future vendor firmware decisions.
For a new or changing system, ask which supported authentication and integration path the suppliers recommend. Recheck before a firmware change rather than assuming an older Profile S result remains the whole answer.
How do you verify a conformance claim?
- Open the official ONVIF Conformant Products database.
- Match the manufacturer/product identity and the specific firmware or software version listed.
- Record whether the entry is a device or client and which profiles are listed.
- Keep the date and record/reference with the project’s version inventory.
- If the exact item/version cannot be matched, ask for clarification; membership or a generic logo is not a substitute.
A catalogue may state an interface or profile. Preserve that as the supplier’s printed statement, but do not relabel it independently verified conformance without the matching evidence.
Why can video work while another function fails?
The requested stream may be supported while an event, analytics field, audio direction, PTZ action or retrieval path is not implemented as required on the other side. Some features also depend on settings, permissions, licensing or a native integration. Identify the missing function instead of diagnosing every issue as “ONVIF doesn’t work.”
Profile M does not create facial recognition, licence-plate recognition or another analytic in a camera that lacks it. Nor does a stream prove that a client can search, display or act on all available metadata. A named integration test is more useful than a general compatibility claim.
| Function required | Test and evidence | Result/owner |
|---|---|---|
| Discovery and onboarding | Exact camera/NVR/client models and firmware; supported account and discovery path. | Pass/Open; owner and date. |
| Live view and recording | Required stream, codec, resolution/frame rate and stable recording under the planned load. | Record actual settings and observed limitation. |
| Playback and export | Find and export an agreed event; check time and required audio tracks where approved. | Keep a non-sensitive test record. |
| Events and analytics | Trigger each required event and verify the expected receiver action/metadata. | Do not substitute “video works” for an analytics test. |
| Recovery and changes | Supported restart/reconnection, time settings and the planned firmware change process. | Document the supported procedure and any untested behavior. |
How should the result be written in a proposal?
State the tested model/version pair, required functions, settings and limitations. Distinguish a supplier statement from a bench test and a site acceptance test. Avoid “works with all ONVIF cameras” when only live streaming from one unit was demonstrated.
For troubleshooting, use the ONVIF connection troubleshooting guide. Keep the firmware maintenance record and handover checklist aligned with the tested version combination.
FAQ
Does a Profile T label guarantee every optional function?
No. Check the required device/client capabilities and test the specific workflow.
Does an ONVIF stream prove all AI features will transfer between brands?
No. Identify the event and metadata interfaces and the receiving product’s support. Confirm native integrations separately where required.
What if the catalogue and database version differ?
Keep both facts in the record and ask the supplier to clarify the exact delivered version. Do not silently substitute a different version in the claim.
What should you send Anabon before equipment selection?
Send the exact camera/NVR/client models, firmware/software versions, database record if available and a list of required functions. A short sample workflow is more useful than “ONVIF compatible?”. For model-specific questions, contact Anabon technical support. Use Anabon Downloads for available product resources. Compare network video recorders after the requirements and evidence needed for acceptance are clear.
References
References checked October 21, 2026. Confirm the current requirements for the actual project before a commitment.
