Jak transkodowanie przez procesor wpływa na zużycie energii serwera w porównaniu z odtwarzaniem bezpośrednim?

Transkodowanie przez CPU zwykle znacznie zwiększa pobór mocy serwera w porównaniu z odtwarzaniem bezpośrednim, ponieważ serwer przestaje głównie odczytywać i wysyłać istniejący strumień multimedialny, a zaczyna dekodować, filtrować i ponownie kodować wideo w czasie rzeczywistym. Nie ma uniwersalnej wartości wzrostu poboru mocy: na wynik wpływają kodek, rozdzielczość, mapowanie tonów HDR, wypalanie napisów, generacja procesora, limity mocy i liczba strumieni. Właściwym punktem odniesienia jest energia zużyta podczas tego samego zadania odtwarzania na tym samym serwerze, a nie ogólne stwierdzenie „transkodowanie zużywa więcej energii”.

Zdefiniuj wynik pomiaru poboru mocy przed rozpoczęciem porównania

Zachowaj bez zmian plik multimedialny, klienta, ścieżkę sieciową, czas odtwarzania i konfigurację serwera. Najpierw odtwórz materiał bezpośrednio, a następnie wymuś programowe transkodowanie przez CPU do ustalonej rozdzielczości i przepływności wyjściowej. W ten sposób otrzymujesz jedną kontrolowaną zmienną: ilość dodatkowej energii serwera potrzebną do utworzenia nowego strumienia.

Plex opisuje odtwarzanie bezpośrednie jako wysyłanie zgodnych multimediów bez konwersji, podczas gdy transkodowanie konwertuje multimedia na potrzeby klienta. Ta różnica wyjaśnia mechanizm, ale nadal nie określa różnicy w poborze mocy dla konkretnego procesora.

Mierz średni pobór mocy z gniazdka i całkowitą zużytą energię przez wystarczająco długi czas odtwarzania, aby ustabilizowały się chwilowe podbicia taktowania i krótkotrwałe zadania uruchomieniowe. Dziesięciosekundowy szczyt może wyglądać spektakularnie, choć wnosi niewiele do dwugodzinnego filmu; bardziej użyteczną miarą eksploatacyjną jest energia zużyta na godzinę odtwarzania.

Odtwarzanie bezpośrednie utrzymuje CPU bliżej bazowego poboru mocy serwera

Odtwarzanie bezpośrednie nadal wykorzystuje pamięć masową, sieć, logikę aplikacji, szyfrowanie — jeśli ma zastosowanie — oraz zarządzanie sesją klienta, więc nie jest całkowicie bezczynne. Kluczowa różnica polega na tym, że CPU nie musi stale dekodować i ponownie kodować każdej klatki wideo, gdy plik jest już zgodny z wymaganiami klienta.

Wytyczne sprzętowe Jellyfin oddzielają serwowanie multimediów od wymagającego obliczeniowo transkodowania i zalecają znacznie większą moc obliczeniową, gdy konwersja staje się częścią obciążenia. Dlatego serwer może wydawać się niemal bezczynny podczas jednej sesji, a chwilę później zostać ograniczony przez CPU, gdy inny klient zażąda niezgodnego formatu.

Odtwarzanie bezpośrednie wyznacza więc praktyczną bazę niższego zużycia energii dla konkretnego materiału i klienta. Jeśli serwer pobiera dużo energii podczas odtwarzania bezpośredniego, przed przypisaniem całego wyniku dostarczaniu multimediów sprawdź dyski, zadania w tle, wentylatory, maszyny wirtualne i zachowanie platformy w stanie bezczynności.

Transkodowanie przez CPU zwiększa aktywność układu na czas trwania strumienia

