Dlaczego Jellyfin buforuje na serwerze domowym?

Jellyfin buforuje, gdy jedna część ścieżki odtwarzania nie może dostarczyć, przekonwertować lub zdekodować wideo szybciej niż postępuje oś czasu. Transkodowanie wideo jest częstą przyczyną, ale nie jedyną. Strumień może też zaciąć się z powodu ograniczeń kodeka klienta, przetwarzania napisów, niestabilnego Wi-Fi, niewystarczającej przepustowości wysyłania zdalnego, konfliktów w pamięci lub katalogu transkodowania, który nie może przyjąć więcej danych tymczasowych.

Najszybszym sposobem znalezienia wąskiego gardła jest sprawdzenie aktualnego trybu odtwarzania przed zmianą ustawień sprzętowych. Następnie porównaj, czy problem dotyczy każdego pliku, tylko mediów 4K lub HDR, jednego klienta, użytkowników zdalnych, odtwarzania z napisami czy kilku jednoczesnych strumieni.

Sprawdź tryb odtwarzania przed wprowadzeniem zmian

Otwórz panel Jellyfin podczas odtwarzania problematycznego wideo i sprawdź aktywną sesję. To pozwala ustalić, czy serwer dostarcza oryginalny plik, czy aktywnie konwertuje jego część.

Jellyfin dzieli odtwarzanie na cztery ścieżki odtwarzania o rosnącym obciążeniu serwera: Odtwarzanie bezpośrednie, Remux, Bezpośredni strumień i transkodowanie wideo. Odtwarzanie bezpośrednie wysyła oryginalny materiał prawie bez przetwarzania. Remux zmienia kontener, Bezpośredni strumień konwertuje audio, zachowując wideo, a Transcode ponownie koduje strumień wideo.

Ten pierwszy wynik zmienia całkowicie kierunek rozwiązywania problemów. Jeśli odtwarzanie bezpośrednie buforuje, zacznij od sieci, pamięci, klienta i pliku multimedialnego. Jeśli transkodowanie wideo buforuje, sprawdź, dlaczego zażądano konwersji i czy serwer może szybko zakończyć cały proces.

Dowiedz się, dlaczego Jellyfin zażądał transkodowania

Plik nie jest odtwarzany bezpośrednio tylko dlatego, że klient obsługuje jego kodek wideo. Jellyfin ocenia pełną kombinację kontenera, kodeka wideo, profilu kodeka, głębi bitowej, rozdzielczości, formatu audio, układu kanałów, napisów, bitrate'u oraz ograniczeń odtwarzania klienta.

Na przykład klient może obsługiwać wideo HEVC, ale nie dołączoną ścieżkę audio TrueHD. Inny klient może dekodować oba strumienie, ale nie wyświetlić wybranego formatu napisów. Te różnice mogą sprawić, że ten sam plik będzie odtwarzany bezpośrednio na jednym urządzeniu, z konwersją audio na innym i pełnym transkodowaniem wideo w przeglądarce.

Zanotuj powód odtwarzania przed zmianą ustawień. Przetestuj także inną ścieżkę audio, wyłącz napisy i odtwórz ten sam plik na innym kliencie Jellyfin. Te kontrolowane testy są bardziej przydatne niż włączanie wszystkich kodeków w menu transkodowania.

Transkodowanie programowe może przeciążyć mały serwer

Transkodowanie programowe wykorzystuje CPU do dekodowania źródła, stosowania filtrów, skalowania obrazu i kodowania nowego strumienia w czasie rzeczywistym. Procesor o niskiej mocy może poradzić sobie z konwersją 1080p, ale zawieść przy źródle 4K HEVC, 10-bitowym wideo lub HDR.

Gdy konwersja nie nadąża za odtwarzaniem, klient ostatecznie zużywa zbuforowane segmenty wideo i zatrzymuje się. Użycie CPU może pozostać bliskie maksimum, podczas gdy Jellyfin wielokrotnie próbuje zbudować wystarczającą ilość danych przed aktualną pozycją.

