Dlaczego serwer multimediów używa dużo procesora podczas odtwarzania?

Wysokie użycie CPU podczas odtwarzania mediów zwykle oznacza, że serwer robi więcej niż tylko wysyła oryginalny plik. Może dekodować i ponownie kodować wideo, wypalać napisy w każdej klatce, konwertować HDR dla klienta SDR, zmniejszać rozdzielczość lub tworzyć strumień o niższym bitrate dla połączenia zdalnego.

Jednak wysokie obciążenie CPU nie oznacza automatycznie, że procesor jest zbyt słaby. Przyspieszenie sprzętowe może działać tylko dla części procesu, w tle może działać zadanie analizy lub kilka sesji może rywalizować o te same zasoby. Pierwszym krokiem jest zidentyfikowanie trybu odtwarzania i procesu faktycznie zużywającego CPU.

Sprawdź tryb odtwarzania, zanim obwinisz sprzęt

Otwórz panel serwera, gdy problematyczny strumień jest aktywny. Plex, Jellyfin, Emby i podobne platformy zwykle pokazują, czy sesja używa Direct Play, Direct Stream lub Remux, konwersji audio lub pełnego transkodowania wideo.

Direct Play wysyła oryginalny kontener, wideo, dźwięk i obsługiwane ścieżki napisów do klienta. Remux lub Direct Stream zmienia tylko część formatu dostawy, często bez ponownego kodowania wideo. Transkodowanie wideo dekoduje źródło i tworzy nowy strumień wideo, co czyni je najbardziej prawdopodobną przyczyną utrzymującego się wysokiego obciążenia CPU.

To rozróżnienie decyduje o kolejnym teście. Wysokie obciążenie CPU podczas potwierdzonego transkodowania wideo może być oczekiwane, jeśli przetwarzanie odbywa się w oprogramowaniu. Wysokie obciążenie CPU podczas Direct Play zwykle wskazuje na inną sesję, zadanie analizy w tle lub inny proces działający na serwerze.

Główną przyczyną jest zwykle transkodowanie wideo w oprogramowaniu

Serwer medialny transkoduje wideo, gdy klient nie może odtworzyć oryginalnej kombinacji kodeka, profilu, rozdzielczości, bitrate, kontenera, dźwięku lub napisów. Może też transkodować, ponieważ użytkownik wybrał niższą jakość odtwarzania.

Serwer musi dekodować klatki źródłowe, zastosować wymagane filtry, zmienić rozmiar lub konwersję obrazu oraz zakodować nowy strumień na tyle szybko, by wyprzedzić odtwarzanie. Źródło 4K HEVC przekonwertowane na H.264 o niższej rozdzielczości wymaga znacznie więcej przetwarzania niż serwowanie oryginalnego pliku.

Jeśli wszystkie te etapy działają na ogólnych rdzeniach CPU, wysokie wykorzystanie może być normalne. Istotne pytanie brzmi, czy transkoder pozostaje szybszy niż odtwarzanie. Obciążony CPU z płynnym odtwarzaniem różni się od CPU pracującego na granicy, podczas gdy klient ciągle buforuje.

To klient często decyduje, czy potrzebny jest CPU

Ten sam plik może być odtwarzany bezpośrednio na jednym urządzeniu streamingowym, a wywoływać pełne transkodowanie w przeglądarce, aplikacji telewizyjnej, telefonie lub starszym odtwarzaczu. Każdy klient obsługuje inną kombinację kontenerów, profili wideo, głębi bitowej, formatów audio, napisów i maksymalnych bitrate’ów.

Nawet gdy kodek wideo jest obsługiwany, niekompatybilna ścieżka audio lub format napisów może zmienić ścieżkę odtwarzania. Klient może akceptować wideo HEVC, ale wymagać konwersji dźwięku TrueHD lub wymagać transkodowania wideo, gdy wybrane napisy nie mogą być renderowane lokalnie.

Porównaj ten sam plik na dwóch klientach, zachowując tę samą ścieżkę audio, wybór napisów i ustawienia jakości. Jeśli wysokie użycie CPU występuje tylko przy jednym kliencie, skup się na możliwościach i ustawieniach tego klienta, zanim wymienisz sprzęt serwera.

