Pourquoi un serveur multimédia utilise-t-il beaucoup de CPU pendant la lecture ?

Une utilisation élevée du CPU pendant la lecture multimédia signifie généralement que le serveur fait plus que simplement envoyer le fichier original. Il peut décoder et réencoder la vidéo, incruster les sous-titres dans chaque image, convertir le HDR pour un client SDR, réduire la résolution ou créer un flux à débit réduit pour une connexion distante.

Cependant, un CPU élevé ne prouve pas automatiquement que le processeur est trop faible. L'accélération matérielle peut ne fonctionner que pour une partie du pipeline, une tâche d'analyse en arrière-plan peut s'exécuter en même temps, ou plusieurs sessions peuvent se disputer les mêmes ressources. La première étape est d'identifier le mode de lecture et le processus qui consomme réellement le CPU.

Vérifiez le mode de lecture avant de blâmer le matériel

Ouvrez le tableau de bord du serveur pendant que le flux problématique est actif. Plex, Jellyfin, Emby et des plateformes similaires montrent normalement si la session utilise la lecture directe, le flux direct ou le remux, la conversion audio ou un transcodage vidéo complet.

La lecture directe envoie le conteneur original, la vidéo, l'audio et les pistes de sous-titres prises en charge au client. Le remux ou le flux direct modifie seulement une partie du format de livraison, souvent sans ré-encoder la vidéo. Un transcodage vidéo décode la source et crée un nouveau flux vidéo, ce qui en fait la cause la plus probable d'une utilisation élevée et soutenue du CPU.

Cette distinction détermine le test suivant. Un CPU élevé lors d'un transcodage vidéo confirmé peut être attendu si le traitement est effectué en logiciel. Un CPU élevé lors d'une lecture directe indique généralement une autre session, une tâche d'analyse en arrière-plan ou un autre processus en cours sur le serveur.

Le transcodage vidéo logiciel est généralement la principale cause

Un serveur multimédia transcode la vidéo lorsque le client ne peut pas accepter la combinaison originale de codec, profil, résolution, débit, conteneur, audio ou sous-titres. Il peut aussi transcoder parce que l'utilisateur a choisi une qualité de lecture inférieure.

Le serveur doit décoder les images source, appliquer les filtres nécessaires, redimensionner ou convertir l’image, et encoder un nouveau flux assez rapidement pour rester en avance sur la lecture. Une source 4K HEVC convertie en H.264 de résolution inférieure demande beaucoup plus de traitement que la diffusion du fichier original.

Si toutes ces étapes s’exécutent sur des cœurs CPU polyvalents, une forte utilisation peut être normale. La question importante est de savoir si le transcodeur reste plus rapide que la lecture. Un processeur occupé avec une lecture fluide est différent d’un processeur saturé alors que le client met en tampon en boucle.

C’est souvent le client qui décide si le processeur est nécessaire

Le même fichier peut être lu directement sur une box de streaming et déclencher un transcodage complet dans un navigateur, une application télévisée, un téléphone ou un lecteur plus ancien. Chaque client supporte une combinaison différente de conteneurs, profils vidéo, profondeurs de bits, formats audio, sous-titres et débits maximums.

Même lorsque le codec vidéo est pris en charge, une piste audio ou un format de sous-titres incompatible peut modifier le chemin de lecture. Un client peut accepter la vidéo HEVC mais nécessiter la conversion de l’audio TrueHD, ou exiger un transcodage vidéo lorsque les sous-titres sélectionnés ne peuvent pas être rendus localement.

Comparez le même fichier sur deux clients en conservant la piste audio, la sélection des sous-titres et le réglage de qualité inchangés. Si la forte utilisation du processeur suit un client, concentrez-vous sur les capacités et les réglages de ce client avant de remplacer le matériel serveur.

Une qualité inférieure peut augmenter l’utilisation du processeur du serveur

Choisir un réglage de qualité inférieur peut sembler réduire la charge du serveur. En réalité, le serveur doit généralement créer un nouveau flux lorsque la résolution ou le débit demandé diffère de la source.

Par exemple, demander du 1080p à 8 Mbps à partir d’un fichier 4K à haut débit nécessite un décodage, un redimensionnement et un ré-encodage. Sélectionner la qualité Originale peut permettre la lecture directe lorsque le client supporte le format source et que le réseau peut gérer son débit.

