Jak sprawdzić, czy sprzętowe transkodowanie faktycznie działa

Włączenie transkodowania sprzętowego nie jest równoznaczne z udowodnieniem, że transkodowanie sprzętowe działa. Serwer multimediów może mieć włączone to ustawienie, ale aktualny strumień może nadal być odtwarzany bezpośrednio, przełączać się na transkodowanie programowe, używać sprzętu tylko w części procesu lub nie mieć dostępu do GPU w środowisku Docker.

Bezpieczniejszym sposobem sprawdzenia jest śledzenie tego samego aktywnego strumienia z kilku perspektyw: wymuszenie rzeczywistego transkodowania, odczyt pulpitu serwera multimediów, potwierdzenie aktywności GPU lub iGPU na poziomie hosta, analiza logów FFmpeg, gdy wynik jest niejasny, oraz weryfikacja, czy klient otrzymuje oczekiwany wynik odtwarzania.

Ustawienie daje tylko uprawnienie, a nie dowód

Ustawienie transkodowania sprzętowego to uprawnienie, a nie wynik testu. Informuje Plex, Jellyfin, Emby lub inny serwer multimediów, że może używać przyspieszenia sprzętowego, gdy strumień, kodek, sterownik, dostęp do urządzenia i warunki odtwarzania są zgodne. Nie dowodzi to, że oglądany właśnie strumień korzysta z GPU.

Plex opisuje strumieniowanie z przyspieszeniem sprzętowym jako sposób, w jaki Plex Media Server wykorzystuje dedykowany sprzęt do dekodowania i kodowania wideo podczas konwersji, co może zmniejszyć obciążenie CPU związane z transkodowaniem. Jednak Plex zauważa również, że może nastąpić powrót do oprogramowania, gdy przyspieszenie sprzętowe nie jest dostępne lub kompatybilne z daną ścieżką wideo.

To rozróżnienie jest ważne, ponieważ serwer multimediów może pokazywać zdrową stronę ustawień, podczas gdy aktywna sesja robi coś innego. Plik może być odtwarzany bezpośrednio. Serwer może transkodować tylko dźwięk. Wideo może być dekodowane sprzętowo, ale kodowane programowo. Albo kontener może nie mieć dostępu do urządzenia, które widzi system operacyjny hosta.

Niezawodny proces weryfikacji powinien odpowiedzieć na pięć pytań: czy strumień faktycznie jest transkodowany, czy na pulpicie widać przyspieszenie sprzętowe, czy na hoście widać aktywność kodowania lub dekodowania wideo, czy logi FFmpeg pokazują ścieżkę sprzętową oraz czy wynik odtwarzania na kliencie odpowiada oczekiwanej rozdzielczości, przepływności, kodekowi lub zachowaniu napisów?

Jeśli te warstwy się zgadzają, transkodowanie sprzętowe prawdopodobnie działa. Jeśli się nie zgadzają, odpowiedź nie jest po prostu taka, że ustawienie jest uszkodzone lub panel jest błędny. Lepszą odpowiedzią jest znalezienie, która warstwa w łańcuchu przetwarzania uległa zmianie.

Najpierw upewnij się, że strumień faktycznie się transkoduje

Przed sprawdzeniem użycia GPU upewnij się, że serwer multimediów wykonuje rzeczywiste transkodowanie. Jeśli plik jest odtwarzany bezpośrednio, serwer w większości wysyła oryginalny strumień do klienta. W takim przypadku niskie użycie CPU i GPU jest normalne.

Kontrolowany testowy strumień powinien wymusić na serwerze konwersję czegoś. Zazwyczaj można to zrobić, obniżając jakość odtwarzania, używając przeglądarki lub klienta, który nie obsługuje kodeka źródłowego, ustawiając zdalny limit bitrate, włączając napisy wymagające wypalenia lub wybierając plik o wysokim bitrate, który musi zostać zmniejszony dla klienta.

Dla Plex prostym testem jest rozpoczęcie wideo i obniżenie jakości odtwarzania, aby Plex musiał przekonwertować strumień. Przewodnik Plex opisuje obniżenie jakości wideo, na przykład wymuszając konwersję do 480p, a następnie sprawdzenie szczegółów odtwarzania w panelu Plex pod kątem wskaźnika przyspieszenia sprzętowego.