Niższa jakość może zwiększyć użycie CPU przez serwer

Wybór niższej jakości może wydawać się sposobem na zmniejszenie obciążenia serwera. W rzeczywistości serwer zwykle musi utworzyć nowy strumień, gdy żądana rozdzielczość lub bitrate różnią się od źródła.

Na przykład, żądanie 1080p przy 8 Mbps z pliku 4K o wysokim bitrate wymaga dekodowania, skalowania i ponownego kodowania. Wybranie oryginalnej jakości może umożliwić Direct Play, gdy klient obsługuje format źródłowy, a sieć jest w stanie przenieść jego bitrate.

Użyj oryginalnej jakości jako testu diagnostycznego w sieci lokalnej. Nie jest to uniwersalne rozwiązanie: klient z niekompatybilnymi kodekami, niewystarczającą przepustowością lub nieobsługiwanymi napisami może nadal wymagać konwersji.

Wtopienie napisów może zamienić lekki strumień w ciężki

Jeśli użycie procesora wzrasta dopiero po włączeniu napisów, wybrana ścieżka napisów jest silnym podejrzanym. Napisy tekstowe, takie jak SRT, są często renderowane przez klienta, podczas gdy PGS i VobSub to formaty oparte na obrazach. ASS i SSA zawierają tekst, ale mogą też zawierać stylizację i pozycjonowanie, których niektóre klienty nie potrafią odtworzyć.

Gdy klient nie może wyświetlić ścieżki napisów, serwer może je wtopić w obraz. Wymaga to dekodowania wideo, nałożenia napisów na każdą klatkę oraz zakodowania nowego strumienia wideo.

Plex specjalnie pracował nad poprawą wydajności wypalania napisów podczas sprzętowego transkodowania, a wyniki zależą od systemu operacyjnego, typu GPU oraz tego, czy mapowanie tonalne pozostało w procesie. Dlatego ten sam test napisów może dawać różne użycie CPU na różnych serwerach.

Przetestuj ścieżkę napisów osobno

Odtwórz tę samą scenę z wyłączonymi napisami. Jeśli użycie CPU natychmiast spada, a sesja wraca do Direct Play, to ścieżka napisów — a nie samo źródło wideo — powoduje dodatkowe obciążenie.

Następnie spróbuj zewnętrznej ścieżki SRT, innego języka napisów lub klienta z szerszym wsparciem dla napisów. Sprawdź także, czy serwer raportuje wypalanie napisów, a nie tylko ich zwykłe wyświetlanie.

Nie zakładaj, że każdy format napisów ma taki sam koszt. Stylizowana ścieżka tekstowa może być łatwa dla jednego klienta i wymagać pełnego przetwarzania wideo u innego, podczas gdy napisy obrazkowe z Blu-ray mogą być szczególnie trudne do dostarczenia bez wypalania.

Działające GPU nie oznacza, że cały proces jest przyspieszony

Możliwe jest obserwowanie aktywności GPU, podczas gdy CPU pozostaje wysokie. Przyspieszenie sprzętowe może dekodować i kodować wideo, podczas gdy CPU nadal obsługuje renderowanie napisów, konwersję audio, skalowanie, mapowanie tonalne lub inny filtr.

Przypadek rozwiązywania problemów w społeczności pokazał transkodowanie GPU działające równolegle z wysokim użyciem CPU spowodowanym wypalaniem napisów i konwersją audio. Ten przypadek nie powinien być traktowany jako stała zasada dla każdej aktualnej wersji, ale ilustruje, dlaczego samo wykorzystanie GPU nie jest pełnym dowodem.

Sprawdź zarówno silniki dekodowania, jak i kodowania GPU, a następnie przejrzyj log transkodera pod kątem filtrów programowych. Porównaj użycie CPU przy wyłączonych napisach, wybranym kompatybilnym ścieżce audio i usuniętym mapowaniu tonalnym podczas testu.

