Comment vérifier si le transcodage matériel fonctionne réellement

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Check If Hardware Transcoding Is Actually Working - Zima Store Online

Activer le transcodage matériel n'est pas la même chose que prouver que le transcodage matériel fonctionne. Un serveur multimédia peut avoir ce paramètre activé, mais le flux actuel peut toujours être lu directement, basculer vers un transcodage logiciel, utiliser le matériel pour seulement une partie du pipeline, ou ne pas réussir à accéder au GPU dans Docker.

La manière la plus sûre de vérifier est de suivre le même flux actif sous plusieurs angles : forcer un transcodage réel, lire le tableau de bord du serveur multimédia, confirmer l'activité GPU ou iGPU au niveau de l'hôte, inspecter les journaux FFmpeg lorsque le résultat est incertain, et vérifier que le client reçoit la sortie de lecture attendue.

Le paramètre ne donne que l'autorisation, pas la preuve

Un paramètre de transcodage matériel est une autorisation, pas un résultat de test. Il indique à Plex, Jellyfin, Emby ou un autre serveur multimédia qu'il peut utiliser l'accélération matérielle lorsque le flux, le codec, le pilote, l'accès au périphérique et les conditions de lecture sont réunis. Cela ne prouve pas que le flux que vous regardez actuellement utilise le GPU.

Plex décrit le streaming accéléré par matériel comme un moyen pour Plex Media Server d'utiliser un matériel dédié de décodage et d'encodage vidéo lors de la conversion vidéo, ce qui peut réduire la charge de transcodage intensive sur le CPU. Mais Plex note aussi que le repli logiciel peut se produire lorsque l'accélération matérielle n'est pas disponible ou compatible avec un chemin vidéo donné.

Cette distinction est importante car un serveur multimédia peut afficher une page de configuration saine alors que la session active fait autre chose. Le fichier peut être lu directement. Le serveur peut ne transcoder que l'audio. La vidéo peut être décodée par le matériel mais encodée par logiciel. Ou le conteneur peut ne pas avoir accès au périphérique que le système d'exploitation hôte peut voir.

Un processus de vérification fiable doit répondre à cinq questions : le flux est-il réellement en train d'être transcodé, le tableau de bord affiche-t-il l'accélération matérielle, l'hôte montre-t-il une activité d'encodage ou de décodage vidéo, les journaux FFmpeg indiquent-ils un chemin matériel, et le résultat de la lecture côté client correspond-il à la résolution, au débit, au codec ou au comportement des sous-titres attendus ?

Si ces couches sont d'accord, le transcodage matériel fonctionne probablement. S'il y a un conflit, la réponse n'est pas simplement que le paramètre est cassé ou que le tableau de bord est erroné. La meilleure réponse est de trouver quelle couche du pipeline a changé.

Faites d'abord en sorte que le flux soit réellement transcodé

Avant de vérifier l'utilisation du GPU, assurez-vous que le serveur multimédia effectue un transcodage réel. Si le fichier est lu directement, le serveur envoie principalement le flux original au client. Dans ce cas, une faible utilisation du CPU et du GPU est normale.

Un flux de test contrôlé doit forcer le serveur à convertir quelque chose. Vous pouvez généralement le faire en réduisant la qualité de lecture, en utilisant un navigateur ou un client qui ne supporte pas le codec source, en définissant une limite de débit à distance, en activant des sous-titres nécessitant une incrustation, ou en choisissant un fichier à débit élevé qui doit être réduit pour le client.

Pour Plex, un test simple consiste à démarrer une vidéo et à réduire la qualité de lecture pour que Plex doive convertir le flux. Le guide de Plex décrit comment baisser la qualité vidéo, par exemple en forçant une conversion en 480p, puis en vérifiant les détails de lecture du tableau de bord Plex pour l'indicateur d'accélération matérielle.

Pour Jellyfin ou Emby, le même test de lecture contrôlé s'applique. Commencez avec un fichier que le client ne peut pas lire directement, ou réglez manuellement une qualité de lecture inférieure. Ensuite, ouvrez les informations de lecture, les détails du flux actif ou les diagnostics du flux pour confirmer si la session est en lecture directe, en streaming direct ou en transcodage.