Dla Jellyfin lub Emby obowiązuje ten sam kontrolowany test odtwarzania. Zacznij od pliku, którego klient nie może odtwarzać bezpośrednio, lub ręcznie ustaw niższą jakość odtwarzania. Następnie otwórz informacje o odtwarzaniu, szczegóły aktywnego strumienia lub diagnostykę strumienia, aby potwierdzić, czy sesja to direct play, direct stream czy transkodowanie.

Nie używaj losowego pliku jako jedynego testu transkodowania sprzętowego. Film, który odtwarza się bezpośrednio na telewizorze, może nigdy nie korzystać z transkodera, podczas gdy ten sam plik może być transkodowany w przeglądarce, podczas zdalnego dostępu, na danych mobilnych lub z włączonymi napisami. Plik testowy powinien tworzyć wyraźny warunek przed i po.

Panel to pierwsza wskazówka

Panel serwera multimediów to pierwszy użyteczny sygnał, ponieważ łączy aktywną sesję odtwarzania z interpretacją tego strumienia przez serwer. Jednak to nadal wskazówka z panelu, a nie pełny łańcuch dowodowy.

Plex: Sprawdź dekodowanie i kodowanie sprzętowe

W Plex rozpocznij strumień, o którym wiesz, że jest transkodowany, następnie otwórz Panel internetowy i rozwiń szczegóły Teraz odtwarzane. Plex informuje, że gdy używane jest przyspieszenie sprzętowe, powinieneś zobaczyć (hw) obok formatu wideo w rozszerzonych szczegółach odtwarzania.

Silny sygnał Plex wygląda jak linia transkodowania z (hw) dołączoną do ścieżki wideo. W zależności od pliku źródłowego, sprzętu, systemu operacyjnego i wersji Plex, sprzęt może być zaangażowany w dekodowanie, kodowanie lub oba procesy. Ważnym krokiem jest rozwinięcie szczegółów strumienia zamiast patrzenia tylko na główną kartę Teraz Odtwarzane.

Jeśli Plex pokazuje Direct Play, transkodowanie sprzętowe nie powinno się pojawiać. Jeśli Plex pokazuje Transcode, ale bez (hw), strumień może korzystać z transkodowania programowego. Jeśli Plex pokazuje (hw), ale CPU nadal jest aktywne, nie oznacza to automatycznie awarii; transkodowanie audio, napisy, remuxing, mapowanie tonów i inne etapy mogą nadal wykorzystywać CPU.

Jellyfin i Emby: Sprawdź szczegóły strumienia

W Jellyfin sprawdź aktywny strumień lub informacje o odtwarzaniu, aby poznać powód transkodowania oraz metodę przyspieszenia sprzętowego. Dokumentacja Jellyfin dotycząca przyspieszenia sprzętowego wyjaśnia, że Jellyfin używa zmodyfikowanego transkodera FFmpeg i może korzystać z zintegrowanych lub dedykowanych GPU przez metody takie jak Intel QSV, NVIDIA NVDEC / NVENC, AMD AMF, VA-API, VideoToolbox oraz inne specyficzne dla platformy ścieżki.

Przydatne pytanie to nie tylko czy następuje transkodowanie, ale jaką metodą jest ono wykonywane. Jeśli szczegóły odtwarzania pokazują QSV, VAAPI, NVENC, AMF lub VideoToolbox, to silniejszy znak niż ogólna etykieta transkodowania. Jeśli szczegóły strumienia pokazują tylko transkodowanie programowe, GPU prawdopodobnie nie obsługuje tego strumienia.

Sprawdzanie panelu kontrolnego jest szczególnie przydatne w połączeniu z jeszcze jednym pytaniem: dlaczego serwer transkoduje? Niezgodność kodeków, limit bitrate, wtopienie napisów, mapowanie tonów HDR, nieobsługiwany strumień audio lub zdalne ustawienie jakości mogą wywołać różne ścieżki przetwarzania. Dlatego dwa pliki mogą zachowywać się inaczej na tym samym serwerze.

Aktywność GPU hosta to druga warstwa dowodu

Kolejną warstwą jest aktywność GPU na poziomie hosta. Jeśli GPU lub iGPU faktycznie pomaga przy transkodowaniu na żywo, host zwykle powinien pokazywać aktywność w silniku kodowania lub dekodowania wideo podczas działania strumienia.

Ta warstwa jest ważna, ponieważ panele kontrolne mogą być uproszczone. Panel może pokazywać zaangażowanie sprzętu bez wyjaśnienia, który etap jest przyspieszany. Host może pokazać, czy silnik wideo staje się aktywny, gdy rozpoczyna się strumień, i uspokaja się, gdy strumień się zatrzymuje.