Przyspieszenie sprzętowe może przełączyć się na oprogramowanie

Opcja przyspieszenia sprzętowego może być włączona w interfejsie serwera, nawet gdy sterownik hosta, uprawnienia urządzenia, środowisko uruchomieniowe lub wybrany kodek nie działają poprawnie.

Niektóre formaty źródłowe mogą korzystać z GPU, podczas gdy inne przełączają się na CPU. GPU może obsługiwać H.264 i HEVC Main, ale niekoniecznie dokładną głębię bitową, format chromy, docelowe kodowanie lub ścieżkę mapowania tonalnego wymaganą przez konkretny plik.

Wymuś znane transkodowanie i monitoruj serwer w czasie rzeczywistym. Potwierdź, że sprzętowy dekoder i enkoder są aktywne, sprawdź polecenie transkodera i szukaj błędów inicjalizacji lub komunikatów o przejściu na oprogramowanie zamiast polegać tylko na zaznaczonej opcji.

Docker dodaje oddzielną warstwę dostępu do GPU.

Gdy serwer multimediów działa w Dockerze, wykrycie GPU na hoście nie dowodzi, że aplikacja może go używać wewnątrz kontenera. Kontener potrzebuje urządzenia, kompatybilnych bibliotek użytkownika, odpowiedniego środowiska uruchomieniowego i uprawnień do dostępu do funkcji wideo.

W przypadku wdrożeń NVIDIA przydatna jest sekwencja weryfikacji: najpierw potwierdź sterownik hosta, sprawdź, czy Docker rozpoznaje środowisko uruchomieniowe NVIDIA, zweryfikuj obecność wymaganych bibliotek i urządzeń w kontenerze oraz obserwuj aktywność enkodera podczas wymuszonego transkodowania. Kontener, w którym nvidia-smi Uruchomienia mogą nadal nie mieć bibliotek lub funkcji wymaganych przez serwer multimediów.

Praktyczna konfiguracja Dockera musi więc sprawdzić środowisko uruchomieniowe NVIDIA, biblioteki użytkownika, dostęp do urządzenia i aktywność enkodera wewnątrz kontenera. Unikaj stałego używania trybu uprzywilejowanego; udostępniaj tylko zasoby potrzebne usłudze.

Maszyny wirtualne mogą powodować ten sam wzorzec awarii.

Maszyna wirtualna może wykryć adapter wyświetlacza bez dostępu do funkcji sprzętowego kodowania i dekodowania wymaganych do transkodowania mediów. Przekazywanie GPU, urządzenia pośredniczące, sterowniki i uprawnienia gościa wpływają na wynik.

Zweryfikuj GPU z poziomu systemu gościa, a następnie z procesu serwera multimediów. Aktywność GPU na poziomie hosta nie dowodzi, że aplikacja gościa używa zamierzonego silnika.

Jeśli natywna instalacja korzysta z akceleracji sprzętowej, a identyczna instalacja VM używa dużo CPU, porównaj dostęp do urządzenia i logi przed zmianą ustawień kodeka lub ponownym kodowaniem biblioteki.

Mapowanie tonów HDR może pozostawić znaczną część pracy na CPU.

Gdy media HDR są odtwarzane na wyświetlaczu SDR lub przez klienta, który nie może przyjąć oryginalnego strumienia HDR, serwer może potrzebować wykonać mapowanie tonów oprócz normalnego transkodowania.

Proces może obejmować dekodowanie 10-bitowe, konwersję przestrzeni kolorów, mapowanie jasności, skalowanie, kompozycję napisów i kodowanie. Wsparcie sprzętowe dla kodeka źródłowego nie gwarantuje, że każdy z tych etapów pozostanie na GPU.

Przetestuj ten sam plik na kliencie obsługującym HDR, a następnie porównaj go z wyjściem SDR. Jeśli zwykłe transkodowania SDR są wydajne, ale sesje HDR do SDR zużywają dużo CPU, zbadaj metodę mapowania tonów i wsparcie sprzętowe, zamiast traktować wszystkie materiały 4K jako równoważne.

