Война за секунды
Почему задержка внезапно стала важнее мегапикселей
Ещё десять лет назад видеонаблюдение жило спокойной и размеренной жизнью. Все спорили о разрешении, угле обзора, количестве кадров в секунду и глубине архива. Задержка? Какая задержка? Камера, регистратор и монитор стояли в одном здании, иногда — в одном шкафу. Видео шло по проводу, максимум через соседний коммутатор. Интернет в этой схеме был гостем факультативным и не особо желанным.
А потом видеонаблюдение вышло «в люди». Камеры полезли в облака, пользователи — в смартфоны, а сети внезапно перестали быть предсказуемыми. LTE, 5G, публичные Wi-Fi, корпоративные прокси, CG-NAT у операторов — всё это превратило доставку live-видео в соревнование на выживание. И тут выяснилось неприятное: смотреть «почти сейчас» — это уже плохо. Пользователь хочет видеть сейчас.
Когда охранник открывает камеру в мобильном приложении и видит, что человек в кадре уже успел уйти, видеонаблюдение перестаёт быть наблюдением. Оно становится архивом с задержкой. А архив, как известно, никого не спас.
Именно в этот момент старые протоколы начали нервно кашлять.
RTSP, рожденный для локальных сетей, плохо переносит интернет и ненавидит NAT.
HLS — прекрасен для сериалов и спортивных трансляций, но слишком нетороплив для live-сценариев.
RTMP честно отработал своё и ушёл вместе с Flash, не оглядываясь.
Индустрии понадобился новый компромисс: быстро, устойчиво и без шаманства. И тут на сцену вышел SRT — без фанфар, но с очень удачным резюме.
SRT без мифов
UDP, но с мозгами и часами
SRT часто называют «UDP с интеллектом». Грубо - да, но по сути верно. В основе SRT лежит UDP: быстрый, лёгкий, абсолютно безответственный. Он не гарантирует доставку, порядок пакетов и вообще ничего не обещает. Зато летает быстро. Именно поэтому UDP десятилетиями используют в real-time-системах - от VoIP до видеоконференций.
Проблема в том, что интернет — место суровое. Потери пакетов, джиттер, внезапные провалы связи — всё это норма. Чистый UDP в таких условиях быстро превращает видео в кубизм.
SRT решает эту проблему не как TCP. Он не говорит: «Я доставлю всё, даже если пользователь состарится». Он говорит иначе:
«У меня есть окно времени. Не успел — идём дальше».
Протокол заранее знает, сколько миллисекунд он готов потратить на восстановление пакета. Если пакет не успел - он считается погибшим при исполнении. Видео продолжается. Никаких стоп-кадров, бесконечных буферов и нарастающей задержки.
И вот здесь скрыт главный секрет SRT. В live-видео важнее не идеальная картинка, а время. Пара артефактов — переживём. Видео, отставшее на десять секунд, уже бесполезно. SRT позволяет разработчику самому выбрать баланс: чуть больше latency ради устойчивости или минимальную задержку ради «живой» картинки. В мобильных сетях, где условия меняются каждую секунду, это буквально вопрос выживания.
Бонусом идёт встроенное шифрование. Не «прикрутим потом», не «обернём в TLS», а сразу, на уровне протокола. Для видеонаблюдения, где почти любое видео - это персональные данные, это не опция, а обязанность.
При этом важно понимать: SRT — не кодек, не контейнер и не плеер. Он не знает, что такое H.264 или H.265. Он просто аккуратно и быстро переносит байты. Чаще всего внутри SRT летит MPEG-TS с привычным видеокодеком. Камеры от этого не пугаются, инфраструктура — тоже.
Но настоящий интерес начинается там, где SRT встречается с мифическим P2P.
P2P, которого почти не бывает
Как на самом деле подключаются облачные камеры
Если верить маркетингу, облачные камеры живут в счастливом мире P2P. Камера напрямую разговаривает с телефоном пользователя, никаких серверов, облаков и посредников. Прямо цифровая идиллия.
В реальности всё прозаичнее. Камеры почти всегда сидят за NAT. Иногда за несколькими. Мобильные устройства — за CG-NAT операторов. Прямое соединение возможно, но редко и при большом везении.
Поэтому настоящая архитектура почти всегда включает сервер. Иногда он нужен только для сигналинга и авторизации. Иногда — для полноценной ретрансляции видео. Система честно пытается соединить камеру и клиента напрямую, но при первой же проблеме включает relay. Пользователь при этом продолжает видеть надпись «P2P», чтобы не расстраиваться.
SRT в такой архитектуре чувствует себя как дома. Камера или edge-сервер публикует поток, клиенты подключаются к нему. Инициатором соединения выступает клиент, что критично для NAT. Сервер просто слушает входящие UDP-соединения. Никакой сложной ICE-магии, никакой сетевой акробатики.
И это не обман, а инженерный здравый смысл. Полностью безсерверное P2P в массовом видеонаблюдении — плохо масштабируется, нестабильно и сложно поддерживается. Сервер даёт контроль, безопасность и управляемость. А SRT становится надёжным транспортом между всеми участниками этой схемы.
И именно здесь начинает проявляться разница между мобильными приложениями и браузером.
Почему мобильные приложения «живее»
Когда архитектура важнее протокола
В браузере всё почти всегда сводится к HTML5 video и HLS. HLS — надёжный, масштабируемый, дружелюбный к CDN. И ужасно медленный для live. Видео режется на сегменты, плеер держит буфер, сглаживает сеть — и в итоге между реальностью и экраном образуется несколько секунд тишины.
Для фильмов это нормально. Для видеонаблюдения — катастрофа.
Мобильные приложения живут в другом мире. Они используют нативные плееры: libVLC, FFmpeg и их производные. Они умеют работать напрямую с UDP, SRT и RTSP, точно контролировать буферизацию и latency. Разработчик сам решает, чем жертвовать.
Плюс — более прямой доступ к сетевому стеку. Быстрее реакция на изменения канала, лучше адаптация к мобильным сетям. В результате задержка от камеры до экрана смартфона при использовании SRT часто укладывается в 1–2 секунды. Это почти физический предел без двусторонних протоколов вроде WebRTC.
Браузеры здесь не виноваты. Они просто заточены под другую задачу: безопасность, совместимость и масштабирование. Мобильные приложения могут позволить себе быть агрессивными. Поэтому они и выглядят «живее».
VSaaS сегодня
Один пользователь — несколько протоколов
Современные VSaaS-платформы давно перестали выбирать один протокол «на всё». Камеры чаще всего продолжают работать по RTSP. Сервер принимает поток, решает вопросы доступа и дальше выбирает, как именно отдавать видео клиенту.
Мобильным приложениям - SRT или WebRTC.
Браузерам - HLS, иногда в low-latency-варианте.
Для пользователя это один сервис. Для архитектуры — осознанное разделение ролей. Именно так сегодня выглядит зрелая промышленная система.
SRT здесь не конкурент HLS, а его напарник. Он закрывает нишу живого видео для контролируемых клиентов - и делает это очень уверенно.
Что дальше
SRT иногда называют временным трендом. Но если посмотреть шире, это логичный этап эволюции. От локальных систем — к облакам. От мониторов — к смартфонам. От архивов — к live-интерфейсам реального мира.
Он не вытеснит всё остальное. HLS останется в браузерах. WebRTC - там, где нужна минимальная задержка любой ценой. RTSP — внутри камер. Но SRT уже занял своё место между этими мирами.
Он не волшебный, не «настоящее P2P» и не панацея. Это просто хорошо сделанный транспорт, который идеально попал в требования времени.
Именно поэтому мобильные приложения всегда будут «живее» браузеров. Именно поэтому P2P почти всегда означает облако. И именно поэтому SRT сегодня не эксперимент, а рабочая лошадь современной индустрии видеонаблюдения.