NVIDIA: Obserwuj silnik wideo, nie tylko użycie GPU

Dla systemów NVIDIA użyj nvidia-smi podczas działania testowego transkodowania. Sprawdź proces serwera multimedialnego lub transkodera, użycie pamięci GPU oraz aktywność enkodera / dekodera. Dokumentacja NVIDIA zawiera monitorowanie wykorzystania enkodera i dekodera, a monitorowanie procesów może pokazać użycie GPU na proces.

Podstawowa kontrola NVIDIA to:

nvidia-smi

Dla bardziej aktywnego widoku monitorowania użyj:

nvidia-smi dmon

Powszechnym błędem jest obserwowanie tylko ogólnego procentu GPU. Transkodowanie wideo może nie wyglądać jak renderowanie 3D, gry czy obliczenia AI. Sprawdź konkretnie aktywność kodowania / dekodowania wideo, odpowiedni proces serwera multimedialnego i czy czas zgadza się z aktywnym strumieniem.

Intel Quick Sync: Potwierdź, że iGPU jest faktycznie zajęte

Dla systemów Intel iGPU / Quick Sync na Linuksie intel_gpu_top jest często najczytelniejszym narzędziem. Rozpocznij wymuszone transkodowanie, a następnie obserwuj, czy silnik wideo wykazuje aktywność. Jeśli pulpit nawigacyjny serwera multimedialnego pokazuje, że akceleracja sprzętowa jest aktywna, ale silnik wideo Intela pozostaje bezczynny, serwer może używać niewłaściwego urządzenia, brakować mu uprawnień lub przechodzić na oprogramowanie.

Możesz także sprawdzić, czy Linux widzi urządzenie graficzne:

lspci -nn | grep -Ei "3d|wyświetlacz|vga"

Dokumentacja Jellyfin dotycząca akceleracji sprzętowej kieruje użytkowników do specyficznych dla sprzętu kontroli przed wyborem metody akceleracji, ponieważ dostępna ścieżka akceleracji zależy od urządzenia, sterownika i wsparcia platformy.

AMD: Dopasuj aktywność GPU do aktywnego strumienia

W systemach AMD dokładne narzędzie do monitorowania zależy od systemu operacyjnego i stosu sterowników. Na Linuksie użytkownicy często sprawdzają aktywność związaną z VAAPI / AMF za pomocą narzędzi takich jak radeontop lub pulpitów platformy. Logika weryfikacji jest taka sama: rozpocznij wymuszone transkodowanie, obserwuj aktywność GPU związaną z wideo, a następnie zatrzymaj strumień i sprawdź, czy aktywność spada.

Nie oczekuj, że każde narzędzie oznaczy akcelerację wideo w ten sam sposób. Praktycznym pytaniem jest, czy aktywność pojawia się podczas tego konkretnego strumienia i czy czas zgadza się z pulpitem nawigacyjnym serwera multimedialnego.

Logi FFmpeg pokazują rzeczywistą ścieżkę transkodowania

Gdy pulpit nawigacyjny i metryki hosta się nie zgadzają, logi FFmpeg są zwykle kolejnym miejscem do sprawdzenia. Większość serwerów multimedialnych opiera się na FFmpeg lub zmodyfikowanej wersji FFmpeg do transkodowania, więc logi mogą pokazać, czy strumień korzystał ze sprzętowej ścieżki, przeszedł na oprogramowanie lub nie mógł uzyskać dostępu do urządzenia.

W logach ścieżki sprzętowe mogą zawierać nazwy takie jak:

h264_nvenc
hevc_nvenc
h264_qsv
hevc_qsv
h264_vaapi
hevc_vaapi

Ścieżki kodowania programowego często obejmują:

libx264
libx265

Dokumentacja FFmpeg opisuje opcje ścieżki akceleracji sprzętowej FFmpeg dla dekodowania dopasowanych strumieni, z metodami takimi jak vaapi, qsv, d3d11va, dxva2 i videotoolbox. Wyjaśnia też, że faktyczna dostępność zależy od wybranej metody, wsparcia dekodera, sprzętu i środowiska sterowników.

To rozróżnienie ma znaczenie. Fakt, że FFmpeg został zbudowany z metodą akceleracji sprzętowej, nie dowodzi, że aktualny strumień z niej korzystał. Log powinien pokazać faktyczną ścieżkę kodeka, dostęp do urządzenia oraz czy FFmpeg cicho przeszedł na kodowanie programowe.

