По некоторым данным, на сегодняшний день, в мире установлены сотни миллионов IP-камер для видеонаблюдения. Однако далеко не для всех из них критична задержка в воспроизведении видео. Видеонаблюдение, как правило, происходит «статично» — поток записывается в хранилище и может быть проанализирован на движение. Для видеонаблюдения разработано множество программных и аппаратных решений, которые хорошо делают свою работу.

В данной статье мы рассмотрим немного другое применение IP-камеры, а именно применение в онлайн-трансляциях, где требуется низкая коммуникационная задержка.

Прежде всего давайте устраним возможное недопонимание в терминологии про вебкамеры и IP-камеры.

Вебкамера — это устройство захвата видео, не имеющее собственного процессора и сетевого интерфейса. Вебкамера требует подключения к компьютеру, смартфону, либо другому устройству, имеющему сетевую карту и процессор.

IP-камера — это автономное устройство, имеющее собственную сетевую карту и процессор для сжатия захваченного видео и отправки в сеть. Таким образом, IP-камера представляет собой автономный мини-компьютер, который полноценно соединяется с сетью и не требует подключения к другому устройству, и может напрямую вещать в сеть.

Низкая задержка (low latency) — это достаточно редкое требование для IP-камер и онлайн-трансляций. Необходимость работы с низкой задержкой появляется, например, в том случае, если источник видеопотока активно взаимодействует со зрителями этого потока.

Чаще всего низкая задержка необходима в игровых сценариях использования. В качестве таких примеров можно привести: видео-аукцион в реальном времени, видео-казино с живым дилером, интерактивное онлайн-тв шоу с ведущим, удалённое управление квадрокоптером, и т.д.

Дилер живого интернет-казино за работой.

Обычная RTSP IP камера, как правило жмёт видео в H.264 кодек и может работать в двух режимах транспортировки данных: interleaved и non-interleaved.

Режим interleaved наиболее популярный и удобный, т.к. в этом режиме видео данные передаются по протоколу TCP внутри сетевого подключения к камере. Для того чтобы раздавать с IP-камеры в interleaved нужно всего лишь открыть / пробросить один RTSP-порт камеры (например 554) наружу. Плееру остаётся лишь подключиться к камере по TCP и забрать поток уже внутри этого соединения.

Вторым режимом работы камеры является non-interleaved. В этом случае соединение устанавливается по протоколу RTSP / TCP, а трафик идёт уже отдельно, по протоколу RTP / UDPвне созданного TCP-канала.

Режим non-interleaved более благоприятен для трансляции видео с минимальной задержкой, так как использует протокол RTP / UDP, но в то же время является более проблемным, если плеер расположен за NAT.

При подключении к IP-камере плеера, который находится за NAT, плеер должен знать — какие внешние IP-адреса и порты он может использовать для приема аудио и видео трафика. Эти порты указываются в текстовом SDP-конфиге, который передается камере при установке RTSP-соединения. Если NAT был вскрыт правильно и определены корректные IP-адреса и порты, то все будет работать.

Итак, для того чтобы забрать видео с камеры с минимальной задержкой, нужно использовать non-interleave mode и получать видеотрафик по UDP.

Браузеры не поддерживают стек протоколов RTSP / UDP напрямую, но поддерживают стек протоколов встроенной технологии WebRTC.

Технологии браузера и камеры очень похожи, в частности SRTP это шифрованное RTP. Но для корректной раздачи на браузеры, IP камере бы потребовалась частичная поддержка WebRTC-стека.

Чтобы устранить эту несовместимость требуется промежуточный сервер-ретранслятор, который будет являться мостом между протоколами IP-камеры и протоколами браузера.

Сервер забирает поток с IP-камеры на себя по RTP / UDP и отдаёт подключившимся браузерам по WebRTC.

Технология WebRTC работает по протоколу UDP и тем самым обеспечивает низкую задержку по направлению Сервер > Браузер. IP-камера также работает по протоколу RTP / UDP и обеспечивает низкую задержку по направлению Камера > Сервер.

