Jellyfin zamiast Plexa: jak zbudować własny serwis streamingowy na komputerze lub NAS-ie, kiedy potrzebne jest transkodowanie i jak oglądać bibliotekę poza domem

Jellyfin ma jedną przewagę nad Plexem, której nie da się sprowadzić do wyglądu aplikacji: serwer i oficjalne klienty są bezpłatne, a funkcje sprzętowego transkodowania nie są zamknięte za płatną licencją. Biblioteka filmów, seriali i muzyki zostaje na własnym komputerze lub NAS-ie, a aplikacja zajmuje się katalogowaniem, metadanymi, użytkownikami i dostarczaniem materiału na telewizor, telefon czy przeglądarkę.

Nie oznacza to jednak, że dowolny stary NAS automatycznie stanie się odpowiednikiem Netflixa. Największe różnice między sprawnie działającym serwerem a instalacją, która zacina się przy pierwszym filmie 4K, wynikają z trzech rzeczy: formatów plików, możliwości sprzętowego transkodowania i przepustowości łącza wychodzącego. To właśnie je trzeba sprawdzić przed kupowaniem mocniejszego sprzętu.

Komputer czy NAS? Sprzęt dobiera się do biblioteki, nie do liczby dysków

Najprostszy Jellyfin może działać na komputerze z Windowsem, Linuksem lub macOS. Można go również uruchomić w Dockerze, na wielu gotowych NAS-ach oraz w środowiskach takich jak TrueNAS SCALE. Sam Jellyfin nie wymaga drogiego procesora. Problem zaczyna się dopiero wtedy, gdy serwer musi zmieniać film podczas odtwarzania.

Jeżeli telewizor lub odtwarzacz obsługuje zapisany plik bezpośrednio, Jellyfin korzysta z Direct Play. Serwer praktycznie tylko odczytuje dane z dysku i przesyła je przez sieć. W takim scenariuszu nawet skromny komputer może jednocześnie obsługiwać kilka strumieni.

Dlatego przed zakupem nowego NAS-a zrobiłbym prosty test: zainstalował Jellyfin na komputerze, który już stoi w domu, dodał kilkanaście reprezentatywnych filmów i sprawdził sposób ich odtwarzania na docelowych urządzeniach. Biblioteka testowa powinna zawierać przynajmniej:

• film 1080p H.264 z AAC lub AC3,
• materiał 4K HEVC 10-bit,
• film HDR10,
• materiał z dźwiękiem DTS lub TrueHD, jeżeli takie pliki występują w kolekcji,
• plik z napisami SRT,
• film z napisami graficznymi, np. PGS.

W panelu odtwarzania Jellyfin można później sprawdzić, czy materiał idzie jako Direct Play, Direct Stream czy Transcode. Ta informacja jest bardziej użyteczna niż syntetyczny benchmark procesora.

Do nowej, energooszczędnej instalacji szczególnie sensowne są platformy Intela z obsługą Quick Sync Video. Dokumentacja Jellyfin jako odpowiedni punkt wejścia wymienia m.in. Intel N100 oraz nowsze układy Intela. Typowy mini-PC z N100, 8–16 GB RAM i SSD jest wystarczającą bazą dla domowego serwera, jeśli pliki trzymane są na osobnym NAS-ie lub dyskach USB.

Nie kupowałbym natomiast używanego NAS-a tylko dlatego, że ma cztery zatoki. Procesor jest ważniejszy, niż sugerują katalogi producentów. Urządzenie z szybkim interfejsem 2,5 GbE, ale słabym ARM-em albo procesorem bez odpowiedniego układu graficznego może świetnie przechowywać dane i jednocześnie fatalnie radzić sobie z transkodowaniem.

Dobrym przykładem różnicy konstrukcyjnej są urządzenia wykorzystujące starsze procesory Intel Celeron z iGPU, które potrafią skorzystać z Quick Sync, oraz NAS-y z procesorami pozbawionymi zintegrowanej grafiki. W tym drugim przypadku mocny wynik CPU nie oznacza automatycznie dobrego serwera wideo.

Przy zakupie sprzętu przyjąłbym następujące minimum:

• 4 GB RAM wystarczy dla lekkiego serwera Linux bez interfejsu graficznego, ale 8 GB daje znacznie rozsądniejszy zapas;
• system, baza Jellyfin, miniatury i cache powinny znajdować się na SSD;
• serwer najlepiej podłączyć do routera przez Gigabit Ethernet lub szybszy interfejs;
• filmy mogą leżeć na HDD, ponieważ przy odtwarzaniu liczy się przede wszystkim odczyt sekwencyjny;
• przy większej kolekcji dobrze oddzielić system i konfigurację Jellyfin od właściwego magazynu filmów.

SSD nie musi przechowywać samych filmów. Korzyść daje przede wszystkim przeniesienie na niego bazy danych, obrazków, metadanych oraz katalogu transkodowania. Mechaniczny dysk systemowy jest jednym z tych elementów, które na papierze „działają”, ale w codziennym korzystaniu powodują irytujące opóźnienia przy otwieraniu biblioteki.

W Polsce rozsądna konfiguracja nie musi być droga. Używany komputer klasy Dell OptiPlex Micro, HP ProDesk Mini albo Lenovo ThinkCentre Tiny można często znaleźć za kilkaset złotych, natomiast nowy mini-PC na energooszczędnej platformie Intela zwykle kosztuje kilkaset do ponad 1000 zł w zależności od RAM-u i SSD. Pełny NAS z kilkoma zatokami jest wyraźnie droższy, szczególnie po doliczeniu dysków.

Jeśli priorytetem są filmy, a nie funkcje NAS-a, często lepszym układem jest mały komputer z Jellyfinem plus osobny magazyn danych niż kupowanie kosztownego NAS-a tylko po to, by znaleźć model zdolny do transkodowania.

Transkodowanie nie jest trybem „lepszej jakości”. To koszt zgodności

Najczęstszy błąd przy Jellyfinie polega na traktowaniu transkodowania jak normalnego sposobu oglądania. Powinno być odwrotnie. Najlepszym scenariuszem jest Direct Play, ponieważ serwer nie zmienia kodeka wideo, nie traci jakości i zużywa niewiele energii.

Transkodowanie pojawia się wtedy, gdy urządzenie odtwarzające nie obsługuje któregoś elementu pliku albo gdy użytkownik wymusi niższą jakość.

Typowe sytuacje to:

• telewizor nie obsługuje kodeka wideo;
• przeglądarka nie potrafi odtworzyć konkretnego profilu HEVC;
• urządzenie nie obsługuje ścieżki audio, np. DTS;
• klient wymaga innego kontenera;
• napisy muszą zostać wypalone w obraz;
• materiał ma wyższy bitrate, niż pozwala łącze internetowe;
• film HDR trzeba przekształcić do SDR.

Nie każdy z tych przypadków kosztuje tyle samo. Zamiana samego kontenera lub ścieżki audio jest stosunkowo lekka. Transkodowanie obrazu 4K HEVC z HDR do H.264 SDR to zupełnie inna klasa obciążenia.

Szczególnie podstępne są napisy. Zwykłe napisy tekstowe SRT często można obsłużyć bez ciężkiego przeliczania obrazu. Napisy graficzne lub format nieobsługiwany przez klienta mogą wymusić ich wypalenie w każdej klatce. Nagle film, który przed włączeniem napisów działał jako Direct Play, zaczyna obciążać GPU.

Właśnie dlatego serwer Jellyfin warto budować wokół sprzętowego kodera, a nie bardzo mocnego CPU.

Jellyfin obsługuje między innymi:

• Intel Quick Sync Video,
• NVIDIA NVENC/NVDEC,
• AMD AMF w Windows,
• VA-API w Linuksie,
• Apple VideoToolbox w macOS,
• akcelerację Rockchip na obsługiwanych układach.

Do typowego domowego serwera wybrałbym Intela. Quick Sync jest dobrze wspierany, działa także w systemach bez monitora, a współczesne układy radzą sobie sprzętowo z najważniejszymi kodekami. Nowsze generacje oferują również sprzętowe dekodowanie AV1.

