Jak dobrać parametry domowego serwera do odtwarzania w Jellyfin materiałów HDR z napisami

Dobierz serwer Jellyfin do obsługi HDR i napisów, testując dokładne kombinacje klienta, pliku i napisów, które uruchamiają odtwarzanie bezpośrednie, mapowanie tonów lub wypalanie napisów w obraz.

Odtwarzanie HDR niewiele obciąża serwer, jeśli klient obsługujący HDR akceptuje oryginalne wideo, dźwięk, kontener i sposób obsługi napisów; ten sam plik może wymagać intensywnej konwersji na innym ekranie. Przygotuj małą macierz obciążeń, zarezerwuj akcelerację sprzętową na przypadki, w których konwersja wideo jest nieunikniona, zachowaj zapas mocy CPU na filtrowanie i etapy awaryjne oraz sprawdź najtrudniejszy scenariusz w domu, zanim zwiększysz ilość pamięci RAM, dodasz GPU lub rozdzielisz obliczenia i pamięć masową.

Utwórz macierz doboru na podstawie klientów, formatów HDR i rodzajów napisów

Wypisz istotne ekrany: główny telewizor HDR, telewizory lub projektory SDR, przeglądarki, telefony, tablety i urządzenia zdalne. Dla każdego przetestuj reprezentatywne pliki 4K HEVC HDR bez napisów, z prostymi napisami tekstowymi oraz z napisami graficznymi lub stylizowanymi, które faktycznie masz w bibliotece.

Zapisz uzyskaną ścieżkę odtwarzania, zamiast określać urządzenie jako „obsługujące 4K”. Ten sam klient może odtwarzać bezpośrednio jeden tytuł HDR, remuksować inny ze względu na kontener lub dźwięk, a wideo konwertować, gdy napisy nie mogą być renderowane lokalnie. Ta ścieżka jest podstawą do doboru serwera.

Przeprowadź test przy przepływności i liczbie klatek na sekundę, z których faktycznie korzystasz. Krótki klip demonstracyjny nie dowodzi, że pełny film o wysokiej przepływności, nietypowa ścieżka napisów ani zdalny limit jakości zostaną obsłużone w ten sam sposób.

Odróżnij natywne odtwarzanie HDR od konwersji HDR do SDR

Gdy klient obsługujący HDR może odtworzyć materiał źródłowy, serwer głównie przesyła dane, a zapotrzebowanie na moc obliczeniową pozostaje niewielkie. Trudności pojawiają się, gdy urządzenie docelowe wymaga SDR lub innego niezgodnego formatu wyjściowego, a serwer musi zdekodować obraz, zmienić kolory i jasność oraz zakodować nowy strumień wideo.

Jeśli konwersji nie da się uniknąć, skonfiguruj i sprawdź sprzętowo przyspieszane transkodowanie w Jellyfin na właściwym hoście, zamiast zakładać, że GPU działa, bo opcja w panelu jest włączona. Sprzętowe silniki multimedialne mogą znacznie odciążyć procesor, ale cały proces nadal zależy od kodeków, sterowników, filtrów, uprawnień i żądań klienta.

Dobierz sprzęt do konwersji, której naprawdę potrzebujesz, a nie do każdego pliku HDR w bibliotece. Jeśli mapowania tonów wymaga tylko jedno zdalne urządzenie SDR, punktem odniesienia powinien być jeden zweryfikowany, wymagający scenariusz. Jeśli dwóch domowników może jednocześnie uruchomić taki scenariusz, przetestuj dwa równoległe strumienie, zanim uznasz serwer za wystarczający.

Traktuj wypalanie napisów jako osobny czynnik wpływający na wymagania sprzętowe

Napisy to nie drobny dodatek, który nie wpływa na zapotrzebowanie serwera. Ścieżki tekstowe, które klient może renderować, pozwalają zachować Direct Play, natomiast napisy obrazkowe lub niekompatybilne z klientem mogą wymagać renderowania ich przez serwer na każdej klatce wideo, zmieniając sesję o niewielkim obciążeniu w pełny potok przetwarzania wideo.

Niezależny poradnik dotyczący transkodowania wymuszanego przez napisy wskazuje PGS i VobSub jako częste przypadki, w których Jellyfin może wypalać napisy w obraz, gdy klient nie potrafi ich renderować bezpośrednio. Jeśli pasuje do materiału, udostępnij też opcję tekstowych napisów SRT, ale zachowaj oryginalne ścieżki, gdy liczy się jakość lub styl, i dobierz serwer do klientów, którzy nadal wymagają wypalania napisów.

