Kalkulator przepustowości sieci i pojemności dysków dla kamer IP

Ten kalkulator przepustowości sieci i pojemności dysków dla kamer IP liczy w czterech krokach, ile strumieni zmieści się na łączu i ile miejsca zajmą nagrania. Krok Bitrate wideo wyznacza bitrate każdego typu strumienia, krok Ruch w sieci dolicza nagłówki pakietów i sumuje ruch wszystkich strumieni, krok Wykorzystanie łącza porównuje go z przepustowością łącza i planowanym limitem oraz podaje, ile strumieni jeszcze się zmieści, a krok Miejsce na nagrania podaje pojemność dysków potrzebną na nagrania. Każdy krok korzysta z wyników poprzednich.

Na końcu strony wyniki można pobrać jako plik PNG lub skopiować jako tekst.

Kalkulator: Jacek Garbuliński, Blixild. Aktualizacja: 13 października 2026 r.

Przykład obliczeń

Po otwarciu kalkulator pokazuje przykład: 16 kamer na łączu 1 Gb/s z limitem 70%, RTSP przez TCP (ang. Real Time Streaming Protocol, Transmission Control Protocol) i IPv4, ruch w kadrze 25%, nagrania przez 30 dni. Każda kamera wysyła strumień główny 2560 × 1440 pikseli w H.265, 25 klatek na sekundę, z limitem VBR (zmienny bitrate) 4,096 Mb/s i klatką kluczową co 1 s, nagrywany na dysk, oraz strumień pomocniczy 640 × 360 pikseli w H.264, 15 klatek na sekundę, z limitem 0,448 Mb/s i klatką kluczową co 1 s, do podglądu. Ruch w sieci wynosi 22,29 Mb/s, czyli 2,229% łącza, z zapasem 677,7 Mb/s do limitu. Nagrania zajmują 198,2 GB na dobę i 5,945 TB przez 30 dni.

Bitrate wideo

Ten krok wyznacza bitrate wideo każdego typu strumienia z ustawień kamery i ruchu w kadrze.

Każdy strumień, który serwer pobiera z kamery, generuje osobny ruch. Jeśli nagrywasz strumień główny, a do podglądu pobierasz strumień pomocniczy, dodaj oba typy.

Podaj bitrate z ustawień kamery: w trybie CBR (stały bitrate, ang. constant bit rate) ustawioną wartość, w trybie VBR (zmienny bitrate, ang. variable bit rate) górny limit.

Co ile klatek kamera wysyła pełny obraz, czyli długość grupy obrazów GOP (ang. group of pictures). Dekodowanie obrazu zaczyna się od klatki kluczowej, dlatego przy ustawieniu co 1 s podgląd na żywo i przełączenie kamery czekają na obraz najwyżej sekundę; to typowy wybór, gdy liczy się szybka reakcja. Przy ustawieniu co 2 s oczekiwanie wydłuża się do 2 s, ale klatek kluczowych jest o połowę mniej, co obniża bitrate i miejsce na nagrania, najbardziej w scenach z małym ruchem.

Wybór wpisuje do pola bitrate’u wartość startową, którą możesz zmienić; wartości wpisanej przez Ciebie kalkulator nie zmienia. Wartości startowe pochodzą z tabeli zaleceń Hikvision, dla najbliższej liczby klatek na sekundę nie mniejszej od ustawionej; powyżej 30 klatek na sekundę przyjmujemy wartość dla 30. Przy rozdzielczości „własna” podaj bitrate z ustawień kamery.

Ruch w kadrze,

m

Część obrazu, która zmienia się między klatkami, od 0% (obraz bez zmian) do 100% (największy możliwy ruch). Dotyczy limitu VBR; bitrate CBR jest stały.

Strumień metadanych ONVIF

Metadane ONVIF (ang. Open Network Video Interface Forum), np. wyniki analityki obrazu: podaj bitrate na kamerę z jej statystyk strumienia i liczbę komunikatów na sekundę.

Strumień główny

R_w

1,147 Mb/sna strumień; 16 strumieni: 18,35 Mb/s

Strumień pomocniczy

R_w

0,1344 Mb/sna strumień; 16 strumieni: 2,150 Mb/s

Wideo łącznie20,50 Mb/sliczba strumieni: 32

Bitrate wideo jednego strumienia w zależności od ruchu w kadrze

Równania

R_w = R_{\max}\,\frac{1 + m\,(G - 1)}{G}

$R_w$ to bitrate wideo jednego strumienia w Mb/s, a $R_{\max}$ limit VBR z ustawień kamery. $G$ to liczba klatek między klatkami kluczowymi, a $m$ ruch w kadrze od 0 do 1: przy $m = 0$ dane niosą tylko klatki kluczowe, przy $m = 1$ każda klatka. W trybie CBR (stały bitrate) $R_w$ jest stały i równy ustawionej wartości.