Konwersja audio zwykle nie jest tak obciążająca jak transkodowanie wideo

TrueHD, DTS, dźwięk wielokanałowy lub nieobsługiwany kodek audio mogą być konwertowane do formatu, który klient może odtwarzać. Serwer może także zredukować dźwięk przestrzenny do stereo.

Transkodowanie audio zużywa moc obliczeniową, ale jest zazwyczaj lżejsze niż dekodowanie i ponowne kodowanie całego strumienia wideo. Remuxowanie kontenera również zachowuje strumień wideo i zwykle wymaga znacznie mniej obliczeń niż konwersja wideo.

Jeśli panel kontrolny pokazuje tylko transkodowanie audio, a CPU pozostaje blisko limitu, sprawdź przetwarzanie napisów, analizę w tle, inną aktywną sesję lub osobny proces transkodera. Nie zakładaj, że widoczna etykieta audio wyjaśnia całe obciążenie.

Direct Play z wysokim zużyciem CPU zwykle oznacza, że działa inne zadanie

Direct Play nadal wymaga odczytu plików, uwierzytelniania, logiki aplikacji i dostarczania przez sieć, więc zużycie CPU nie będzie dokładnie zerowe. Zazwyczaj nie wymaga jednak ciężkiego przetwarzania wideo związanego z transkodowaniem programowym.

Plex może zużywać znaczną moc CPU na wykrywanie intro i napisów końcowych, podgląd miniatur, analizę głosu, wykrywanie reklam, optymalizację mediów i przygotowanie do pobrania. Niektóre z tych zadań uruchamiają transkoder nawet wtedy, gdy nikt aktywnie nie ogląda mediów.

Sprawdź listę procesów systemu operacyjnego, a nie tylko ogólny wykres CPU. Zidentyfikuj, czy odpowiedzialny jest transkoder aktualnego strumienia, proces zaplanowanej analizy, skaner biblioteki czy niezwiązany kontener.

Zaplanowana analiza może wyglądać jak obciążenie podczas odtwarzania

Proces w tle może rozpocząć się mniej więcej w tym samym czasie, gdy ktoś zaczyna oglądać, co może sprawiać wrażenie, że to odtwarzanie spowodowało skok obciążenia CPU. Okna konserwacyjne często odbywają się w nocy lub krótko po dodaniu nowej zawartości.

Jedna dyskusja na forum Unraid przypisała pozornie bezczynne obciążenie CPU zaplanowanej analizie mediów, a później wykrywaniu intro i napisów końcowych. To przykład z społeczności, a nie dowód, że każdy przypadek obciążenia w stanie bezczynności ma tę samą przyczynę.

Tymczasowo wstrzymaj generowanie podglądu, wykrywanie intro, wykrywanie napisów końcowych, optymalizację i głęboką analizę mediów. Jeśli użycie CPU spadnie bez zmiany aktywnego strumienia, przenieś te zadania na inny okres konserwacji zamiast zmieniać ustawienia odtwarzania.

Wiele strumieni mnoży różne rodzaje pracy

Jedna sesja Direct Play głównie zwiększa zapotrzebowanie na pamięć masową i sieć. Jedno transkodowanie audio to mniejsze zadanie konwersji. Jedno programowe transkodowanie wideo 4K może zużywać znacznie więcej mocy obliczeniowej niż kilka strumieni bezpośrednich.

Gdy inny użytkownik zaczyna odtwarzanie, sprawdź każdą sesję indywidualnie. Dwóch użytkowników niekoniecznie generuje dwukrotnie takie samo obciążenie: jeden może odtwarzać bezpośrednio, a drugi wypalać napisy w transkodzie HDR.

Dodawaj sesje testowe pojedynczo, obserwując CPU, GPU, sieć, opóźnienia dysku i szybkość transkodowania. To ujawnia, czy praktycznym ograniczeniem jest kodowanie programowe, pojemność enkodera sprzętowego, konflikt o zasoby dyskowe czy łączna przepustowość.

Telewizja na żywo może wymagać dodatkowego przetwarzania