N'utilisez pas un fichier aléatoire comme seul test de transcodage matériel. Un film qui se lit directement parfaitement sur une TV peut ne jamais passer par le transcodeur, alors que le même fichier peut être transcodé dans un navigateur, via un accès à distance, en données mobiles ou avec les sous-titres activés. Le fichier de test doit créer une condition claire avant et après.

Le tableau de bord est le premier indice

Le tableau de bord du serveur multimédia est le premier indice utile car il relie la session de lecture active à l'interprétation de ce flux par le serveur. Mais ce n'est qu'un indice du tableau de bord, pas la preuve complète.

Plex : Recherchez le décodage et l'encodage matériel

Dans Plex, lancez un flux que vous savez être en cours de transcodage, puis ouvrez le tableau de bord Web et développez les détails de la lecture en cours. Plex indique que lorsque l'accélération matérielle est utilisée, vous devriez voir (hw) à côté du format vidéo dans les détails de lecture étendus.

Un signal fort de Plex ressemble à une ligne de transcodage avec (hw) attaché au chemin vidéo. Selon le fichier source, le matériel, le système d'exploitation et la version de Plex, le matériel peut être impliqué dans le décodage, l'encodage ou les deux. L'étape importante est d'étendre les détails du flux au lieu de se contenter de regarder la carte principale Maintenant en lecture.

Si Plex affiche Lecture directe, le transcodage matériel ne devrait pas apparaître. Si Plex affiche Transcodage mais pas de (hw), le flux peut utiliser un transcodage logiciel. Si Plex affiche (hw) mais que le CPU est toujours actif, cela ne signifie pas automatiquement un échec ; le transcodage audio, les sous-titres, le remuxing, la cartographie tonale et d'autres étapes peuvent encore utiliser le CPU.

Jellyfin et Emby : vérifiez les détails du flux

Dans Jellyfin, vérifiez le flux actif ou les informations de lecture pour la raison du transcodage et la méthode d'accélération matérielle. La documentation de Jellyfin sur la méthode d'accélération matérielle explique que Jellyfin utilise un transcodeur FFmpeg modifié et peut utiliser des GPU intégrés ou discrets via des méthodes telles que Intel QSV, NVIDIA NVDEC / NVENC, AMD AMF, VA-API, VideoToolbox et d'autres chemins spécifiques à la plateforme.

La question utile n'est pas seulement de savoir s'il y a transcodage, mais quelle méthode est utilisée. Si les détails de lecture montrent QSV, VAAPI, NVENC, AMF ou VideoToolbox, c'est un signe plus fort qu'une étiquette générique de transcodage. Si les détails du flux montrent uniquement un transcodage logiciel, le GPU ne gère probablement pas ce flux.

Les vérifications du tableau de bord sont particulièrement utiles lorsqu'elles sont associées à une question supplémentaire : pourquoi le serveur effectue-t-il un transcodage ? Un décalage de codec, une limite de débit, un incrustation de sous-titres, une cartographie tonale HDR, un flux audio non pris en charge ou un réglage de qualité à distance peuvent chacun déclencher une pipeline différente. C'est pourquoi deux fichiers peuvent se comporter différemment sur le même serveur.

L'activité GPU de l'hôte est la deuxième couche de preuve

La couche suivante est l'activité GPU au niveau de l'hôte. Si le GPU ou iGPU aide réellement à un transcodage en direct, l'hôte devrait généralement montrer une activité dans le moteur d'encodage ou de décodage vidéo pendant que le flux est en cours.

Cette couche est importante car les tableaux de bord peuvent être simplifiés. Un tableau de bord peut montrer l'implication du matériel sans expliquer quelle étape est accélérée. L'hôte peut indiquer si le moteur vidéo s'active lorsque le flux commence et se calme lorsque le flux s'arrête.

NVIDIA : Surveillez le moteur vidéo, pas seulement l'utilisation du GPU

Pour les systèmes NVIDIA, utilisez nvidia-smi pendant que le transcodage test est en cours. Cherchez le processus serveur multimédia ou transcodeur, l'utilisation de la mémoire GPU, et l'activité de l'encodeur / décodeur. La documentation NVIDIA inclut l'utilisation de l'encodeur et du décodeur, et la surveillance des processus peut montrer l'utilisation GPU par processus.