Камера может отдать ограниченное количество потоков, в силу ограниченных ресурсов и полосы пропускания. Использование промежуточного сервера позволяет масштабировать трансляцию с IP камеры на большое число зрителей.

С другой стороны, при использовании сервера, включаются две коммуникационных ноги:
1) Между зрителями и сервером
2) Между сервером и камерой
Такая топология имеет ряд «особенностей» или «подводных камней». Перечислим их ниже.

Подводный камень #1 — Кодеки

Препятствием для работы с низкой задержкой и причинами ухудшения общей производительности системы могут стать используемые кодеки.

Например, если камера отдает 720p видеопоток в H.264, а подключается Chrome-браузер на смартфоне Android с поддержкой только VP8.

При включении транскодинга, для каждой из подключенных IP-камер должна быть создана транскодинг-сессия, которая декодирует H.264 и кодирует в VP8. В этом случае 16 ядерный двухпроцессорный сервер сможет обслужить только 10-15 IP камер, из примерного расчета 1 камера на физическое ядро.

Поэтому если серверные мощности не позволяют транскодировать планируемое количество камер, то транскодинга нужно избегать. Например обслуживать только браузеры с поддержкой H.264, а остальным предлагать использовать нативное мобильное приложение для iOS или Android, где есть поддержка кодека H.264.

Как вариант для обхода транскодинга в мобильном браузере, можно использовать HLS. Но стриминг по HTTP совсем не обладает низкой задержкой и в настоящий момент не может быть использован для интерактивных трансляций.

Подводный камень #2 — Битрейт камеры и потери

UDP протокол помогает справиться с задержкой, но допускает потери видеопакетов. Поэтому несмотря на низкую задержку, при больших потерях в сети между камерой и сервером, картинка может быть испорчена.

Для того чтобы исключить потери, нужно убедиться, что генерируемый камерой видеопоток имеет битрейт, который помещается в выделенную полосу между камерой и сервером.

Подводный камень #3 — Битрейт зрителей и потери

Каждый подключившийся к серверу зритель трансляции также имеет определенную пропускную способность на Download.

Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

В этом случае есть три варианта:

1. Транскодировать видеопоток индивидуально под каждого зрителя под требуемый битрейт.
2. Транскодировать потоки не для каждого подключившегося, а для группы группы зрителей.
3. Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах.

Первый вариант с транскодингом под каждого зрителя не подходит, так как израсходует ресурсы CPU уже при 10-15 подключившихся зрителей. Хотя нужно отметить, что именно этот вариант дает максимальную гибкость при максимальной загрузке CPU. Т.е. это идеальный вариант например в том случае, если вы транслируете потоки всего на 10 географически распределенных человек, каждый из них получает динамический битрейт и каждому из них нужна минимальная задержка.

Второй вариант заключается в уменьшении нагрузки на CPU сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две: 

• 200 Kbps
• 1 Mbps

В случае, если зрителю не хватает пропускной полосы, он переключается в ту группу, в которой он сможет комфортно получать видеопоток. Таким образом, количество транскодинг-сессий не равно количеству зрителей как в первом случае, а является фиксированным числом, например 2, если групп транскодинга две.

Третий вариант предполагает полный отказ от транскодинга на стороне сервера и использование уже подготовленных видеопотоков в различных разрешениях и битрейтах. В этом случае камера настраивается на отдачу двух или трех потоков с разными разрешениями и битрейтами, а зрители переключаются между этими потоками в зависимости от своей пропускной способности.

В этом случае транскодинговая нагрузка на сервер уходит и смещается на саму камеру, т.к. камера теперь вынуждена кодировать два и более потоков вместо одного.

В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 1 ядро сервера, то получаются следующая таблица нагрузки на CPU:

Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 2 и 3 при этом выглядят наиболее оптимальными.

Тестирование RTSP как WebRTC

Пришла пора провести несколько тестов для выявления действительной картины происходящего. Возьмем реальную IP-камеру и проведем тестирование с целью измерения задержки при трансляции.