Transkodowanie programowe utrzymuje aktywność rdzeni ogólnego przeznaczenia podczas dekodowania, stosowania filtrów, nakładania napisów, konwersji kolorów i kodowania. Wyższe wykorzystanie zwykle odsuwa procesor od głębszych stanów bezczynności i wymusza wyższe, utrzymywane częstotliwości, dlatego pobór mocy pakietu procesora zwykle rośnie tak długo, jak konwersja odbywa się w czasie rzeczywistym.

Linux udostępnia rozliczanie energii pakietu procesora Intel za pośrednictwem liczników energii RAPL dla pakietów CPU. Interfejs raportuje zgromadzoną energię, a nie pojedynczą chwilową wartość mocy, dzięki czemu nadaje się do porównywania całkowitej energii CPU podczas sesji o tej samej długości: odtwarzania bezpośredniego i transkodowania programowego.

Wpływ zależy od porównywanych warunków, a nie od stałego mnożnika. Nowoczesny, wydajny procesor wykonujący lekką konwersję 1080p może zużyć tylko umiarkowanie więcej energii, natomiast trudna programowa konwersja z 4K HEVC do H.264 z przetwarzaniem HDR może obciążyć wiele rdzeni i przenieść cały system w zupełnie inny stan poboru mocy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mierz energię na godzinę odtwarzania zamiast szczytowej mocy

Moc szczytowa odpowiada na pytanie, czy zasilacz i układ chłodzenia poradzą sobie z krótkim obciążeniem. Nie odpowiada jednak na pytanie o koszty eksploatacji. W przypadku serwera multimediów zintegruj energię zużytą podczas powtarzalnego okresu odtwarzania i porównaj watogodziny dla odtwarzania bezpośredniego oraz tej samej sesji z transkodowaniem przez CPU.

Intel opisuje RAPL jako raportowanie zgromadzonej energii w domenach zasilania procesora. Traktuj je jako sygnał na poziomie pakietu, a jeśli chcesz uwzględnić pamięć, pamięć masową, wentylatory, straty zasilacza i pozostałe elementy serwera, połącz je z pomiarem watomierzem.

Decyzja zmienia się, gdy dodatkowa energia jest zużywana często i przez długi czas. Jedno rzadkie transkodowanie może być praktycznie nieistotne, ale kilka godzin programowego transkodowania każdego wieczoru może zmienić zgodność multimediów w rzeczywisty problem związany z poborem mocy, temperaturą i współbieżnością.

Wybór kodeka i filtrów może bardziej wpłynąć na różnicę w poborze mocy niż sama rozdzielczość

Dwa strumienie 4K mogą powodować zupełnie różne obciążenie CPU. Jeden może wymagać jedynie zmiany kontenera, podczas gdy drugi będzie wymagał programowego dekodowania HEVC, mapowania tonów, wypalania napisów, skalowania i kodowania H.264. Traktuj cały potok jako przypadek testowy, zamiast zakładać, że samo „4K” jednoznacznie przewiduje pobór mocy.

FFmpeg udostępnia etapy dekodowania, filtrowania, skalowania, obsługi napisów i kodowania jako osobne kroki przetwarzania. Jego mechanizmy filtrowania i potoku kodeków pokazują, dlaczego transkodowanie może obejmować kilka etapów intensywnie wykorzystujących CPU, nawet gdy przepływność wyjściowa jest umiarkowana.

Jeśli wzrost poboru mocy powoduje jedna trudna ścieżka napisów lub HDR, zmiana tej ścieżki może zmniejszyć zużycie energii bardziej niż zakup procesora o niższym TDP. Zakończ analizę mechanizmu, gdy zidentyfikujesz dokładny etap powodujący stałe obciążenie CPU i będziesz w stanie go uniknąć lub przyspieszyć.

Współbieżność zmienia różnicę w poborze mocy w decyzję dotyczącą wydajności