Une vérification NVIDIA basique est :

nvidia-smi

Pour une vue de surveillance plus active, utilisez :

nvidia-smi dmon

L'erreur courante est de ne regarder qu'un pourcentage général du GPU. Le transcodage vidéo ne ressemble pas forcément au rendu 3D, au jeu ou au calcul IA. Cherchez spécifiquement l'activité d'encodage / décodage vidéo, le processus serveur multimédia concerné, et si le timing correspond au flux actif.

Intel Quick Sync : Confirmer que l'iGPU est réellement occupé

Pour les systèmes Intel iGPU / Quick Sync sous Linux, intel_gpu_top est souvent l'outil le plus clair. Lancez le transcodage forcé, puis observez si le moteur vidéo montre une activité. Si le tableau de bord du serveur multimédia indique que l'accélération matérielle est active mais que le moteur vidéo Intel reste inactif, le serveur peut utiliser le mauvais appareil, manquer de permissions ou revenir au logiciel.

Vous pouvez également vérifier si Linux détecte le périphérique graphique :

lspci -nn | grep -Ei "3d|affichage|vga"

La documentation de Jellyfin sur l'accélération matérielle oriente les utilisateurs vers des vérifications spécifiques au matériel avant de choisir une méthode d'accélération, car le chemin d'accélération disponible dépend de l'appareil, du pilote et du support de la plateforme.

AMD : Faire correspondre l'activité GPU au flux actif

Pour les systèmes AMD, l'outil de surveillance exact dépend du système d'exploitation et de la pile de pilotes. Sous Linux, les utilisateurs vérifient souvent l'activité liée à VAAPI / AMF avec des outils tels que radeontop ou les tableaux de bord de la plateforme. La logique de vérification est la même : lancer un transcodage forcé, observer l'activité GPU liée à la vidéo, puis arrêter le flux et voir si l'activité diminue.

Ne vous attendez pas à ce que chaque outil étiquette l'accélération vidéo de la même manière. La question pratique est de savoir si une activité apparaît pendant ce flux précis et si le timing correspond au tableau de bord du serveur multimédia.

Les journaux FFmpeg montrent le chemin réel du transcodage

Lorsque le tableau de bord et les métriques de l'hôte ne concordent pas, les journaux FFmpeg sont généralement le prochain endroit à vérifier. La plupart des serveurs multimédias s'appuient sur FFmpeg ou une version modifiée de FFmpeg pour le transcodage, donc les journaux peuvent indiquer si le flux a utilisé un chemin matériel, est passé au logiciel, ou n'a pas pu accéder à un appareil.

Dans les journaux, les chemins matériels peuvent inclure des noms tels que :

h264_nvenc
hevc_nvenc
h264_qsv
hevc_qsv
h264_vaapi
hevc_vaapi

Les chemins d’encodage logiciel incluent souvent :

libx264
libx265

La documentation de FFmpeg décrit les options de chemin d’accélération matérielle FFmpeg pour le décodage des flux correspondants, avec des méthodes telles que vaapi, qsv, d3d11va, dxva2 et videotoolbox. Elle explique aussi que la disponibilité réelle dépend de la méthode choisie, du support du décodeur, du matériel et de l’environnement des pilotes.

Cette distinction est importante. Voir que FFmpeg a été compilé avec une méthode d’accélération matérielle ne prouve pas que le flux actuel l’a utilisée. Le journal doit montrer le chemin réel du codec, l’accès au périphérique et si FFmpeg est passé silencieusement à un encodage logiciel.

Voir des chemins d’encodage logiciel tels que libx264 ou libx265 dans un journal de transcodage d’un serveur média est souvent un fort indice d’un retour logiciel libx264 ou d’un encodage logiciel, surtout lorsque vous attendiez NVENC, QSV, VAAPI, AMF ou VideoToolbox.

Utilisez les journaux lorsque les preuves du tableau de bord et les métriques de l’hôte divergent, lorsque Docker ou les permissions ont récemment changé, lorsqu’un codec fonctionne mais pas un autre, lorsque les sous-titres ou le mappage de tons HDR modifient le résultat, ou lorsque le flux démarre, met en mémoire tampon, échoue ou bascule silencieusement vers un transcodage logiciel.

