Jellyfin для семейного архива: прямое воспроизведение вместо перегруженного CPU

Представьте один и тот же фильм из семейного архива: свадебная съёмка, переведённая в аккуратный файл, или отпускной ролик, склеенный из кусков с разных камер. На телевизоре в гостиной он стартует мгновенно, сервер при этом почти не замечает, что его о чём-то попросили. Тот же файл открывают на телефоне у бабушки, и процессор сервера внезапно упирается в потолок, вентилятор (или его виртуальный аналог) начинает работать на пределе, картинка подтормаживает. Файл не изменился. Сервер не изменился. Изменился только тот, кто смотрит.

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

Файл как матрёшка: что именно должен понять клиент

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

Согласно документации Jellyfin по совместимости кодеков, поддержка контейнеров, видео- и аудиокодеков и форматов субтитров зависит от клиента. Это ключевая фраза всей темы. Нет универсального списка «Jellyfin умеет вот это»: есть список «вот это умеет конкретное приложение на конкретном устройстве». Один и тот же сервер может отдавать файл напрямую в одно приложение и перекодировать его для другого.

Поэтому правильный вопрос звучит не «какой формат лучший», а «какую четвёрку признаков имеет мой файл и кто из моих зрителей эту четвёрку читает без перевода». Четвёрка такая:

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

Достаточно одного несовпадения, и режим воспроизведения меняется. Какого именно — зависит от того, какой слой не сошёлся.

Четыре режима, и только один из них по-настоящему дорог

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

1. Direct Play. Клиенту отдаётся исходный файл без изменений. Серверу остаётся читать диск и отправлять данные по сети.
2. Remux. Меняется контейнер, а дорожки внутри остаются прежними. Это пересборка коробки без переупаковки содержимого.
3. Direct Stream. Видео передаётся как есть, но звук может быть изменён: например, дорожка, непонятная клиенту, заменяется на понятную.
4. Transcode. Меняется само видео. Это и есть тот самый дорогой режим: изображение приходится декодировать и кодировать заново.

Принципиальная разница между третьей и четвёртой ступенями объясняет многое. Видеопоток — самый тяжёлый по объёму данных и по вычислительной сложности. Перепаковать контейнер или пересжать звук для процессора почти невесомо по сравнению с повторным кодированием картинки. Поэтому ситуация «в панели написано не Direct Play» ещё не повод для паники: вполне возможно, что идёт Remux или Direct Stream, и сервер почти не напрягается. Тревожным сигналом служит именно Transcode для видео.

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

Почему телефон «ломает» то, что телевизор читает легко

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

Видео: профиль, разрядность и динамический диапазон

Один и тот же кодек может существовать в разных вариантах. Файл с обычной восьмибитной картинкой и файл с десятибитным цветом — разные задачи для декодера, даже если название кодека совпадает. Отдельная тема — HDR. Документация Jellyfin предупреждает, что программное преобразование HDR в SDR может сильно нагружать CPU. Логика понятна: если экран телефона или приложение не умеют показывать расширенный диапазон, серверу придётся не просто пересжать картинку, а ещё и пересчитать её яркость и цвет, и делать это на процессоре, без аппаратной помощи.

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

Звук: незаметный виновник

Многоканальный звук в экзотическом формате — частая причина того, что Direct Play превращается в Direct Stream. Само по себе это недорого, но запомните: режим сменился, и дальше сервер уже участвует в процессе. Если зрителей несколько, эти небольшие траты суммируются. А у телефона с динамиками и наушниками обычно меньше возможностей по звуку, чем у телевизора с саундбаром, поэтому именно мобильные клиенты чаще запрашивают замену аудиодорожки.

Субтитры: самая коварная деталь

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

Получается неприятный парадокс: фильм идеально совместим по видео, по звуку и по контейнеру, но включённые субтитры в неподходящем формате превращают лёгкий Direct Play в полноценное транскодирование. Если в вашей семье смотрят старые фильмы с субтитрами, проверять надо именно с включёнными субтитрами, а не только «просто запустить».

Матрица устройств: как не гадать, а записать

Теперь соберём всё в рабочий инструмент. Идея простая: составить таблицу, где строки — ваши реальные устройства, а столбцы — признаки файла. В клетках фиксируется результат, который вы увидели в панели Jellyfin, а не результат, который вам кажется вероятным.

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

Заметьте, что в строках указано не только устройство, но и приложение. Это не мелочь. Поскольку, как мы выяснили, поддержка зависит от клиента, один и тот же ноутбук в браузере и в отдельном приложении может дать разные результаты. Поэтому строка матрицы — это пара «устройство плюс клиент», а не просто «устройство».

В каждой клетке записывайте одно из четырёх слов: Direct Play, Remux, Direct Stream, Transcode. И, если получилось Transcode, добавьте короткую пометку, что именно, по вашим наблюдениям, спровоцировало преобразование: видео, субтитры или что-то ещё. Пара вечеров такой работы даёт гораздо больше, чем любое чтение таблиц совместимости, потому что вы получаете картину именно для своей семьи.

Как прочитать готовую матрицу

Когда таблица заполнена, на неё стоит смотреть не по клеткам, а по столбцам и строкам.

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

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

Подготовка библиотеки: выбрать главного зрителя

