Akceleracja sprzętowa a transkodowanie przez CPU dla tego samego strumienia 4K

W przypadku tego samego strumienia 4K odtwarzanego w czasie rzeczywistym akceleracja sprzętowa jest zwykle lepszym rozwiązaniem dla serwera multimediów, gdy procesor graficzny lub silnik multimedialny obsługuje każdy wymagany etap dekodowania, filtrowania, mapowania tonów i kodowania. Przenosi najbardziej wymagające operacje wideo z ogólnych rdzeni procesora, zmniejsza jego obciążenie i zapewnia większy zapas na obsługę wielu zadań jednocześnie. Transkodowanie procesorowe pozostaje przydatne, gdy ścieżka sprzętowa nie obsługuje wymaganego formatu lub filtra albo gdy jednorazowe kodowanie programowe stawia wydajność kompresji ponad przepustowość w czasie rzeczywistym. Porównanie ma sens tylko wtedy, gdy plik źródłowy, rozdzielczość docelowa, przepływność, klient i wymagania dotyczące przetwarzania pozostają stałe.

Utrzymaj stałe zadanie 4K przed porównaniem silników

Uczciwe porównanie wykorzystuje ten sam plik źródłowy, rozdzielczość wyjściową, docelową przepływność lub ustawienie jakości, stan napisów, wymagania HDR/SDR oraz klienta. Zmiana któregokolwiek z tych parametrów może zmienić zakres pracy bardziej niż wybór między kodowaniem sprzętowym a procesorowym.

Dokumentacja wydajności HandBrake pokazuje, jak ustawienie kodera, docelowa jakość, przepływność i filtry wpływają na szybkość. Jego kontrolowane zmienne wydajności kodera zapewniają właściwą metodykę testów: porównuj jedną ścieżkę naraz, zamiast porównywać dwa różne zadania.

Zapisz szybkość transkodowania, liczbę pominiętych lub opóźnionych odtworzeń, wykorzystanie procesora, wykorzystanie silnika wideo, zużycie energii przez system, jeśli jest dostępne, oraz jakość wyjściową. Jeśli obie ścieżki działają szybciej niż w czasie rzeczywistym, kolejna decyzja powinna dotyczyć zapasu wydajności i efektywności, a nie tego, czy którakolwiek ścieżka jest w stanie technicznie zakończyć zadanie.

Akceleracja sprzętowa wygrywa test przepustowości w czasie rzeczywistym

Obsługiwana akceleracja sprzętowa korzysta ze specjalizowanych bloków dekodowania i kodowania zaprojektowanych konkretnie do obsługi wideo. Dzięki temu nie trzeba zużywać cykli procesora ogólnego przeznaczenia na każdy makroblok czy transformację, co zwykle pozostawia znacznie większą moc obliczeniową dla aplikacji multimedialnej, stosu pamięci masowej, napisów, obsługi bazy danych i niezwiązanych z tym usług.

Jellyfin wymienia QSV, NVENC/NVDEC, AMF, VA-API, VideoToolbox i inne metody sprzętowe oraz opisuje, jak potok transkodowania może odciążyć kilka etapów. Potok transkodowania z funkcjami stałymi potwierdza praktyczny wniosek: sprzęt wygrywa, gdy cała wymagana ścieżka jest faktycznie akcelerowana.

Korzyść jest największa, gdy nakłada się na siebie kilka strumieni. Procesor, który potrafi transkodować programowo jedno źródło 4K w czasie rzeczywistym, może mieć niewielki zapas na drugą sesję, podczas gdy odpowiedni silnik wideo często może obsłużyć więcej jednoczesnych zadań bez wykorzystywania takiej samej części ogólnego budżetu procesora.

Transkodowanie przez procesor zachowuje elastyczność tam, gdzie kończą się możliwości ścieżek sprzętowych