L’encodage matériel partiel est normal

L’encodage matériel n’est pas toujours tout ou rien. Un flux peut utiliser un décodage matériel mais un encodage logiciel, ou un encodage matériel mais un décodage logiciel. Il peut aussi utiliser l’accélération GPU pour la vidéo tandis que l’audio, les sous-titres, la mise à l’échelle, le remuxing ou le mappage de tons utilisent encore le CPU.

La documentation de Jellyfin est utile ici car elle décompose les étapes du pipeline de transcodage en décodage vidéo, désentrelacement, mise à l’échelle / conversion de format, mappage de tons HDR / DV, incrustation de sous-titres, encodage vidéo et copie zéro. Elle note également que certaines étapes peuvent ne pas être accélérées par GPU en raison de limitations logicielles, matérielles ou de pilotes.

La bonne question n'est donc pas de savoir si le CPU est à zéro. Un meilleur contrôle du transcodage matériel consiste à vérifier si le décodage vidéo se fait sur le matériel, si l'encodage vidéo se fait sur le matériel, si l'utilisation du CPU s'explique par l'audio ou les sous-titres, si la lecture s'améliore par rapport au transcodage uniquement logiciel, et si les journaux montrent un chemin matériel ou un retour au logiciel.

Une accélération partielle peut toujours être un résultat réussi si l'étape vidéo lourde est déchargée et que le travail CPU restant est attendu. Cela devient un problème lorsque le serveur revient au logiciel pour l'étape que vous attendiez du GPU.

Pourquoi l'utilisation du CPU peut encore sembler élevée

Une utilisation élevée du CPU ne signifie pas automatiquement que le transcodage matériel a échoué. L'encodage et le décodage vidéo ne sont qu'une partie du pipeline de lecture. Le CPU peut encore gérer le transcodage audio, l'incrustation des sous-titres, le remuxing du conteneur, les entrées/sorties de fichiers, le redimensionnement, les tâches de métadonnées, la surcharge réseau ou certaines parties du mappage tonal HDR.

Les sous-titres sont un exemple courant. Si le client ne peut pas gérer directement un format de sous-titres, le serveur peut incruster les sous-titres dans la vidéo. Cela peut modifier le chemin de transcodage et ajouter du travail supplémentaire au CPU. L'audio est un autre exemple : l'accélération vidéo matérielle ne signifie généralement pas que le GPU transcode l'audio.

Une bonne façon d'isoler l'étape gourmande en CPU est de tester plusieurs fichiers contrôlés : un fichier H.264 simple sans sous-titres, un fichier HEVC, un fichier avec sous-titres désactivés, un fichier avec sous-titres activés, un fichier lu dans un navigateur, et un fichier lu sur une TV ou un client mobile.

Si le fichier simple montre une activité GPU mais que le fichier avec sous-titres ou HDR fait grimper le CPU, le transcodage matériel peut fonctionner, mais cette étape spécifique est gourmande en CPU.

Quand Docker est le vrai goulot d'étranglement

Dans une configuration Docker, le fait que l'hôte détecte le GPU ne prouve pas que le conteneur peut l'utiliser. Plex, Jellyfin, Emby ou Frigate peuvent démarrer normalement, afficher une interface saine, et pourtant revenir au CPU parce que le conteneur n'a pas le bon accès au périphérique.

Pour les chemins Intel Quick Sync ou VAAPI, le périphérique clé est souvent /dev/dri. Le guide d'accélération matérielle de Plex indique que le transcodage matériel sous Docker nécessite une configuration supplémentaire, et les configurations Plex Docker ont souvent besoin que le périphérique noyau pertinent soit passé dans le conteneur pour Intel Quick Sync.

Pour les systèmes NVIDIA, l’accès GPU Docker peut impliquer --gpus, NVIDIA Container Toolkit, la configuration du runtime et les capacités du pilote. La documentation du NVIDIA Container Toolkit explique l’accès GPU Docker via des options telles que --gpus ou NVIDIA_VISIBLE_DEVICES, selon la configuration du runtime.

