Как это устроено
Принятый поток разбирается и упаковывается во фрагменты один раз. Все протоколы раздачи читают этот же буфер, из него же ведётся запись архива. Отсюда и задержка, и расход ресурсов — ниже они разобраны по шагам.
Приём и раздача
HLS отдаёт готовые фрагменты сегментами плейлиста, MSE-WS шлёт их в браузер по вебсокету, RTSP распаковывает обратно в пакеты — все из одной упаковки. Повторной работы нет, поэтому «лишние» протоколы почти ничего не стоят.
- 01 Приём по схеме адреса Способ приёма задаёт схема в начале адреса источника: RTSP, HTTP, UDP, RTMP, публикация, файл.
- 02 Разбор один раз Поток разбирается на кадры один раз — сколько бы протоколов его потом ни отдавало.
- 03 Упаковка один раз Кадры складываются во фрагменты, готовые к отдаче. Перекодирования нет: меняется только контейнер.
- 04 Раздача 10 протоколов Все протоколы читают одну и ту же упаковку, поэтому включать «лишние» не вредно.
- Второй протокол почти бесплатен
- Он не добавляет работы по переупаковке — только отправку. Платить приходится за поток, а не за формат.
- Архив пишется из той же упаковки
- Отдельного разбора «для записи» нет: на диск дописываются уже упакованные фрагменты, без повторной упаковки.
- Медленный зритель не мешает остальным
- Индивидуальных очередей на зрителя нет, поэтому один медленный канал не задерживает остальных.
Что приходит на сервер
Способ приёма определяется адресом источника. Забор сервер выполняет сам — и сам переподключается; публикацию он ждёт от кодировщика или браузера.
Таблица прокручивается вбок.
| Источник | Что это | Когда применять |
|---|---|---|
| RTSP · RTSPS | Забор с камеры, видеорегистратора или кодировщика | Основной сценарий видеонаблюдения. Транспорт TCP или UDP, Basic и Digest |
| HTTP · HTTPS | Забор HLS, DASH или непрерывного MPEG-TS; формат определяется автоматически | Пересборка чужой раздачи, приём от вышестоящего сервера |
| UDP · multicast | MPEG-TS по UDP — одноадресный или групповой | Головные станции и транспорт внутри своей сети |
| RTMP · RTMPS | Сервер сам подключается к источнику и забирает поток | Источник, который умеет отдавать только по RTMP |
| Публикация RTMP | Кодировщик публикует поток на сервер, в том числе поверх TLS | Студийные кодировщики; источник, к которому нельзя подключиться снаружи |
| WHIP (WebRTC) | Публикация из браузера по WebRTC поверх обычного HTTP-запроса | Камера и микрофон рабочего места, источник за NAT |
| Файл MP4 | Локальный файл, проигрываемый по кругу в реальном темпе | Заглушка вместо камеры, проверка конвейера, демонстрация |
| Тест-паттерн | Встроенный синтетический источник с часами | Проверка установки до появления камер, нагрузочное тестирование |
| Второе имя потока | Второй путь к уже принятому потоку без второго подключения | Публичное имя потока, отдельный набор меток доступа |
Что уходит зрителям
Раздача поднимается на том же потоке одновременно всеми протоколами: зритель выбирает адрес, а не сервер выбирает формат за него.
Таблица прокручивается вбок.
| Протокол | Доставка | Где применять |
|---|---|---|
| HLS fMP4 | несколько секунд | Универсальная совместимость: браузеры, мобильные, телевизоры, CDN |
| LL-HLS | доли секунды | Тот же HLS, когда важна задержка |
| HLS-TS | несколько секунд | Приставки и телевизоры, не понимающие fMP4 |
| DASH | несколько секунд | Встраиваемые плееры и устройства, ориентированные на DASH |
| MSE-WS | доли секунды | Видеостены и панели наблюдения в браузере без WebRTC |
| HTTP-TS | доли секунды | Простые потребители, читающие непрерывный поток по HTTP |
| RTSP · RTSPS | десятки миллисекунд | Видеорегистраторы, стороннее ПО, служебная диагностика |
| RTMP · RTMPS | доли секунды | Передача в сторонние сервисы, принимающие RTMP |
| WHEP (WebRTC) | доли секунды | Самая низкая задержка в браузере и единственный способ услышать звук G.711 |
| Multicast MPEG-TS | доли секунды | Раздача внутри своей сети без запроса от клиента |
| Превью-кадр | — | Плитки, списки камер, заставка до запуска видео |
| Встраиваемый плеер | — | Быстрый просмотр и встраивание в свою страницу |
Протоколов в этой таблице десять: превью-кадр и встраиваемый плеер — адреса раздачи, но не протоколы, а варианты поверх TLS считаются тем же протоколом. В колонке «Доставка» — путь до плеера; итог у зрителя определяет буфер плеера — он разобран в разделе «Задержка» ниже.
Что действительно бесплатно
- Семейство fMP4 — HLS, LL-HLS, DASH, MSE-WS, WHEP, RTSP — читает готовую упаковку: добавление любого из них не создаёт работы по переупаковке.
- HTTP-TS и HLS-TS требуют отдельной упаковки в MPEG-TS. Она бездействует, пока нет зрителей.
- Групповая раздача — постоянный потребитель: пакеты уходят в сеть всегда, независимо от того, слушает ли их кто-нибудь.
Перекодирования нет
- Кадр доходит до зрителя байт в байт — меняется только контейнер. Кодек и разрешение выбираются на камере, а не на сервере.
- Каждый протокол несёт только то, что способен нести. Звук G.711 доступен в браузере единственным способом — через WebRTC; AAC по WebRTC, наоборот, не согласуется.
- Несовместимая дорожка не создаётся и не объявляется в плейлисте: зритель получает исправное видео без звука, а не сломанный поток.
Задержка до зрителя
Итог у зрителя определяет не столько доставка, сколько буфер плеера — запас против неровности сети; разница между протоколами — в способе раздачи и глубине этого запаса, а не в качестве картинки. Поток отдаётся всеми протоколами сразу, поэтому протокол выбирают под задачу.
- RTSP доли секунды у зрителя · буфер задаёт клиент, обычно минимальный
- MSE-WS ≈1 с у зрителя · цель плеера 0,95 с, на Safari — 1,5 с
- LL-HLS ≈4 с у зрителя · цель плеера — запас ради плавности
- HLS обычный ≈8 с у зрителя · цель плеера — ≈3 сегмента от живого края
доставка до плеера — измерено запас плеера до его целевой задержки
Доставка измерена на одном стенде и одном источнике, настройки по умолчанию. Итог у зрителя — целевая задержка нашего веб-плеера: она отсчитывается от живого края и уже включает доставку, слои не складываются. Запас выбран ради плавности — подвисания недопустимы — и при необходимости снижается настройкой плеера. Шкала логарифмическая — иначе столбец обычного HLS раздавил бы остальные; точные числа зависят от источника, сети и плеера, порядок величин устойчив.
Реакция на событие
RTSP · WHEPПост охраны, диспетчерская, поворотная камера под управлением оператора: между действием и картинкой — доли секунды. Буфер задаёт клиент; в браузере ту же роль играет WebRTC.
Стена в браузере
MSE-WSДесятки плиток на одном экране без плагинов: обычный вебсокет и готовые фрагменты. У зрителя — около секунды: плеер держит небольшой запас против рывков сети.
Массовая раздача
HLS · LL-HLSТысячи зрителей, любые устройства, кэширование на промежуточных узлах. У зрителя — около восьми секунд, и для этой задачи это норма; LL-HLS — отдельный адрес того же потока, вдвое ближе к эфиру.
Как получить минимальную задержку
Три решения, и первое из них — не серверное. Пока камера не отдаёт опорные кадры чаще, остальные упираются в её потолок.
- 01 Выберите протокол под задачу
- Между RTSP и обычным HLS — почти тридцатикратная разница. Поток отдаётся всеми протоколами сразу — выбирает принимающая сторона.
- 02 Настройте камеру
- Интервал опорных кадров на камере влияет на задержку сильнее любой серверной настройки: он задаёт нижнюю границу. Рабочее значение — одна-две секунды.
- 03 Возьмите адрес низкой задержки
- Доставка — 317 мс вместо 2 605 мс, у зрителя — около четырёх секунд вместо восьми. Низкая задержка — отдельный адрес того же потока, а не параметр запроса: обычный и низколатентный HLS доступны одновременно, выбирает плеер.
Архив и VoD
Запись ведётся из той же упаковки, из которой идёт раздача: отдельного разбора «для архива» нет. Медленный или полный диск не создаёт обратного давления на источник — приём потока не тормозит никогда.
- 15 / 30 / 60 минут
- длительность одного файла записи
- 90 %
- порог вытеснения по заполнению диска
- 6 часов
- окно одного плейлиста архива
- 24 часа
- предельная длительность одной выгрузки
Непрерывная запись
Записи режутся на файлы фиксированной длительности, рез — всегда по опорному кадру. Рядом с каждым файлом лежит индекс, поэтому перемотка по архиву мгновенна. Незавершённая запись физически не может попасть ни в выдачу, ни под удаление.
Глубина архива
Глубина задаётся временем, объёмом или обоими сразу — сработает то ограничение, которое наступит раньше. Удобный приём: время по требованиям регламента, объём — как страховка от выросшего битрейта.
Вытеснение по месту
Кроме глубины, заданной каждому потоку, есть вторая защита: когда файловая система переходит порог заполнения, обслуживание удаляет самые старые записи по всем потокам этого хранилища. Самая свежая запись потока не удаляется никогда.
Холодный ярус S3
На диске держится короткое горячее окно, длинная история уезжает в S3-совместимое хранилище. Индекс всегда остаётся локальным, поэтому календарь, шкала и переход в произвольную точку работают одинаково быстро — независимо от того, где лежит само видео.
Просмотр и таймшифт
Архив отдаётся тем же протоколом, что и живое видео: плеер получает обычный плейлист, только описывающий запрошенный интервал времени. Таймшифт — тот же архив, привязанный к живому краю: зритель отматывает назад и продолжает смотреть, а плеер по мере записи догоняет реальное время.
Экспорт и VoD
Фрагмент выгружается готовым MP4 без перекодирования, со сброшенным в ноль отсчётом времени и полным звуком. Отдельно от архива работает библиотека VoD: вы кладёте файлы в каталог, и они играются с перемоткой без этапа импорта.
Свойства ярусов
- Индекс всегда локальный
- Календарь, шкала и переход в произвольную точку не ходят в сеть — даже когда тело записи лежит уже только в объектном хранилище.
- Выгрузка с подтверждением
- Объект сверяется по размеру и контрольной сумме. Чужой объект с тем же именем не перезаписывается никогда, а локальная копия удаляется только после подтверждения.
- Том проверяется маркером
- Сервер отличает «диск не смонтирован» от «архив пуст» и во втором случае не начинает наполнять точку монтирования на системном разделе.
Когда хранилище подводит
- Том не смонтирован
- Запись не начинается, чтение архива отвечает «повторите позже»
- Диск заполнен
- Обслуживание просыпается досрочно и освобождает место; приём потока не тормозится
- Каталог закрыт на запись
- Запись не начинается, поток продолжает раздаваться живьём, причина — в журнале
- Объектное хранилище молчит
- Холодные записи отвечают «повторите позже», невыгруженный остаток копится и не теряется
- Хранилище отвечает ошибками
- Предохранитель выдерживает паузу от секунды до минуты, чтобы повторы не умножали нагрузку
Недоступный архив всегда отвечает «повторите позже», а не «записи нет»: клиент различает эти случаи по коду ответа и не принимает пробел за норму.
Откуда берётся экономия
Плотность потоков — главное конкурентное преимущество платформы: расход линеен и предсказуем, тысячный поток стоит столько же, сколько первый.
до 50 Гбит/с
с одного сервера Верхняя граница трафика одной машины при достаточной полосе. Как и плотность, зависит от характеристик потоков.
Зрители обходятся почти даром
Вся тяжёлая работа привязана к потоку и не зависит ни от числа зрителей, ни от числа включённых протоколов. Зритель добавляет к ней только отправку байтов, поэтому рост аудитории почти не увеличивает расход процессора.
- Второй и третий протокол раздачи добавляют только отправку.
- Тысяча зрителей одного потока обходится дешевле, чем сто зрителей десяти потоков.
- Запись архива дешёвая: на диск дописываются уже упакованные фрагменты, без повторной упаковки.
- Дороже среднего обходятся шифрованные раздачи, WebRTC и RTSP по UDP — там работа приходится на каждого зрителя отдельно.
Откуда это берётся
Ядро написано на Rust — современном высокопроизводительном языке. Дальше дело в качестве: выверенный и тщательно протестированный код и архитектура, спроектированная под эту нагрузку с самого начала.
- Специальные платы и ускорители не нужны: обычный сервер общего назначения на Linux x86-64.
- Память считается по потокам, а не по зрителям: поток на 4 Мбит/с занимает около 6 МБ, плюс 100–150 МБ на сам процесс.
- Медленный зритель отстаёт только сам и не тормозит ни поток, ни соседей.
- Расход процессора и памяти сервер измеряет сам и публикует в панели, API и метриках — проверить расчёт можно на своей установке.
Что происходит, когда что-то ломается
Обрыв источника не разрушает поток: упаковка, зрительские сессии и запись архива переживают переподключение. Ни один зритель не отключается, ни один запрос не отвечает ошибкой «нет такого потока».
Резервный источник
- Текущий источник отказал
- Немедленный переход к следующему, без паузы
- Цепочка кончилась
- Цикл начинается заново после паузы в 3 секунды плюс случайная добавка до 3 секунд
- Работа на резерве
- Через 30 секунд приём с резерва прерывается и сервер пробует основной источник
- Основной ответил
- Работа продолжается на нём, без паузы
- Камера «замерла»
- Сокет жив, кадров нет: сторож срабатывает через 20 секунд — это верхняя граница задержки переключения
Переключение не бесшовное по кадрам: зритель увидит паузу. Резерв защищает от длительной пропажи картинки, а не от секундного перерыва. И резервируется источник, а не сервер.
Отстающий зритель по протоколам
- MSE-WS
- Срок записи кадра 10 секунд; превышение отключает эту сессию
- HTTP-TS
- Пересинхронизация вперёд, обратное давление сокетом
- Multicast
- Пересев на ближайший опорный кадр и догон восьмикратной скоростью
- RTMP
- Срок записи 10 секунд
Индивидуальных очередей на зрителя нет, поэтому один медленный канал не удерживает память за остальных и не задерживает соседей.
Кэширование на промежуточных узлах
- Закрытые сегменты и части кэшируются навсегда
- Сегменты, части низкой задержки, файлы инициализации, завершённые записи архива, сборка плеера
- Плейлисты и манифесты не кэшируются
- Живой край меняется постоянно: плейлисты, манифест DASH, превью, непрерывный поток, страница плеера
Кэшируемость сегментов пропадает у потока, привязанного к домену, и у потока, закрытого внешней авторизацией: закрытый поток и промежуточный кэш несовместимы в принципе.
Правка без простоя
Изменения сверяются по одному, и перезапускается только то, чей отпечаток изменился. Поэтому правка одного потока не задевает соседние, а неудачная правка не задевает вообще ничего.
Таблица прокручивается вбок.
| Что изменили | Что перезапустится |
|---|---|
| Параметр одного потока | Только этот поток. Остальные сохраняют аптайм, буферы и зрителей |
| Только метки доступа | Ничего: новые метки действуют сразу, видео не прерывается |
| Добавили поток | Новый поток запускается, существующие не трогаются |
| Убрали поток | Останавливается он один, его сессии закрываются |
| Настройки хранилища | Каждый поток, который в это хранилище пишет; остальные не трогаются |
| Доступ и сертификаты | Ничего: политика доступа перечитывается на каждый запрос |
| Порты, ядра, глобальные параметры | Ничего до перезапуска службы: значение записано, но ждёт |
| Секрет подписи сессий | Ничего: выданные билеты аннулируются, плеер переустанавливает сессию следующим запросом |
- Файл проверяется отдельной командой, которая ничего не запускает и печатает все ошибки разом, а не по одной за попытку.
- Отвергнутая правка не меняет ничего: работающая конфигурация остаётся прежней, зрители этого не замечают.
- Сервер сам относит каждое изменение к своему классу и пишет вердикт в журнал — гадать, применилось ли, не нужно.
Проверьте на своей задаче
По запросу выдаём демо-лицензию: снимете задержку и загрузку на своём оборудовании и своих источниках — решение примете по собственным цифрам, а не по нашим синтетическим замерам.