Utilisez la qualité Originale comme test de diagnostic sur le réseau local. Ce n’est pas une solution universelle : un client avec des codecs incompatibles, une bande passante insuffisante ou des sous-titres non pris en charge peut toujours nécessiter une conversion.

L’incrustation des sous-titres peut transformer un flux léger en un flux lourd

Si l’utilisation du processeur augmente uniquement après l’activation des sous-titres, la piste de sous-titres sélectionnée est un suspect sérieux. Les sous-titres textuels comme le SRT sont souvent rendus par le client, tandis que les formats PGS et VobSub sont basés sur des images. Les formats ASS et SSA contiennent du texte mais peuvent inclure du style et du positionnement que certains clients ne peuvent pas reproduire.

Lorsque le client ne peut pas afficher la piste de sous-titres, le serveur peut les incruster dans l’image. Cela nécessite de décoder la vidéo, de composer les sous-titres sur chaque image, puis d’encoder un nouveau flux vidéo.

Plex a spécifiquement travaillé sur l'amélioration des performances d'incrustation des sous-titres pendant le transcodage matériel, avec des résultats dépendant du système d'exploitation, du type de GPU et de la présence ou non du mappage tonal dans la chaîne. C'est pourquoi le même test de sous-titres peut produire des utilisations CPU différentes selon les serveurs.

Testez la piste de sous-titres séparément

Rejouez la même scène avec les sous-titres désactivés. Si l'utilisation du CPU chute immédiatement et que la session revient en lecture directe, c'est le chemin des sous-titres — et non la vidéo source seule — qui cause le travail supplémentaire.

Ensuite, essayez une piste SRT externe, une autre langue de sous-titres ou un client avec un support plus large des sous-titres. Vérifiez également si le serveur signale une incrustation des sous-titres plutôt qu'une simple livraison.

Ne supposez pas que tous les formats de sous-titres ont le même coût. Une piste de texte stylée peut être facile pour un client et nécessiter un traitement vidéo complet sur un autre, tandis qu'un sous-titre image d'un Blu-ray peut être particulièrement difficile à livrer sans incrustation.

Un GPU fonctionnel ne signifie pas que toute la chaîne est accélérée

Il est possible de voir une activité GPU alors que le CPU reste élevé. L'accélération matérielle peut décoder et encoder la vidéo tandis que le CPU gère encore le rendu des sous-titres, la conversion audio, la mise à l'échelle, le mappage tonal ou un autre filtre.

Un cas de dépannage communautaire a montré un transcodage GPU fonctionnant parallèlement à une forte utilisation du CPU due à l'incrustation des sous-titres et à la conversion audio. Ce cas ne doit pas être considéré comme une règle fixe pour chaque version actuelle, mais il illustre pourquoi l'utilisation du GPU seule est une preuve incomplète.

Vérifiez à la fois les moteurs de décodage et d'encodage GPU, puis inspectez le journal du transcodeur pour les filtres logiciels. Comparez l'utilisation du CPU avec les sous-titres désactivés, une piste audio compatible sélectionnée et le mappage tonal retiré du test.

L'accélération matérielle peut revenir au logiciel

Une option d'accélération matérielle peut être activée dans l'interface du serveur même lorsque le pilote hôte, les permissions du périphérique, le runtime ou le codec sélectionné ne fonctionnent pas correctement.

Certains formats source peuvent utiliser le GPU avec succès tandis que d'autres reviennent au CPU. Un GPU peut prendre en charge H.264 et HEVC Main mais pas la profondeur de bits exacte, le format de chroma, la cible d'encodage ou le chemin de mappage tonal requis par un fichier particulier.

Forcez un transcodage connu et surveillez le serveur en temps réel. Confirmez que le décodeur et l’encodeur matériels sont actifs, inspectez la commande du transcodeur, et recherchez des échecs d’initialisation ou des messages de repli logiciel plutôt que de vous fier uniquement à la case cochée.

Docker ajoute une couche d’accès GPU distincte.

Lorsque le serveur média fonctionne dans Docker, détecter le GPU sur l’hôte ne prouve pas que l’application peut l’utiliser à l’intérieur du conteneur. Le conteneur a besoin du périphérique, des bibliothèques utilisateurs compatibles, du runtime correct et de la permission d’accéder aux fonctions vidéo.