Jeśli serwer ma obsługiwaną zintegrowaną lub dedykowaną kartę graficzną, poprawnie skonfigurowane przyspieszenie sprzętowe zwykle jest bardziej efektywne niż zmiana liczby wątków FFmpeg. Jeśli serwer nie ma kompatybilnego enkodera, zmniejszenie żądanej rozdzielczości lub bitrate’u może potwierdzić, że ograniczeniem jest zdolność transkodowania.

Przyspieszenie sprzętowe to wieloetapowy proces

Wybranie Intel Quick Sync, VA-API, NVIDIA NVENC lub AMD AMF w panelu sterowania nie gwarantuje, że każda część konwersji będzie wykonywana na GPU.

Transkodowanie w Jellyfin może obejmować dekodowanie, usuwanie przeplotu, skalowanie, konwersję formatu, mapowanie tonów HDR, wypalanie napisów oraz kodowanie. Jellyfin zauważa, że niektóre etapy mogą pozostać na CPU z powodu ograniczeń sprzętowych, sterowników lub oprogramowania. Częściowe przyspieszenie może więc powodować wysokie użycie CPU, nawet gdy aktywność GPU jest widoczna.

Zweryfikuj cały proces, a nie tylko obecność karty graficznej. Wymuś przewidywalne transkodowanie, obserwuj silniki dekodowania i kodowania wideo, sprawdź polecenie FFmpeg i poszukaj filtrów, które przeszły na oprogramowanie.

Nie włączaj formatów dekodowania, których Twoja karta graficzna nie obsługuje

Strona przyspieszenia sprzętowego pozwala administratorom wybrać formaty wideo, które Jellyfin może próbować dekodować przez GPU. Włączenie nieobsługiwanego formatu nie dodaje tej funkcji sprzętowi.

Jeśli GPU nie może dekodować dokładnego profilu kodeka lub głębi bitowej, Jellyfin może przełączyć się na dekodowanie programowe lub nie zainicjować ścieżki sprzętowej. Dlatego jeden plik HEVC może działać, podczas gdy inny powoduje niespodziewanie wysokie zużycie CPU.

Potwierdź generację GPU i obsługiwane profile, a następnie włącz tylko formaty, które GPU faktycznie może przetworzyć. Testuj osobno zwykłe pliki H.264, HEVC Main 10 i HDR zamiast traktować wszystkie media 4K jako jedno obciążenie.

Docker musi mieć dostęp do GPU

GPU wykryte przez system operacyjny hosta nie jest automatycznie dostępne wewnątrz kontenera Jellyfin. Kontener potrzebuje również poprawnego mapowania urządzenia, środowiska uruchomieniowego, sterowników, grup i uprawnień.

Dla GPU Intel i AMD na Linuksie host zwykle udostępnia urządzenia renderujące w /dev/dri. Użytkownik kontenera musi mieć dostęp do odpowiedniego urządzenia renderującego. Konfiguracje NVIDIA wymagają sterownika hosta i odpowiedniego środowiska uruchomieniowego kontenera. Praktyczne kontrole Dockera obejmują weryfikację urządzenia renderującego, mapowanie go do kontenera oraz dodanie właściwego GID grupy renderującej.

Nie pozostawiaj kontenera w trybie uprzywilejowanym jako stałego rozwiązania. Można go użyć krótko, aby potwierdzić, że podstawowym problemem jest dostęp do urządzenia, ale ostateczne wdrożenie powinno udostępniać tylko wymagane zasoby i uprawnienia GPU.

Zweryfikuj aktywność GPU podczas rzeczywistego transkodowania

Pomyślne uruchomienie kontenera nie dowodzi, że transkodowanie sprzętowe działa. Jellyfin może działać normalnie, skanować bibliotekę i odtwarzać pliki bezpośrednio, nie mając dostępu do GPU.