Для тестирования возьмем древнюю IP-камеру D-link DCS-2103 с поддержкой RTSP и кодеков H.264 и G.711.

Так как камера долго пролежала в шкафу с другими полезными девайсами и проводами, пришлось отправить ее в Reset, нажав и подержав кнопку на задней стороне камеры 10 секунд.

После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37.

Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:

Далее заходим в сетевые настройки и узнаем RTSP адрес камеры. В данном случае RTSP-адрес live1.sdp, т.е. Камера доступна по адресу rtsp://192.168.1.37/live1.sdp

Доступность камеры легко проверить с помощью VLC плеера. Media — Open Network Stream.

Мы убедились, что камера работает и отдает видео по RTSP.

В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC.

Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2.

После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки 

rtsp_interleaved_mode=false

Эта настройка добавляется в конфиг flashphoner.properties и требует перезагрузки сервера:

service webcallserver restart

Таким образом, у нас есть сервер, который работает по схеме non-interleaved, принимает пакеты от IP-камеры по UDP, и далее раздаёт по WebRTC (UDP).

Тестовый сервер находится на VPS-сервере, расположенном в датацентре Франкфурта, имеет 2 ядра и 2 гигабайта RAM.

Камера находится в локальной сети по адресу 192.168.1.37.

Поэтому первое что мы должны сделать — это пробросить порт 554 на адрес 192.168.1.37 для входящих TCP / RTSP соединений, чтобы сервер мог установить подключение к нашей IP-камере. Для этого в настройках роутера добавляем всего одно правило:

Правило говорит роутеру перенаправлять весь входящий на порт 554 трафик, на 37 — IP адрес.

Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip

Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером.

Стандартный демо плеер в браузере Google Chrome выглядит так:

Чтобы начать играть RTSP поток, нужно просто ввести его адрес в поле Stream.
В данном случае адрес потока: rtsp://ip-cam/live1.sdp
Здесь ip-cam это внешний IP адрес вашей камеры. Сервер будет пытаться установить соединение именно по этому адресу.

Тестирование задержек VLC vs WebRTC

После того, как мы настроили IP камеру и протестировали в VLC, настроили сервер и протестировали RTSP поток через сервер с раздачей по WebRTC, мы наконец-то можем сравнить задержки.

Для этого будем использовать таймер, который будет показывать на экране монитора доли секунды. Включаем таймер и воспроизводим видеопоток одновременно на VLC локально и на браузере Firefox через удалённый сервер.

Пинг до сервера 100 ms.
Пинг локально 1 ms.

Первый тест с использованием таймера выглядит так:

На черном фоне расположен исходный таймер, который показывает нулевую задержку. Слева VLC, справа Firefox, получающий WebRTC поток с удаленного сервера.

На этом тесте видим задержку на VLC в два раза больше чем задержку на Firefox + Web Call Server, не смотря на то, что видео в VLC воспроизводится в локальной сети, а видео, которое отображается в Firefox проходит через сервер в датацентре в Германии и возвращается обратно. Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.

Мы сделали несколько снимков чтобы зафиксировать значения задержки:

Результаты измерений выглядят так:

Таким образом, средняя задержка при тестировании с VLC в локальной сети составила 768 миллисекунд. В то время, как средняя задержка при проходе видео через удаленный сервер составила 341 миллисекунду, т.е. была в 2 раза ниже при использовании UDP и WebRTC.

Тестирование задержек RTMP vs WebRTC

Проведем похожие тесты с RTMP- плеером через Wowza сервер и одновременный тест с WebRTC-плеером через Web Call Server.

Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).

Тест — 1

Тест — 2

Тест — 3

Тест — 4

Результаты тестирования можно вывести в уже знакомую таблицу:

Таким образом, средняя задержка при воспроизведении RTSP потока в Flash Player по RTMP составила 1683 миллисекунд. Средняя задержка по WebRTC 384 миллисекунды. Т.е. WebRTC оказалась в среднем в 4 раза лучше по задержке.

Ссылки