Docker Compose a son propre modèle de réservation GPU. Le guide officiel de Docker Compose pour le support GPU explique que les services peuvent réserver des périphériques GPU et que les capacités doivent être définies pour ces réservations GPU. Cela fait partie du même problème d’accès aux périphériques du conteneur.

Vérifiez Docker lorsque le GPU de l’hôte est visible mais que le tableau de bord du serveur multimédia montre un transcodage logiciel, lorsque nvidia-smi fonctionne sur l’hôte mais pas à l’intérieur du conteneur, lorsque /dev/dri existe sur l’hôte mais est absent dans le conteneur, ou lorsqu’une mise à jour du conteneur a modifié les permissions, groupes, runtime ou mappage des périphériques.

Un serveur multimédia conteneurisé doit prouver l’accès au périphérique depuis l’intérieur du conteneur, pas seulement depuis l’hôte. Sinon, vous risquez de déboguer le mauvais niveau.

Une séquence de test plus propre pour Plex, Jellyfin et Emby

Utilisez une seule séquence de test propre au lieu de changer plusieurs paramètres à la fois. Une séquence stable facilite la preuve du transcodage matériel et son débogage.

Choisissez un fichier vidéo qui peut déclencher un transcodage.
Lancez la lecture sur un client où vous pouvez contrôler la qualité.
Réduisez la qualité de lecture pour forcer un transcodage.
Ouvrez le tableau de bord du serveur multimédia.
Confirmez que le flux indique Transcodage, pas Lecture Directe.
Vérifiez si le tableau de bord affiche (hw) ou une méthode matérielle.
Surveillez l’activité du moteur vidéo GPU / iGPU de l’hôte pendant le flux.
Ouvrez le journal de transcodage FFmpeg pour cette session exacte.
Cherchez les chemins du codec matériel ou le repli logiciel.
Désactivez les sous-titres et testez à nouveau.
Arrêtez le flux et confirmez que l’activité GPU diminue.
Répétez avec un seul codec ou client différent seulement après que le premier test soit clair.

Cette séquence évite le faux diagnostic le plus courant : changer la qualité, les sous-titres, le type de client, les paramètres du pilote et le mappage Docker en même temps. Si le résultat change, vous devez savoir quelle variable en est la cause.

À quoi ressemble un transcodage matériel réussi

Un transcodage matériel réussi ne se résume pas à une capture d'écran. C'est un ensemble de signaux qui concordent.

Signal	Bon signe	Ce que cela prouve
Statut du flux	Transcodage, pas lecture directe	Il y a un vrai travail de transcodage à vérifier.
Tableau de bord	`(hw)` ou une méthode matérielle nommée apparaît	Le serveur média rapporte l'accélération matérielle pour le flux actif.
Métriques de l'hôte	Le moteur d'encodage/décodage vidéo devient actif	Le GPU ou iGPU est impliqué au niveau de l'hôte.
Journal FFmpeg	Un chemin NVENC, QSV, VAAPI, AMF ou VideoToolbox apparaît	Le transcodeur a utilisé un chemin matériel pour au moins une partie du pipeline.
Comportement du CPU	Le CPU reste compréhensible, pas saturé comme lors d'un transcodage logiciel complet	L'audio, les sous-titres, le remuxing ou le tone mapping peuvent encore utiliser le CPU.
Accès Docker	Le conteneur peut voir le GPU ou iGPU nécessaire	L'application a accès aux appareils, pas seulement l'hôte.
Résultat client	Résolution, débit, codec et comportement des sous-titres attendus	La sortie correspond à l'objectif du test.

La preuve la plus forte vient de la correspondance du même flux actif entre le tableau de bord, les métriques de l'hôte, les journaux et le résultat de lecture. Si une couche est en désaccord, simplifiez le test avant de modifier les paramètres.

Comment la même vérification s'applique aux flux IA vidéo et caméra

La même mentalité de vérification s'applique au-delà de Plex ou Jellyfin. Les flux IA vidéo et caméra peuvent aussi sembler installés alors que le chemin matériel réel, l'accès aux appareils du conteneur, le point de terminaison du modèle, la sortie des journaux ou le résultat final de l'analyse ne fonctionnent pas correctement.