Wymuś transkodowanie, tymczasowo wybierając niższą jakość klienta niż źródło. Na systemach Intel monitoruj silniki wideo za pomocą narzędzia takiego jak intel_gpu_topNa systemach NVIDIA sprawdź aktywne procesy i aktywność enkodera za pomocą nvidia-smiSprawdź także, czy zużycie CPU spada w porównaniu z transkodowaniem programowym.

Jeśli nie ma aktywności GPU, potwierdź mapowanie urządzenia, użytkownika kontenera, członkostwo w grupie renderującej, metodę przyspieszenia sprzętowego oraz log FFmpeg. Jeśli GPU jest aktywne, ale odtwarzanie nadal jest wolne, inny etap potoku może być nadal wykonywany w oprogramowaniu.

Napisy mogą wywołać pełne transkodowanie wideo

Częstym objawem jest płynne odtwarzanie do momentu włączenia napisów. Często zdarza się to przy napisach obrazkowych lub stylizowanych formatach, których wybrany klient nie potrafi bezpośrednio wyświetlić.

Gdy Jellyfin musi wtopić napisy w obraz, dekoduje każdą klatkę, renderuje warstwę napisów i koduje nowy strumień wideo. To może zamienić inaczej lekką sesję Direct Play w jedną z najbardziej obciążających ścieżek odtwarzania serwera.

Wyłącz napisy i odtwórz tę samą scenę ponownie. Jeśli buforowanie zniknie, spróbuj ścieżki napisów tekstowych, takich jak SRT, przetestuj innego klienta lub sprawdź, czy wybrana ścieżka sprzętowa może przyspieszyć otaczające operacje dekodowania, filtrowania i kodowania.

Mapowanie tonów HDR może być bardziej wymagające niż normalne transkodowanie

Jeśli media 1080p i zwykłe 4K SDR odtwarzają się poprawnie, ale zawartość HDR buforuje na kliencie SDR, mapowanie tonów jest silnym kandydatem na przyczynę.

Serwer może potrzebować zdekodować źródło HDR 10-bitowe, przekształcić jego zakres kolorów i jasności do SDR, skalować je i zakodować nowy strumień wideo. System zdolny do normalnego transkodowania H.264 może nadal nie być w stanie wykonać tego pełnego zadania w czasie rzeczywistym za pomocą oprogramowania.

Przetestuj ten sam plik HDR na kliencie obsługującym HDR, a następnie wymuś transkodowanie do SDR i porównaj aktywność CPU i GPU. Sprzętowe wsparcie dla dekodowania HEVC nie oznacza automatycznie, że wybrana metoda mapowania tonów jest w pełni przyspieszona.

Klient decyduje o dużej części ścieżki odtwarzania

Jellyfin może odtwarzać plik bezpośrednio w kliencie na komputerze, a jednocześnie transkodować go w przeglądarce lub aplikacji telewizyjnej. Ta różnica nie oznacza, że konfiguracja serwera zmieniła się między sesjami.

Każdy klient raportuje obsługiwane kodeki, kontenery, formaty audio, napisy, rozdzielczości i limity bitrate’u. Bardziej zaawansowany odtwarzacz może uniknąć konwersji, podczas gdy ograniczony odtwarzacz może wymagać konwersji audio, remuxingu lub pełnego transkodowania wideo.

Przetestuj ten sam plik, ścieżkę audio, ścieżkę napisów i połączenie sieciowe na dwóch klientach. Jeśli problem występuje tylko na jednym kliencie, zbadaj możliwości odtwarzania i ustawienia aplikacji tego urządzenia, zanim zmienisz konfigurację serwera.

Direct Play może nadal buforować

Direct Play eliminuje konwersję wideo jako główne wąskie gardło, ale nie dowodzi, że każda inna część ścieżki działa poprawnie.

NAS nadal musi odczytać media, sieć musi je dostarczać ciągle, a klient musi je dekodować i wyświetlać. Szczyty wysokiego bitrate’u, niestabilne Wi-Fi, wolny interfejs klienta, ponowne próby odczytu z pamięci lub niewystarczająco wydajny odtwarzacz mogą przerwać inaczej bezpośredni strumień.

