n1ro°
RU

Текст и данные · Инструкция

Как включить аппаратное транскодирование Jellyfin

Включить аппаратное транскодирование Jellyfin имеет смысл, когда сервер регулярно преобразует видео для клиентов и CPU.

Редакция N1RO · Проверено

Короткий ответ

В Dashboard → Playback включите метод, соответствующий платформе: Intel QSV, NVIDIA NVENC, AMD AMF/VA-API, Apple VideoToolbox или поддерживаемый RKMPP. Затем принудительно снизьте качество воспроизведения и проверьте FFmpeg-лог: там должен использоваться аппаратный декодер/энкодер, а не только CPU.

Когда Jellyfin вообще начинает транскодировать

Jellyfin предпочитает отдавать клиенту файл напрямую, если контейнер, кодек, профиль, разрешение, битрейт, аудио и субтитры подходят устройству. Поэтому после включения hardware acceleration можно увидеть почти нулевую нагрузку GPU просто потому, что транскодирование не требуется. Сервер начинает преобразование, когда клиент просит меньший битрейт или не поддерживает исходный формат, а также в некоторых сценариях с субтитрами, HDR и несовместимым аудио. Выходные параметры определяются возможностями клиента и исходного файла; вручную заставить сервер всегда выдавать конкретное разрешение нельзя тем же способом, которым задаётся качество в плеере. Для проверки нужно осознанно создать ситуацию транскодирования — например, запустить тяжёлый файл и снизить качество потока. Если воспроизведение остаётся Direct Play, это нормальный и обычно самый эффективный режим, а не ошибка конфигурации.

Совет: Сначала проверьте причину сессии: Direct Play обычно требует меньше ресурсов, чем любое транскодирование.

Какой метод аппаратного ускорения выбирать

  • Intel, Windows. QSV. Основной поддерживаемый путь для Intel на Windows
  • Intel, Linux. QSV или VA-API. QSV предпочтителен на поддерживаемых современных поколениях
  • NVIDIA, Windows/Linux. NVENC/NVDEC. Нужна модель с медиаблоками и корректный драйвер
  • AMD, Windows. AMF. Официальный путь Jellyfin для Windows
  • AMD, Linux. VA-API. Предпочтительный вариант по документации Jellyfin
  • macOS. VideoToolbox. Использует аппаратные медиавозможности Mac

Предупреждение: Не выбирайте backend наугад. Метод зависит от ОС и GPU; несовместимая комбинация часто заканчивается software fallback или ошибкой FFmpeg.

Настройка и проверка аппаратного транскодирования

  1. Определите GPU сервера и кодеки, которые он умеет декодировать и кодировать. Для Linux проверьте, что устройство видно системе и доступно процессу Jellyfin или контейнеру.
  2. Используйте официальный jellyfin-ffmpeg, который поставляется с официальными пакетами и контейнерами. Случайный системный FFmpeg может дать лишь частичное ускорение.
  3. Откройте Dashboard → Playback/Transcoding и выберите аппаратный метод для своей платформы. Не отмечайте кодеки, которые GPU аппаратно не поддерживает.
  4. Если сервер работает в Docker, пробросьте GPU-устройство и необходимые права внутрь контейнера. На bare metal убедитесь, что драйвер установлен и сервис Jellyfin имеет доступ к устройству.
  5. Запустите видео, требующее транскодирования, и выберите более низкий битрейт или разрешение. В информации о воспроизведении должна появиться причина Transcoding.
  6. Проверьте FFmpeg-лог и системную нагрузку. Аппаратный backend в логе важнее общего процента GPU, потому что Video Decode/Encode часто считаются отдельно от 3D-нагрузки.
  7. Повторите тест на HEVC/HDR-файле и на обычном H.264. Частичное ускорение одного формата не гарантирует поддержку другого.

Важно: Если CPU всё равно загружен, это не всегда сбой: отдельные этапы, включая часть обработки субтитров, scaling или tone mapping, могут оставаться программными.

Почему ускорение бывает частичным