Widok ścieżek kodowania programowego takich jak libx264 lub libx265 w logu transkodowania serwera multimediów jest często silnym sygnałem programowego fallbacku libx264 lub kodowania programowego, zwłaszcza gdy oczekiwano NVENC, QSV, VAAPI, AMF lub VideoToolbox.

Używaj logów, gdy dane z panelu i metryki hosta się nie zgadzają, gdy Docker lub uprawnienia zostały niedawno zmienione, gdy jeden kodek działa, a inny nie, gdy napisy lub mapowanie tonów HDR zmieniają wynik, lub gdy strumień się uruchamia, buforuje, zawiesza lub cicho przełącza na transkodowanie programowe.

Częściowe transkodowanie sprzętowe jest normalne

Transkodowanie sprzętowe nie zawsze jest albo wszystko, albo nic. Strumień może używać sprzętowego dekodowania, ale programowego kodowania, lub sprzętowego kodowania, ale programowego dekodowania. Może również korzystać z akceleracji GPU dla wideo, podczas gdy audio, napisy, skalowanie, remuxing lub mapowanie tonów nadal używają CPU.

Dokumentacja Jellyfin jest tutaj przydatna, ponieważ rozbija etapy potoku transkodowania na dekodowanie wideo, deinterlacing, skalowanie / konwersję formatu, mapowanie tonów HDR / DV, wypalanie napisów, kodowanie wideo oraz zero-copy. Zauważa również, że niektóre etapy mogą nie być przyspieszone przez GPU z powodu ograniczeń oprogramowania, sprzętu lub sterowników.

Więc właściwe pytanie nie brzmi, czy CPU jest zerowe. Lepszym testem transkodowania sprzętowego jest sprawdzenie, czy dekodowanie wideo odbywa się na sprzęcie, czy kodowanie wideo odbywa się na sprzęcie, czy użycie CPU jest wyjaśnione przez dźwięk lub napisy, czy odtwarzanie poprawia się w porównaniu z transkodowaniem tylko programowym oraz czy logi pokazują ścieżkę sprzętową lub awaryjne przejście na oprogramowanie.

Częściowa akceleracja może być nadal udanym wynikiem, jeśli ciężki etap wideo jest odciążony, a pozostała praca CPU jest spodziewana. Problem pojawia się, gdy serwer przełącza się na oprogramowanie dla etapu, który miał obsługiwać GPU.

Dlaczego użycie CPU może nadal być wysokie

Wysokie użycie CPU nie oznacza automatycznie, że transkodowanie sprzętowe zawiodło. Kodowanie i dekodowanie wideo to tylko część ścieżki odtwarzania. CPU może nadal obsługiwać transkodowanie dźwięku, wtopienie napisów, remuxowanie kontenera, operacje I/O na plikach, skalowanie, zadania metadanych, narzut sieciowy lub części mapowania tonów HDR.

Napisy są częstym przykładem. Jeśli klient nie obsługuje bezpośrednio formatu napisów, serwer może wtopić napisy w wideo. To może zmienić ścieżkę transkodowania i przenieść dodatkową pracę na CPU. Innym przykładem jest dźwięk: sprzętowa akceleracja wideo zwykle nie oznacza, że GPU transkoduje dźwięk.

Dobrym sposobem na rozdzielenie etapu obciążającego CPU jest przetestowanie kilku kontrolowanych plików: jednego prostego pliku H.264 bez napisów, jednego pliku HEVC, jednego pliku z wyłączonymi napisami, jednego pliku z włączonymi napisami, jednego pliku odtwarzanego w przeglądarce oraz jednego pliku odtwarzanego na telewizorze lub urządzeniu mobilnym.

Jeśli prosty plik pokazuje aktywność GPU, ale plik z napisami lub HDR powoduje skok użycia CPU, transkodowanie sprzętowe może działać, ale ta konkretna ścieżka ma etap obciążający CPU.

Gdy Docker jest prawdziwym wąskim gardłem

W konfiguracji Docker to, że host widzi GPU, nie oznacza, że kontener może go używać. Plex, Jellyfin, Emby lub Frigate mogą uruchomić się normalnie, pokazać działający interfejs i mimo to przełączyć się na CPU, ponieważ kontener nie ma odpowiedniego dostępu do urządzenia.

