Документация на Flussonic Media Server

  1. Быстрый старт
  2. How-to
  3. Потоковое вещание
    1. Варианты источников
    2. Переключение источников
    3. Публикация на Flussonic
    4. Прием мультикаста
    5. Серверные плейлисты
    6. Микширование
    7. Захват с SDI
    8. Отправка на другие серверы
    9. Распознавание DVB субтитров
    10. Наложение логотипа
  4. Транскодер
    1. Логотип
    2. Hardware
    3. Скриншоты
    4. Мозаика
  5. DRM
    1. Simple CAS
    2. Conax DRM
    3. BuyDRM (KeyOS)
    4. Widevine
    5. PallyCon
    6. EzDRM
  6. Авторизация
    1. Конструктор бэкендов
    2. Сервис сбора статистики
    3. Domain lock
    4. Middleware
    5. Secure links
    6. Ограничение сессий
    7. Мультиавторизация
    8. Бан IP адресов
    9. DVR
    10. Aliaser
  7. API
    1. HTTP API
    2. Events API
    3. MySQL API
    4. SQL API для кластеров
    5. SNMP
  8. Кластер
    1. Ретрансляция
    2. Кластерный захват
    3. Балансировщик нагрузки
    4. Пиринг
    5. Организация CDN
  9. VOD
    1. Кэш
    2. Облако
    3. Транскодирование файлов
    4. Мультибитрейтный VOD из файлов
  10. DVR
    1. Настройка
    2. Timeshift
    3. Catchup
    4. Проигрывание
    5. Экспорт в MP4
    6. Доступ по протоколам
    7. Timelapse
    8. API
    9. Кластеризация DVR
    10. Репликация
    11. Облако
  11. Воспроизведение
    1. HLS
    2. embed.html
    3. HTML5 с низкой задержкой
    4. Плеер HTML5 с низкой задержкой
    5. MPEG-TS
    6. RTMP
    7. DASH
    8. HDS
    9. RTSP
    10. multicast, CBR UDP
    11. WebRTC проигрывание
    12. H.265
  12. Администрирование
    1. Установка
    2. Обновление
    3. Конфигурация
    4. Мониторинг
    5. Производительность
    6. Лицензия
    7. LUA скрипты
    8. Безопасность
    9. Let's Encrypt
    10. Миграция
  13. IPTV
    1. Захват спутникового видео
    2. Транскодирование
    3. Middleware в IPTV OTT
    4. Экспорт EPG со спутника
    5. Группы каналов
    6. Реклама

Почему рассыпается картинка с IP-камеры?

В подавляющем большинстве недорогих IP-камер (стоимостью до 30 тыс рублей) практически идентичный код прошивки, и почти везде встречается одна и та же проблема в сетевом стеке.

Эта проблема выражается в том, что качество получаемой картинки начинает зависеть от сетевых условий.

Выглядит это явление так: в офисе при просмотре через VLC картинка хорошая, а когда камеру вешают на уличный столб — при просмотре через Flussonic картинка рассыпается.

Аналогично может быть при проверке работы камеры через родное приложение: в нём всё идеально, в Flussonic рассыпается.

Технические детали Anchor Anchor x2

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

ПО на камере при вещании по TCP RTSP переводит сетевой сокет в неблокирующий режим. В этом режиме Linux будет копировать в выходной буфер сокета столько данных, сколько может, но не больше, чем осталось места в буфере. В неблокирующем режиме программа не засыпает на время отправки данных по сети (и это в целом правильно, что бы не терять кадры с сенсора), вместо этого функция write будет возвращать количество записанных байт, которое может быть меньше, чем программа попросила отправить в сеть.

Т.е. RTSP стример готовит пакет для отправки по UDP или TCP, пытается отправить по TCP примерно 1500 байт, но записывается только 300 байт. Что бы данные отправились правильно, программа должна запомнить этот факт и допослать данные позже.

Проблема с китайскими камерами заключается в том, что в них используется старый код live555 сервера примерно 2005 года, в котором нет такой логики и камера просто выбрасывает недоотправленные данные. Т.е. в программе на камере неверная реализация сетевой логики.

Пакет начинает слаться по сети, идет его заголовок в котором написано: 1450 байт длина, дальше идет 300 байт и начинается следующий пакет. Таким образом достигается удивительное поведение: данные передаются по TCP и теряются.

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

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

Если вы хотите посмотреть, когда это происходит, то посмотрите в tcpdump: как только приходит сигнал о закрытии приемного буфера, сразу рассыпается картинка.

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

Сопутствующие проблемы Anchor Anchor x2

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

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

Как с этим бороться Anchor Anchor x2

На сервере мало что можно сделать с этой проблемой. В Flussonic реализовано несколько методик борьбы с этой проблемой: большие приемные буферы, восстановление разрушенного потока и т.п.

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

Агент на камере Anchor Anchor x2

Самое действенное решение — это агент на камере. Очень важно, что бы L2 транспорт поменялся на L7, чтобы камере никогда не приходило сообщение о закрытии буфера.

Наш агент написан так, что он всегда примет данные от камеры и, следовательно, ничего не потеряет.

Аналогичный эффект будет при использовании других подобных решений или проброса портов через ssh.