Цепочка транскодирования состоит из декодирования, возможного деинтерлейса, масштабирования, преобразования формата, tone mapping, обработки субтитров и повторного кодирования. Аппаратная поддержка каждого этапа зависит от GPU, драйвера и конкретного кодека. Поэтому сценарий, где decode идёт на GPU, а burn-in субтитров или часть фильтров грузит CPU, нормален. Ещё один источник путаницы — неподдерживаемые профили: например, H.264 10-bit аппаратно поддерживается гораздо хуже типичного H.264 8-bit, и Jellyfin может перейти на software. Для HEVC 10-bit ситуация обычно лучше на новых поколениях, но матрица всё равно зависит от железа. На домашнем сервере важнее не максимальное число галочек, а стабильное воспроизведение типичных файлов. Если почти все клиенты умеют Direct Play, покупка мощной дискретной карты только ради редкого транскода может быть лишней.

Совет: SSD для временного transcoding cache помогает, если упор идёт в медленный диск, но не исправляет неподдерживаемый кодек.

Признаки рабочей настройки

  • При понижении качества сессия действительно переходит в Transcoding.
  • В FFmpeg-логе виден выбранный аппаратный backend без постоянного fallback на software.
  • CPU ниже, чем при том же тесте с отключённым hardware acceleration.
  • Нет регулярных пропусков кадров и переполнения буфера.
  • HEVC/HDR и H.264 проверены отдельно, если оба формата есть в медиатеке.
  • После перезапуска контейнера или сервиса доступ к GPU сохраняется.

Как оценивать результат, а не только проценты загрузки

Успешная настройка определяется не красивым графиком GPU, а тем, что реальный клиент воспроизводит сложный файл без пропусков кадров и сервер не упирается в процессор. На Intel, NVIDIA и AMD аппаратный decode/encode может отображаться в отдельных движках Video Decode, Video Encode или Media, а общая 3D-загрузка останется низкой. Сравните один и тот же файл в двух режимах: с выключенным HWA и с включённым. Если лог подтверждает аппаратный путь, CPU заметно разгружен, а поток стабилен, конфигурация выполняет свою задачу. Если же включение ускорения вызывает ошибки только на конкретном кодеке, отключите именно неподдерживаемый формат в настройках и не ломайте рабочие сценарии. Для удалённого просмотра отдельно тестируйте ограничение битрейта, потому что сеть и транскодер влияют на результат одновременно. Так вы отличите недостаток пропускной способности от проблемы с GPU.

Если Jellyfin запущен в Docker или LXC

В контейнерной установке одного выбора QSV, NVENC или VA-API в панели недостаточно: Jellyfin должен видеть аппаратное устройство из контейнера. На Linux сначала убедитесь на хосте, что GPU определяется системой и драйвер предоставляет нужный интерфейс, затем пробросьте устройство в контейнер и дайте процессу Jellyfin права на его использование. Для Intel и AMD это часто связано с устройствами из /dev/dri, а для NVIDIA — с установленным драйвером и контейнерным runtime, поддерживающим GPU. После перезапуска контейнера снова откройте настройки и проведите реальный тест transcoding. Если FFmpeg пишет permission denied, device not found или не видит выбранный backend, проблема находится ниже уровня веб-интерфейса Jellyfin. Не выдавайте контейнеру лишние привилегии только ради быстрого исправления: лучше пробросить конкретные устройства и группы доступа. После обновления Docker-образа повторно проверьте, что доступ к GPU сохранился и официальный jellyfin-ffmpeg по-прежнему используется.

Важно: Если HWA работало до пересоздания контейнера, а потом исчезло, первым делом проверьте проброс GPU и группы доступа, а не меняйте кодеки в библиотеке.

Что учитывать

Цепочка транскодирования состоит из декодирования, возможного деинтерлейса, масштабирования, преобразования формата, tone mapping, обработки субтитров и повторного кодирования. Аппаратная поддержка каждого этапа зависит от GPU, драйвера и конкретного кодека. Поэтому сценарий, где decode идёт на GPU, а burn-in субтитров или часть фильтров грузит CPU, нормален. Ещё один источник путаницы — неподдерживаемые профили: например, H.264 10-bit аппаратно поддерживается гораздо хуже типичного H.264…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Hardware Acceleration). Пример и формулировки — редакция N1RO на 2026-09-20.