Dla ścieżek Intel Quick Sync lub VAAPI kluczowym urządzeniem jest często /dev/dri. Przewodnik Plex dotyczący akceleracji sprzętowej zauważa, że transkodowanie sprzętowe w Dockerze wymaga dodatkowej konfiguracji, a konfiguracje Plex Docker zwykle potrzebują przekazania odpowiedniego urządzenia jądra do kontenera dla Intel Quick Sync.

Dla systemów NVIDIA dostęp do GPU w Dockerze może wymagać --gpus, NVIDIA Container Toolkit, konfiguracji środowiska uruchomieniowego i możliwości sterownika. Dokumentacja NVIDIA Container Toolkit wyjaśnia dostęp do GPU w Dockerze przez opcje takie jak --gpus lub NVIDIA_VISIBLE_DEVICES, w zależności od konfiguracji środowiska uruchomieniowego.

Docker Compose ma własny model rezerwacji GPU. Oficjalny przewodnik Docker Compose dotyczący wsparcia GPU wyjaśnia, że usługi mogą rezerwować urządzenia GPU i że możliwości muszą być ustawione dla rezerwacji GPU. To część tego samego problemu z dostępem do urządzeń kontenera.

Sprawdź Dockera, gdy GPU gospodarza jest widoczne, ale panel serwera multimediów pokazuje transkodowanie programowe, gdy nvidia-smi działa na gospodarzu, ale nie wewnątrz kontenera, gdy /dev/dri istnieje na gospodarzu, ale brakuje go w kontenerze, lub gdy aktualizacja kontenera zmieniła uprawnienia, grupy, środowisko uruchomieniowe lub mapowanie urządzeń.

Kontenerowy serwer multimediów powinien potwierdzić dostęp do urządzenia z wnętrza kontenera, a nie tylko z gospodarza. W przeciwnym razie możesz debugować niewłaściwą warstwę.

Czystsza sekwencja testowa dla Plex, Jellyfin i Emby

Użyj jednej czystej sekwencji testowej zamiast zmieniać wiele ustawień naraz. Stabilna sekwencja ułatwia potwierdzenie sprzętowego transkodowania i jego debugowanie.

1. Wybierz plik wideo, który może wywołać transkodowanie.
2. Rozpocznij odtwarzanie na kliencie, gdzie możesz kontrolować jakość.
3. Obniż jakość odtwarzania, aby wymusić transkodowanie.
4. Otwórz panel serwera multimediów.
5. Potwierdź, że strumień mówi Transkodowanie, a nie Direct Play.
6. Sprawdź, czy panel kontrolny pokazuje (hw) lub metodę sprzętową.
7. Obserwuj aktywność silnika wideo GPU / iGPU gospodarza podczas strumienia.
8. Otwórz log transkodowania FFmpeg dla tej konkretnej sesji.
9. Sprawdź ścieżki sprzętowego kodeka lub awaryjne przejście na oprogramowanie.
10. Wyłącz napisy i przetestuj ponownie.
11. Zatrzymaj strumień i potwierdź spadek aktywności GPU.
12. Powtórz test z jednym innym kodekiem lub klientem dopiero po uzyskaniu jasnego wyniku pierwszego testu.

Ta sekwencja unika najczęstszej fałszywej diagnozy: zmiany jakości, napisów, typu klienta, ustawień sterownika i mapowania Dockera jednocześnie. Jeśli wynik się zmienia, powinieneś wiedzieć, która zmienna to spowodowała.

Jak wygląda udane sprzętowe transkodowanie

Udane sprzętowe transkodowanie to nie jeden zrzut ekranu. To zestaw sygnałów, które się ze sobą zgadzają.

Najsilniejszym dowodem jest dopasowanie tego samego aktywnego strumienia w panelu, metrykach hosta, logach i wyniku odtwarzania. Jeśli jedna warstwa się nie zgadza, uprość test przed zmianą ustawień.

Jak ta sama weryfikacja odnosi się do AI wideo i workflow kamer

To samo podejście do weryfikacji stosuje się poza Plex czy Jellyfin. AI wideo i workflow kamer mogą wyglądać na zainstalowane, podczas gdy faktyczna ścieżka sprzętowa, dostęp do urządzeń kontenera, punkt końcowy modelu, wyjście logów lub końcowy wynik analizy nie działają poprawnie.

