IP- проти SDI-камер відеоспостереження: чому обидва стандарти цифрові, але інженер працює з ними по-різному

Питання «IP чи SDI» — не питання якості. Це питання сигнальної моделі, шини передачі, методів діагностики та того, як саме сигнал доходить від матриці до накопичувача. Обидва стандарти цифрові, але цифрові вони на абсолютно різних шарах. Нижче — технічний розбір без побутових пояснень: для тих, хто вже тримав у руках і CCTV-тестер з мережевими інтерфейсами, BNC-входом, і LAN-тестер з PoE-навантаженням.

1. Хронологія: чому SDI з'явився раніше, але прийшов у CCTV пізніше

Послідовний цифровий інтерфейс SDI — це не «продукт відеоспостереження». Він народився у телемовленні: SMPTE 259M (SD-SDI, 270 Mbps) ратифікований у 1989 році, SMPTE 292M (HD-SDI, 1.485 Gbps) — у 1998-му. До початку 2010-х SDI існував винятково в студіях, ПТС, апаратних, де треба було передавати нестиснуте baseband-відео коротким коаксіалом без ЗАТРИМКИ.

На ринок CCTV HD-SDI зайшов лише близько 2010 року — як відповідь на запит «дайте HD по існуючому коаксіалу». На той момент аналогові системи на CVBS уже не задовольняли роздільністю, а демонтаж RG-6 на тисячах об’єктів був економічно немислимим. SDI обіцяв повноцінний 1080p поверх RG-59/RG-6 без перекладання трас. Однак паралельно з’явилися аналогово-цифрові гібриди — HD-CVI (Dahua, 2012), HD-TVI (Hikvision, 2014), AHD (Nextchip, 2014). Вони були дешевшими, толерантнішими до якості кабелю, з більшою дальністю по тому ж RG-59. SDI у CCTV отримав вузьку нішу і там залишився, надаючи відео високої якості.

IP-камери формально старші за HD-SDI у безпеці: перша мережева камера Axis NetEye 200 — 1996 рік. Але масове промислове використання почалося після 2005-го з появою ONVIF (2008), стабільного H.264, керованих PoE-комутаторів та доступних NVR. Саме IP-камери, а не SDI, виграв ринок безпеки — і виграв його за рахунок мережевої моделі, а не якості картинки.

Лінійка SDI: HD-SDI, 3G-SDI, 6G/12G-SDI та CCTV-гілка EX-SDI

Узагальнене «SDI» — це не один стандарт, а ціле сімейство, кожен член якого вирішує конкретну інженерну задачу свого часу. Початковою точкою для відеоспостереження є SD-SDI (SMPTE 259M, 1989, 270 Mbps) — стандартної чіткості, на цьому рівні CCTV з ним практично не перетнувся, бо аналогові CVBS-системи були дешевші. Перший серйозний контакт ринку безпеки з SDI стався з HD-SDI (SMPTE 292M, 1998, 1.485 Gbps), який передавав 720p50/60 і 1080i50/60 одним 75-омним коаксіалом до приблизно 100–150 м на RG-6. У 2002 році з’явився Dual-Link HD-SDI (SMPTE 372M) — два паралельні коаксіали, які разом давали 2.97 Gbps і вже дозволяли 1080p50/60 або 4:4:4 RGB. Для broadcast це був робочий компроміс, для CCTV — практично мертвонароджена ідея, бо подвоювати коаксіал заради кожної камери ніхто не збирався. Логічним наступним кроком став 3G-SDI (SMPTE 424M, 2006, 2.97 Gbps в одному кабелі), який упакував все, що раніше потребувало двох ліній, в один RG-6. Тут варто розрізняти три мапінги, які на польовому тестері виглядають однаково, але поводяться по-різному: Level A — пряме відображення 1080p сигналу і де-факто стандарт у CCTV; Level B-DL — дволанковий HD-SDI, мапований на 3G для зворотної сумісності; Level B-DS — два потоки 720p/1080i у тій же лінії. Якщо камера віддає Level B, а тестер чи реєстратор очікує Level A, картинка просто не з’явиться, попри коректний lock — це класична причина «всі параметри в нормі, але ні зображення, ні помилки», яку часто плутають з апаратною несправністю. Подальший розвиток сімейства — 6G-SDI (SMPTE ST 2081, 2015, 5.94 Gbps, UHD до 30p), 12G-SDI (SMPTE ST 2082, 2015, 11.88 Gbps, UHD 60p, де-факто сучасна броадкаст-норма) і нішевий 24G-SDI (SMPTE ST 2083, 2019, 23.76 Gbps, 8K) — у CCTV вони майже не зустрічаються, бо економічно витіснені IP, але іноді з’являються у видеостінах ситуаційних центрів і в гібридних інсталяціях із broadcast-обладнанням. Загальний принцип лінійки: кожне подвоєння бітрейту приблизно вдвічі скорочує дальність по тому ж коаксіалу і кратно посилює вимоги до якості BNC і до return loss роз’ємів. На 12G-SDI дешевий китайський BNC, який терпіти можна на HD-SDI, дає eye-діаграму, в яку приймач не залочиться навіть на двох метрах кабелю.