Transkodowanie programowe może obsługiwać formaty, opcje kodera lub filtry, których dana generacja sprzętu nie udostępnia. Umożliwia również korzystanie z wolniejszych ustawień wstępnych, które przeznaczają więcej obliczeń na poprawę decyzji dotyczących kompresji. Może to być atrakcyjne podczas przygotowywania biblioteki offline, choć zwykle słabo sprawdza się przy odtwarzaniu na żywo.

Aktualne wytyczne Plex dotyczące sprzętowego przesyłania strumieniowego wskazują, że generacja sprzętu może wpływać na jakość wyjściową, a kodowanie HEVC wymaga większych zasobów niż H.264. Jego zależne od generacji wyjście sprzętowe wyznacza granicę: sprzęt nie korzysta z identycznego kodera w przypadku każdej generacji procesorów i kart graficznych.

Transkodowanie przez procesor pozostaje więc rozwiązaniem awaryjnym, gdy akcelerator nie może wykonać całego wymaganego zadania. Nie należy wybierać go wyłącznie dlatego, że dostępna jest moc obliczeniowa procesora; pytanie brzmi, czy jego większa elastyczność jest warta dodatkowego zużycia energii i mniejszej liczby jednoczesnych sesji podczas odtwarzania materiału 4K na żywo.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Częściowa akceleracja może ukrywać prawdziwe wąskie gardło

Sesja może wykorzystywać sprzętowe kodowanie, podczas gdy procesor nadal wykonuje dekodowanie, wypalanie napisów, przetwarzanie dźwięku, skalowanie lub działanie innego filtra. W takim przypadku system nie porównuje pełnego potoku sprzętowego z pełnym potokiem procesora, lecz dwa potoki hybrydowe z różnymi etapami programowymi.

NVIDIA Video Codec SDK rozdziela możliwości NVDEC i NVENC oraz dokumentuje obsługę sprzętową poszczególnych kodeków. Jego oddzielne możliwości sprzętowego dekodowania i kodowania pokazują, dlaczego pomyślne kodowanie sprzętowe nie oznacza, że dekodowanie źródła również odbywa się z użyciem akceleracji.

Obserwuj jednocześnie aktywność procesora i silnika wideo, a następnie sprawdź log transkodowania. Jeśli wąskim gardłem jest filtr programowy, przejście na szybszy sprzętowy koder może nie zmienić odtwarzania, dopóki ten filtr również nie zyska akcelerowanej ścieżki albo nie zmienią się wymagania dotyczące odtwarzania.

Jakość należy porównywać przy rzeczywistej przepływności dostarczania, z której faktycznie korzystasz

Koder programowy może korzystać z wolnych ustawień, aby dokładniej szukać efektywności kompresji, podczas gdy sprzęt stałofunkcyjny jest zoptymalizowany pod kątem przepustowości i przewidywalnych opóźnień. Nowsze kodery sprzętowe znacznie się poprawiły, dlatego różnice jakości należy mierzyć, a nie zakładać ich na podstawie porównań starszych generacji.

Dokumentacja Intel dotycząca Quick Sync podkreśla, że funkcja jest zaimplementowana w układzie graficznym procesora i musi być obsługiwana przez konkretny model CPU. Sprawdzenie dokładnej generacji Quick Sync ma znaczenie, ponieważ „akceleracja sprzętowa” może oznaczać zupełnie różne silniki multimedialne w zależności od generacji platformy.

W przypadku odtwarzania na żywo porównuj widoczną jakość przy przepływności, którą otrzyma użytkownik zdalny lub klient. Jeśli obie opcje spełniają próg jakości w gospodarstwie domowym, wybierz tę, która pozostawia większy zapas zasobów, zamiast optymalizować parametr kodera, którego widz nie może dostrzec.

Zasilanie i obsługa wielu strumieni zmieniają test jednego strumienia w decyzję dotyczącą serwera

Ten sam strumień 4K może być obsługiwany przez CPU, a mimo to nie być właściwym wyborem domyślnym dla serwera działającego stale. Wysokie wykorzystanie programowe zwiększa ryzyko, że drugi strumień, skanowanie biblioteki, kopia zapasowa lub inna usługa będą kolidować z odtwarzaniem. Akceleracja sprzętowa zapewnia większy margines zasobów na takie nakładanie się obciążeń.