Skopiuj problematyczny plik na klienta i odtwórz go lokalnie. Jeśli lokalne odtwarzanie również zacina się, zbadaj plik multimedialny lub dekoder klienta. Jeśli lokalna kopia działa, a Jellyfin Direct Play buforuje, skup się na sieci i ścieżce przechowywania serwera.

Testuj rzeczywistą ścieżkę LAN zamiast testu prędkości internetu

Szybki wynik internetu nie mierzy ścieżki od serwera Jellyfin do telewizora, telefonu czy urządzenia streamingowego w domu. Nie ujawnia też wahań Wi-Fi, utraty pakietów, przeciążenia sieci mesh ani wolnego interfejsu urządzenia.

Przydatna lokalna diagnoza porównuje utrzymującą się przepustowość kopiowania plików, klienta przewodowego, kodowanie o niższym bitrate i oryginalny plik o wysokim bitrate. Praktyczne lokalne testy strumieniowania obejmują także testowanie Ethernetu, sprawdzanie, czy klient wymusza transkodowanie oraz przenoszenie ciężkich zadań w tle poza godziny oglądania.

Szukaj utrzymującej się wydajności, a nie najwyższej wartości pokazywanej przez kilka sekund. Wideo z dużymi szczytami bitrate potrzebuje wystarczającego zapasu, aby przetrwać krótkie spowolnienia sieci bez wyczerpania bufora klienta.

Zdalne buforowanie zwykle ma inną przyczynę

Jeśli ten sam materiał odtwarza się poprawnie w domu, ale buforuje przez połączenie zewnętrzne, głównymi podejrzanymi są przepustowość wysyłania serwera i zdalna trasa.

Użyteczna prędkość jest ograniczona przez prędkość wysyłania połączenia domowego, prędkość pobierania klienta zdalnego, narzut VPN lub reverse-proxy, konkurencyjny ruch w gospodarstwie domowym oraz bitrate strumienia. Duży remux może przekroczyć dostępną przepustowość wysyłania, mimo że odtwarza się idealnie bezpośrednio w sieci LAN.

Tymczasowo obniż jakość odtwarzania zdalnego. Jeśli to rozwiąże problem z buforowaniem, ustaw trwały zdalny bitrate lub użyj sprzętowego transkodowania, aby stworzyć mniejszy strumień. Traktuj niższe ustawienie jako dowód ograniczenia przepustowości, a nie jako dowód uszkodzenia oryginalnego pliku.

Przechowywanie danych jest bardziej podatne na awarie podczas pracy współbieżnej

Sprawny dysk twardy zwykle bez problemu odtwarza jeden zwykły strumień filmowy. Przechowywanie danych staje się bardziej podejrzane, gdy odtwarzanie nakłada się na pobieranie, kopie zapasowe, skanowanie biblioteki, generowanie miniatur, operacje parzystości, czyszczenie lub kilku użytkowników.

Te zadania powodują konkurujące odczyty, zapisy i wyszukiwania. Dysk może wykazywać akceptowalną prędkość sekwencyjną w benchmarku, a jednocześnie rozwijać wysokie opóźnienia podczas mieszanej aktywności.

Monitoruj wykorzystanie i opóźnienia podczas buforowania. Wstrzymaj pobieranie i zadania konserwacyjne, a następnie odtwórz ten sam plik ponownie. Przechowuj bazę danych Jellyfin, metadane i pamięć podręczną na nośnikach o niższych opóźnieniach, gdy to możliwe, podczas gdy duże pliki multimedialne mogą pozostać na dyskach nastawionych na pojemność.

Pełny katalog transkodowania może zatrzymać odtwarzanie

Transkodowane wideo jest zapisywane jako tymczasowe segmenty, zanim klient je odczyta. Jeśli przypisany system plików, SSD, dysk RAM lub wolumen Docker ma niewystarczająco wolnego miejsca, FFmpeg nie może tworzyć nowych segmentów.