Окрема, повністю CCTV-орієнтована гілка SDI — EX-SDI, розроблена корейською fabless-компанією Eyenix і вперше представлена близько 2013 року. Технічно EX-SDI — не нащадок SMPTE-стандартів, а самостійне рішення з тією самою філософією (нестиснений цифровий потік по 75-омному коаксіалу), але з принципово іншою модуляцією. У HD-SDI основна спектральна енергія сигналу зосереджена в районі 750 МГц, що змушує кабель і конектори працювати на межі своєї фізики — звідси жорсткі обмеження на дальність і чутливість до якості RG-59. EX-SDI використовує модуляцію в значно нижчій смузі (умовно 60–150 МГц залежно від генерації), де затухання коаксіалу і паразитні відбиття поводяться куди лояльніше. Практичний результат: EX-SDI 1.0 (2013) стабільно тримає 1080p на RG-59 до 300 м, на RG-6 — до 500 м, що для HD-SDI неможливо без активних еквалайзерів і репітерів. EX-SDI 2.0 (близько 2015–2016) підняв роздільність до 4 MP / 5 MP при збереженні дальності, EX-SDI 3.0 довів робочі можливості до 8 MP (UHD-діапазон) знову ж таки на старій аналоговій кабельній інфраструктурі. Саме це і пояснює, чому EX-SDI зайняв ту нішу, до якої HD/3G-SDI не дотягнувся: ринок ретрофіту аналогових CCTV-систем у Південній Кореї, потім Південно-Східній Азії, частково Близькому Сході та СНД, де об’єкти мали тисячі метрів покладеного RG-59 під аналогові 960H-камери, і де перекладання на UTP коштувало більше за всю іншу модернізацію разом узяту. Важливі для інженера наслідки: EX-SDI — пропрієтарний протокол (SMPTE його не нормує), тестер мусить його окремо підтримувати, реєстратор мусить його окремо приймати, і сумісність між поколіннями (1.0 ↔ 2.0 ↔ 3.0) забезпечується не завжди й не у всіх режимах. На практиці це означає, що мікс EX-SDI камери одного покоління і EX-SDI реєстратора іншого — потенційне джерело несумісності, яке не діагностується нічим, крім таблиці сумісності виробника. Із позитивного: за рахунок нижчої частотної смуги EX-SDI значно толерантніший до неякісних BNC, до перегинів кабелю і до домішок старого монтажу — там, де HD-SDI вимагає переобтиснути все, EX-SDI просто продовжує працювати. У сегменті казино, режимних об’єктів і ретрофіту з вимогою «нестиснута картинка + жодної мережі + старий коаксіал» EX-SDI часто є єдиним технічно адекватним рішенням, тому, попри маркетингову непомітність порівняно з IP, він живий, активно розвивається і має сенс знати його параметри як мінімум на рівні розпізнавання сигналу на тестері.

Зведена характеристика для довідки

Дальності в таблиці — практичні робочі значення для якісного RG-6/RG-59 без активних еквалайзерів. Конкретні цифри залежать від виробника камери та приймача, перерізу центральної жили, якості BNC і температурного режиму траси; у реальному проєкті завжди закладається запас 20–30%.

2. Чому обидва - цифрові, але "цифрові" на різних рівнях

Слово «цифровий» у маркетингових описах об’єднує дві принципово різні архітектури. Розберімо, на якому шарі сигнал стає цифровим і що саме передається кабелем.

SDI: цифровий baseband, серіалізований бітовий потік

У SDI-камері АЦП на матриці видає паралельні відліки YCbCr 4:2:2 (або 4:4:4 у вищих профілях), як у відеоіндустрії. Серіалізатор перетворює їх на послідовний бітовий потік, який скрембрюється поліномом G(x) = X⁹ + X⁴ + 1, далі застосовується NRZI-кодування для збереження частоти переходів. На виході — самосинхронний потік 1.485 Gbps (HD-SDI), 2.97 Gbps (3G-SDI), 5.94 Gbps (6G-SDI) або 11.88 Gbps (12G-SDI), що передається 75-омним коаксіалом до приймача.

Ключова теза: SDI не використовує жодної компресії та жодного мережевого протоколу. Це чистий baseband. Кабелем йде той самий потік відліків, що вийшов з АЦП, лише серіалізований і скрембльований. Аудіо вбудовується через embedded audio (SMPTE 299M), таймкод і метадані — через ANC-канали у горизонтальних і вертикальних пробілах кадру.

IP: цифровий пакетний потік над стеком протоколів