Pour les déploiements NVIDIA, une séquence de validation utile consiste à confirmer d’abord le pilote hôte, vérifier que Docker reconnaît le runtime NVIDIA, contrôler que les bibliothèques et périphériques requis existent dans le conteneur, et observer l’activité de l’encodeur lors d’un transcodage forcé. Un conteneur où nvidia-smi Les exécutions peuvent toujours manquer de bibliothèques ou de capacités requises par le serveur média.

Une configuration Docker pratique doit donc vérifier le runtime NVIDIA, les bibliothèques utilisateurs, l’exposition des périphériques et l’activité de l’encodeur à l’intérieur du conteneur. Évitez d’utiliser le mode privilégié comme raccourci permanent ; exposez uniquement les ressources nécessaires au service.

Les machines virtuelles peuvent créer le même schéma d’échec.

Une machine virtuelle peut détecter un adaptateur d’affichage sans avoir accès aux fonctions matérielles d’encodage et de décodage nécessaires au transcodage média. Le passthrough GPU, les périphériques médiés, les pilotes et les permissions invité influencent tous le résultat.

Validez le GPU depuis le système d’exploitation invité puis depuis le processus du serveur média. L’activité GPU au niveau de l’hôte ne prouve pas que l’application invitée utilise le moteur prévu.

Si une installation native utilise l’accélération matérielle mais qu’une installation VM identique utilise beaucoup le CPU, comparez l’exposition des périphériques et les journaux avant de modifier les paramètres du codec ou de réencoder la bibliothèque.

La cartographie tonale HDR peut laisser un travail important au CPU.

Lorsque des médias HDR sont lus sur un écran SDR ou via un client qui ne peut pas accepter le flux HDR original, le serveur peut devoir effectuer une cartographie tonale en plus du transcodage normal.

Le pipeline peut inclure le décodage 10 bits, la conversion d’espace colorimétrique, la cartographie de la luminosité, la mise à l’échelle, la composition des sous-titres et l’encodage. Le support matériel du codec source ne garantit pas que chacune de ces étapes puisse rester sur le GPU.

Testez le même fichier sur un client compatible HDR, puis comparez-le avec une sortie SDR. Si les transcodages SDR ordinaires sont efficaces mais que les sessions HDR vers SDR utilisent beaucoup de CPU, examinez la méthode de mappage des tons et le support matériel plutôt que de traiter tous les médias 4K comme équivalents.

La conversion audio n’est généralement pas aussi lourde que le transcodage vidéo

TrueHD, DTS, audio multicanal ou un codec audio non pris en charge peuvent être convertis en un format que le client peut lire. Le serveur peut aussi réduire le son surround en stéréo.

Le transcodage audio consomme de la puissance de traitement, mais il est généralement plus léger que le décodage et le ré-encodage d’un flux vidéo complet. Le remuxing d’un conteneur préserve aussi le flux vidéo et nécessite normalement beaucoup moins de calcul que la conversion vidéo.

Si le tableau de bord indique uniquement un transcodage audio alors que le CPU reste proche de sa limite, vérifiez le traitement des sous-titres, l’analyse en arrière-plan, une autre session active ou un processus de transcodage séparé. Ne supposez pas que l’étiquette audio visible explique toute la charge de travail.

La lecture directe avec un CPU élevé signifie généralement qu’une autre tâche est en cours

La lecture directe nécessite toujours des lectures de fichiers, une authentification, une logique d’application et une livraison réseau, donc l’utilisation du CPU ne sera pas exactement nulle. Elle ne devrait normalement pas nécessiter le traitement vidéo lourd associé à un transcodage logiciel.

Plex peut consommer beaucoup de CPU pour la détection d’intro et de générique, les vignettes d’aperçu, l’analyse vocale, la détection de publicités, l’optimisation des médias et la préparation des téléchargements. Certains de ces travaux invoquent le transcodeur même lorsque personne ne regarde activement les médias.

Vérifiez la liste des processus du système d’exploitation plutôt que seulement le graphique total du CPU. Identifiez si le transcodeur du flux actuel, un processus d’analyse programmée, un scanner de bibliothèque ou un conteneur non lié est responsable.

L’analyse programmée peut ressembler à une charge de lecture

Un travail en arrière-plan peut commencer au même moment où quelqu’un commence à regarder, donnant l’impression que la lecture elle-même a causé le pic de CPU. Les fenêtres de maintenance ont souvent lieu la nuit ou peu après l’ajout de nouveau contenu.