Un flux de travail IA caméra ZimaOS est un exemple utile. Le guide ZimaSpace pour Frigate et Ollama IA caméra montre une configuration pouvant impliquer des caméras RTSP, la détection d'objets, des points de terminaison de modèles locaux, des instantanés, le stockage, le mappage des appareils, les permissions des conteneurs et les journaux. Dans ce type de flux, l'interface installée n'est que la première couche ; la vraie vérification est de savoir si les flux arrivent, si le conteneur peut accéder aux bons appareils, si le point de terminaison du modèle répond, si les journaux restent propres, et si la sortie attendue de détection ou de description apparaît.

Ce n'est pas la même chose que le transcodage matériel Plex, mais la règle d'auto-hébergement est similaire : ne faites pas confiance à un seul paramètre. Pour les charges vidéo, vérifiez le flux actif, l'accès aux appareils, les journaux, le modèle ou le chemin de l'encodeur, et la sortie finale.

Une configuration de cloud privé ou de serveur domestique telle que ZimaCube 2 AI NAS peut prendre en charge des flux multimédias auto-hébergés et des workflows vidéo IA plus riches lorsque le stockage, l’accès GPU ou iGPU, les conteneurs et les journaux sont considérés comme un système unique. La leçon importante n’est pas le nom du produit ; c’est le modèle de vérification. Si l’interface indique activé mais que le flux, le périphérique, les journaux et la sortie ne sont pas d’accord, la charge de travail n’est pas encore entièrement vérifiée.

FAQ

Comment savoir si le transcodage matériel Plex fonctionne ?

Forcez un transcodage Plex en réduisant la qualité de lecture, puis ouvrez l’application Web Plex, allez dans le tableau de bord, développez la section Lecture en cours et cherchez (hw) à côté du format vidéo. Pour une preuve plus solide, vérifiez également l’activité GPU de l’hôte et les journaux de transcodage Plex.

Comment vérifier le transcodage matériel dans Jellyfin ?

Démarrez un flux nécessitant un transcodage Jellyfin, puis ouvrez les informations de lecture ou les détails du flux actif. Recherchez la raison du transcodage et la méthode d'accélération matérielle, comme QSV, VAAPI, NVENC, AMF ou VideoToolbox. Si le tableau de bord n’est pas clair, vérifiez l’activité GPU de l’hôte et les journaux FFmpeg.

Pourquoi mon CPU reste-t-il élevé alors que le transcodage matériel est activé ?

L'utilisation du CPU peut rester élevée car l'accélération matérielle peut ne couvrir que le décodage ou l'encodage vidéo. Le transcodage audio, l'incrustation des sous-titres, le remuxing, le redimensionnement, la cartographie des tons, les entrées/sorties de fichiers et certains filtres peuvent toujours utiliser le CPU. Vérifiez les journaux avant de supposer que le transcodage matériel a échoué.

Que signifie le transcodage matériel partiel ?

Le transcodage matériel partiel signifie que seule une partie de la chaîne est accélérée. Par exemple, le GPU peut décoder la vidéo source tandis que le CPU gère les sous-titres, l'audio ou une autre étape. Cela peut aussi signifier que l'encodage matériel est actif mais que le décodage est revenu au logiciel.

Que dois-je vérifier si le transcodage matériel fonctionne sur l'hôte mais pas dans Docker ?

Vérifiez l'accès au périphérique du conteneur. Pour un iGPU Intel, confirmez que /dev/dri est bien passé dans le conteneur. Pour NVIDIA, vérifiez le pilote hôte, le NVIDIA Container Toolkit, le runtime Docker, l'accès --gpus et les capacités du pilote liées à la vidéo. Vérifiez également si l'utilisateur du serveur multimédia à l'intérieur du conteneur a la permission d'accéder au périphérique.

Le transcodage matériel ne fonctionne que lorsque le flux actif est réellement en cours de transcodage, que le serveur multimédia signale l'accélération matérielle, que l'hôte affiche une activité d'encodage ou de décodage vidéo, et que les journaux confirment le chemin matériel attendu au lieu d'un repli logiciel. Si un élément ne correspond pas, testez avec un fichier plus simple, réduisez les variables et vérifiez la chaîne de traitement étape par étape.