Выделенный сервер для стриминг-платформы: RTMP, транскодирование и выбор тарифа

MAATRIX · Выделенные серверы · Статья 16 из 48

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

Выделенный сервер для стриминг-платформы выбирают по трём отдельным задачам: приём потока, преобразование и доставка. RTMP описывает лишь часть пути. Рассмотрим, что можно поручить PYLON или NECROPOLIS без заявленного GPU и в какой момент число зрителей начинает зависеть прежде всего от сети.

Проследим один кадр от камеры до браузера

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

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

RTMP может использоваться для доставки исходного потока от программы вещания. Для просмотра в современных браузерах обычно выбирают другие механизмы, например HLS или WebRTC, в зависимости от требований. Поддерживаемые браузерные варианты описаны в документации MediaMTX.

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

Две разные цены: перепаковать и пересчитать

FFmpeg называет копирование сжатых потоков без декодирования streamcopy. Транскодирование включает декодирование и последующее кодирование. Разница описана в официальной документации FFmpeg. Для выбора сервера это важнее самой надписи RTMP в проекте.

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

Теперь другой сценарий: из исходного видео нужно постоянно делать несколько вариантов качества. Каждый вариант требует соответствующей обработки. Дополнительно могут понадобиться изменение частоты кадров, графика, обработка звука и запись. Здесь производительность кодировщика становится центральной частью расчёта.

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

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

В тарифах нет GPU: что это меняет

В предоставленных конфигурациях видеокарта не заявлена. Следовательно, нельзя строить предложение на аппаратном кодировании NVIDIA или другом ускорителе, наличие которого не подтверждено. Нужен расчёт CPU-транскодирования либо отдельное согласование подходящей GPU-конфигурации.

PYLON в США предлагает Ryzen 7950X, шестнадцать физических ядер, 64 ГБ DDR5 и NVMe на 1 ТБ за $429 в месяц. NECROPOLIS — EPYC 7642, 48 ядер, 128 ГБ DDR4 и два NVMe по 1 ТБ за $529. Оба можно включить в испытания, но по числу ядер нельзя заранее назначить количество каналов заданного качества.

PYLON интересен там, где кодировщику полезна производительность современных ядер и хватает 64 ГБ. NECROPOLIS может быть удобен для большого числа независимых работ и сопутствующих служб. Насколько конкретный энкодер использует ядра внутри одной задачи и между задачами, покажет только испытание выбранной сборки и настроек.

ANKH с шестью ядрами Ryzen 7600X, 64 ГБ и 1 ТБ за $329 можно проверить для умеренного приёма и раздачи без тяжёлого преобразования. Но слово «умеренный» нужно превратить в конкретные потоки и зрителей. Если требуется много одновременных трансляций с несколькими профилями качества, схема может быстро перерасти такую машину.

PYRAMID с 24 суммарными ядрами двух Xeon Silver 4510 и 128 ГБ DDR5 за $729 не становится автоматически лучшим выбором только из-за цены и двух сокетов. Для медиапроцесса важны кодек, библиотеки, память и распределение работы. Ускорения процессора полезны лишь тогда, когда используемое ПО действительно задействует их.

Сколько зрителей помещается в гигабит

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

Например, условные 200 зрителей по 4 Мбит/с дают 800 Мбит/с полезного видео. При 250 таких зрителях получается уже 1 Гбит/с без остальных расходов. Это не паспортная вместимость сервера: реальные ограничения могут проявиться раньше, а распределение качества у аудитории будет другим.

У рассматриваемых тарифов канал 1 Гбит/с. Надпись UNLIMITED не увеличивает его пропускную способность и не обещает одинаковую скорость до всех стран. Также уточните условия продолжительного исходящего трафика, ограничения услуги и доступные варианты расширения сети. Эти сведения должны появиться в проекте до продажи доступа зрителям.

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

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

Запись эфира превращает временный поток в постоянный расход

Один поток со средним битрейтом 6 Мбит/с создаёт примерно 2,7 ГБ видео за час в десятичных единицах. Это условный расчёт по полезным данным. Несколько каналов, звук, дополнительные варианты качества и служебные файлы увеличивают потребность в хранении.

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

У одного NVMe на 1 ТБ нужно оставить место под систему, временные сегменты, буферы и обработку записей. У NECROPOLIS два накопителя позволяют выбрать схему, но зеркало уменьшит полезную ёмкость примерно до одного диска. Два устройства не означают заранее готового RAID или отдельной резервной копии.

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

Нужные записи сохраняйте вне основного узла и проверяйте возможность их воспроизведения. Резервирование медиаконтента отличается от сохранения конфигурации сервера, поэтому нужны оба процесса. «Файл есть» ещё не гарантирует, что эфир завершён корректно и в нём присутствует звук.

Медиаузел и сайт платформы не обязаны жить вместе

Аккаунты, расписание, платежи или внутренние права доступа относятся к прикладной части платформы. Приём, преобразование и доставка потока — к медиачасти. На старте они могут делить машину, но границы должны оставаться понятными.

Если тяжёлое кодирование занимает все ресурсы, личный кабинет не должен становиться недоступным одновременно с эфиром. Ограничивайте работу процессов или разделяйте узлы по мере роста. Масштабировать веб-приложение и транскодирование часто приходится по разным причинам.

MediaMTX поддерживает несколько способов публикации, чтения и записи потоков; общий состав возможностей перечислен в документации проекта. Но наличие протокола в медиасервере не означает готовую бизнес-платформу со всеми правами, биллингом и правилами просмотра.

Обзор различий медиастеков есть в статье о MediaMTX и nginx-rtmp. При выборе сверяйте актуальную документацию конкретных версий и проверяйте нужную цепочку кодеков: сходные названия функций не всегда означают взаимозаменяемое поведение.

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

Репетиция должна напоминать день события

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

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

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

Отработайте резервный сценарий: повторное подключение источника, запасной медиасервер, переключение доставки и уведомление оператора. Один физический узел остаётся общей точкой отказа независимо от числа процессов на нём. Если эфир критичен, резерв закладывают до события.

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

PYLON и NECROPOLIS можно выбирать после этой репетиции, когда понятна работа CPU и памяти. Для большого числа зрителей потребуется соответствующая сеть распространения, а для тяжёлого транскодирования стоит отдельно оценить GPU. Хорошая платформа оставляет зрителю содержание эфира. Все вычисления, очереди и тарифы должны остаться за кадром.

Все материалы о выделенных серверах