В IP-камері той самий АЦП дає сирі відліки — далі ISP, шумозаглушення, балансування, тональна корекція. А потім обов’язково вмикається відеокодер: H.264, H.265 (HEVC), дедалі частіше H.265+ з кадрами зі змінною роздільністю фону, окремі продукти на AV1. Стиснений потік пакетується в RTP, передається через RTSP-сесію (рідше — ONVIF Profile T-керований MJPEG-over-HTTP або WebRTC), переноситься Ethernet-кадрами по 802.3 Layer 2 і маршрутизується IP-стеком L3.

Тобто «цифрова» IP-камера — це стиснений, пакетизований, маршрутизований потік. Його можна загубити в комутаторі, можна перерозподілити QoS, можна шифрувати TLS, можна мультикастити. SDI цього не вміє за визначенням і не повинен уміти. Але обидва класи цього відеообладнання використовуються, хоча і в різних нішах - тому команда від нашої торговельної марки RV-ZAFT намагається впроваджувати вимірювальне обладнання і тестери відеосигналів, які бачать всі стандарти відео, в тому числі і SDI. Як правило, для SDI в прилади в якості окремої опції додаються ще один-два інтерфейси. Наша стратегія - "все-в-одному" діє також в лінійці комбайнів CCTV, об'єднаних з оптичними рефлектометрами і оптичними тестерами. 

Принципова архітектурна різниця: PCM-baseband проти повного стеку TCP/IP

Зведено до однієї фрази, відмінність виглядає так: SDI — це передача PCM-відеовідліків у baseband-каналі без жодного протокольного стеку; IP — це передача стиснених кадрів через повний мережевий стек TCP/IP, мапований на референсну модель OSI. Це не дві реалізації однієї ідеї, а два принципово різні класи систем. Зупинемось детальніше на їх різниці.

SDI як ланцюг PCM-захоплення плюс NRZI-baseband. На вході сигнального ланцюга — так, класична імпульсно-кодова модуляція (PCM). АЦП матриці виконує два кроки: дискретизацію за часом (тактовану рядковою і кадровою розгорткою) і квантування амплітуди — з 10-бітовою глибиною для HD-SDI / 3G-SDI Level A і 12-бітовою для 6G/12G у RGB-режимах. На виході АЦП ми маємо потік PCM-відліків у форматі YCbCr 4:2:2 (або 4:4:4 у вищих профілях). Дотепер усе відповідає визначенню PCM. Але далі потік не передається кабелем як «PCM-сигнал» у класичному сенсі — він серіалізується, скрембрюється поліномом G(x) = X⁹ + X⁴ + 1 (для усунення DC-складової і гарантії частоти переходів), і вже після цього модулюється на коаксіалі як NRZI — лінійне baseband-кодування, де перепади напруги напряму відображають значення бітів. Несучої частоти немає. Жодних рівнів абстракції над фізикою — теж немає. Кабель і сигнал є одне ціле: те, що згенерував передавач, доходить приймача без будь-якої інкапсуляції чи маршрутизації. Усе SDI-«взаємодія» відбувається на L1 у термінах OSI; рівнів L2–L7 у цій моделі просто не існує.

IP-камера як повний мережевий стек. У IP-світі ситуація прямо протилежна — кадр зображення проходить п’ять-шість рівнів послідовної інкапсуляції, перш ніж потрапити в кабель. Розкладемо це через OSI-модель, на яку мапується реальний стек TCP/IP:

• L1 (фізичний) — мідь Cat 5e/Cat 6 або оптичне волокно; робочі частоти UTP — до 250 МГц для Cat 5e, до 500 МГц для Cat 6 при PoE++.
• L2 (канальний) — Ethernet 802.3 з MAC-адресацією, опційно VLAN-теги 802.1Q, опційно агрегація LACP. Тут же — PoE-узгодження за 802.3af/at/bt (LLDP-MDI).
• L3 (мережевий) — IPv4 або IPv6, ICMP для діагностики, маршрутизація між підмережами.
• L4 (транспортний) — UDP (типово для медіа-потоку RTP, мінімальна затримка) або TCP (для керування RTSP, ONVIF, HTTP/HTTPS, надійна доставка).
• L5–L6 (сесійний і презентаційний у класичному OSI) — у TCP/IP-моделі ці рівні явно не виділяються; функціонально сюди потрапляє керування RTSP-сесією, рукостискання TLS для шифрованого транспорту, і подача стисненого відео у форматі NAL-юнітів H.264 / H.265 з відповідними SPS/PPS-заголовками.
• L7 (прикладний) — ONVIF (Profile S для базового стрімінгу, Profile T для H.265 і аналітики, Profile G для запису, Profile M для метаданих), HTTP/HTTPS для веб-інтерфейсу, mDNS і WS-Discovery для автовиявлення в підмережі, SNMP для моніторингу.

