{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "item": { "id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "slug": "prove-frame-rate-at-the-recorder-not-only-at-the-camera", "url": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera.md", "json": "https://update.dsesecurity.com/api/v1/posts/prove-frame-rate-at-the-recorder-not-only-at-the-camera/" }, "title": "Prove frame rate at the recorder, not only at the camera", "summary": "A camera setting does not guarantee the same frame rate reaches storage. Validate the entire path under representative load and with production image features enabled.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:36:09+00:00", "modified_at": "2026-08-25T21:36:16+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 441, "potentially_affected": "Systems with evidentiary or analytic tasks that depend on a controlled minimum frame rate through cameras, networks, recorders, and clients.", "dse_recommendation": "Measure recorded frame cadence during the hardest production condition and record any feature, network, or VMS setting that can reduce it.", "primary_source": { "name": "Controlled full frame rate", "url": "https://whitepapers.axis.com/en-us/controlled-full-frame-rate", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: the frame-rate value shown in a camera interface is an instruction or limit, not proof of the cadence stored by the recorder. Processing load, competing streams, network capacity, VMS configuration, and recording load can change the result.

\n

Source fact: full frame rate depends on the complete system

\n

Axis’s Controlled full frame rate paper states that a configured frame rate cannot be guaranteed through a system without sufficient capacity across the path. It identifies camera features and processing demands that may affect available performance, including analytics, electronic image stabilization, audio, and distortion correction. It also notes that VMS configuration can alter device settings.

\n

The acceptance point is therefore the recorded and retrievable result. A live client can look smooth while the archive is thinner, or a recorder can meet the target during daytime and fall below it when night processing and motion increase.

\n

Source boundary and applicability

\n

The paper describes Axis technology and considerations; it is not a performance guarantee for any product combination. The necessary cadence depends on the security task, exposure time, motion, compression, resolution, scene complexity, and whether an analytics engine samples the same stream. A higher number is not automatically better evidence.

\n

Applicability questions

\n\n

DSE recommendation: test cadence where evidence is consumed

\n

The following steps are DSE recommendations based on the cited source.

\n

Define the required minimum from the operational task, then stage representative motion with production resolution, exposure, compression, analytics, stabilization, audio, privacy, and secondary streams enabled. Create normal and peak-load tests, including the lighting condition that produces the highest processing or bitrate demand. Retrieve the archive through the normal investigator workflow and measure actual presentation timestamps or inter-frame intervals rather than judging smoothness by eye.

\n

If the target is missed, change one constrained resource or feature at a time and document the tradeoff. Protect the accepted camera profile from undocumented VMS overwrites. Use change control because reducing exposure, resolution, analytics, or other image functions may solve cadence while degrading the original task.

\n

Verification and evidence

\n

Retain the task requirement, camera and recorder exports, feature list, topology, utilization samples, retrieved native clip, measurement method, measured minimum and distribution, test scene, and approval of any tradeoff. Repeat after firmware, VMS, stream-profile, analytics, switch, server, or storage changes.

\n

Official references

\n", "content_text": "Bottom line: the frame-rate value shown in a camera interface is an instruction or limit, not proof of the cadence stored by the recorder. Processing load, competing streams, network capacity, VMS configuration, and recording load can change the result.\nSource fact: full frame rate depends on the complete system\nAxis’s Controlled full frame rate paper states that a configured frame rate cannot be guaranteed through a system without sufficient capacity across the path. It identifies camera features and processing demands that may affect available performance, including analytics, electronic image stabilization, audio, and distortion correction. It also notes that VMS configuration can alter device settings.\nThe acceptance point is therefore the recorded and retrievable result. A live client can look smooth while the archive is thinner, or a recorder can meet the target during daytime and fall below it when night processing and motion increase.\nSource boundary and applicability\nThe paper describes Axis technology and considerations; it is not a performance guarantee for any product combination. The necessary cadence depends on the security task, exposure time, motion, compression, resolution, scene complexity, and whether an analytics engine samples the same stream. A higher number is not automatically better evidence.\nApplicability questions\n\nWhat minimum recorded cadence does the observation, recognition, transaction, or forensic task actually require?\nWhich stream is archived, and can the VMS override camera frame-rate or profile settings?\nWhich features are enabled simultaneously on the camera?\nWhat are the peak camera, switch, uplink, recorder, storage, and client loads?\nDo event mode, low light, multiple viewers, or an export change performance?\n\nDSE recommendation: test cadence where evidence is consumed\nThe following steps are DSE recommendations based on the cited source.\nDefine the required minimum from the operational task, then stage representative motion with production resolution, exposure, compression, analytics, stabilization, audio, privacy, and secondary streams enabled. Create normal and peak-load tests, including the lighting condition that produces the highest processing or bitrate demand. Retrieve the archive through the normal investigator workflow and measure actual presentation timestamps or inter-frame intervals rather than judging smoothness by eye.\nIf the target is missed, change one constrained resource or feature at a time and document the tradeoff. Protect the accepted camera profile from undocumented VMS overwrites. Use change control because reducing exposure, resolution, analytics, or other image functions may solve cadence while degrading the original task.\nVerification and evidence\nRetain the task requirement, camera and recorder exports, feature list, topology, utilization samples, retrieved native clip, measurement method, measured minimum and distribution, test scene, and approval of any tradeoff. Repeat after firmware, VMS, stream-profile, analytics, switch, server, or storage changes.\nOfficial references\n\nControlled full frame rate – Axis Communications", "content_markdown": "Bottom line: the frame-rate value shown in a camera interface is an instruction or limit, not proof of the cadence stored by the recorder. Processing load, competing streams, network capacity, VMS configuration, and recording load can change the result.\n\n## Source fact: full frame rate depends on the complete system\n\nAxis’s [Controlled full frame rate](https://whitepapers.axis.com/en-us/controlled-full-frame-rate) paper states that a configured frame rate cannot be guaranteed through a system without sufficient capacity across the path. It identifies camera features and processing demands that may affect available performance, including analytics, electronic image stabilization, audio, and distortion correction. It also notes that VMS configuration can alter device settings.\n\nThe acceptance point is therefore the recorded and retrievable result. A live client can look smooth while the archive is thinner, or a recorder can meet the target during daytime and fall below it when night processing and motion increase.\n\n## Source boundary and applicability\n\nThe paper describes Axis technology and considerations; it is not a performance guarantee for any product combination. The necessary cadence depends on the security task, exposure time, motion, compression, resolution, scene complexity, and whether an analytics engine samples the same stream. A higher number is not automatically better evidence.\n\n## Applicability questions\n\n- What minimum recorded cadence does the observation, recognition, transaction, or forensic task actually require?\n\n- Which stream is archived, and can the VMS override camera frame-rate or profile settings?\n\n- Which features are enabled simultaneously on the camera?\n\n- What are the peak camera, switch, uplink, recorder, storage, and client loads?\n\n- Do event mode, low light, multiple viewers, or an export change performance?\n\n## DSE recommendation: test cadence where evidence is consumed\n\nThe following steps are DSE recommendations based on the cited source.\n\nDefine the required minimum from the operational task, then stage representative motion with production resolution, exposure, compression, analytics, stabilization, audio, privacy, and secondary streams enabled. Create normal and peak-load tests, including the lighting condition that produces the highest processing or bitrate demand. Retrieve the archive through the normal investigator workflow and measure actual presentation timestamps or inter-frame intervals rather than judging smoothness by eye.\n\nIf the target is missed, change one constrained resource or feature at a time and document the tradeoff. Protect the accepted camera profile from undocumented VMS overwrites. Use change control because reducing exposure, resolution, analytics, or other image functions may solve cadence while degrading the original task.\n\n## Verification and evidence\n\nRetain the task requirement, camera and recorder exports, feature list, topology, utilization samples, retrieved native clip, measurement method, measured minimum and distribution, test scene, and approval of any tradeoff. Repeat after firmware, VMS, stream-profile, analytics, switch, server, or storage changes.\n\n## Official references\n\n- [Controlled full frame rate](https://whitepapers.axis.com/en-us/controlled-full-frame-rate) – Axis Communications" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "url": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Prove frame rate at the recorder, not only at the camera", "item": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/#article", "identifier": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "url": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/", "headline": "Prove frame rate at the recorder, not only at the camera", "description": "A camera setting does not guarantee the same frame rate reaches storage. Validate the entire path under representative load and with production image…", "abstract": "A camera setting does not guarantee the same frame rate reaches storage. Validate the entire path under representative load and with production image features enabled.", "articleBody": "Bottom line: the frame-rate value shown in a camera interface is an instruction or limit, not proof of the cadence stored by the recorder. Processing load, competing streams, network capacity, VMS configuration, and recording load can change the result.\nSource fact: full frame rate depends on the complete system\nAxis’s Controlled full frame rate paper states that a configured frame rate cannot be guaranteed through a system without sufficient capacity across the path. It identifies camera features and processing demands that may affect available performance, including analytics, electronic image stabilization, audio, and distortion correction. It also notes that VMS configuration can alter device settings.\nThe acceptance point is therefore the recorded and retrievable result. A live client can look smooth while the archive is thinner, or a recorder can meet the target during daytime and fall below it when night processing and motion increase.\nSource boundary and applicability\nThe paper describes Axis technology and considerations; it is not a performance guarantee for any product combination. The necessary cadence depends on the security task, exposure time, motion, compression, resolution, scene complexity, and whether an analytics engine samples the same stream. A higher number is not automatically better evidence.\nApplicability questions\n\nWhat minimum recorded cadence does the observation, recognition, transaction, or forensic task actually require?\nWhich stream is archived, and can the VMS override camera frame-rate or profile settings?\nWhich features are enabled simultaneously on the camera?\nWhat are the peak camera, switch, uplink, recorder, storage, and client loads?\nDo event mode, low light, multiple viewers, or an export change performance?\n\nDSE recommendation: test cadence where evidence is consumed\nThe following steps are DSE recommendations based on the cited source.\nDefine the required minimum from the operational task, then stage representative motion with production resolution, exposure, compression, analytics, stabilization, audio, privacy, and secondary streams enabled. Create normal and peak-load tests, including the lighting condition that produces the highest processing or bitrate demand. Retrieve the archive through the normal investigator workflow and measure actual presentation timestamps or inter-frame intervals rather than judging smoothness by eye.\nIf the target is missed, change one constrained resource or feature at a time and document the tradeoff. Protect the accepted camera profile from undocumented VMS overwrites. Use change control because reducing exposure, resolution, analytics, or other image functions may solve cadence while degrading the original task.\nVerification and evidence\nRetain the task requirement, camera and recorder exports, feature list, topology, utilization samples, retrieved native clip, measurement method, measured minimum and distribution, test scene, and approval of any tradeoff. Repeat after firmware, VMS, stream-profile, analytics, switch, server, or storage changes.\nOfficial references\n\nControlled full frame rate – Axis Communications", "datePublished": "2026-08-25T21:36:09+00:00", "dateModified": "2026-08-25T21:36:16+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Prove frame rate at the recorder, not only at the camera" }, "articleSection": [ "Networks & Infrastructure", "Video Surveillance" ], "keywords": [ "Networks & Infrastructure", "Video Surveillance", "Briefing", "Important priority" ], "genre": "Briefing", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 441, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Controlled full frame rate", "url": "https://whitepapers.axis.com/en-us/controlled-full-frame-rate" } } ] } }