CCTV-/NVR-Speicherrechner

1. Wie die Bitrate geschätzt wird

Anstatt sich auf generische Pauschalwerte zu verlassen, wendet dieser Kamera-Speicherschätzer ein dynamisches Berechnungsmodell an, um den Bandbreitenverbrauch anhand realer Kameraleistungskennzahlen zu simulieren.

Die primäre Formel für den aktiven Kameradurchsatz lautet:

Bitrate_Active = baseBR × fpsFactor × K_Codec × K_Scene

Basisbitrate (baseBR)

Die grundlegende Infrastrukturlast wird direkt aus der Sensorauflösung berechnet:

baseBR = Auflösung (MP) × 1.3

Anwendungsbeispiel: Eine Standard-Full-HD-1080p-Kamera (etwa 2.07 MP), die mit einer Basis von 15 FPS, Standard-H.264-Komprimierung und mittlerer Szenenkomplexität betrieben wird, ergibt: 2.07 × 1.3 × 1.0 × 1.0 ungefähr 2.69 Mbit/s Dieser Koeffizient ist ein empirischer Basiswert aus Planungsleitfäden der Hersteller, um eine optimale Pixeldichte während der aktiven Überwachung sicherzustellen.

Bildratenskalierung (fpsFactor)

Die Bandbreitenskalierung verläuft bei Änderungen der Bildrate (FPS) nicht linear. Da moderne Encoder zeitliche Unterschiede zwischen Frames erfassen, statt vollständige statische Bilder nacheinander zu übertragen, hat eine Verdopplung der Bildrate eine unterlineare Auswirkung auf das Gesamtvolumen. Die Engine wendet eine Potenzgesetz-Kurve an, um dieses Verhalten präzise zu modellieren:

fpsFactor = (FPS / 15)^0.45

Dieser Skalierungsfaktor verhindert eine Überdimensionierung der Kapazität bei der Planung von hochfrequenten (30 fps) Installationen.

2. Speicherbedarf von H.264 vs. H.265

Die Effizienz der Videokomprimierung ändert sich je nach Umgebungsrauschen und Bewegungsentropie.

Szenenkomplexitäts-Modifikatoren (K_Scene)

• Niedrig (× 0.7): Zugangskontrollierte Umgebungen mit minimalen Pixelverschiebungen (zum Beispiel ruhige Lagerhallen oder nächtliche Innenflure).
• Mittel (× 1.0): Standard-Einzelhandelsumgebungen oder Gewerbeflächen mit mäßigem Publikumsverkehr.
• Hoch (× 1.4): Dynamische, uneingeschränkte Außenumgebungen mit ständiger Bewegung (zum Beispiel belebte Kreuzungen, Menschenmengen, sich bewegendes Laub oder wechselndes Licht). Hohes Rauschen begrenzt die Effizienz der Interframe-Komprimierung.

3. Auswirkung der Bewegungserkennung

Wenn die Aufnahme-bei-Bewegung-Konfiguration aktiviert ist, wendet die Plattform einen Zwei-Zustands-Arbeitszyklus an. In Phasen der Inaktivität fällt der Datenstrom auf eine benutzerdefinierte Leerlauf-FPS-Obergrenze und senkt die Szenenkomplexität auf das absolute Minimum (0.7). Der zeitliche Nettobedarf wird berechnet als:

Bitrate_Mean = (Bitrate_Active × M) + (Bitrate_Idle × (1 - M))

Dabei steht M für den geschätzten Prozentsatz der Bewegungsaktivität über einen standardmäßigen 24-Stunden-Zyklus. Ist zusätzlich die Audioaufnahme ausgewählt, wird dem aktiven Budget eine feste Zuteilung von 64 kbit/s (0.064 Mbit/s) pro Kamera hinzugefügt, um standardmäßige G.711-PCM-Audiostreams zu berücksichtigen.

4. RAID-Speicher-Overhead

Die Planung physischer Laufwerke geht über das reine rechnerische Volumen hinaus. Das integrierte CCTV-RAID-Rechner-Modul nutzt standardmäßige fehlertolerante Arrays, um genau zu bestimmen, wie viele Speicherebenen gekauft werden müssen:

• RAID 1: Reine Spiegelarchitektur. Der Redundanz-Overhead erfordert genau 2.0 × Nettovolumen, beschränkt auf genau N=2 Festplatten.
• RAID 5: Einfache verteilte Parität. Erfordert mindestens 3 Laufwerke. Der Speicherverlust entspricht genau 1 Laufwerk: N / (N - 1).
• RAID 6: Doppelte verteilte Parität. Erfordert mindestens 4 Laufwerke. Übersteht zwei gleichzeitige Laufwerksausfälle, indem zwei Laufwerke für Paritätsdaten reserviert werden: N / (N - 2).
• RAID 10: Kombiniertes Spiegel-/Striping-Array. Erfordert mindestens 4 Laufwerke und ist strikt auf gerade Layouts beschränkt (N mod 2 = 0). Die Hälfte der physischen Kapazität (50%) wird für den Overhead verwendet.

Laufwerksberechnung: Die Engine teilt den gesamten fehlertoleranten Bedarf durch die Laufwerksanzahl (N) und gleicht das Ergebnis automatisch mit den üblichen kommerziellen HDD-Abstufungen ab (zum Beispiel 2, 4, 6, 8, 12, 16, 20 TB).

5. Speicher- & Dateisystem-Overhead

Eine grundlegende Overhead-Option (empfohlen bei 15%) ist im Prozess der Videoüberwachungs-Speicherberechnung enthalten, um systematische Kapazitätsverluste auszugleichen:

1. Binär-Dezimal-Umrechnung: HDD-Hersteller berechnen Speicher in Dezimalschreibweise (10^12 Bytes pro TB), während Betriebssysteme Arrays in Binärschreibweise formatieren (1024^3 Bytes pro TB). Diese systembedingte Diskrepanz reduziert die physische Laufwerkskapazität um etwa 7.3%.
2. Metadaten-Journaling: Dateisysteme (wie EXT4 oder XFS) reservieren einen Prozentsatz der Speicherblöcke für die Metadatenindizierung, Dateiwiederherstellungstabellen und das Sektor-Mapping.
3. Schutzbereiche: NVR-Speicher-Arrays verlieren bei völliger Auslastung an Schreibeffizienz; ein üblicher Puffer von 5–10% verhindert Leistungseinbußen während routinemäßiger automatisierter FIFO-Festplattenbereinigungen.

6. NVR-Durchsatzgrenzen

Der Rechner löst eine Optimierungswarnung aus, wenn der aggregierte Systemdurchsatz 320 Mbit/s überschreitet.

Während Standard-Gigabit-Schnittstellen höhere Rohdatenmengen bewältigen, stellen 320 Mbit/s die typischen Aufnahmedurchsatzgrenzen vieler kommerzieller NVR-Plattformen der Mittelklasse dar. Eine Überschreitung dieser Grenze führt zu Engpässen in den internen System-on-Chip-Verarbeitungspfaden oder bei der Schreibgeschwindigkeit der Speicherdatenbank-Engine. Das führt direkt zu verlorenen Videoframes, instabilen Streams oder verzögerter Wiedergabe. Systeme, die über diese Schwelle hinaus arbeiten, erfordern aufgeteilte Netzwerklayouts über mehrere NVR-Knoten oder ein Upgrade auf durchsatzstarke Hardware in Projektqualität.