Pourquoi Plex utilise-t-il davantage de mémoire GPU en cas de concurrence entre clients mixtes ?

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.

Plex utilise davantage de mémoire GPU avec une concurrence entre clients différents lorsque des sessions simultanées nécessitent de conserver en mémoire leurs espaces de travail distincts pour le décodage, la transformation et l’encodage.

La variable importante n’est pas simplement le nombre de spectateurs. Une conversion H.264 en 1080p, une conversion HEVC HDR en 4K et une session en lecture directe peuvent solliciter des chemins GPU très différents au même moment. Pour établir un diagnostic utile, il faut distinguer la pression exercée sur la mémoire vidéo du débit d’encodage, du basculement vers le processeur et des limites du stockage ou du réseau avant de considérer la VRAM comme le goulot d’étranglement.

Des clients différents créent des espaces de travail GPU différents

Un parc de clients variés modifie ce que Plex doit garder prêt pour chaque session active. Un téléviseur peut accepter la vidéo HEVC d’origine, un autre navigateur peut nécessiter une sortie H.264 et un téléphone connecté à distance via une liaison limitée peut demander une résolution inférieure. Les sessions ne consomment donc pas les ressources GPU comme des copies identiques d’une même charge de travail.

Lorsqu’une conversion vidéo est nécessaire, Plex a besoin de la prise en charge du décodage et de l’encodage propres au codec, ainsi que de tampons pour les images intermédiaires. Le chemin matériel de décodage et d’encodage vidéo exact varie selon la combinaison entre la source et la sortie, ce qui explique pourquoi deux sessions à la même résolution nominale peuvent créer des empreintes mémoire différentes.

La lecture directe constitue un cas de référence utile, car elle n’oblige pas le serveur à décoder puis à réencoder la vidéo. Si la mémoire GPU n’augmente que lorsqu’un client passe de la lecture directe à une transcodification matérielle, l’allocation supplémentaire provient du chemin de conversion, et non de la concurrence en elle-même.

La résolution et le codec modifient la taille des surfaces d’image

La mémoire vidéo sert à bien plus qu’au fichier compressé provenant du stockage. Les décodeurs et encodeurs matériels utilisent des surfaces d’image décodées, des images de référence et des tampons de sortie intermédiaires dont la taille varie selon la résolution, la profondeur de couleur, le format de chrominance et le comportement du codec. Une image 4K nécessite donc un espace de travail plus important qu’une image 1080p, même avant de prendre la concurrence en compte.

Le HEVC en 4K peut nécessiter davantage de VRAM que l’AVC en 1080p dans certaines charges de travail Plex HDR. Considérez cela comme un indice concernant la charge de travail, et non comme une formule fixe par flux, car les versions des pilotes, les chemins de mappage des tons, l’architecture du GPU et les versions de Plex peuvent modifier l’allocation exacte.

La conséquence pour le diagnostic est simple : comparez le même nombre de sessions en ne modifiant que la catégorie de la source. Si deux conversions en 1080p fonctionnent confortablement, mais que le remplacement de l’une d’elles par du HEVC en 4K fait fortement augmenter la mémoire, les surfaces liées à la résolution et au codec en sont en partie responsables.

Le mappage des tons et les étapes de transformation ajoutent une couche mémoire supplémentaire

Une conversion peut inclure bien plus que le décodage d’un format et l’encodage dans un autre. La mise à l’échelle, la conversion des couleurs, le mappage des tons HDR vers SDR et la composition des sous-titres peuvent introduire des surfaces intermédiaires qui chevauchent les tampons du décodeur et de l’encodeur. Ces étapes sont particulièrement importantes lorsque différents clients nécessitent des sorties différentes à partir de la même bibliothèque.

Dans un conteneur, les nœuds de périphériques de rendu utilisés pour le traitement vidéo matériel doivent être accessibles à Plex avant que les relevés de mémoire GPU soient significatifs. Dans le cas contraire, le basculement vers le processeur peut donner l’impression que la VRAM est peu utilisée, alors que le travail coûteux a été déplacé ailleurs.

Considérez un faible relevé de VRAM accompagné d’une forte utilisation du processeur comme un problème de vérification du chemin avant de conclure que le GPU est sous-utilisé. La règle inverse s’applique également : une mémoire GPU élevée avec une vitesse de transcodification normale peut correspondre à une résidence normale des données plutôt qu’à un problème de capacité.

La concurrence devient importante lorsque ces espaces de travail se chevauchent

Chaque session transcodée matériellement conserve son propre état actif de décodage et d’encodage pendant la lecture. Avec des clients différents, ces états peuvent varier et rester actifs simultanément, de sorte que la mémoire GPU totale peut augmenter plus rapidement que ne le laisse penser un simple comptage des spectateurs. Ce chevauchement devient plus important lorsque plusieurs utilisateurs effectuent une recherche, démarrent une lecture ou modifient la qualité dans un intervalle très court.

Sur une configuration équipée d’une GTX 1660 Ti, une seule transcodification 4K a utilisé environ 600 Mo de mémoire GPU. Il s’agit d’un exemple mesuré et limité de résidence en mémoire, et non d’une quantité de VRAM recommandée pour chaque flux 4K.

Utilisez la combinaison réaliste la plus exigeante plutôt que de lancer en boucle des fichiers de test identiques. La charge de travail doit inclure les codecs, les modes HDR, les qualités de sortie et les clients réellement utilisés dans le foyer, car la concurrence entre clients différents est précisément la condition qui rend les estimations fondées sur des flux identiques peu fiables.

Distinguez la pression mémoire des autres limites du GPU

La VRAM peut être pleine alors que l’encodeur dispose encore de débit, ou une quantité importante de VRAM peut rester libre alors qu’une étape de codec, une limite de sessions, un chemin de pilote ou une opération exécutée uniquement sur le processeur prend du retard. Quick Sync peut gérer plusieurs transcodifications dans des charges de travail adaptées, mais cela ne fait pas de la capacité mémoire la seule limite à la concurrence.

Surveillez simultanément la mémoire GPU, l’utilisation du moteur vidéo, la vitesse de transcodification, l’utilisation du processeur et la lecture. La pression mémoire devient crédible lorsque de nouvelles sessions ou des sessions plus exigeantes échouent à mesure que l’allocation approche la limite du périphérique, tandis que le reste du chemin fonctionne correctement ; une utilisation élevée sans ce schéma indique probablement un autre problème.

Pour le chemin serveur environnant, utilisez un chemin Plex 4K fonctionnel comme référence pour la prise en charge des codecs, la distribution du stockage et l’accélération matérielle. La mémoire GPU n’est qu’un élément de cet ensemble, et non une spécification autonome du nombre de flux pris en charge.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.