Trzeba natomiast uważać na procesory Intela z literą F na końcu nazwy. Nie mają zintegrowanego GPU, więc nie zapewnią Quick Sync bez dodatkowej karty graficznej.

Osobna karta NVIDIA ma sens przede wszystkim wtedy, gdy komputer już ją posiada albo serwer ma obsługiwać większe obciążenie. Kupowanie dużej karty tylko dla dwóch domowych strumieni zwykle oznacza wyższy koszt, pobór prądu i więcej ciepła bez proporcjonalnej korzyści.

Jeszcze gorszym pomysłem jest liczenie wyłącznie na transkodowanie programowe przez procesor. Przy zwykłym 1080p może zadziałać. Przy 4K HDR potrafi jednak zabraknąć wydajności nawet bardzo mocnym CPU, zwłaszcza gdy trzeba jednocześnie wykonać tone mapping HDR → SDR.

Po włączeniu akceleracji trzeba ją sprawdzić, a nie zakładać, że działa. Najprostszy test wygląda tak:

1. uruchomić wymagający materiał;
2. ręcznie ustawić w aplikacji niższy bitrate lub rozdzielczość, aby wymusić transkodowanie;
3. wejść do panelu administracyjnego Jellyfin;
4. sprawdzić informacje o aktywnym odtwarzaniu;
5. obserwować obciążenie GPU i CPU.

Jeżeli podczas transkodowania procesor jest stale blisko 100%, a jednostki Video Decode/Encode pozostają bezczynne, konfiguracja akceleracji jest prawdopodobnie błędna.

W Dockerze pojawia się dodatkowa pułapka: kontener musi dostać dostęp do urządzenia GPU. Sama obecność Quick Sync w procesorze nie wystarczy. Na Linuksie typowo oznacza udostępnienie urządzeń z /dev/dri oraz właściwe uprawnienia użytkownika uruchamiającego Jellyfin.

Nie warto również zastępować dostarczanego z Jellyfinem jellyfin-ffmpeg przypadkową wersją FFmpeg. Projekt dostosowuje własny pakiet do obsługi funkcji transkodowania i sprzętowej akceleracji. Własna wersja może działać, ale może również pozbawić część potoku akceleracji sprzętowej.

Oglądanie poza domem: najpierw upload, później domena i HTTPS

Serwer działający w salonie to dopiero połowa prywatnego streamingu. Druga połowa zaczyna się po wyłączeniu Wi-Fi w telefonie.

Pierwszym parametrem do sprawdzenia nie jest wtedy procesor, lecz upload domowego internetu. To serwer wysyła film do użytkownika.

Przy jednym zdalnym strumieniu 1080p ograniczonym do około 8 Mb/s samo łącze powinno zapewniać zauważalnie większy upload niż 8 Mb/s, ponieważ trzeba zostawić margines dla pozostałego ruchu. Jellyfin jako rozsądne minimum dla zdalnego dostępu wskazuje około 20 Mb/s uploadu. Jeżeli całe łącze wychodzące ma mniej niż 100 Mb/s, dokumentacja sugeruje ograniczyć przepustowość Jellyfina mniej więcej do 70% dostępnego uploadu, aby odtwarzanie filmu nie blokowało całego domowego internetu.

Przykład: przy łączu 300/50 Mb/s ustawiłbym limit wszystkich zdalnych transmisji Jellyfina na około 35 Mb/s. Zostaje wtedy mniej więcej 15 Mb/s na wideokonferencję, kopię w chmurze, monitoring czy zwykłe korzystanie z sieci.

Problem rośnie przy kopiach Blu-ray UHD. Remux 4K potrafi mieć dziesiątki megabitów na sekundę, a chwilowy bitrate może być jeszcze wyższy. W domu po gigabitowej sieci nie stanowi to problemu. Przez internet taki plik często trzeba transkodować do np. 10–20 Mb/s, szczególnie na połączeniu mobilnym.

Druga kwestia to sposób dostania się do serwera. Jellyfin standardowo korzysta w sieci lokalnej z portu 8096/TCP dla HTTP. Nie wystawiałbym go bezpośrednio do internetu. Sam projekt również nie rekomenduje takiego wariantu.