Технология WebRTC
RTSP — RFC
RTSP interleaved — RFC, 10.12 Embedded (Interleaved) Binary Data
RTMP — спецификация
Web Call Server — WebRTC медиасервер с поддержкой RTSP
VLC — плеер для воспроизведения RTSP

•  

   

   OvO 20 марта 2017 в 21:46   

  Лечение vlc по фотографии — поставьте network-caching в 100 мс

   
  •  a1ien_n3t 20 марта 2017 в 21:35   
    

    0

      

    VLC все равно большие задержки дает. А если ставить очень маленькое время кеширование то видео смотреть становится невозможно.
    На gstreamer получается гораздо лучше. Особенно это заметно когда гонишь чистый rtp поток.
    Если в VLC поставить задержку на RTP менее 300ms то начинаются дикие лаги на видио.

     
    •  OvO 20 марта 2017 в 21:46   
      

      0

        

      На моей системе vlc показывал задержку в 300мс в hd, с учетом камеры и сети. Попробуйте синхронизировать время.

       

       
      •  a1ien_n3t 20 марта 2017 в 21:55   
        

        0

          

        Сложно засинхронить время у железки которая делает аппаратное сжатие и запихивает это все в rtp.
        А вообще мы для своих задач отказались от rtp, перешли на mpegts и даже удобнее стало. И вполне задержка получилась 250-300 мс для fullhd. Просто hd где-то 200-250мс. Ну у нас своя специфика.
        Просто раньше мы смотрели все на vlc пытались на нем или на ffmpeg получить маленькую задержку.
        Но все равно как ни крути gstreamer выдает немного меньшую задержку.

         

         
•  barker 20 марта 2017 в 21:28 
  

  0

    

  Увидел заголовок и даже не сомневался, что снова будет реклама вне блога компании про Web Call Server. За последний месяц уже по-моему пятый раз.

   

   
•  HurrTheDurr 20 марта 2017 в 21:31 
  

  +1

    

  Это вы VLC с дефолтными настройками испытывали, а не RTSP… Советую провести повторное тестирование, используя более приспособленные к поставленной задаче плееры.
  Я выставляю на соревнование «mplayer -benchmark -framedrop -nosound», sdp он понимает. Решал с его помощью схожую задачу, задержка при стриме full hd видео была на уровне 100 мс, чего вполне достаточно для игр в аркадные гоночки без монитора.

   

   
  •  a1ien_n3t 20 марта 2017 в 21:41   
    

    0

      

    А сколько у вас кадров в секунду? Если у вас 30фпс то я в жизни не поверю в задержку в 100мс.
    Если 60фпс, то в принципе 100мс вполне реально.

     

     
    •  HurrTheDurr 20 марта 2017 в 21:58   
      

      0

        

      Только что проверил. На 30 fps — около 80-90 мс, на 60 fps — ровно 100 мс. Сеть — обычная локалка через обычный домашний роутер, ноутбук подключен по wi-fi. 

      Слева — ноутбук (TN+Film), принимает стрим. Справа — ПК (IPS + f.lux), отдает стрим. 

      30 fps, 80-90 ms

      60 fps, 100 ms

      Но! Это голый MPEG-TS через UDP. Если добавить промежуточный сервер, который будет заворачивать все в RTSP — задержка, очевидно, увеличится, но не думаю, что она дорастет даже до «лучшего» результата топикстартера в 323 мс.

       

       
      •  2030andme 23 марта 2017 в 20:45   
        

        –1

          

        Как отобразить голый MPEG-TS через UDP в браузере? Без плагинов?

        В статье описаны тесты трансляции RTSP на браузер. Понятно, что используя MPEG-TS и десктопный софт, можно добиться задержки в 1-2 RTT.

         

         