Założenia

Przy największym ruchu każda klatka zajmuje tyle co klatka kluczowa, czyli cały limit bitrate’u; bez ruchu dane niosą tylko klatki kluczowe, a klatki pośrednie traktujemy jako puste.
Między tymi skrajnościami bitrate rośnie liniowo z częścią obrazu, która się zmienia; to założenie modelu, nie pomiar.
Przy tej samej jakości subiektywnej koder HEVC (ang. High Efficiency Video Coding, H.265) potrzebuje według Ohma i in. (2012) „approximately 50% less bit rate on average” niż H.264/AVC (ang. Advanced Video Coding); wynik dotyczy koderów referencyjnych i sekwencji testowych, nie kamer.
Wartości startowe to przybliżone zalecenia Hikvision dla jego kamer; według producenta w bardziej złożonych scenach można je zwiększyć o 20 do 30%. Ustawienia innych kamer mogą być niższe lub wyższe, dlatego najdokładniejszy jest bitrate z ustawień Twojej kamery.
Wszystko, co zmienia obraz między klatkami, kodek traktuje jak ruch w kadrze, także szum nocny przy podczerwieni, deszcz, śnieg i drzewa poruszane wiatrem.

Ruch w sieci

Ten krok dolicza do wideo nagłówki pakietów, zależne od protokołu transportu i wersji IP (ang. Internet Protocol), i sumuje ruch wszystkich strumieni.

Korzysta z typów strumieni i bitrate’u wideo z kroku Bitrate wideo.

Narzut pełnego pakietu

B_n / B_w

7,402%68 B nagłówków w pakiecie IP, 106 B z ramką Ethernetu, 1432 B wideo

Strumień główny

R_s

19,88 Mb/s16 strumieni po 1,242 Mb/s, w tym nagłówki 0,09549 Mb/s

Strumień pomocniczy

R_s

2,411 Mb/s16 strumieni po 0,1507 Mb/s, w tym nagłówki 0,01631 Mb/s

Ruch łącznie

R

22,29 Mb/swideo 20,50 Mb/s i nagłówki 1,789 Mb/s

Pełny pakiet w ramce Ethernetu na kablu, w skali, pole po polu

Równania

B_w = 1500 - B_h,

B_n = 1538 - B_w

R_n = R_w\,\frac{B_n}{B_w} + \frac{0{,}5\,f\,B_n \cdot 8}{10^6}

R_s = (R_w + R_n)\,N,

R = \sum R_s

$B_h$ to bajty nagłówków w pakiecie IP, $B_w$ bajty wideo w pełnym pakiecie, a $B_n$ bajty nagłówków na pakiet razem z ramką Ethernetu na kablu (38 B: preambuła i SFD, ang. start frame delimiter, nagłówek, suma kontrolna FCS, ang. frame check sequence, oraz przerwa międzyramkowa). $R_n$ to nagłówki jednego strumienia w Mb/s: nagłówki pełnych pakietów oraz średnio nagłówki połowy pakietu na każdą klatkę, bo ostatni pakiet klatki jest niepełny; dla metadanych ONVIF zamiast $f$ liczymy komunikaty na sekundę.

$R_s$ to ruch $N$ strumieni danego typu, a $R$ ruch wszystkich strumieni w Mb/s.

Założenia

Pakiety mają rozmiar do 1500 B, czyli MTU (ang. maximum transmission unit) Ethernetu, a każdy niesie nagłówki RTP, transportu i IP.
Dla TCP przyjmujemy opcję znaczników czasu (10 B i 2 B wyrównania); bez niej narzut pełnego pakietu jest mniejszy o 0,89 punktu procentowego przy IPv4 i o 0,92 przy IPv6.
Zakładamy pakiety pełnego rozmiaru i jeden niepełny pakiet na klatkę; kamery wysyłające mniejsze pakiety lub dzielące klatkę na kilka wycinków (ang. slices) dodają więcej nagłówków.
Pomijamy nagłówek fragmentacji RTP (2 lub 3 B na pakiet), dźwięk i pakiety kontrolne RTCP (ang. RTP Control Protocol); metadane ONVIF liczą się tylko po włączeniu ich strumienia.
Liczymy jeden kierunek łącza pełnodupleksowego: od kamer do serwera; podgląd pobierany bezpośrednio z kamer to osobny strumień.
Nie uwzględniamy potwierdzeń TCP, znacznika VLAN (ang. virtual local area network), multicastu (wysyłania jednego strumienia do wielu odbiorców) ani ramek jumbo (większych niż 1500 B).