Тобто один і той самий NAL-юніт стиснутого H.265-кадру до моменту виходу на фізичну лінію встигає бути загорнутим у RTP, RTP — у UDP-датаграму, UDP — у IP-пакет, IP-пакет — в Ethernet-кадр із MAC-заголовками, і вже Ethernet-кадр — у послідовність сигналів 1000BASE-T на витій парі. Кожен з цих рівнів має власні заголовки, власну логіку, власні режими відмови, власні параметри діагностики. У SDI цього стеку немає від слова «зовсім».

Практичні наслідки для діагностики. Саме тому SDI-канал фізично не може мати IP-конфлікту, ARP-storm, проблеми з MTU, помилкового VLAN-тегування чи multicast-міскондигурації — таких сутностей у ньому не існує. І навпаки: IP-канал не має jitter в одиницях UI на eye-діаграмі, не має return loss BNC-роз’ємів, не має pathological-pattern test — ці поняття належать виключно baseband-світу. Інструментарій діагностики не перетинається. Інженер, який звик працювати тільки з IP, шукає причини несправності SDI-каналу методом ping і traceroute — і не знаходить, бо їх там немає за визначенням; інженер, який працює тільки з SDI, не розуміє, чому камера на коректному UTP не віддає потік, поки не виявить, що порт ізольований у VLAN управління. Дві різні дисципліни, два різні набори рефлексів. Це, мабуть, головна причина, чому проєкти на гібридній інфраструктурі (одночасно SDI і IP) вимагають інженера з компетенціями в обох сферах — їх не зведеш в одну ментальну модель, скільки б годин стажу не було тільки в одній з них.

3. Технічні параметри: SDI (з коментарями для діагностики)

Жоден з цих параметрів не існує у світі IP. Eye-діаграма, return loss, alignment jitter, pathological-pattern test (комбінація SDI Matrix і SDI Equalizer) — це інструментарій SDI-інженера. Pathological-патерн — окрема цікава штука: послідовність бітів, що мінімізує переходи й максимізує DC-офсет, спеціально розрахована за межі робочих умов скремблера. Якщо канал тримає pathological — він тримає все.

4. Технічні параметри: IP-камери (з коментарями для діагностики)

Повністю інша система координат. Тут немає eye pattern, але є TDR-довжина пари, є балансування пар, є PoE-навантаження під класом, є wiremap, є RTSP-handshake, є ONVIF-discovery, є перевірка multicast IGMP-snooping. На IP-каналі ви ніколи не міряєте jitter в одиницях UI — ви міряєте packet delay variation у мілісекундах.

5. Що вимірюється в одному типі та принципово відсутнє в іншому

• Eye-діаграма (eye amplitude, eye height, eye width) — фізичний стан сигналу, у IP його замінює BER на канальному рівні, але доступу до нього на польовому тестері немає.
• Alignment jitter / timing jitter з фільтрами 100 kHz / 10 Hz — у IP немає аналога; пакетна модель приховує jitter всередині буфера.
• Pathological pattern test — стрес-тест скремблера й еквалайзера приймача.
• Return loss BNC-роз’ємів — критичний для 6G/12G, неактуальний для UTP (там є NEXT/FEXT/ACR, що інше).
• Cable Reach Estimation по затуханню в SDI-частотах — окремий тест, який не відтворюється на LAN-тестерах навіть формально.

• PoE budget і клас споживача — вимірюється під реальним навантаженням, не «холодний» вольтаж.
• Wiremap + перевірка пар (split pair, miswire) — на коаксі не існує концепції «пар».
• RTSP-stream verification, ONVIF-discovery, snapshot-by-URI — вся прикладна частина.
• Packet loss, jitter (RFC 3550), latency, MTU-discovery — мережеві параметри, які не мають жодного відповідника в SDI.
• VLAN-tagging, IGMP-перевірка, DHCP-аналіз, ARP-конфлікти — інженерія L2/L3.
• TDR на парах UTP — для пошуку обриву чи КЗ із точністю до метра.

• Перегляд зображення з контролем фокуса і експозиції.
• Вимірювання живлення (DC 12 В у SDI-камер, PoE у IP).
• Перевірка ІЧ-підсвітки (за зображенням у нічному режимі).
• Тест безперервності кабелю.

6. Інструмент польової діагностики

Для практичної роботи інженеру потрібні дві категорії приладів — і вони не взаємозамінні. CCTV-комбайн з BNC, AHD/TVI/CVI, HDMI і RJ-45 закриває оглядове тестування, але не замінює спеціалізованої вимірювальної техніки на критичних об’єктах.

