Użytkownik ZimaOS, uruchamiający Jellyfin na systemie z procesorem Intel N100 i 16 GB pamięci RAM, zgłosił wyraźną różnicę w sposobie odtwarzania: materiały o rozdzielczości do 1080p działały normalnie, ale strumień 4K wymagający transkodowania zwiększał użycie procesora do 100% i stawał się zbyt rwący, aby dało się go oglądać. Jellyfin działał z siecią w trybie Host, a serwer nie miał dedykowanej karty graficznej.
Dyskusja społeczności nie doprowadziła do jednego, potwierdzonego ostatecznego rozwiązania. Przerodziła się natomiast w praktyczne badanie transkodowania programowego, zintegrowanej grafiki Intela, VA-API, zgodności kodeków, mapowania tonów HDR oraz właściwego miejsca weryfikacji aktywnego transkodowania. Pierwotny użytkownik ostatecznie włączył akcelerację sprzętową i mógł odtwarzać jeden transkodowany strumień, choć użycie procesora nadal utrzymywało się na poziomie około 95–98%.
Pierwotny problem z transkodowaniem 4K w Jellyfin
Serwer korzystał z procesora Intel N100 i 16 GB pamięci. Jellyfin pełnił funkcję lokalnego serwera multimediów, a typ sieci Docker był ustawiony na Host. Zwykłe odtwarzanie w rozdzielczości 1080p nie stanowiło problemu.
Problem występował tylko wtedy, gdy plik 4K wymagał transkodowania. Wówczas użycie procesora wzrastało do 100%, odtwarzanie się zacinało, a strumień stawał się praktycznie niemożliwy do oglądania. Użytkownik chciał więc wiedzieć, które ustawienia Jellyfin mogłyby poprawić wydajność transkodowania bez dedykowanej karty graficznej.
Ta różnica między 1080p a 4K stała się główną wskazówką w odpowiedziach. Członkowie społeczności skupili się mniej na sieci i pamięci, a bardziej na tym, co konwertował Jellyfin, czy wykorzystywana była zintegrowana grafika układu N100 oraz czy wybrany klient mógł bezpośrednio odtwarzać format źródłowy.
Dlaczego zgodność kodeka i klienta stała się przedmiotem dyskusji
goultron opisał transkodowanie 4K na systemie klasy N100 jako wymagające zadanie, zwłaszcza gdy serwer przełącza się na procesor. Ich własne podejście polegało na rezygnacji z utrzymywania biblioteki 4K i preferowaniu materiałów H.264, ponieważ można je bezpośrednio odtwarzać na większej liczbie urządzeń.
Odpowiedź zwróciła również uwagę na ważną kwestię praktyczną: nawet wideo H.264 może nadal wymagać pewnej formy konwersji. Ostateczny sposób odtwarzania może zależeć od urządzenia odbierającego, obsługiwanych przez nie formatów audio oraz dostępnej prędkości sieci. goultron podejrzewał, że za konwersję części strumieni, które nadal były transkodowane mimo użycia wideo H.264, odpowiadał dźwięk.
Skontrastowano to ze znaczną częścią dostępnych treści 4K, które często wykorzystują H.265/HEVC. Niektóre mniejsze urządzenia do odtwarzania i telewizory mogą nie obsługiwać bezpośrednio każdego profilu H.265. W takich przypadkach Jellyfin musi przekonwertować źródło na potrzeby klienta, ponownie przenosząc obciążenie na serwer.
Główna diagnoza gelbuilding: najpierw sprawdź iGPU układu N100
gelbuilding uznał zachowanie N100 za oczekiwane, jeśli Jellyfin wykonywał programowe transkodowanie 4K. Jego wyjaśnienie było proste: niewielki procesor może zostać całkowicie obciążony przez takie zadanie, co wyjaśnia płynne odtwarzanie 1080p przez pierwotnego użytkownika oraz nieużyteczne transkodowanie 4K.
Pierwszym proponowanym sprawdzeniem było ustalenie, czy Jellyfin rzeczywiście korzysta z intelowskiego silnika multimedialnego wbudowanego w układ N100. N100 nie potrzebuje osobnej karty graficznej, aby udostępnić iGPU, ale Jellyfin musi mieć włączoną akcelerację sprzętową i możliwość dostępu do tego urządzenia z poziomu kontenera.
Ścieżka ustawień udostępniona w odpowiedzi to:
- Otwórz interfejs administracyjny Jellyfin.
- Otwórz Playback.
- Otwórz Transcoding.
- Włącz akcelerację sprzętową.
- Wybierz VA-API dla konfiguracji omawianej w tym wątku.
Oczekiwano, że obciążenie zostanie przeniesione z programowego przetwarzania przez procesor na Intel iGPU. gelbuilding ostrzegł również, że nie można oczekiwać, iż iGPU układu N100 płynnie przekonwertuje każde źródło 4K. W szczególności wskazał niektóre pliki HEVC o wysokiej przepływności bitowej jako zadania, które nadal mogą przełączać się na przetwarzanie programowe.
Społeczność skorygowała miejsce sprawdzania VA-API
Początkowa odpowiedź sugerowała sprawdzenie na stronie Dashboard → Activity, czy widoczna jest etykieta VA-API dla H.264 lub HEVC. goultron przetestował tę poradę w Jellyfin 10.10.7 i stwierdził, że strona Activity wyświetlała jedynie zdarzenia takie jak VideoPlayback i VideoPlaybackStopped.
gelbuilding następnie skorygował instrukcję. Nie oczekiwano, że strona Activity będzie wyświetlać, czy transkodowanie używało VA-API, czy oprogramowania. Odpowiednie informacje należy sprawdzić, gdy strumień 4K jest aktywnie transkodowany w sekcji:
- Panel
- Odtwarzanie
- Transkodowanie
Aktywna sesja powinna wyświetlać wiersz pod kodekiem. Etykieta VA-API oznacza, że bierze udział akceleracja sprzętowa, natomiast etykieta Software wskazuje, że konwersję wykonuje procesor. Jeśli obszar transkodowania jest pusty, plik może być odtwarzany bezpośrednio (Direct Playing) lub przesyłany bezpośrednio (Direct Streaming), co oznacza, że nie odbywa się aktywne transkodowanie wideo.
Dlaczego btop nie udzielił jednoznacznej odpowiedzi w tym wątku
goultron próbował również zweryfikować aktywność iGPU za pomocą btop. Intel iGPU nie było wyraźnie widoczne w sekcji GPU, mimo że to samo iGPU zostało już pomyślnie przekazane do Frigate, a Frigate wykazywał, że korzysta z tego urządzenia.
gelbuilding odpowiedział, że w tym kontekście ZimaOS narzędzie btop pokazywało głównie dedykowane układy GPU, dlatego mogło nie wyświetlać zintegrowanej grafiki Intel nawet wtedy, gdy była aktywna. Na tej podstawie zalecili traktowanie aktywnego widoku Transcoding w Jellyfin jako bezpośredniej metody potwierdzenia.
Zima-Jerry dodał później, że do obserwowania użycia GPU można używać narzędzia btop. Te dwa stwierdzenia nie zostały uzgodnione przed zakończeniem dyskusji. Wątek społeczności wspiera zatem używanie btop jako dodatkowego narzędzia obserwacyjnego, ale nie jako jedynego dowodu; aktywne informacje o transkodowaniu w Jellyfin są nadal niezbędne do rozróżnienia przetwarzania VA-API od przetwarzania programowego.
Konfiguracja mapowania tonów HDR autorstwa Zima-Jerry
Zima-Jerry zamieścił odnośnik do innej społecznościowej konfiguracji skoncentrowanej na akceleracji sprzętowej Jellyfin i mapowaniu tonów HDR na układzie Intel N100. W tamtym wcześniejszym przypadku zgłaszano, że dostępna wówczas w App Store wersja Jellyfin miała problem z konwersją tonów kolorów.
Sugerowaną alternatywą był obraz kontenera Jellyfin nyanmisaka wraz z niestandardową konfiguracją YAML. Było to społecznościowe obejście związane z wersjami Jellyfin i ZimaOS używanymi w tamtym czasie, dlatego przed zastąpieniem istniejącej instalacji należy porównać je z aktualną wersją w App Store.
Wynik opisany w powiązanym poście nie oznaczał nieograniczonego transkodowania 4K. Zima-Jerry oszacował, że zintegrowana grafika układu N100 może płynnie konwertować wideo Dolby Vision w przybliżeniu do 4K przy 30 kl./s lub mniej w testowanej konfiguracji.
Co się zmieniło po włączeniu akceleracji sprzętowej przez pierwotnego użytkownika
Po przeanalizowaniu odpowiedzi Heimwerkerking włączył akcelerację sprzętową transkodowania. Przyniosło to wyraźną poprawę: co najmniej jeden transkodowany strumień zaczął się odtwarzać.
Informacje o aktywnym odtwarzaniu wyświetlane w panelu były następujące: 48,7 Mb/s MP4 H264 AACJednak użycie procesora pozostawało na poziomie od 95% do 98%, więc użytkownik nadal nie miał pewności, czy zintegrowany układ graficzny Intel faktycznie obsługiwał konwersję wideo.
Wynik ten nie dowiódł, że problem został całkowicie rozwiązany. Pokazał, że zmiana konfiguracji poprawiła odtwarzanie, ale wątkowi nadal brakowało potwierdzonej etykiety VA-API, kompletnego wyniku FFmpeg lub uzgodnionego odczytu iGPU. W ostatniej odpowiedzi ponownie zasugerowano obserwowanie użycia GPU za pomocą btop, a później nie opublikowano żadnego potwierdzenia.
Co właściwie potwierdza ten wątek społeczności
Dyskusja zdecydowanie wskazuje, że programowe transkodowanie 4K jest pierwszym wyjaśnieniem osiągania przez N100 100% wykorzystania procesora. Ustala również skorygowaną ścieżkę weryfikacji: uruchom transkodowanie 4K i sprawdź aktywną sesję w obszarze Odtwarzanie i Transkodowanie w Jellyfin, zamiast przeglądać historię aktywności.
Odpowiedzi wskazują na kilka dodatkowych czynników ograniczających obciążenie. Zgodność klienta z H.265, konwersja dźwięku, wysoka przepływność źródła, mapowanie tonów HDR oraz konkretny kontener Jellyfin mogą zmienić rezultat. Włączenie VA-API poprawiło możliwość odtwarzania jednego transkodowanego strumienia przez pierwotnego użytkownika, ale obciążenie procesora pozostało wysokie.
Wątek nie ustala uniwersalnej liczby strumieni dla N100 ani nie dowodzi, że układ GPU Intel Arc jest wymagany. gelbuilding przedstawił dwa możliwe kolejne kroki dla użytkowników, którzy nadal potrzebują stabilnej konwersji 4K: obniżenie przepływności źródła lub dodanie niewielkiego układu GPU Intel Arc. Dyskusja zakończyła się, zanim autor oryginalnego wpisu przetestował którąkolwiek z tych opcji.
Najczęściej zadawane pytania z dyskusji społeczności
Dlaczego 1080p działało, podczas gdy transkodowanie 4K się zacinało?
Społeczność przypisała tę różnicę znacznie większemu obciążeniu programowemu powstającemu, gdy plik 4K wymagał konwersji. Oryginalny N100 osiągał pełne wykorzystanie procesora podczas tego procesu.
Gdzie w Jellyfin należy sprawdzić VA-API?
Uruchom strumień 4K wymuszający transkodowanie, a następnie sprawdź aktywną sesję w sekcjach Pulpit nawigacyjny, Odtwarzanie i Transkodowanie. Wykaz zdarzeń aktywności nie zawierał wymaganej etykiety VA-API ani Software.
Co oznacza pusty widok aktywnego transkodowania?
Zgodnie z korektą gelbuildinga może to oznaczać, że plik jest odtwarzany bezpośrednio lub przesyłany strumieniowo bezpośrednio, a transkodowanie obrazu nie jest obecnie aktywne.
Czy włączenie akceleracji sprzętowej całkowicie rozwiązało problem?
Nie. Umożliwiło to odtwarzanie jednego transkodowanego strumienia, ale zgłaszane obciążenie procesora nadal wynosiło 95–98%, a wątek zakończył się bez ostatecznego potwierdzenia, że iGPU obsłużyło cały proces.
Jakie opcje zasugerowała społeczność, jeśli transmisja 4K nadal działała niestabilnie?
Odpowiedzi sugerowały, aby w miarę możliwości preferować zgodne materiały H.264, obniżyć przepływność źródła 4K, przetestować niestandardową konfigurację Jellyfin udostępnioną przez Zima-Jerry albo dodać niewielki układ GPU Intel Arc, aby uzyskać wydajniejszą ścieżkę transkodowania sprzętowego.