Praktycznie są trzy rozsądne ścieżki.

VPN jest najbezpieczniejszy i najłatwiejszy do kontrolowania, jeżeli dostęp ma mieć tylko właściciel i kilka własnych urządzeń. Rozwiązania wykorzystujące WireGuard lub sieci nakładkowe typu Tailscale eliminują potrzebę publikowania panelu Jellyfin dla całego internetu. Minusem jest konieczność skonfigurowania klienta VPN na każdym urządzeniu. Na niektórych telewizorach staje się to kłopotliwe.

Reverse proxy z HTTPS sprawdza się lepiej, jeśli z serwera korzysta kilka osób i potrzebny jest zwykły adres w rodzaju jellyfin.example.pl. Jellyfin oficjalnie opisuje konfiguracje z Caddy, Nginx, Traefikiem, HAProxy i Apache, przy czym Caddy jest jednym z prostszych wariantów ze względu na automatyzację obsługi certyfikatów TLS.

Schemat wygląda wtedy tak:

internet → router → port 443 → reverse proxy → Jellyfin:8096.

Do wystawienia usługi przez klasyczny reverse proxy potrzeba publicznie osiągalnego adresu IP albo odpowiedniej konfiguracji IPv6. Przy zmiennym adresie IPv4 przydaje się Dynamic DNS.

Tu pojawia się problem coraz częstszy u polskich operatorów: CGNAT. Jeżeli operator nie daje klientowi publicznego IPv4, zwykłe przekierowanie portu na routerze nie zadziała. Można wtedy poprosić operatora o publiczne IP, wykorzystać IPv6, VPN z odpowiednią architekturą albo pośredniczący VPS.

Przed otwarciem portów sprawdziłbym więc adres WAN routera i porównał go z publicznym adresem widocznym w internecie. Jeżeli są różne, a adres routera pochodzi np. z prywatnej puli, konfiguracja port forwarding może nie mieć żadnego efektu.

Przy reverse proxy trzeba dopilnować jeszcze kilku rzeczy:

• używać HTTPS z zaufanym certyfikatem, a nie certyfikatu samopodpisanego;
• prawidłowo obsłużyć WebSockety;
• skonfigurować reverse proxy jako Known Proxy w Jellyfinie;
• nie przechowywać bez zabezpieczenia pełnych logów URL, ponieważ niektóre żądania Jellyfina mogą zawierać dane uwierzytelniające;
• utworzyć osobne konta dla użytkowników;
• wyłączyć zdalny dostęp osobom, które go nie potrzebują;
• regularnie aktualizować Jellyfin, reverse proxy i system operacyjny.

Szczególnie zła konfiguracja to wystawienie portu 8096 bez TLS tylko dlatego, że „na telefonie działa”. Funkcjonalnie problem jest rozwiązany, ale serwer staje się usługą publiczną bez warstwy, którą normalnie powinien zapewnić HTTPS i poprawnie skonfigurowany firewall.

Dla większości domowych instalacji kolejność powinna być więc odwrotna: najpierw działający Direct Play w LAN, później sprzętowe transkodowanie, następnie pomiar uploadu, a dopiero na końcu zdalny dostęp. Konfigurowanie domeny i reverse proxy przed sprawdzeniem, czy serwer w ogóle poprawnie odtwarza HEVC i napisy, tylko dokłada kolejne miejsce do diagnozowania błędów.

FAQ: najczęstsze pytania przed uruchomieniem Jellyfina

Czy Jellyfin naprawdę jest darmowy?
Tak. Serwer Jellyfin oraz oficjalne aplikacje są udostępniane bez opłat i bez płatnego odpowiednika Plex Pass wymaganego do odblokowania sprzętowego transkodowania. Projekt jest oprogramowaniem open source na licencji GNU GPL.

Czy Jellyfin musi działać na NAS-ie?
Nie. Może działać na zwykłym komputerze, mini-PC, serwerze Linux, Windowsie, macOS lub obsługiwanym NAS-ie. Często bardzo dobrym rozwiązaniem jest uruchomienie Jellyfina na małym komputerze z Intelem, podczas gdy NAS pełni wyłącznie funkcję magazynu plików.

