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

  1. Быстрый старт
  2. How To
  3. Потоковое вещание
    1. Публикация
    2. Прием мультикаста
    3. Варианты источников
    4. Переключение источников
    5. Плейлисты
    6. Наложение логотипа
    7. Миксер
    8. WebRTC публикация
    9. SDI
    10. Отправка на другие сервера
    11. Распознавание DVB субтитров
  4. Транскодер
    1. Логотип
    2. Hardware
    3. Скриншоты
    4. Мозаика
  5. DRM
    1. Simple CAS
    2. Conax DRM
    3. BuyDRM (KeyOS)
  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. Транскодирование файлов
  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. Группы каналов

Уменьшение потребления памяти

Уменьшение потребления памяти Anchor Anchor x2

Запущенный Flussonic может потреблять огромное количество памяти: до 30 Гигабайт.

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

Так, для протоколов HLS и HDS все сегменты хранятся в памяти и отдаются из неё максимально быстро. При этом Flussonic – фактически один из двух серверов, которые эффективно используют несколько ядер и раздает видео из общей памяти клиентам по ядрам.

Большинство серверов на С не могут работать в многопоточном режиме и требуют записи HLS сегментов на диск. Такое поведение сервера приводит к непредсказуемой скорости отдачи видео с диска, и удачная запись в лог может нарушить вещание прямого эфира. У Flussonic такой проблемы нет за счёт того, что явно используется память для хранения последних секунд потока.

Давайте рассмотрим, какие основные потребители памяти есть в Flussonic.

HDS Anchor Anchor x2

Для того, что бы уменьшить расход памяти, проще всего отключить HDS. Без него обойтись можно, а вот HLS лучше оставить:
stream ort {
  url udp://239.0.0.1;
  hds off;
}

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

Prepush Anchor Anchor x2

Следующий способ сокращения расходов на память — отключение препуша. Препуш — это кадры в памяти, которые будут посланы клиенту, который только что подключился по протоколу RTMP или HTTP MPEG-TS, и сохранены в буфере на клиенте:
stream ort {
  url udp://239.0.0.1;
  hds off;
  prepush off;
}

Теперь кадры не будут сохраняться в потоке, будут накапливаться только в списке HLS сегментов.