Testuj napisy na tym samym pliku HDR, ponieważ te dwa wymagania mogą się na siebie nałożyć. Serwer może potrzebować dekodowania, renderowania napisów, mapowania tonów z HDR do SDR, skalowania i kodowania w ramach jednego żądania. To właśnie ta łączna ścieżka, a nie samo „4K”, najprawdopodobniej ujawni niedowymiarowaną lub tylko częściowo przyspieszoną konfigurację.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przydziel procesor, Media Engine i pamięć do różnych zadań

Korzystaj z układu wideo do obsługiwanych etapów dekodowania, filtrowania, mapowania tonów i kodowania, jeśli platforma może je przyspieszyć. Zachowaj moc procesora na potrzeby samego Jellyfin, konwersji dźwięku, obsługi napisów, która w razie potrzeby odbywa się programowo, działań bazy danych i innych usług współdzielących serwer.

Pamięć zwykle nie jest pierwszym wąskim gardłem podczas odtwarzania HDR, więc nie traktuj 32 GB jako sposobu na poprawę jakości wideo. Serwer przeznaczony głównie do Jellyfin może mieć skromne podzespoły, jeśli obciążenie obejmuje głównie Direct Play. Dodaj pamięć, gdy inne kontenery, maszyny wirtualne, duże pamięci podręczne lub równoległe usługi działające w tle powodują mierzalne obciążenie.

Warunkiem zakończenia doboru podzespołów jest zachowanie zasobów w docelowym potoku. Jeśli układ GPU/wideo ma zapas mocy, CPU nie jest obciążony do granic możliwości przez etapy awaryjnego przetwarzania, pamięć nie jest przenoszona na dysk, a odtwarzanie zachowuje zapas bufora, więcej rdzeni ani RAM-u nie poprawi testowanego strumienia.

Przechowuj dane aplikacji na szybkiej pamięci masowej i zapewnij odpowiednią przepustowość dla plików tymczasowych transkodowania

Przechowuj konfigurację Jellyfin, bazę danych, metadane i pamięć podręczną na szybkiej pamięci masowej o niskich opóźnieniach. Filmy i odcinki przechowuj na nośniku o dużej pojemności, który niezawodnie obsługuje wymagane przepływności źródłowe, a obszar roboczy transkodowania umieść w lokalizacji, która nie zapełni dysku systemowego podczas długich sesji.

Jeśli multimedia są przechowywane na osobnym serwerze NAS, uwzględnij w teście połączenie między jednostką obliczeniową a pamięcią masową. Podczas intensywnego transkodowania plik źródłowy jest odczytywany przez to połączenie, zanim nowy strumień zostanie wysłany do klienta, a wykonywana równolegle kopia zapasowa lub transfer plików może korzystać z tego samego połączenia.

Jeśli odtwarzanie nie działa, zastosuj tę samą metodę analizy krok po kroku, opisaną w artykule diagnozowanie buforowania w Jellyfin podczas obsługi napisów lub konwersji HDR: najpierw ustal, czy używana jest funkcja Direct Play, czy transkodowanie, a następnie sprawdź osobno napisy, mapowanie tonów, akcelerację sprzętową, pamięć masową i działanie sieci. Nie kupuj wydajniejszego sprzętu, dopóki nie ustalisz, które ogniwo jest aktualnym wąskim gardłem.

Sprawdź jeden strumień w najgorszym przypadku, a następnie celowo zwiększaj obciążenie równoległe

Przygotuj powtarzalny zestaw testowy zawierający najbardziej wymagające źródło HDR, format napisów, który najprawdopodobniej wymaga wypalania, oraz najsłabszego klienta, którego faktycznie obsługujesz. Zacznij od jednej sesji i zapisuj stan odtwarzania, obciążenie procesora, użycie GPU i silnika wideo, szybkość transkodowania lub stan bufora, pamięć oraz temperatury.

Dopiero gdy jedna ścieżka działa stabilnie, dodaj drugiego użytkownika lub zadanie w tle działające równocześnie, które odzwierciedla rzeczywiste obciążenie domowej sieci. Celem nie jest ustalenie uniwersalnej liczby strumieni, lecz sprawdzenie, jakie obciążenie równoległe może obsłużyć Twój konkretny zestaw multimediów, klientów i sprzętu, zanim któryś etap zostanie przeciążony.

Zakończ skalowanie, gdy najbardziej wymagające przewidywane połączenie wielokrotnie działa z zapasem. Dodawaj lub wymieniaj sprzęt tylko wtedy, gdy zmierzona awaria ma jasno wskazaną przyczynę: brakująca ścieżka kodeka wymaga innego silnika multimedialnego, powtarzające się przejście na przetwarzanie programowe wymaga mocniejszego procesora lub lepszego akceleratora, rywalizacja o dostęp do pamięci masowej wymaga zmiany topologii, a duże obciążenie równoległe, którego nie da się obsłużyć jednocześnie, może uzasadniać dedykowany węzeł transkodowania.