Документация на 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

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

Важно понимать, что все такие оценки (в том числе те, которые описаны на этой странице) — очень примерные и могут не отражать истинное положение вещей.

Например, можно считать, что в среднем одна камера отдает видео со скоростью 2 мегабита, но с тем же успехом какая-то другая камера может отдавать и 1, и 4, и 8. Вы можете примерно предположить, сколько ресурсов процессора займет один поток, но какой-то другой, особый, поток может использовать гораздо больше ресурсов.

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

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

Архитектура Anchor Anchor x2

Flussonic Media Server работает на следующих архитектурах:

  • amd64 (x86_64)
  • armhf 32bit (RaspberryPI, Cubieboard, Parallela и т.п.)
  • tilera
  • mips

Примерная оценка производительности Anchor Anchor x2

Кол-во одновременных подключений 10 100 1 000 5 000+
Процессор Любой 1-ядерный 4-х ядерный (Xeon / Core i7) 2-х процессорный Xeon E5
Оперативная память 128 Мб 256 Мб 1024 Мб 16 Гб
Место на жестком диске 40 Мб 40 Мб 40 Мб 40 Мб
Сетевой адаптер 100 Мбит/с 1 Гбит/с 1 Гбит/с серверный 10 Гбит/с Intel
Операционная система Debian Linux, Ubuntu Linux

Часто первым же узким местом является пропускная способность сети. Мощнейший процессор не поможет, когда клиентам просто не хватает ширины канала для получения видео. В среднем можно считать что один клиент (один человек, смотрящий видео по сети) будет тратить 2 мегабита на просмотр обычной камеры или SD-канала, или 10 мегабит на HD-канал.

Оперативную память можно брать в среднем из расчета 20-50 мегабайт на 1 поток. Это количество памяти может значительно возрасти при использовании дополнительных возможностей типа JPEG thumbnails, или наоборот уменьшено с помощью директив вроде hds off.

Необходимо учитывать, что при передаче мультимедиа-данных из файлов на жестком диске, основная нагрузка ложится на дисковую подсистему. Соответственно, при планировании конфигурации сервера, особое внимание должно быть уделено производительности используемых жестких дисков. SSD стоит использовать для «горячей зоны» и кэша, HDD для всего остального. Подробнее в разделе про вещание файлов.

Процессор Anchor Anchor x2

Минимально нужен любой современный процессор. i5/i7/Xeon — выдержит ретрансляцию без транскодирования около 200 потоков/камер, Raspberry — только 64.

Один сервер с несколькими процессорами лучше, чем несколько серверов с одним процессором.

Транскодирование Anchor Anchor x2

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

Транскодирование — ресурсоёмкая задача. Рассчитывайте всего от 5 до 20 каналов на один сервер в зависимости от настроек. Более конкретно: например, на Xeon E3 1240 сервере транскодируется около 5-10 каналов.

Из разумных вариантов процессора для транскодирования — Xeon E5 с максимальной тактовой частотой. Это серверное решение.

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

Взаимодействие с другими приложениями и операционной системой Anchor Anchor x2

При планировании мощностей сервера, должны быть также учтены ресурсы, необходимые для работы операционной системы и других сервисов, которые будут функционировать параллельно с Flussonic Media Server.

Лучше всего сделать так, чтобы на сервере выполнялся только Flussonic Media Server и всё. Если у вас есть какие-то другие видеостриминговые приложения — вынесите их на другие, отдельные сервера.

Если вы планируете использовать более 60 гигабайт оперативной памяти, рассчитывайте что нужно зарезервировать под Linux около 10 гигабайт.

Также придется полностью отключить swap, так как его наличие несовместимо с видеостримингом. Если на сервере не хватает оперативной памяти, её нельзя расширять с помощью swap.

Кластеризация Anchor Anchor x2

Если возможностей одного сервера не хватает, то можно распределить нагрузку сразу на несколько серверов. Подробная информация находится в разделе о кластеризации.

Большие нагрузки Anchor Anchor x2

Рекомендуем посмотреть запись доклада «Вещание видео на 10 ГБитс», сделанного на конференции HighLoad ведущим разработчиком Эрливидео Максимом Лапшиным.

Ссылка на доклад: https://vimeo.com/95959450

Вещание видео на 10 ГБитс, Максим Лапшин (Erlyvideo) from Ontico on Vimeo.

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

Во второй части доклада будет рассказано, какие аппаратные проблемы, проблемы уровня операционной системы и алгоритмические проблемы возникают при достижении трафика в 10 Гбит/с с одного сервера.

А именно:

  • почему приходится отказываться от аппаратных рейдов в пользу примитивных JBOD-решений и как ими управлять?
  • как так получилось, что для быстрой сети существует событийный API epoll, а для медленных дисков — только блокирующий API, и что с этим делать?
  • как эффективно использовать дорогие SSD в связке с дешевыми HDD? Различные профили нагрузки у сайтов с разным контентом: где-то весь трафик можно раздать с зеркалированного SSD, а где-то размер "горячей" зоны переваливает за 5 терабайт.
  • подходы к решению проблемы выбора: какой контент класть на SSD, а какой продолжать раздавать с HDD?
  • как строить программу так, чтобы она никогда не сообщала об истекшем времени ожидания и внятно диагностировала собственную перегрузку?