Przewodnik ZimaSpace dotyczący sprawdzania, czy transkodowanie sprzętowe rzeczywiście działa zaleca weryfikację aktywnego strumienia, aktywności akceleratora hosta i logów, zamiast polegania wyłącznie na ustawieniu. Przed przypisaniem ścieżce sprzętowej jakiejkolwiek przewagi pod względem wydajności wykonaj tę samą weryfikację.

Jeśli jeden strumień z akceleracją sprzętową działa stabilnie, ale drugi się nie uruchamia, oznacza to, że znaleziono rzeczywistą granicę obsługi równoległości. Jeśli programowe transkodowanie przez CPU działa tylko wtedy, gdy każda inna usługa jest bezczynna, przeszło demonstrację, ale nie sprawdziło się przy rzeczywistym obciążeniu serwera.

Najczęściej zadawane pytania

Czy transkodowanie sprzętowe zawsze zapewnia gorszą jakość niż transkodowanie przez CPU?

Nie. Jakość zależy od generacji sprzętu, kodeka, ustawień kodera, docelowej przepływności oraz użytego programowego profilu kodowania. Wolne profile programowe mogą wymagać znacznie większej mocy obliczeniowej w zamian za lepszą wydajność kompresji, ale nowsze silniki sprzętowe nadal mogą zapewniać bardzo dobrą jakość obrazu w czasie rzeczywistym. Porównuj obraz przy przepływności i rozmiarze wyświetlania, które faktycznie widzą użytkownicy.

Dlaczego użycie CPU nadal jest wysokie, gdy akceleracja sprzętowa jest włączona?

Przyspieszeniem może być objęta tylko część potoku. Konwersja dźwięku, napisy, mapowanie tonów, skalowanie, nieobsługiwane formaty dekodowania lub inne filtry mogą nadal działać na CPU. Korzystaj z dzienników strumienia i aktywności silnika na hoście, aby sprawdzić, który etap nadal jest ograniczony przez oprogramowanie.

Czy warto używać transkodowania przez CPU, jeśli serwer ma wiele bezczynnych rdzeni?

Tylko jeśli ścieżka programowa zapewnia działanie w czasie rzeczywistym z wystarczającym zapasem na najgorsze jednoczesne obciążenie, a cenisz jej elastyczność lub charakterystykę wyjścia. Bezczynne rdzenie stanowią przydatny zapas mocy dla baz danych, skanowania, kopii zapasowych i dodatkowych sesji; zużywanie ich tylko dlatego, że są dostępne, może zmniejszyć odporność serwera.

W przypadku transmisji 4K na żywo najpierw wybierz sprzęt, a CPU traktuj jako ścieżkę wyjątkową

Wybierz akcelerację sprzętową, gdy dokładna ścieżka od źródła 4K do wyjścia jest w pełni obsługiwana, a znaczenie mają przepustowość w czasie rzeczywistym, obsługa wielu jednoczesnych strumieni i zapas mocy serwera. To typowe rozwiązanie dla stale działającego serwera multimediów obsługującego różne urządzenia klienckie.

Wybierz transkodowanie przez CPU, gdy sprzęt nie obsługuje wymaganego kodeka lub etapu przetwarzania albo gdy zadanie działa w trybie offline i świadomie akceptujesz znacznie dłuższy czas kodowania na rzecz programowego profilu kodowania. To wyjątek wynikający z charakteru obciążenia, a nie dowód na to, że sprzęt wideo o stałej funkcjonalności jest niepotrzebny.

Jeśli strumień już korzysta z funkcji Direct Play, całkowicie przestań porównywać te dwie ścieżki. Ani transkodowanie sprzętowe, ani CPU nie poprawi sesji, która nie wymaga konwersji wideo; zachowaj Direct Play i przeznacz zasoby serwera na konwersje, których nie da się uniknąć.