Wcześniejszy problem Jellyfin opisywał, jak odtwarzanie mogło trwać tylko do ostatniego segmentu utworzonego przed zapełnieniem katalogu transkodowania. Raport jest stary i zamknięty, ale objaw ten pozostaje przydatnym powodem do sprawdzenia miejsca, gdy transkodowany strumień zatrzymuje się po kilku minutach.

Sprawdź wolne miejsce, dostępność inode, mapowanie kontenera, uprawnienia do zapisu i limit pojemności ścieżki transkodowania. Szczególnie uważaj na małe dyski RAM lub tymczasowe systemy plików: użycie pamięci może zmniejszyć opóźnienia magazynowania, ale zbyt niski limit może spowodować nagłe przerwanie odtwarzania.

Jeden problematyczny plik zwykle wskazuje na media

Jeśli wiele plików o podobnej rozdzielczości i bitrate odtwarza się poprawnie, pojedynczy wadliwy tytuł rzadziej świadczy o niedostatecznej mocy całego serwera.

Plik może zawierać nietypowy profil kodeka, uszkodzone klatki, nieobsługiwany układ audio, ścieżkę napisów obrazkowych, nieprawidłowe znaczniki czasu lub ekstremalny szczyt bitrate. Jeden sezon serialu mógł też zostać zakodowany inaczej niż pozostałe.

Przetestuj inny ścieżkę audio, wyłącz napisy, sprawdź informacje o mediach i porównaj plik z innym tytułem używającym tego samego kodeka. Proste remuxowanie do nowego kontenera może pomóc ustalić, czy problem dotyczy kontenera lub znaczników czasu, bez konieczności ponownego kodowania całego wideo.

Wiele strumieni ujawnia ograniczenia współdzielonych zasobów

Serwer domowy może obsłużyć jeden strumień bez problemu i zacząć buforować dopiero, gdy inny użytkownik rozpocznie odtwarzanie. Porównaj tryb odtwarzania każdej aktywnej sesji, zanim założysz, że winna jest wyłącznie sieć.

Kilka sesji Direct Play głównie zwiększa obciążenie pamięci masowej i sieci. Kilka transkodowań wideo konkuruje również o pojemność kodowania GPU, filtry CPU, przepustowość pamięci i miejsce w katalogu transkodowania.

Przetestuj jedną sesję, następnie dodawaj strumienie pojedynczo, obserwując użycie CPU, GPU, dysku i sieci. To pozwala określić, czy praktycznym limitem jest liczba konwersji, łączny bitrate mediów czy mieszana aktywność pamięci.

Przeczytaj dziennik FFmpeg przed ponowną instalacją Jellyfin.

Panel serwera pokazuje, jaki typ odtwarzania ma miejsce, podczas gdy odpowiadający dziennik FFmpeg wyjaśnia, jak Jellyfin próbował przetworzyć plik.

Szukaj błędów inicjalizacji urządzenia sprzętowego, błędów uprawnień, nieobsługiwanych profili, przejścia na oprogramowanie, filtrów napisów, filtrów mapowania tonów, błędów wejścia/wyjścia, kodów zakończenia procesów i błędów miejsca na dysku.

Zarejestruj dziennik z dokładnej sesji, która buforuje. Dziennik z niezwiązanego Direct Play lub udanego transkodowania może prowadzić do błędnych wniosków. Ponowna instalacja serwera rzadko rozwiązuje limit kodeka klienta, niedostępne urządzenie GPU lub pełny tymczasowy katalog.

Użyj objawu, aby wybrać następny test.

Postępuj zgodnie z tym porządkiem rozwiązywania problemów.