Telewizja na żywo może być przesyłana w kodeku, rozdzielczości, formacie przeplotu lub bitrate, których klient odtwarzający nie może bezpośrednio zaakceptować. Serwer może potrzebować deinterlacingu, konwersji wideo, zmiany audio lub stworzenia strumienia o niższej przepływności.

Te operacje mogą sprawić, że odtwarzanie na żywo będzie bardziej obciążające dla CPU niż zwykły film odtwarzany bezpośrednio. Nagrywanie i analiza reklam mogą też działać równolegle z oglądaniem, dodając więcej pracy serwerowi.

Sprawdź osobno kodek źródłowy sesji na żywo, status deinterlacingu, tryb odtwarzania i wybraną jakość, niezależnie od biblioteki mediów zapisanych. Problem z telewizją na żywo nie oznacza, że wszystkie lokalne pliki wymagają tego samego sprzętu.

Zdalne odtwarzanie często wymusza nowy bitrate

Plik o wysokim bitrate może być odtwarzany bezpośrednio (Direct Play) w sieci LAN, ale przekraczać dostępną prędkość wysyłania internetu serwera. Wtedy klient zdalny lub limit serwera żąda mniejszego strumienia.

Zmniejszenie bitrate oznacza, że serwer zwykle musi stworzyć nowy strumień wideo. Wykorzystanie CPU może więc wzrosnąć podczas zdalnego odtwarzania, nawet gdy ten sam klient używa niewiele mocy obliczeniowej serwera w domu.

Porównaj bitrate źródła z trwałą przepustowością wysyłania oraz zdalnym ustawieniem jakości klienta. Jeśli obniżenie strumienia powoduje transkodowanie programowe, poprawnie skonfigurowana akceleracja sprzętowa lub wstępnie zakodowana zdalna wersja mogą zmniejszyć zapotrzebowanie na CPU.

Krótki skok użycia CPU może być normalny

Niektóre transkodery pracują z wyprzedzeniem względem pozycji odtwarzania, tworząc bufor. Wykorzystanie CPU może gwałtownie wzrosnąć na początku, spaść po wyprodukowaniu wystarczającej liczby segmentów, a następnie ponownie wzrosnąć, gdy potrzebne będzie więcej danych wyjściowych.

Krótki szczyt z płynnym odtwarzaniem i stabilną temperaturą nie wymaga koniecznie naprawy. Utrzymujące się maksymalne użycie, spadająca prędkość transkodowania, powtarzające się buforowanie lub termiczne ograniczenia wskazują na poważniejszy problem z wydajnością.

Obserwuj obciążenie przez kilka minut, zamiast polegać na pojedynczym zrzucie CPU. Zapisz, czy procesor pozostaje obciążony, czy transkoder nadąża i czy taktowanie serwera spada wraz ze wzrostem temperatury.

Nie koduj ponownie całej biblioteki na początku

Konwersja każdego pliku do szeroko obsługiwanego formatu może zmniejszyć przyszłe transkodowanie w czasie rzeczywistym, ale wymaga czasu, dodatkowej przestrzeni dyskowej i kolejnego kroku stratnej kompresji dla wielu źródeł.

Może też nie rozwiązać rzeczywistej przyczyny, jeśli wysokie CPU wynika z wypalania napisów, mapowania tonów HDR, zdalnych limitów bitrate, analizy w tle lub uszkodzonego dostępu do GPU wewnątrz Dockera.

Najpierw zidentyfikuj kombinacje, które wielokrotnie zawodzą na klientach, których faktycznie używasz. Twórz zoptymalizowane kopie tylko dla mediów z wysoką częstotliwością problemów lub używaj bardziej wydajnego klienta, jeśli to prostsze niż utrzymywanie wielu wersji biblioteki.

Użyj tego porządku rozwiązywania problemów