Здесь возникает настоящий выбор, и он больше организационный, чем технический. Библиотеку можно подстраивать под самый частый способ просмотра. Сначала определите, кто и на чём смотрит чаще всего. Для многих семей это один-два основных клиента, а всё остальное — исключения.

Дальше сценарии получаются такими.

Сценарий первый: основной зритель — телевизор

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

Сценарий второй: смотрят в основном на телефонах

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

Сценарий третий: клиенты разные, общего знаменателя нет

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

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

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

Старые записи и новые съёмки

Семейный архив обычно состоит из двух разных пластов. Старые оцифрованные записи небольшого разрешения, как правило, проще и совместимее. Новые съёмки на телефоны чаще бывают тяжёлыми: высокое разрешение, десятибитный цвет, возможно, HDR. Разумно разделить эти два пласта в матрице, потому что их проблемы разные. В старом пласте чаще встречаются экзотические контейнеры и звук. В новом — динамический диапазон и разрешение. Лечить их приходится по-разному.

Сервер по реальной задаче, а не по страху

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

Рассуждение выстраивается в три шага.

1. Сколько одновременных просмотров с настоящим Transcode вы ожидаете? Не просмотров вообще, а именно тех, где меняется видео. Если матрица показывает, что почти все сеансы идут напрямую, ответ может быть «ноль или один в редких случаях».
2. Какое это преобразование? Как следует из документации, программный пересчёт HDR в SDR способен сильно нагрузить CPU. Это значит, что один такой сеанс может весить больше, чем несколько простых. Поэтому важно не количество зрителей, а тип материала.
3. Насколько вы готовы терпеть деградацию в редких случаях? Если Transcode случается пару раз в месяц и никому не критичен, держать под него запас мощности нет смысла.

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

Где здесь VPS и что он даёт

Если сервер Jellyfin вы размещаете на VPS, полезно понимать, что даёт такая среда и чего не даёт. На VPS MAATRIX доступны NVMe-накопители, процессоры AMD EPYC и root-доступ, а значит, вы сами устанавливаете и настраиваете Jellyfin и смотрите режимы воспроизведения в его панели. Размещение возможно в локациях, перечисленных в публичном предложении: UK, US, RU и FR; оплата — картой РФ или через СБП, а VPS создаётся автоматически через пару минут после оплаты. Подробности есть на странице аренды VPS MAATRIX.

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

По тарифной линейке отправные точки такие: Ba — 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ, 80 ГБ; Heka — 4 vCPU, 8 ГБ, 160 ГБ; Maat — 8 vCPU, 16 ГБ, 240 ГБ; Djed — 16 vCPU, 32 ГБ, 320 ГБ. Эти цифры — исходные данные для вашего собственного теста, а не обещание, сколько зрителей потянет конкретный план. Практичный путь: взять конфигурацию, соответствующую вашей матрице, запустить типичные просмотры на реальных устройствах, посмотреть в панели режимы и заметить, как ведёт себя нагрузка на процессор. Если при Direct Play почти всё свободно, а один сеанс с преобразованием HDR заметно загружает ядра, вы получите настоящие данные для решения, а не догадки.

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

Рабочий пример рассуждения

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

В семье три основных зрителя: телевизор в гостиной, телефон одного из родителей и ноутбук, на котором иногда смотрит подросток. Архив состоит из оцифрованных старых кассет и свежих роликов с телефона. Хозяин архива заполняет матрицу и замечает два момента: на телефоне часть старых фильмов уходит в Direct Stream из-за звука, а один из новых роликов с HDR на ноутбуке даёт Transcode.

Что он делает дальше? Сначала оценивает частоту. Телевизор — главный зритель, там почти везде Direct Play, значит, основная библиотека менять не нужно. Звук на телефоне — недорогая проблема: Direct Stream не требует тяжёлого пересжатия видео. Остаётся HDR-ролик на ноутбуке. Смотрят его редко, но нагрузка при этом ощутимая. Здесь у хозяина два варианта: либо принять это как редкое исключение, либо подготовить для такого ролика версию в стандартном динамическом диапазоне. Он выбирает второе только для нескольких самых любимых клипов, потому что остальные смотрят очень редко.

В итоге вместо покупки более мощной конфигурации «на всякий случай» он оставляет скромный план и заменяет несколько файлов. Именно такая логика — от матрицы к точечным правкам, а не к росту тарифа — и есть смысл этой статьи.

Когда всё-таки нужен запас по CPU

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

Но даже тогда сначала стоит выяснить, какие именно сеансы идут через Transcode и почему. Часто оказывается, что 80 процентов проблем создают две-три причины: одно приложение, один тип субтитров, одна группа файлов. Устранение причин почти всегда дешевле роста мощности. Запас по CPU — это последний шаг, когда матрица показала, что убрать преобразование нельзя, а не первый шаг при первом же подозрении на тормоза.

Если вы ещё выбираете сам медиасервер и сравниваете подходы, может пригодиться материал Jellyfin или Plex: что выбрать для сервера, где разобран выбор между двумя системами.

Библиотека, которая читается без пересказа

Хорошо подготовленный семейный архив похож на текст, написанный на языке, который понимают все читатели. Не нужен переводчик, не нужно тратить усилия на пересказ, и никто не ждёт, пока кто-то в серверной комнате перекодирует очередной ролик. Файл просто открывается: контейнер знаком клиенту, видео читается им напрямую, звук понятен, субтитры рисуются на экране без вмешательства сервера.

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

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