Une discussion sur Unraid a attribué apparemment la charge CPU au repos à une analyse programmée des médias puis à la détection d’intro et de générique. Il s’agit d’un exemple communautaire et non d’une preuve que chaque cas de charge au repos a la même cause.

Mettez temporairement en pause la génération de prévisualisation, la détection d’intro, la détection de générique, l’optimisation et l’analyse approfondie des médias. Si l’utilisation du CPU diminue sans changer le flux actif, déplacez ces tâches vers une autre fenêtre de maintenance au lieu de modifier les paramètres de lecture.

Plusieurs flux multiplient différents types de travail

Une session de lecture directe ajoute principalement une demande de stockage et réseau. Un transcodage audio ajoute une tâche de conversion plus petite. Un transcodage vidéo 4K logiciel peut consommer beaucoup plus de ressources que plusieurs flux directs.

Quand un autre utilisateur démarre la lecture, inspectez chaque session individuellement. Deux utilisateurs ne créent pas forcément deux fois la même charge : l’un peut lire directement tandis que l’autre incruste des sous-titres dans un transcodage HDR.

Ajoutez des sessions de test une par une tout en surveillant le CPU, GPU, réseau, latence disque et vitesse de transcodage. Cela révèle si la limite pratique est l’encodage logiciel, la capacité de l’encodeur matériel, la contention du stockage ou la bande passante globale.

La TV en direct peut nécessiter un traitement supplémentaire

La TV en direct peut arriver dans un codec, une résolution, un format entrelacé ou un débit que le client de lecture ne peut pas accepter directement. Le serveur peut devoir désentrelacer, convertir la vidéo, changer l’audio ou créer un flux à débit réduit.

Ces opérations peuvent rendre la lecture en direct plus gourmande en CPU qu’un film ordinaire lu directement. L’enregistrement et l’analyse publicitaire peuvent aussi s’exécuter en parallèle, ajoutant du travail serveur.

Vérifiez séparément le codec source de la session en direct, le statut de désentrelacement, le mode de lecture et la qualité sélectionnée par rapport à la bibliothèque de médias stockés. Un problème de TV en direct ne prouve pas que tous les fichiers locaux nécessitent le même matériel.

La lecture à distance force souvent un nouveau débit binaire

Un fichier à débit élevé peut être lu directement sur le réseau local domestique mais dépasser la vitesse d'upload internet disponible du serveur. Le client distant ou la limite serveur demande alors un flux plus petit.

Réduire le débit binaire signifie normalement que le serveur doit créer une nouvelle sortie vidéo. L'utilisation du processeur peut donc augmenter pendant la lecture à distance même si le même client utilise peu de ressources serveur à domicile.

Comparez le débit binaire source avec la capacité d'upload durable et le réglage de qualité à distance du client. Si la réduction du flux crée un transcodage logiciel, une accélération matérielle correctement configurée ou une version pré-encodée à distance peut réduire la demande CPU.

Un pic bref de CPU peut être normal

Certains transcodeurs travaillent en avance sur la position de lecture pour créer un tampon. L'utilisation du processeur peut augmenter brusquement au début, diminuer lorsque suffisamment de segments ont été produits, puis augmenter à nouveau lorsque plus de sortie est nécessaire.

Un pic bref avec une lecture fluide et des températures stables ne nécessite pas forcément de correction. Une utilisation maximale soutenue, une baisse de la vitesse de transcodage, des mises en mémoire tampon répétées ou un bridage thermique indiquent un problème de capacité plus sérieux.

Observer la charge sur plusieurs minutes plutôt que de se fier à une seule capture d'écran CPU. Enregistrer si le processeur reste bloqué, si le transcodeur reste en avance, et si la fréquence du serveur baisse avec l'augmentation de la température.

Ne pas réencoder toute la bibliothèque en premier

Convertir chaque fichier en un format largement supporté peut réduire la transcodification en temps réel future, mais cela nécessite du temps, un stockage supplémentaire et une étape d'encodage avec perte supplémentaire pour de nombreuses sources.

Cela peut aussi ne pas résoudre la cause réelle si la forte utilisation CPU provient de l'incrustation des sous-titres, du mappage tonal HDR, des limites de débit à distance, de l'analyse en arrière-plan ou d'un accès GPU défaillant dans Docker.