1. Odtwórz sesję z wysokim użyciem CPU z tym samym plikiem i klientem.
2. Zanotuj, czy to Direct Play, Remux, transkodowanie audio czy wideo.
3. Zidentyfikuj dokładny proces zużywający CPU.
4. Zanotuj podany powód konwersji.
5. Przetestuj oryginalną jakość w sieci lokalnej.
6. Wyłącz napisy i wybierz inną ścieżkę audio.
7. Odtwórz ten sam plik na innym kliencie.
8. Monitoruj silniki dekodowania i kodowania GPU.
9. Sprawdź log transkodera lub FFmpeg pod kątem awaryjnego trybu programowego.
10. Zweryfikuj dostęp do GPU z poziomu Dockera lub maszyny wirtualnej.
11. Wstrzymaj analizę mediów, generowanie podglądu i zadania optymalizacji.
12. Dodawaj kolejne strumienie pojedynczo.
13. Sprawdź temperaturę i taktowanie CPU.
14. Ulepsz sprzęt dopiero po potwierdzeniu wąskiego gardła.

Podsumowanie końcowe

Wysokie zużycie CPU podczas odtwarzania mediów zwykle wynika z decyzji o przetwarzaniu, a nie jest samo w sobie diagnozą. Najczęstszą przyczyną jest pełne programowe transkodowanie wideo, ale wypalanie napisów, mapowanie tonów HDR, częściowe przyspieszenie sprzętowe, zdalne ograniczenia jakości i równoczesne sesje mogą powodować podobne obciążenie.

Zacznij od zidentyfikowania trybu odtwarzania i dokładnego procesu zużywającego CPU. Jeśli sesja transkoduje, przetestuj kompatybilność klienta, oryginalną jakość, napisy, ścieżki audio i pełny pipeline sprzętowego przyspieszenia. Jeśli jest to Direct Play, sprawdź analizę w tle i inne aktywne zadania.

Ulepsz serwer dopiero po tym, jak logi i kontrolowane testy pokażą, że wymagane przetwarzanie w czasie rzeczywistym przekracza dostępne zasoby obliczeniowe. Wiele przypadków wysokiego zużycia CPU można rozwiązać, zmieniając ścieżkę odtwarzania, poprawiając dostęp GPU w Dockerze, planując analizę poza godzinami oglądania lub wybierając klienta, który może odtwarzać oryginalne media bezpośrednio.

FAQ

Dlaczego zużycie CPU wzrasta po włączeniu napisów?

Klient może nie być w stanie wyświetlić wybranego formatu napisów. Serwer wtedy wypala napisy na każdą klatkę wideo, co wymaga dekodowania i ponownego kodowania wideo. Przetestuj wyłączenie napisów lub wybierz obsługiwany tekstowy ślad.

Dlaczego CPU jest nadal wysokie, gdy włączone jest sprzętowe transkodowanie?

GPU może przyspieszać tylko dekodowanie i kodowanie wideo, podczas gdy CPU obsługuje napisy, dźwięk, mapowanie tonów, skalowanie lub inne filtry. Dostęp do sprzętu może być też niepełny w środowisku Docker lub maszynie wirtualnej.

Czy Direct Play nie używa CPU?

Nie. Direct Play nadal wymaga dostępu do pliku, sieci, uwierzytelniania i przetwarzania aplikacji. Zwykle powinno zużywać znacznie mniej CPU niż transkodowanie wideo, więc utrzymujące się duże obciążenie powinno skłonić do sprawdzenia zadań w tle lub innego procesu.

Dlaczego obniżenie jakości strumienia zwiększa zużycie CPU?

Niższa rozdzielczość lub bitrate zwykle wymaga od serwera utworzenia nowego strumienia wideo. Jeśli oryginalny plik mógł być odtwarzany bezpośrednio (Direct Play), wybór niższej jakości zmienia sesję na transkodowanie i zwiększa obciążenie serwera.

Czy skanowanie mediów może powodować wysokie zużycie CPU podczas odtwarzania filmu?

Tak. Generowanie podglądu miniaturki, wykrywanie wstępu lub napisów końcowych, optymalizacja, analiza głosu i inne zadania w tle mogą działać jednocześnie z odtwarzaniem. Sprawdź listę procesów i status zaplanowanych zadań, zanim przypiszesz całe zużycie CPU aktywnemu strumieniowi.