Wykorzystanie łącza

Ten krok porównuje ruch w sieci z przepustowością łącza i planowanym limitem oraz podaje, ile strumieni każdego typu jeszcze się zmieści.

Korzysta z ruchu wszystkich strumieni z kroku Ruch w sieci.

Wykorzystanie łącza

U

2,229%22,29 Mb/s z 1 Gb/s

Zapas do limitu

Z

677,7 Mb/sRuch mieści się w limicie 70%, czyli 700,0 Mb/s.

Strumień główny

n_{\mathrm{dod}}

545jeszcze się zmieści; bez innych strumieni łącze pomieści 563

Strumień pomocniczy

n_{\mathrm{dod}}

4496jeszcze się zmieści; bez innych strumieni łącze pomieści 4644

Łącze w skali: ruch każdego typu strumienia, limit i zapas

Równania

U = \frac{R}{C},

Z = C\,L - R

n_{\mathrm{dod}} = \left\lfloor \frac{Z}{R_w + R_n} \right\rfloor,

n_{\mathrm{max}} = \left\lfloor \frac{C\,L}{R_w + R_n} \right\rfloor

$C$ to przepustowość łącza, $L$ planowany limit, $U$ wykorzystanie łącza, a $Z$ zapas do limitu. $n_{\mathrm{dod}}$ to liczba strumieni danego typu, które jeszcze się zmieszczą, a $n_{\mathrm{max}}$ liczba, która zmieści się na łączu bez innych strumieni; $\lfloor x \rfloor$ to zaokrąglenie w dół.

Założenia

Limit 70% to margines projektowy, nie norma: bitrate w trybie VBR (zmienny bitrate, ang. variable bit rate) ma szczyty, a klatki kluczowe powodują chwilowe skoki ruchu, które rzadko pokrywają się we wszystkich kamerach naraz. Ustaw własną wartość, jeśli zasady projektowania Twojej sieci przewidują inną.
$n_{\mathrm{dod}}$ i $n_{\mathrm{max}}$ liczymy dla jednego typu strumienia naraz, przy pozostałych ustawieniach bez zmian.

Miejsce na nagrania

Ten krok podaje pojemność dysków potrzebną na nagrania ze strumieni nagrywanych.

Korzysta z typów strumieni i bitrate’u wideo z kroku Bitrate wideo.

Bitrate nagrań

R_{\mathrm{nagr}}

18,35 Mb/sliczba strumieni nagrywanych: 16; nagrywanie ciągłe

Miejsce na dobę

M_d

198,2 GBdane nagrywane w ciągu doby, bez nadmiarowości

Miejsce łącznie

M

5,945 TB5,407 TiB (tebibajty); 30 dni, mnożnik nadmiarowości 1

Równania

R_{\mathrm{nagr}} = s_n \sum R_w\,N,

M_d = \frac{R_{\mathrm{nagr}} \cdot 86\,400}{8 \cdot 1000} = 10{,}8\,R_{\mathrm{nagr}},

M = k_n\,M_d\,D

$R_{\mathrm{nagr}}$ to bitrate danych strumieni nagrywanych w Mb/s, a $s_n$ część doby, w której kamery nagrywają (1 przy nagrywaniu ciągłym). $M_d$ to miejsce na nagrania na dobę w GB, $D$ czas przechowywania w dniach, $k_n$ mnożnik nadmiarowości, a $M$ miejsce łącznie.

Założenia

Liczymy same dane strumieni nagrywanych (wideo oraz metadane ONVIF, jeśli są nagrywane), bez nagłówków sieciowych.
Bitrate nagrań wynika z ruchu w kadrze ustawionego w kroku Bitrate wideo; strumień w trybie CBR (stały bitrate, ang. constant bit rate) zajmuje miejsce zgodne z ustawioną wartością.
Przy nagrywaniu podczas ruchu przyjmujemy zużycie proporcjonalne do części doby, w której kamery nagrywają.
Pojemność podajemy w TB dziesiętnych (10¹² B); systemy operacyjne często pokazują TiB (tebibajty, 2⁴⁰ B), o 9,05% mniej.

Cytowanie: Jacek Garbuliński, Kalkulator przepustowości sieci i pojemności dysków dla kamer IP, Blixild, 2026, https://blixild.pl/kalkulator-przepustowosci-kamer-ip.html

Pytania i odpowiedzi

Kiedy i po co korzystać z tego kalkulatora?

Przed doborem przełączników, łączy i rejestratora: kalkulator pokazuje, czy strumienie z kamer zmieszczą się na łączu z zapasem i ile pojemności dysków potrzeba na nagrania przez wymagany czas. Wynik jest punktem wyjścia; pomiar ruchu w działającej instalacji rozstrzyga.