• Для базової інсталяції та сервісу — мультиінтерфейсні CCTV-тестери з підтримкою SDI/AHD/TVI/CVI/IP, PoE/PoE+ output, RTSP-плеєром, ONVIF-discovery, UTP-wiremap, генератором тонального сигналу. Робочий каталог — «Тестери для CCTV та LAN».
• Для високоточної діагностики, проєктування та паспортизації трас — рефлектометри для ВОЛЗ (OTDR), сертифікаційні кабельні аналізатори, BERT-генератори, осцилографи з SDI-плагінами, вимірювачі RLC. Тут є важливий нюанс: для HD-SDI/3G/6G/12G існує сформована екосистема broadcast-приладів від Tektronix, Leader, Phabrix, тоді як для EX-SDI вимірювальна база суттєво обмеженіша через пропрієтарність протоколу — це варто чесно вказати. Окремий клас broadcast-приладів, який у CCTV зустрічається рідше, але абсолютно необхідний на режимних об’єктах із критичними вимогами до якості SDI (казино, диспетчерські, ситуаційні центри). Це переважно стаціонарні rack-mount або портативні прилади з 7–9" екраном і повним набором broadcast-метрик. Найвищий рівень аналізу — для ситуацій, коли rasterizer показує проблему, але не пояснює її першопричину, реалізується на цифрових осцилографах із смугою пропускання 3–8 ГГц і спеціалізованим програмним забезпеченням для декодування й аналізу SDI на фізичному рівні. Окрема категорія — джерела тестових патернів (SDI-генератори тестових сигналів). Без них неможливо повноцінно тестувати ні приймальний тракт реєстратора, ні відеокабель без камери, ні відповідність обладнання SMPTE-специфікаціям. Вимірювальна база для EX-SDI принципово вужча, ніж для SMPTE-стандартизованих SDI. Причина проста — EX-SDI є пропрієтарним протоколом Eyenix, не нормованим SMPTE, тож broadcast-вимірювальні прилади (Tektronix, Leader, Phabrix) його не підтримують. Інженер працює з EX-SDI переважно через CCTV-тестери з заявленою підтримкою EX-SDI, фірмові генератори сигналів, універсальні цифрові осцилографи без SDI-плагінів. Це вже категорія «КВПіА та лабораторне обладнання»: без неї сертифікувати лінію Cat6A під PoE++ або підтвердити запас по jitter у 12G-SDI неможливо.

Практична порада: на об’єктах із гібридною інфраструктурою (наприклад, телестудія + охоронна периметрія) обидва набори має сенс мати у виїзному кейсі. CCTV-тестер швидко локалізує проблему «по площині», лабораторний прилад дає кількісну оцінку, з якою вже можна сперечатися з підрядником і вписувати в акт.

7. Переваги та недоліки в реальній експлуатації

Сильні сторони. Затримка вимірюється мікросекундами — критично для оперативних центрів, казино, моніторингу швидких процесів. Картинка нестиснута: жодних артефактів I-кадрів, жодних блочних спотворень при русі. Канал ізольований за визначенням — кібератака на SDI-камеру через коаксіал технічно неможлива (немає стека, немає прошивки з відкритим портом). Синхронізація між камерами через genlock — рівень, недосяжний для IP без PTP/IEEE 1588 з дорогими комутаторами.

Слабкі сторони. Один кабель — одна камера, без агрегації. Окреме живлення, бо PoE по коаксіалу — це костилі (PoC у деяких рішеннях, але не SDI). Дальність обмежена і падає квадратично з підвищенням бітрейту. Немає ANR (запис на edge при втраті зв’язку), немає аналітики на борту камери, немає метаданих у форматі, який розуміє сучасна VMS. Розширення системи — тільки додаванням окремих ліній і реєстраторів.

Сильні сторони. Один UTP — і відео, і живлення, і керування. Edge-аналітика (line crossing, intrusion, об’єктна класифікація на NPU камери), мультистрім (запис у high-quality, перегляд у sub-stream). ONVIF-сумісність — змішування виробників. Масштабованість обмежена лише ядром мережі. Відстань — десятки кілометрів через оптику без втрати якості.

Слабкі сторони. Затримка glass-to-glass у кращому випадку 120 мс, у середньому 250–400 мс. Артефакти кодування на сценах із дощем, листям, мерехтінням — H.265 ріже деталі, які SDI зберіг би. Кібербезпека — окрема дисципліна: CVE на прошивках, дефолтні паролі, ботнети класу Mirai. Залежність від мережі: один заштормлений комутатор кладе сегмент. Біт-рейт «дихає» при VBR — сховище доводиться розраховувати з запасом.

8. Чому SDI рідко використовується в системах безпеки, але повністю не зник

Ринок безпеки масово пішов в IP не тому, що IP кращий за зображенням — а тому, що IP кращий за системними властивостями: масштабом, аналітикою, інтеграцією з системами контролю доступу, відеоверифікацією для пультів, інтеграцією з VMS і VSaaS. На об’єкті з 200 камерами SDI-архітектура економічно нежиттєздатна. Тому 95%+ нових проєктів CCTV — IP.

