Сколько сеансов транскодинга потянет медиасервер: замер на одном фильме

MAATRIX

Друзья и родственники подключились к вашему Jellyfin или Plex, и вечером в пятницу сервис начинает заикаться: у одного видео тормозит на буферизации, у другого звук отстаёт от картинки. Вопрос «сколько человек одновременно потянет сервер» звучит просто, но правильный ответ — не число из таблицы производителя процессора, а результат замера на конкретном контенте и конкретном железе. Ниже — как посчитать реальную ёмкость своего медиасервера, не гадая и не покупая процессор «с запасом на всякий случай».

Почему нет универсального числа сеансов

Медиасерверы вроде Plex и Jellyfin умеют отдавать файл двумя принципиально разными способами. Direct play — сервер просто раздаёт исходный файл без изменений, клиент декодирует его сам. Это почти бесплатно для CPU сервера: нагрузка — сетевой ввод-вывод и минимальная работа контейнера. Транскодинг — сервер на лету перекодирует видео в другой формат, разрешение или битрейт, потому что клиент не может воспроизвести исходник напрямую (не поддерживает кодек, слишком слабый канал, не тот контейнер) или потому что вы явно ограничили качество для экономии трафика.

Транскодинг видео программным способом (через CPU, без аппаратного ускорения) — тяжёлая задача: кодировщик x264 или x265 гоняет кадр за кадром через сложный алгоритм сжатия, и это может занимать значительную долю ядра процессора на один поток. Поэтому «сколько сеансов потянет сервер» на самом деле раскладывается на два разных вопроса: сколько сеансов direct play (почти неограниченно, упирается в сеть и диск) и сколько сеансов одновременного транскодинга (жёстко ограничено ядрами CPU или наличием аппаратного ускорителя). Готового числа для «процессора с N ядрами» не существует, потому что нагрузка транскодинга сильно зависит от исходного кодека, разрешения, битрейта, целевого качества и от того, насколько эффективно кодировщик настроен. Тот же процессор потянет условный один сеанс перекодирования 4K HEVC в 1080p H.264 с высокими настройками качества и в разы больше сеансов простого понижения битрейта того же 1080p-файла. Единственный надёжный способ узнать реальную цифру для себя — замерить на своём контенте.

Как понять, что сервер вообще транскодирует

Прежде чем измерять нагрузку, убедитесь, что сеанс действительно идёт транскодингом, а не direct play или direct stream (более лёгкий режим, когда видеопоток не трогают, а меняют только контейнер или перекодируют звук). В Plex это видно на странице «Панель управления» → «Активность» — там для каждого сеанса написано Direct Play, Direct Stream или Transcode, и при наведении показывается причина (несовместимый кодек, ограничение битрейта, субтитры, требующие вжигания в кадр). В Jellyfin аналогичная информация — на вкладке «Панель мониторинга» → «Активность», там же видно, что именно перекодируется: видео, аудио или оба потока.

Частая ошибка — тестировать «ёмкость сервера по транскодингу», подключаясь с того же браузера на том же устройстве, где сервер и так отдаёт direct play, а потом удивляться, что нагрузка на CPU почти нулевая. Проверяйте на реальном клиенте (смартфон в мобильной сети, старый смарт-ТВ, браузер с принудительным ограничением качества), где транскодинг действительно включается, либо принудительно задавайте целевое качество ниже исходного в настройках воспроизведения — так вы гарантированно увидите транскодинг в логах.

Тестовый прогон: замер CPU на одном файле

Самый честный способ узнать ёмкость сервера — не читать чужие бенчмарки (они снимались на другом железе и другом контенте), а прогнать транскодинг вашего типового файла и посмотреть, сколько ресурсов CPU это реально съедает.

Схема замера:

1. Возьмите представительный файл — тот формат, что действительно преобладает в вашей библиотеке (например, 1080p H.264 или 4K HEVC — для разных исходников цифры будут разными, поэтому измеряйте каждый профиль контента отдельно).
2. Запустите воспроизведение с клиента, который гарантированно вызовет транскодинг видео (не просто аудио) — самый показательный случай: снизить целевое качество в настройках плеера ниже битрейта исходника.
3. Пока идёт транскодинг одного сеанса, замерьте загрузку CPU средствами ОС:

top -bn1 | head -20

или для более наглядной картины по ядрам:

mpstat -P ALL 1 5

Смотрите не только на суммарную загрузку системы, но и на конкретный процесс кодировщика (ffmpeg в случае Plex и Jellyfin — оба под капотом используют его для программного транскодинга):

top -p $(pgrep -d',' ffmpeg)

1. Зафиксируйте, сколько процентов от общего CPU-времени системы съедает один сеанс. Если сервер, например, показывает 100% занятости условного одного ядра из имеющихся на транскодинг 1080p-профиля, а система в сумме даёт 400% (4 ядра), это грубо намекает на 3-4 таких сеанса до полной загрузки — но с поправкой на то, что операционной системе и самому медиасерверу тоже нужны ресурсы, и что реальная нагрузка не масштабируется линейно один в один.
2. Повторите тот же замер для второго и третьего одновременного сеанса того же профиля — так вы увидите, действительно ли нагрузка растёт линейно или где-то раньше начинается деградация (упор в память, в диск, в лимиты планировщика).

Важная оговорка: конкретные проценты и «сколько сеансов на сколько ядер» — это не универсальные цифры, которые можно взять из статьи и применить к своему серверу. Слишком много переменных: кодек источника, целевой кодек, разрешение, набор настроек качества, скорость диска, файловая система, версия ffmpeg. Единственный способ получить число, которому можно доверять, — прогнать замер именно на своём файле и своём железе, как описано выше.

Роль direct play: как не грузить CPU там, где не нужно

Прежде чем думать о наращивании мощности CPU под транскодинг, стоит спросить: а нельзя ли вообще избежать транскодинга для большинства сеансов? Direct play не грузит CPU перекодированием, и часто ёмкость сервера по «числу одновременных зрителей» ограничивается не транскодингом, а именно тем, что вы вынуждаете сервер перекодировать то, что клиент прекрасно воспроизвёл бы сам.

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

• Клиент не поддерживает контейнер или кодек исходника (например, старый Smart TV без поддержки HEVC/H.265) — тут без перекодирования не обойтись, разве что заранее перекодировать библиотеку в более совместимый формат.
• Явное ограничение битрейта в настройках плеера или профиля пользователя — сервер вынужден понижать качество, даже если сеть клиента спокойно тянет оригинал.
• Субтитры, требующие «вжигания» в видеопоток (некоторые форматы субтитров или сочетание с определённым контейнером клиент не умеет накладывать сам) — это тоже транскодинг видео, даже если разрешение и битрейт не меняются.
• Слишком строгий лимит удалённого доступа «на всякий случай», выставленный с запасом и включающий транскодинг там, где сеть клиента на самом деле потянула бы оригинал.

Практический вывод: настройте клиентские приложения на максимально совместимые контейнеры и кодеки, при возможности используйте прямую передачу потока с локальной сети без принудительного лимита битрейта и проверьте, действительно ли ограничение качества у мобильных/удалённых пользователей нужно, или это защита от гипотетической, а не реальной проблемы с их каналом. Каждый сеанс, переведённый из транскодинга в direct play, — это высвобожденное ядро CPU для кого-то другого.

Аппаратное ускорение: Quick Sync, VAAPI, NVENC

Если direct play не закрывает всю нагрузку и часть аудитории объективно требует перекодирования (старые ТВ-приставки, ограниченные каналы, разные разрешения экранов), следующий шаг — не наращивать число ядер CPU, а перенести транскодинг на встроенный видеоускоритель.