•  a1ien_n3t 20 марта 2017 в 22:07 (комментарий был изменён) 
  

  0

    

  Аааа у вас не с камеры, а захват с экрана и mpegts тогда да. Это более реально. Просто если с камеры сжимать то у вас +время одного кадра минимум добавляется(так-как вам нужно целеком кадр принять и только потом его передавать).
  То есть в среднем 3 кадра задержка. 
  1)Принять
  2) сжать-передать-разжать(если у нас энкодер, декодер и сеть успевает за время кадра)+ всякие буфера
  3) отобразить. (хотя тут зависит тоже от многих факторов)

  З.Ы. Промазал с ответом.

   

   
  •  HurrTheDurr 20 марта 2017 в 22:20   
    

    0

      

    Безусловно. С другой стороны, у камеры гарантированное аппаратное кодирование и картинку она получает сразу, а не добывает неведомыми окольными путями. Но VLC, в тех же условиях, получая такой же стрим, даже с выставленным в 0 кешем, иногда теряя изображение, выдает задержку почти 900 мс. Почему — не знаю, использую mplayer дальше…

     

     
•  Merkat0r 20 марта 2017 в 23:31 
  

  +4

    

  А, есть такой же «Web Call Server» только не хотящий "$75 subscribe per month per instance"? :)

   

   
•  Areso 21 марта 2017 в 07:05 
  

  0

    

  А если камера расположена на чем-нибудь мобильном и потому прокинуть порты нет технической возможности?
  Можно ли наоборот, настроить IP камеру или веб-камеру+Raspberry для отправки видеопотока на удаленный сервер, чтобы уже он раздавал видео дальше?

   

   
  •  jazzl0ver 21 марта 2017 в 15:45   
    

    0

      

    можно, например, через ssh-тоннель. т.е. что-то из локальной сети с камерой подключается к серверу по ssh и открывает на сервере порт, по которому доступна камера. софт на сервере уже подключается к камере через этот порт и раздает желающим.

     

     
•  Emin 23 марта 2017 в 13:52 
  

  0

    

  Не очень понятно, что с чем сравнивают. И о чём спор.

  1. RTSP и RTMP сделаны на основе TCP. WebRTC сделан на основе UDP. Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!
  

  Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.

  Не «может», а именно, что вызвано. Аналогично и для FlashPlayer-а

  2. Как и в случае с VLC, во FlashPlayer-е для проигрывания потока можно выставить буфер. Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0.

  3. Если уж и сравнивать, то WebRTC на UDP с RTMFP.

   

   
•  2030andme 23 марта 2017 в 20:30 
  

  +1

    

  Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!

  Была некоторая неожиданность в том, что в локальной сети задержка RTSP при воспроизведении в VLC оказалась больше, чем через удалённый сервер при использовании WebRTC. Скажем так, было совсем неочевидно, что тест даст такие результаты.

  Более того, использование UDP не гарантирует задержку ниже чем TCP. Зависит от протокола, который работает поверх UDP. Например, в WebRTC активно используется TCP-like досылка видеопакетов и по этой причине нельзя сказать, будет все без задержек или нет. Зависит от реализации.

  Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0

  Netstream.bufferTime был 0

  Если уж и сравнивать, то WebRTC на UDP с RTMFP.

  RTMP был выбран по двум причинам:
  1. Как реалтаймовый протокол (по сравнению с HLS, где задержка 15 и более секунд).
  2. Как самый распространенный реалтаймовый протокол, для которого есть много решений RTSP-RTMP.

  Протокол RTMFP менее распространен и мне известны буквально единицы решений, конвертирующие RTSP-RTMFP. Кстати, Web Call Server поддерживает такую конвертацию.

  На самом деле, тесты RTSP-RTMFP проводились. По результатам, RTMFP отстает примерно на 100-200ms от WebRTC. Возможно добавлю скриншоты в статью с результатами по RTMFP.
   

   

   
•  Paul_Nice 24 июля 2017 в 12:46 
  

  0

    

  Мне вот интересно, раз уж статья о технологии, использованной в этом продукте, то для конкретных задач (а-ля камхоринг) чем данный продукт лучше чем https://github.com/jitsi ?

  И если у меня уже есть вовза или флюссоник, то зачем мне вообще "webcallserver"?
  Оба стримера умеют в webrtc.