1. Odtwórz problem z tym samym plikiem i klientem.
2. Otwórz panel Jellyfin i zanotuj tryb odtwarzania.
3. Zanotuj podany powód transkodowania lub zgodności.
4. Wyłącz napisy i przetestuj inną ścieżkę audio.
5. Odtwórz ten sam plik na innym kliencie.
6. Sprawdź aktywność CPU i GPU podczas dotkniętej sesji.
7. Otwórz odpowiadający dziennik FFmpeg.
8. Sprawdź miejsce w katalogu transkodowania i uprawnienia do zapisu.
9. Przetestuj stałą przepustowość LAN lub zdalną pojemność przesyłania.
10. Wstrzymaj pobieranie, kopie zapasowe, skanowanie i konserwację pamięci.
11. Porównaj problematyczny plik z podobnymi mediami.
12. Rozważ nowy sprzęt dopiero po tym, jak dowody wykażą ograniczenia obliczeniowe.

Taki porządek zapobiega ukrywaniu się pierwotnej przyczyny przez niepowiązane zmiany. Zmieniaj jedną zmienną na raz i odtwarzaj tę samą scenę, aby wyniki były porównywalne.

Ostateczne wnioski

Buforowanie Jellyfin nie oznacza automatycznie, że serwer domowy potrzebuje szybszego procesora. Zacznij od aktywnego trybu odtwarzania, ponieważ Direct Play i transkodowanie wideo wskazują na różne części systemu.

Dla sesji transkodowanych zidentyfikuj, dlaczego wymagana jest konwersja, zweryfikuj kompletną ścieżkę sprzętowego przyspieszenia, przetestuj bez napisów, sprawdź mapowanie tonów HDR i potwierdź, że ścieżka transkodowania ma wystarczająco dużo miejsca do zapisu. W Dockerze zweryfikuj GPU wewnątrz kontenera, a nie tylko na podstawie wykrywania hosta.

Dla Direct Play skup się na utrzymaniu przepustowości sieci, dekodowaniu po stronie klienta, aktywności pamięci masowej oraz indywidualnym pliku multimedialnym. Połączenie trybu odtwarzania, klienta, kodeka, napisów, aktywności zasobów i logów FFmpeg daje bardziej wiarygodną diagnozę niż losowe zmiany ustawień lub wymiana sprzętu na początek.

FAQ

Dlaczego Jellyfin buforuje tylko wtedy, gdy włączone są napisy?

Wybrany format napisów może wymagać wtopienia ich w obraz. Jellyfin musi wtedy zdekodować wideo, wyrenderować napisy na każdej klatce i zakodować nowy strumień. Spróbuj wyłączyć napisy, wybrać ścieżkę tekstową lub użyć klienta, który potrafi bezpośrednio renderować ten format napisów.

Dlaczego Jellyfin transkoduje na jednym urządzeniu, a na innym używa Direct Play?

Klienci obsługują różne kombinacje kontenerów, kodeków wideo, formatów audio, typów napisów, profili i przepływności. Mniej kompatybilne urządzenie prosi serwer o konwersję nieobsługiwanej części pliku.

Jak mogę potwierdzić, że sprzętowe przyspieszenie Jellyfin działa?

Wymuś transkodowanie wideo, a następnie sprawdź silniki dekodowania i kodowania GPU serwera. Potwierdź także, że log FFmpeg używa oczekiwanego urządzenia sprzętowego i że kontener ma dostęp do urządzenia bez błędów uprawnień.

Dlaczego Jellyfin buforuje, mimo że mówi, że jest Direct Play?

Direct Play eliminuje transkodowanie wideo z procesu, ale sieć, pamięć masowa, plik multimedialny i dekoder klienta mogą nadal być zbyt wolne lub niestabilne. Przetestuj plik lokalnie na tym samym kliencie i porównaj odtwarzanie przewodowe i bezprzewodowe.

Czy Jellyfin powinien używać dysku SSD do transkodowania?

Dysk SSD może zmniejszyć opóźnienia tymczasowych segmentów i jest przydatny dla bazy danych Jellyfin, metadanych oraz pamięci podręcznej. Bardziej istotnym wymaganiem jest ścieżka transkodowania z wystarczającą przestrzenią, niezawodnym zapisem i prawidłowymi uprawnieniami. Odpowiednio dobrany dysk RAM również może działać, ale zbyt mały może zatrzymać odtwarzanie.