Разница принципиальная: программный (CPU-based) транскодинг x264/x265 — это универсальный, но дорогой по ресурсам путь, где один сеанс перекодирования 4K может занимать заметную часть многоядерного процессора. Аппаратный транскодинг использует специализированный блок кодирования/декодирования видео, встроенный в GPU или в сам процессор, и делает ту же работу на порядок дешевле по нагрузке на CPU — ценой чуть меньшей гибкости настроек качества и, как правило, чуть более слабого сжатия при том же битрейте по сравнению с хорошо настроенным программным x265.

Три основных варианта аппаратного ускорения на серверном железе:

Что даёт переход на аппаратное ускорение практически: один и тот же процессор, который программно тянул условно 2-3 одновременных транскодинга 1080p, с включённым Quick Sync или NVENC может обслуживать заметно больше сеансов того же профиля, потому что тяжёлая часть работы (кодирование кадров) уходит с ядер CPU на специализированный блок, а CPU остаётся занят только управлением потоком, контейнером и сетью.

Плюсы аппаратного ускорения:

• Радикально меньше нагрузки на CPU на один сеанс — освобождает ядра под другие сеансы или под остальные сервисы на том же сервере.
• Позволяет обслуживать больше одновременных зрителей на том же железе без апгрейда процессора.
• В Plex часть функций аппаратного перекодирования доступна только с подпиской Plex Pass, в Jellyfin — бесплатно из коробки, это стоит учитывать при выборе платформы.

Ограничения и нюансы, о которых стоит знать заранее:

• Аппаратное ускорение поддерживает не все комбинации кодек-разрешение-профиль — экзотические кодеки или очень высокие битрейты иногда всё равно уходят в программный путь.
• Качество при том же битрейте у аппаратных кодировщиков обычно чуть ниже, чем у тщательно настроенного программного x265 — для большинства зрителей на потоковом видео разница незаметна, но для перфекциониста может быть аргументом.
• На выделенном сервере без дискретной видеокарты и без интегрированной графики (частый случай серверных процессоров без встроенного GPU) аппаратное ускорение попросту недоступно — тогда единственный рычаг — направить максимум сеансов через direct play и держать программный транскодинг про запас на меньшинство клиентов.
• Проброс видеоускорителя в контейнер (Docker) требует правильно настроенных прав доступа к устройству /dev/dri (для Quick Sync/VAAPI) или /dev/nvidia* (для NVENC) — без этого сервис в контейнере аппаратное ускорение просто не увидит, даже если оно физически есть на хосте.

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

Что делать с результатами замера

После того как вы прогнали тестовый транскодинг и увидели реальную загрузку CPU на один сеанс, дальше есть несколько практических путей — в порядке от самого дешёвого к самому затратному:

1. Снизить долю транскодинга через direct play. Проверьте настройки клиентов и лимиты битрейта, как описано выше — часто это закрывает половину нагрузки бесплатно.
2. Включить аппаратное ускорение, если оно физически доступно. Если процессор сервера имеет встроенную графику с поддержкой Quick Sync, это обычно самый выгодный по деньгам шаг — прирост ёмкости без апгрейда железа.
3. Ограничить максимальное качество транскодинга. Понижение целевого разрешения или битрейта уменьшает нагрузку кодировщика на сеанс — не всегда приемлемо для зрителя, но иногда разумный компромисс на пиковой нагрузке.
4. Нарастить число ядер CPU. Если аппаратного ускорения нет или оно недоступно для нужных кодеков, а зрителей объективно много, единственный оставшийся рычаг — сервер с большим числом ядер и высокой частотой на ядро (транскодинг одного потока чувствителен именно к однопоточной производительности, а не только к их количеству).
5. Пересмотреть саму библиотеку. Если основная причина транскодинга — несовместимый кодек у старых клиентов, иногда дешевле один раз перекодировать библиотеку в более совместимый формат (например, H.264 вместо HEVC), чем постоянно тратить CPU на транскодинг на лету.

Такой замер стоит повторять при заметном изменении состава контента (например, если библиотека переходит на 4K HEVC) или при добавлении новых типов клиентов — цифры, снятые на 1080p H.264, не переносятся на 4K-профиль автоматически.

Частые вопросы