Czy Intel N100 wystarczy do Jellyfina?
Do typowego domowego zastosowania jest bardzo sensowną platformą, szczególnie ze względu na sprzętową akcelerację wideo. Nie należy jednak oceniać maksymalnej liczby równoczesnych transkodowań wyłącznie na podstawie nazwy CPU — wynik zależy od kodeka źródłowego, rozdzielczości, HDR, napisów i formatu wyjściowego.

Czy Raspberry Pi jest dobrym serwerem Jellyfin?
Jeżeli celem jest tylko Direct Play, można zbudować działającą konfigurację, ale nie jest to pierwszy wybór do serwera wymagającego regularnego transkodowania. Dokumentacja Jellyfin wprost ostrzega przed większością SBC i jako znacznie ciekawszą klasę sprzętu wskazuje m.in. układy Rockchip RK3588 oraz współczesne platformy Intela.

Ile RAM-u potrzeba?
Dla normalnego serwera przyjmowałbym 8 GB. Lekki Linux bez środowiska graficznego może działać z 4 GB, ale różnica cenowa zwykle nie uzasadnia ograniczania pamięci w nowej konfiguracji.

Czy filmy muszą znajdować się na SSD?
Nie. HDD nadają się bardzo dobrze do przechowywania multimediów. Na SSD lepiej trzymać system, bazę Jellyfina, miniatury, cache i katalog tymczasowy transkodowania.

Dlaczego film działa bez napisów, a po ich włączeniu zaczyna się zacinać?
Najczęściej klient nie potrafi bezpośrednio wyświetlić danego formatu napisów i Jellyfin musi wypalić je w obraz. To może wymusić pełne transkodowanie wideo. W panelu aktywnego odtwarzania trzeba wtedy sprawdzić przyczynę transkodowania.

Czy do oglądania poza domem potrzebny jest publiczny adres IP?
Do klasycznego przekierowania portów — tak, potrzebna jest możliwość osiągnięcia domowej sieci z internetu, przez publiczne IPv4 lub odpowiednio skonfigurowane IPv6. Przy CGNAT można zamiast tego użyć VPN-u, usługi sieci nakładkowej albo pośredniczącego serwera.

Czy wystarczy przekierować port 8096 na routerze?
Technicznie usługa może wtedy być osiągalna, ale nie jest to zalecana konfiguracja. Bezpieczniej zastosować VPN albo reverse proxy z HTTPS i poprawnie skonfigurowanym firewallem.

Jak szybki internet jest potrzebny?
Dla zdalnego dostępu rozsądnym minimum jest około 20 Mb/s uploadu, ale faktyczne zapotrzebowanie wynika z bitrate’u oglądanych materiałów i liczby równoczesnych użytkowników. Przy łączu wychodzącym poniżej 100 Mb/s dobrym punktem startowym jest przeznaczenie dla Jellyfina najwyżej około 70% uploadu.

Czy biblioteka 4K oznacza, że trzeba kupić mocny komputer?
Nie, jeżeli urządzenia końcowe obsługują pliki w Direct Play. Tak, jeżeli regularnie trzeba zamieniać 4K HEVC HDR na niższy bitrate lub SDR. Wtedy sprzętowy dekoder, enkoder i tone mapping mają większe znaczenie niż ogólna wydajność CPU.

Od czego zacząć migrację z Plexa?
Nie od zakupu NAS-a. Najpierw uruchom Jellyfina na sprzęcie, który już masz, dodaj kilka najtrudniejszych plików z biblioteki i przetestuj je na telewizorze, telefonie i komputerze. Sprawdź w panelu, które materiały korzystają z Direct Play, a które wymuszają Transcode. Jeżeli pojawia się transkodowanie, ustal jego przyczynę przed wydaniem pieniędzy. Dopiero wtedy wiadomo, czy potrzebujesz nowego procesora z Quick Sync, lepszego klienta, szybszego uploadu czy po prostu zmiany formatu problematycznych napisów.

Więcej informacji na: https://itux.pl