Калькулятор сховища CCTV / NVR

1. Як оцінюється бітрейт

Замість використання загальних усереднених таблиць цей оцінювач сховища камер застосовує динамічну модель розрахунку, щоб змоделювати споживання смуги пропускання на основі реальних показників продуктивності камери.

Основна формула активної пропускної здатності камери визначається так:

Bitrate_Active = baseBR × fpsFactor × K_Codec × K_Scene

Базовий бітрейт (baseBR)

Базове навантаження на інфраструктуру розраховується безпосередньо з роздільної здатності сенсора:

baseBR = Resolution (MP) × 1.3

Приклад застосування: Стандартна камера Full HD 1080p (приблизно 2.07 MP), що працює на базовій частоті 15 FPS зі стандартним стисненням H.264 і середньою складністю сцени, дає: 2.07 × 1.3 × 1.0 × 1.0 приблизно 2.69 Mbit/s Цей коефіцієнт — емпірична базова величина, виведена з посібників із планування від виробників, щоб забезпечити оптимальну щільність пікселів під час активного спостереження.

Масштабування частоти кадрів (fpsFactor)

Масштабування смуги пропускання не змінюється лінійно зі зміною частоти кадрів (FPS). Оскільки сучасні кодери фіксують часові відмінності між кадрами, а не передають послідовно повні статичні зображення, подвоєння частоти кадрів дає сублінійний вплив на загальний обсяг. Рушій застосовує степеневу криву, щоб точно змоделювати цю поведінку:

fpsFactor = (FPS / 15)^0.45

Цей коефіцієнт масштабування дозволяє уникнути надмірного резервування ємності під час проєктування високочастотних (30 fps) систем.

2. Вимоги до сховища H.264 проти H.265

Ефективність стиснення відео змінюється залежно від рівня шуму навколишнього середовища та ентропії руху.

Модифікатори складності сцени (K_Scene)

• Низька (× 0.7): Середовища з контрольованим доступом і мінімальним зсувом пікселів (наприклад, тихі склади або нічні внутрішні коридори).
• Середня (× 1.0): Стандартні торгові середовища чи комерційні приміщення з помірним потоком людей.
• Висока (× 1.4): Динамічні відкриті середовища без обмежень, схильні до постійного руху (наприклад, жваві перехрестя, натовпи, листя, що коливається, або змінне освітлення). Високий рівень шуму обмежує ефективність міжкадрового стиснення.

3. Вплив детекції руху

Коли ввімкнено конфігурації запису за рухом, платформа застосовує двостановий робочий цикл. У періоди бездіяльності потік даних знижується до заданої користувачем межі FPS у спокої й опускає складність сцени до абсолютного мінімуму (0.7). Чиста часова потреба розраховується так:

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

Де M — оцінений відсоток активності руху протягом стандартного 24-годинного циклу. Крім того, якщо вибрано захоплення звуку, до активного бюджету додається незмінне виділення 64 kbit/s (0.064 Mbit/s) на камеру для врахування стандартних аудіопотоків G.711 PCM.

4. Накладні витрати сховища RAID

Планування фізичних дисків виходить за межі суто математичного обсягу. Вбудований модуль калькулятора RAID для CCTV використовує стандартні відмовостійкі масиви, щоб точно визначити, скільки рівнів сховища потрібно придбати:

• RAID 1: Чиста дзеркальна архітектура. Накладні витрати на надмірність вимагають рівно 2.0 × чистого обсягу, обмежено рівно N=2 дисками.
• RAID 5: Одинарна розподілена парність. Потребує щонайменше 3 дисків. Втрата на виділення сховища точно дорівнює 1 диску: N / (N - 1).
• RAID 6: Подвійна розподілена парність. Потребує щонайменше 4 дисків. Переживає дві одночасні відмови дисків, резервуючи два диски під дані парності: N / (N - 2).
• RAID 10: Комбінований дзеркально-чергувальний масив. Потребує щонайменше 4 дисків і строго обмежений парними конфігураціями (N mod 2 = 0). Половина фізичної ємності (50%) йде на накладні витрати.

Розрахунок дисків: Рушій ділить загальну відмовостійку потребу на кількість дисків (N) і автоматично зіставляє результат зі стандартними кроками комерційного ряду HDD (наприклад, 2, 4, 6, 8, 12, 16, 20 TB).

5. Накладні витрати сховища та файлової системи

Базовий параметр накладних витрат (рекомендовано 15%) включено до процесу розрахунку сховища відеоспостереження, щоб поглинути системні втрати ємності:

1. Двійково-десяткове перетворення: Виробники HDD обчислюють обсяг у десятковій системі (10^12 байтів на TB), тоді як операційні системи форматують масиви у двійковій (1024^3 байтів на TB). Ця системна невідповідність зменшує фізичну ємність диска приблизно на 7.3%.
2. Журналювання метаданих: Файлові системи (такі як EXT4 чи XFS) виділяють частину блоків сховища під індексацію метаданих, таблиці відновлення файлів і відображення секторів.
3. Захисні буфери: Масиви сховища NVR втрачають ефективність запису, коли повністю заповнені; зберігання стандартного буфера 5–10% запобігає погіршенню продуктивності під час планового автоматичного очищення дисків за FIFO.

6. Межі пропускної здатності NVR

Калькулятор видає попередження про оптимізацію, якщо сумарна пропускна здатність вашої системи перевищує 320 Mbit/s.

Хоча стандартні гігабітні інтерфейси справляються з вищими рівнями сирих даних, 320 Mbit/s відповідає типовій межі пропускної здатності запису багатьох комерційних NVR-платформ середнього класу. Перевищення цієї межі створює вузьке місце у внутрішніх шляхах обробки system-on-chip або у швидкості запису рушія бази даних сховища. Це безпосередньо призводить до втрати кадрів відео, нестабільності потоку чи затримок відтворення. Системи, що працюють понад цей поріг, потребують розділених мережевих схем на кілька вузлів NVR або переходу на високопродуктивне обладнання проєктного рівня.