Identifier d'abord les combinaisons qui échouent régulièrement sur les clients que vous utilisez réellement. Créez des copies optimisées uniquement pour les médias à problèmes fréquents, ou utilisez un client plus performant lorsque cela est plus simple que de maintenir plusieurs versions de la bibliothèque.

Utiliser cet ordre de dépannage

1. Reproduire la session à forte utilisation CPU avec le même fichier et client.
2. Enregistrer s'il s'agit de lecture directe, remux, transcodage audio ou vidéo.
3. Identifier le processus exact consommant le CPU.
4. Enregistrer la raison indiquée pour la conversion.
5. Tester la qualité originale sur le réseau local.
6. Désactiver les sous-titres et sélectionner une autre piste audio.
7. Lire le même fichier sur un autre client.
8. Surveiller les moteurs de décodage et d'encodage GPU.
9. Inspecter le journal du transcodeur ou de FFmpeg pour un retour au logiciel.
10. Vérifier l'accès au GPU depuis Docker ou la machine virtuelle.
11. Mettre en pause l'analyse des médias, la génération d'aperçus et les tâches d'optimisation.
12. Ajouter les flux supplémentaires un par un.
13. Vérifier la température et la fréquence du CPU.
14. Mettre à niveau le matériel uniquement après confirmation du goulot d'étranglement.

Conclusion finale

Une forte utilisation du CPU pendant la lecture est généralement le résultat d’une décision de traitement, pas un diagnostic en soi. Le transcodage vidéo logiciel complet est la cause la plus fréquente, mais l’incrustation des sous-titres, la cartographie des tons HDR, l’accélération matérielle partielle, les limites de qualité à distance et les sessions simultanées peuvent créer une charge similaire.

Commencez par identifier le mode de lecture et le processus exact utilisant le CPU. Si la session est en transcodage, testez la compatibilité du client, la qualité originale, les sous-titres, les pistes audio et la chaîne complète d’accélération matérielle. Si c’est une lecture directe, inspectez l’analyse en arrière-plan et les autres tâches actives.

Mettez à niveau le serveur uniquement après que les journaux et des tests contrôlés montrent que le traitement en temps réel requis dépasse la capacité de calcul disponible. De nombreux cas de forte utilisation du CPU peuvent être résolus en modifiant le chemin de lecture, en corrigeant l’accès GPU dans Docker, en programmant l’analyse en dehors des heures de visionnage ou en choisissant un client capable de lire directement le média original.

FAQ

Pourquoi l’utilisation du CPU augmente-t-elle lorsque les sous-titres sont activés ?

Le client peut être incapable d’afficher le format de sous-titres sélectionné. Le serveur incruste alors les sous-titres dans chaque image vidéo, ce qui nécessite de décoder et réencoder la vidéo. Testez avec les sous-titres désactivés ou sélectionnez une piste textuelle prise en charge.

Pourquoi le CPU reste-t-il élevé lorsque le transcodage matériel est activé ?

Le GPU peut n’accélérer que le décodage et l’encodage vidéo tandis que le CPU gère les sous-titres, l’audio, la cartographie des tons, le redimensionnement ou un autre filtre. L’accès matériel peut aussi être incomplet dans Docker ou une machine virtuelle.

La lecture directe n’utilise-t-elle pas de CPU ?

Non. La lecture directe nécessite toujours l’accès au fichier, le réseau, l’authentification et le traitement par l’application. Elle devrait normalement utiliser beaucoup moins de CPU que le transcodage vidéo, donc une charge élevée et soutenue doit inciter à vérifier les tâches en arrière-plan ou un autre processus.

Pourquoi la réduction de la qualité de streaming augmente-t-elle l’utilisation du CPU ?

Une résolution ou un débit inférieur nécessite généralement que le serveur crée un nouveau flux vidéo. Si le fichier original pouvait être lu directement, la sélection d’une qualité inférieure transforme la session en transcodage et augmente le traitement du serveur.

Le scan des médias peut-il provoquer une forte utilisation du CPU pendant la lecture d’un film ?

Oui. La génération de vignettes d’aperçu, la détection d’introduction ou de crédits, l’optimisation, l’analyse vocale et d’autres tâches en arrière-plan peuvent s’exécuter en même temps que la lecture. Vérifiez la liste des processus et l’état des tâches planifiées avant d’attribuer toute l’utilisation du CPU au flux actif.