Co oznacza ruch w kadrze?

Suwak ustawia, jaka część obrazu zmienia się między klatkami. Przy 0% dane niosą tylko klatki kluczowe, wysyłane co określoną liczbę klatek; przy 100% każda klatka kosztuje tyle co klatka kluczowa, czyli kamera wysyła pełny limit bitrate’u. Wartości pośrednie leżą na prostej między tymi skrajnościami.

Które łącze liczyć?

Łącze, przez które przechodzą wszystkie strumienie naraz: port serwera lub rejestratora i połączenia między przełącznikami. Port pojedynczej kamery przenosi tylko jej własne strumienie.

Skąd wziąć bitrate kamery?

Z jej ustawień strumienia: w trybie CBR (stały bitrate) to ustawiona wartość, a w trybie VBR (zmienny bitrate) górny limit, który kalkulator przelicza na bitrate przy ustawionym ruchu w kadrze. Przy projektowaniu nowej instalacji podaj limit, który zamierzasz ustawić w kamerach, albo zacznij od wartości startowej dla rozdzielczości i kodeka.

Dlaczego domyślny limit to 70%?

To margines projektowy: bitrate w trybie VBR (zmienny bitrate) ma szczyty, a klatki kluczowe powodują chwilowe skoki ruchu, które rzadko pokrywają się we wszystkich kamerach naraz. Jeśli zasady projektowania Twojej sieci przewidują inny limit, ustaw własny.

Dlaczego dysk pokazuje mniej niż obliczone TB?

Producenci dysków podają pojemność w TB dziesiętnych (10¹² B), a systemy operacyjne często w TiB (tebibajtach, 2⁴⁰ B), o 9,05% mniejszych liczbowo.

Źródła

J.-R. Ohm, G. J. Sullivan, H. Schwarz, T. K. Tan, T. Wiegand, „Comparison of the Coding Efficiency of Video Coding Standards, Including High Efficiency Video Coding (HEVC)”, IEEE Transactions on Circuits and Systems for Video Technology, t. 22, nr 12, s. 1669-1684, 2012, DOI 10.1109/TCSVT.2012.2221192: „approximately 50% less bit rate on average”.
RFC 791, Internet Protocol (1981): „the minimum value for a correct header is 5” (w słowach 32-bitowych).
RFC 768, User Datagram Protocol (1980): „the minimum value of the length is eight”.
RFC 8200, Internet Protocol, Version 6 (IPv6) Specification (2017): „20 octets for the minimum-length IPv4 header and 20 octets for the minimum-length TCP header”; pola nagłówka IPv6 dają razem 40 oktetów.
RFC 7323, TCP Extensions for High Performance (2014): „Kind: 8 Length: 10 bytes”, z dwoma oktetami NOP dla wyrównania („NOP | NOP | TSopt | 10”).
RFC 3550, RTP: A Transport Protocol for Real-Time Applications (2003): „The first twelve octets are present in every RTP packet”.
RFC 2326, Real Time Streaming Protocol (RTSP) (1998): „encapsulated by an ASCII dollar sign”, a po nim „a one-byte channel identifier” i długość jako „two-byte integer”.
RFC 6184, RTP Payload Format for H.264 Video (2011): „The FU indicator octet” oraz nagłówek FU.
RFC 7798, RTP Payload Format for High Efficiency Video Coding (HEVC) (2016): „HEVC uses a two-byte NAL unit header” oraz „an FU header of one octet”.
RFC 894, A Standard for the Transmission of IP Datagrams over Ethernet Networks (1984): „the maximum length of an IP datagram sent over an Ethernet is 1500 octets”.
RFC 6349, Framework for TCP Throughput Testing (2011): „Ethernet is 14 Bytes, CRC32 is 4 Bytes, IFG is 12 Bytes, Preamble is 7 Bytes” oraz „SFD is 1 Byte”.
ONVIF, schemat konfiguracji urządzeń onvif.xsd (ver10): GovLength, „Determines the interval in which the I-Frames will be coded.”; BitrateLimit, „The maximum output bitrate in kbps.”
Hikvision, „H.264(5) & H.264(5)+ Recommended Bit Rate at General Resolutions”: „Approximate Value”; „If the real environment is more complex, you can increase the bite rate 20%~30% higher than recommend.”; „suitable for all series IPC and PTZ with new platform”.

Wyślij zapytanie

Aby omówić sieć dla systemu monitoringu lub wizyjnego, wyślij zapytanie.

Prosimy krótko opisać wymagania. Odpowiadamy w ciągu jednego dnia roboczego.

kontakt@blixild.com