Przykładem jest workflow AI kamery ZimaOS. Przewodnik ZimaSpace dotyczący Frigate i Ollama AI kamery pokazuje konfigurację, która może obejmować kamery RTSP, wykrywanie obiektów, lokalne punkty końcowe modeli, migawki, magazynowanie, mapowanie urządzeń, uprawnienia kontenerów i logi. W takim workflow instalowany interfejs użytkownika to tylko pierwsza warstwa; prawdziwym testem jest, czy strumienie docierają, kontener ma dostęp do właściwych urządzeń, punkt końcowy modelu odpowiada, logi pozostają czyste, a oczekiwany wynik wykrywania lub opisu się pojawia.

To nie to samo co sprzętowe transkodowanie Plex, ale zasada samodzielnego hostingu jest podobna: nie ufaj pojedynczemu ustawieniu. W przypadku zadań wideo zweryfikuj aktywny strumień, dostęp do urządzenia, logi, model lub ścieżkę enkodera oraz końcowy wynik.

Prywatna chmura lub domowy serwer, taki jak ZimaCube 2 AI NAS, może wspierać bardziej zaawansowane samodzielnie hostowane media i przepływy pracy AI wideo, gdy pamięć masowa, dostęp do GPU lub iGPU, kontenery i logi są traktowane jako jeden system. Ważną lekcją nie jest nazwa produktu, lecz wzorzec weryfikacji. Jeśli interfejs użytkownika pokazuje włączone, ale strumień, urządzenie, logi i wynik się nie zgadzają, obciążenie nie jest jeszcze w pełni zweryfikowane.

FAQ

Jak sprawdzić, czy sprzętowe transkodowanie Plex działa?

Wymuś transkodowanie Plex przez obniżenie jakości odtwarzania, następnie otwórz Plex Web App, przejdź do Panelu, rozwiń Teraz odtwarzane i poszukaj (hw) obok formatu wideo. Dla silniejszego potwierdzenia sprawdź także aktywność GPU hosta i logi transkodowania Plex.

Jak sprawdzić sprzętowe transkodowanie w Jellyfin?

Uruchom strumień wymagający transkodowania Jellyfin, a następnie otwórz informacje o odtwarzaniu lub szczegóły aktywnego strumienia. Poszukaj powodu transkodowania i metody przyspieszenia sprzętowego, takiej jak QSV, VAAPI, NVENC, AMF lub VideoToolbox. Jeśli panel sterowania jest niejasny, sprawdź aktywność GPU hosta i logi FFmpeg.

Dlaczego moje CPU jest nadal obciążone, gdy sprzętowe transkodowanie jest włączone?

Wykorzystanie CPU może pozostać wysokie, ponieważ przyspieszenie sprzętowe może obejmować tylko dekodowanie lub kodowanie wideo. Transkodowanie dźwięku, wypalanie napisów, remuxing, skalowanie, mapowanie tonów, operacje na plikach i niektóre filtry nadal mogą używać CPU. Sprawdź logi, zanim założysz, że sprzętowe transkodowanie zawiodło.

Co oznacza częściowe sprzętowe transkodowanie?

Częściowe sprzętowe transkodowanie oznacza, że tylko część procesu jest przyspieszana sprzętowo. Na przykład GPU może dekodować źródłowe wideo, podczas gdy CPU obsługuje napisy, dźwięk lub inny etap. Może to też oznaczać, że kodowanie sprzętowe jest aktywne, ale dekodowanie wróciło do trybu programowego.

Co powinienem sprawdzić, jeśli sprzętowe transkodowanie działa na hoście, ale nie w Dockerze?

Sprawdź dostęp do urządzenia w kontenerze. W przypadku Intel iGPU potwierdź, że /dev/dri jest przekazywany do kontenera. W przypadku NVIDIA sprawdź sterownik hosta, NVIDIA Container Toolkit, środowisko wykonawcze Dockera, dostęp --gpus oraz możliwości sterownika związane z wideo. Sprawdź także, czy użytkownik serwera multimediów w kontenerze ma uprawnienia do dostępu do urządzenia.

Sprzętowe transkodowanie działa tylko wtedy, gdy aktywny strumień rzeczywiście jest transkodowany, serwer multimediów zgłasza przyspieszenie sprzętowe, host pokazuje aktywność kodowania lub dekodowania wideo, a logi potwierdzają oczekiwaną ścieżkę sprzętową zamiast awaryjnego trybu programowego. Jeśli którykolwiek element się nie zgadza, przetestuj prostszy plik, zmniejsz liczbę zmiennych i zweryfikuj proces krok po kroku.