Але SDI зберігся в кількох конкретних сценаріях:

• Контрольні центри з broadcast-наслідуванням. Центри керування транспортом, диспетчерські, ситуаційні центри, де відеостіна побудована на матричних SDI-комутаторах з гарантованою синхронізацією та нульовою затримкою. Інтеграція IP у такі стіни існує, але часто йде через декодери з виходом на SDI.
• Казино і ігрова індустрія. Регуляторні вимоги в окремих юрисдикціях прямо забороняють компресію та мережеву передачу для зон спостереження за ігровими столами. SDI або 3G-SDI — єдиний легальний варіант.
• Промислова інспекція та технологічне відеоспостереження. Контроль швидкоплинних процесів (металургія, друк, упаковка), де затримка > 50 мс робить операторську реакцію марною.
• Об’єкти з вимогою кіберізоляції. Критична інфраструктура, де по сигнатурах ризику відеоканал не можна виносити в IP-середовище навіть у виділеному VLAN. SDI — фізично air-gapped по своїй природі.
• Ретрофіт без перекладання трас. Об’єкти з якісним RG-6, де HD-CVI/TVI вже не дають потрібної якості (4K зі сторонніми артефактами кодування у дешевих гібридах), а 3G/6G-SDI — дає. Малі за кількістю камер, але зустрічаються.

Тобто SDI — не «застарілий стандарт». Це інструмент із вузькою спеціалізацією, який залишається оптимальним там, де ключові вимоги — затримка, незалежність від мережі, нестиснута картинка та регуляторні обмеження. Невипадково вимірювальне обладнання для відеоспостереження від ТМ RV-ZAFT підримує в опціях EX-SDI, HD-SDI, 3G-SDI тощо.

9. Кіберповерхня IP-камер: побічний продукт мережевого стеку

Усе, що раніше описувалося як перевага IP-архітектури — повний стек TCP/IP, ONVIF-сумісність, віддалене керування, оновлювана прошивка, інтеграція з VMS, хмарне підключення — у дзеркальному відображенні стає поверхнею атаки. Це не недогляд галузі, а прямий математичний наслідок того, що IP-камера є повноцінним мережевим вузлом: з прослуховуваними портами, прошивкою на базі Linux, веб-інтерфейсом, RTSP- та ONVIF-сервісами, а часто — і підключенням до хмарних сервісів виробника. У SDI цього класу проблем не існує за визначенням. В IP цей клас проблем — основна причина того, що в банкінгу, режимних об’єктах і критичній інфраструктурі IP-камери або не використовуються, або жорстко сегментуються в ізольованих контурах із суворими правилами фільтрації.

Канонічна точка відліку для розмови про мережеву безпеку IP-камер — ботнет Mirai, виявлений у серпні 2016 року. Технічно Mirai не використовував жодних zero-day-вразливостей: він просто сканував Інтернет за відкритими портами Telnet (23) і SSH (22) та намагався автентифікуватися через вшиту таблицю з приблизно шістдесяти пар «логін:пароль» дефолтних облікових даних виробників. Серед них — легендарні root:xc3511 (OEM Xiongmai, на якому базуються тисячі ребрендованих DVR і камер), root:vizxv (Dahua), admin:admin, root:888888, root:juantech. Уражені пристрої завантажували бот-агент і отримували команди через C2-сервери. У вересні 2016 Mirai атакував сайт KrebsOnSecurity потоком близько 620 Gbps, далі — хостинг OVH потоком, що сягав 1+ Tbps, а 21 жовтня 2016 — DNS-провайдера Dyn, через що тимчасово впали Twitter, Netflix, GitHub, Reddit, Spotify і десятки інших великих сервісів. Більшість пристроїв-учасників атак — саме IP-камери та DVR. Вихідний код Mirai опублікували у жовтні 2016, і відтоді його похідні — Satori, Okiru, Mukashi, Echobot, Mozi — продовжують активно існувати, регулярно оновлюючи списки експлойтів. Слід підкреслити прикладний наслідок: IP-камера з відкритим портом RTSP назовні та дефолтним паролем сьогодні стає частиною ботнету за лічені години після підключення до Інтернету. Це не теоретичний ризик, а спостережуване щодня явище.

За понад десять років роботи галузі сформувалися кілька стійких класів вразливостей, властивих саме прошивкам IP-камер. Нижче — типологія через конкретні CVE, які варто знати інженеру при підборі обладнання:

• Бекдори автентифікації. CVE-2017-7921 (Hikvision) — обхід автентифікації через URL-параметр з base64-закодованою рядковою константою, що давав права адміністратора без жодного пароля. Зачіпала практично всю лінійку DS-2CD, DS-2CC та похідних до травня 2017. CVE-2021-33044 / 33045 (Dahua) — обхід автентифікації через спеціально сформовані пакети, рейтинг критичний, експлуатується віддалено без облікових даних.
• Командна ін’єкція в CGI/веб-сервері. CVE-2021-36260 (Hikvision) — віддалене виконання коду без автентифікації (RCE) через CGI-обробник, дає root-shell на понад 80 моделях, включно з PTZ та термокамерами. CVSS 9.8. Експлойт публічний, у дикій природі активно використовується кілька років. Аналогічні класи вразливостей регулярно знаходять і в інших виробників — Foscam, Reolink, Vivotek, в OEM-збірках на базі чіпсетів Hisilicon.
• Переповнення буфера у парсерах протоколів. Парсери RTSP, ONVIF SOAP-запитів і PTZ-команд історично демонструють низьку якість валідації вхідних даних. Експлуатація переважно дає DoS, у частині випадків — RCE з-під непривілейованого процесу з подальшим підвищенням привілеїв.
• Незахищені оновлення прошивки. Завантаження firmware-образу через HTTP без перевірки цифрового підпису дозволяє атаку «людина посередині» з підміною прошивки на модифіковану з постійним бекдором. Цей клас атак реальний у мережах із компрометованим маршрутизатором або у відкритих Wi-Fi на період сервісного обслуговування.
• Хмарні P2P-сервіси. Закриті протоколи на кшталт TUTK / Kalay (масштабовані в багатьох OEM-камерах) роками демонстрували вразливості: розкриття UID, слабку криптографію, можливість MITM, ескалацію через хмарну реляційну логіку. CVE-2021-28372 (TUTK Kalay) — приклад уразливості, що дозволяла перехоплення відео- та аудіотрафіку мільйонів пристроїв.
• SSRF та підробка запитів. Камера з функцією завантаження зображень за URL (push на FTP, HTTP-сервер, e-mail) часто не валідує цільову адресу й може використовуватися як проксі для сканування внутрішньої мережі або обходу мережевого периметра.
• Резервні службові акаунти. Часто не задокументовані: telnet:root з паролем, що генерується з MAC-адреси за відомим алгоритмом, фіксований SSH-ключ у прошивці, debug-інтерфейси, увімкнені виробником на час налагодження і забуті у релізі.

Ця типологія справедлива не лише для безіменних OEM з дешевого сегменту — навіть преміум-виробники (Hikvision, Dahua, Axis, Bosch, Vivotek) регулярно з’являються в CVE-базах. Ключова відмінність у поведінці виробників — швидкість випуску патчів і прозорість розкриття. Hikvision і Dahua після 2017 року помітно поліпшили процес responsible disclosure, але інстальована база старих моделей роками лишається без оновлень. Виробників із критичних інфраструктурних інсталяцій (наприклад, Axis, Bosch) часто оцінюють саме за політикою безпеки, а не лише за технічними параметрами камер.

Незмінений пароль адміністратора залишається причиною компрометації номер один. Парадокс у тому, що сучасні камери здебільшого вимагають зміну пароля під час першого налаштування — але інсталятори масово оминають цю вимогу через спрощені сценарії розгортання, копіювання конфігурацій між об’єктами, використання однакових облікових даних для пакетного налаштування десятків камер. На рівні організації це не вирішується технічно — потрібна політика, інвентаризація та регулярний аудит. Емпірична перевірка: пошуковий запит у Shodan на кшталт port:554 has_screenshot:true повертає десятки тисяч живих RTSP-потоків з камер по всьому світу, до яких можна підключитися без жодних облікових даних. Серед них — підприємства, школи, медичні заклади, склади, паркінги. Це не уразливість конкретної моделі. Це системна провина галузі та інсталяторської практики.

Змістовна модель загроз на об’єкті не зводиться до фрази «змініть паролі». Робочий мінімум для проєкту з IP-системою відеоспостереження виглядає так:

• Виділений VLAN для камер із ACL-правилами на L3, які пропускають трафік тільки до VMS і NTP-сервера. Жодного прямого виходу в Інтернет з камерного сегменту.
• Заборона UPnP на маршрутизаторі — щоб камери не могли автоматично відкрити порти назовні через NAT-traversal.
• VPN для віддаленого доступу, ніколи — port forwarding 80/443/554 на зовнішню адресу. Доступ до вебінтерфейсу VMS — тільки через корпоративну VPN з MFA.
• Відключення P2P-функцій і хмарних сервісів виробника на камерах, де це передбачено налаштуваннями. Якщо неможливо відключити — трафік камери до зовнішніх IP блокується файрволом на рівні VLAN.
• Інвентаризація моделей і прошивок з регулярною перевіркою CVE-баз (NVD, фіди виробників, бюлетені ICS-CERT). Неоновлювана прошивка з відомою CVE — це таймер до компрометації, не питання «чи», а питання «коли».
• Унікальні облікові дані для кожної камери, керовані через парольний менеджер або секрет-сховище VMS. Спільний admin-пароль на всю інсталяцію — антипатерн, який рветься від однієї злитої конфігурації або скомпрометованого ноутбука сервісного інженера.
• Моніторинг вихідного трафіку з VLAN камер. Ботнет-агенти видають себе DNS-запитами до C2-доменів, аномальним вихідним трафіком на нестандартні порти, спробами SMTP-relay. NetFlow або IDS на канальному рівні бачать це задовго до того, як проблему виявить виробник.
• Підписана прошивка як критерій вибору при закупівлі. Виробники, які не верифікують цифровий підпис firmware-образу, мають відсіюватися на етапі ТЗ — це базова гігієна, а не високотехнологічна вимога.
• TLS для ONVIF та RTSPS там, де підтримується. ONVIF Profile T і пізніші профілі передбачають захищений транспорт штатно; необхідність вмикати його вручну — типова забута налаштування при пусконаладці.
• Сегрегація відеореєстратора від загальної мережі підприємства. NVR/VMS, який сидить на одному L2 з робочими станціями, через одну компрометовану станцію стає вектором ескалації по всій інфраструктурі.

Тепер прямий контраст. SDI-камера на тій самій інсталяції не має жодного з наведених векторів атаки — і це не питання «менше уваги до безпеки», це фізичне обмеження архітектури. Немає прошивки з відкритим веб-сервером — немає CVE на CGI-обробник. Немає стеку TCP/IP — немає Mirai. Немає хмарного P2P — немає експлойтів TUTK / Kalay. Немає мережевого порту — немає сканування з Shodan. Усе, що теоретично може зробити зловмисник проти SDI-камери, потребує фізичного доступу до самої камери, коаксіального кабелю або реєстратора. Це не робить SDI «кращим» — це робить SDI системою з принципово іншою моделлю загроз, де ризики зміщені з кібер- у фізичну площину. У сценаріях, де компрометація фізично контрольованого периметра малоймовірна (всередині захищеного об’єкта, в ізольованому контурі), а компрометація IP-сегмента — щоденна реальність, SDI залишається технічно осмисленим вибором, попри всі переваги IP в інших аспектах. Вибір між архітектурами на режимному об’єкті в кінцевому підсумку зводиться не до «що дає краще зображення», а до «яку модель загроз ми готові обслуговувати в експлуатації».

10. Швидкий діагностичний чек-лист на об’єкті

1. Перевірити DC 12 В на роз’ємі камери під навантаженням (не «холодний» тест).
2. На CCTV-тестері включити SDI-вхід, перевірити lock на сигналі — є/немає.
3. Якщо lock є, але кадр «розсипається» — це майже завжди jitter або затухання. Виміряти eye amplitude і довжину кабелю; за межами 120 м для HD-SDI на RG-59 — додавати еквалайзер.
4. Якщо lock немає — переобтиснути BNC, перевірити центральну жилу на надлом біля конектора (типова відмова після монтажу), виміряти безперервність.
5. За підозри на pathological-патерн — стрес-тест із лабораторного генератора, не польового тестера.

1. Wiremap UTP — split pair дає Gigabit-link, але рве PoE bt під навантаженням.
2. Виміряти PoE під класом споживача (не холостий вольтаж). Падіння нижче 44 В на бт-навантаженні — або PSE на межі бюджету, або падіння на жилах через переріз/довжину.
3. Перевірити link-швидкість і дуплекс (auto-negotiate vs. forced).
4. ONVIF-discovery: камера відповідає WS-Discovery? Якщо ні — IP-конфлікт, VLAN, isolated port.
5. RTSP-snapshot за відомим URI з облікових даних. Якщо є — VMS-проблема. Якщо немає — камера або мережа.
6. Packet loss на ICMP до камери у фоні 60 секунд. Втрати > 0.1% під навантаженням I-кадрів — комутатор або кабель.
7. Перевірити IGMP, якщо стрім multicast — типова забута помилка на нових комутаторах без snooping.

11. Підсумок для практика

SDI і IP однаково цифрові на рівні АЦП, але абсолютно різні на рівні передачі. SDI — це фізика і сигнали, IP — це пакети і протоколи. Інженер, який працює з обома, тримає в голові дві окремі моделі несправностей і дві окремі шафи інструментів. Помилка в більшості випадків — спроба міряти SDI-канал LAN-тестером або шукати jitter у мережевому потоці. Кожна шкала має свою лінійку. Безпека пішла в IP за масштабом і функціями, broadcast і вузькоспеціалізована безпека залишили SDI за затримкою й ізоляцією. Жоден стандарт не «помер» — кожен живе там, де він технічно правильний. Завдання інженера — впізнати, який саме випадок перед ним, і не намагатися натягнути одну архітектуру на іншу через звичку.