Jedno transkodowanie programowe może być akceptowalne, podczas gdy dwa lub trzy strumienie doprowadzą CPU do granic długotrwałego obciążenia. Większa liczba aktywnych rdzeni, wyższa temperatura pakietu procesora, dłuższa praca wentylatorów na podwyższonych obrotach oraz zakłócenia w działaniu innych usług mogą sprawić, że drugi strumień będzie operacyjnie kosztowniejszy niż pierwszy uruchomiony samodzielnie.

Porównanie ZimaSpace dotyczące zgodności klienta i mocy potrzebnej do transkodowania jest użytecznym sprawdzeniem na wcześniejszym etapie: wyeliminuj możliwe do uniknięcia konwersje, zanim dobierzesz serwer do najgorszego przypadku. Energia zużywana na transkodowanie formatu, który lepiej skonfigurowany klient mógłby odtwarzać bezpośrednio, nie stanowi użytecznej wydajności.

Porównuj najbardziej obciążające, realistyczne okno jednoczesnego użytkowania, a nie sztuczny test obciążenia wszystkich rdzeni. Jeśli serwer utrzymuje działanie pozostałych usług, a wzrost poboru mocy jest akceptowalny, transkodowanie przez CPU może nadal być dobrym rozwiązaniem. Jeśli jednak powtarzające się wieczorne sesje utrzymują system blisko limitu temperatury lub mocy, obciążenie przestaje być okazjonalną pracą na rzecz zgodności i staje się decyzją architektoniczną.

Często zadawane pytania

Czy transkodowanie przez CPU zawsze wykorzystuje 100% procesora?

Nie. Wykorzystanie zależy od złożoności kodeka, rozdzielczości, filtrów, ustawień wyjściowych, planowania wątków oraz tego, czy każdy etap działa programowo. Porównanie poboru mocy powinno opierać się na rzeczywistym obciążeniu, a nie na założeniu pełnego wykorzystania CPU.

Czy transkodowanie sprzętowe zużywa tyle samo energii co odtwarzanie bezpośrednie?

Zwykle nie. Akceleracja sprzętowa może przenieść przetwarzanie wideo do wyspecjalizowanych silników multimedialnych i zmniejszyć obciążenie CPU, ale serwer nadal dekoduje, filtruje lub koduje nowy strumień. Odtwarzanie bezpośrednie całkowicie unika tej pracy konwersyjnej.

Czy obniżenie zdalnej przepływności zawsze zmniejszy pobór mocy serwera?

Niekoniecznie. Niższa przepływność wyjściowa może wymagać intensywniejszej kompresji, zależnie od ustawień kodera, podczas gdy łatwiejszy kodek lub niższa rozdzielczość mogą zmniejszyć obciążenie. Mierz cały profil wyjściowy, a nie samą przepływność.

Wykorzystuj zmierzoną różnicę w poborze mocy tylko tam, gdzie rzeczywiście występuje transkodowanie przez CPU

Praktyczny wniosek jest warunkowy: transkodowanie przez CPU zwiększa zużycie energii serwera w porównaniu z odtwarzaniem bezpośrednim, ponieważ uruchamia potok obliczeniowy działający w czasie rzeczywistym, ale skala wzrostu zależy od konkretnego pliku, procesora, ustawień i liczby strumieni.

Najpierw zmierz odtwarzanie bezpośrednie, następnie wymuś konkretne transkodowanie przez CPU, które rzeczywiście wywołują użytkownicy, i porównaj watogodziny dla tego samego czasu trwania. Otrzymasz w ten sposób wartość przydatną przy planowaniu temperatury, czasu podtrzymania UPS-a, kosztów energii i wydajności, bez udawania, że każdy serwer multimediów ponosi taką samą karę.

Zakończ optymalizację, gdy usuniesz możliwe do uniknięcia transkodowania, a pozostałe konwersje zmieszczą się w budżecie poboru mocy i współbieżności serwera. Jeśli tak nie jest, zmień ścieżkę odtwarzania, użyj obsługiwanej akceleracji sprzętowej lub dobierz inny serwer na podstawie zmierzonego obciążenia.