Pourquoi Jellyfin met-il en mémoire tampon sur un serveur domestique ?

Jellyfin tamponne lorsqu’une partie du chemin de lecture ne peut pas délivrer, convertir ou décoder la vidéo plus rapidement que l’avancement de la timeline. Le transcodage vidéo est une cause fréquente, mais pas la seule. Un flux peut aussi se bloquer à cause des limites du codec client, du traitement des sous-titres, d’un Wi-Fi instable, d’une bande passante d’upload distante insuffisante, d’une contention de stockage ou d’un répertoire de transcodage incapable d’accepter plus de données temporaires.

La façon la plus rapide de trouver le goulot d’étranglement est de vérifier le mode de lecture actuel avant de modifier les paramètres matériels. Comparez ensuite si le problème affecte tous les fichiers, uniquement les médias 4K ou HDR, un client, des utilisateurs distants, la lecture avec sous-titres activés ou plusieurs flux simultanés.

Vérifiez le mode de lecture avant de modifier quoi que ce soit

Ouvrez le tableau de bord Jellyfin pendant la lecture de la vidéo affectée et inspectez la session active. Cela permet de déterminer si le serveur délivre le fichier original ou convertit activement une partie de celui-ci.

Jellyfin sépare la lecture en quatre chemins de lecture avec une charge serveur progressivement plus élevée : lecture directe, remux, flux direct et transcodage vidéo. La lecture directe envoie le média original avec presque aucun traitement. Le remux change le conteneur, le flux direct convertit l’audio tout en conservant la vidéo, et le transcodage ré-encode le flux vidéo.

Ce premier résultat change toute la direction du dépannage. Si la lecture directe tamponne, commencez par le réseau, le stockage, le client et le fichier média. Si le transcodage vidéo tamponne, vérifiez pourquoi la conversion a été demandée et si le serveur peut compléter rapidement toute la chaîne de traitement.

Découvrez pourquoi Jellyfin a demandé une transcodification

Un fichier ne fait pas de lecture directe simplement parce que le client prend en charge son codec vidéo. Jellyfin évalue la combinaison complète du conteneur, du codec vidéo, du profil du codec, de la profondeur de bits, de la résolution, du format audio, de la disposition des canaux, des sous-titres, du débit binaire et des contraintes de lecture du client.

Par exemple, le client peut prendre en charge la vidéo HEVC mais pas la piste audio TrueHD incluse. Un autre client peut décoder les deux flux mais ne pas réussir à afficher le format de sous-titres sélectionné. Ces différences peuvent transformer le même fichier en lecture directe sur un appareil, conversion audio sur un autre, et transcodage vidéo complet dans un navigateur.

Enregistrez la raison de la lecture avant de modifier les paramètres. Testez également une autre piste audio, désactivez les sous-titres et lisez le même fichier via un autre client Jellyfin. Ces tests contrôlés sont plus utiles que d'activer toutes les cases de codec dans le menu de transcodage.

Le transcodage logiciel peut surcharger un petit serveur

Le transcodage logiciel utilise le CPU pour décoder la source, appliquer des filtres, mettre à l'échelle l'image et encoder un nouveau flux en temps réel. Un processeur peu puissant peut gérer une conversion 1080p mais échouer avec une source 4K HEVC, une vidéo 10 bits ou HDR.

Lorsque la conversion ne peut pas rester en avance sur la lecture, le client finit par consommer les segments vidéo mis en mémoire tampon et se met en pause. L'utilisation du CPU peut rester proche de son maximum tandis que Jellyfin tente à plusieurs reprises de constituer suffisamment de données en avance sur la position actuelle.

Si le serveur dispose d'un GPU intégré ou dédié compatible, une accélération matérielle correctement configurée est généralement plus utile que de modifier le nombre de threads FFmpeg. Si le serveur ne possède pas d'encodeur compatible, réduire la résolution ou le débit binaire demandé peut confirmer que la capacité de transcodage est le facteur limitant.

L'accélération matérielle est un pipeline à plusieurs étapes

Sélectionner Intel Quick Sync, VA-API, NVIDIA NVENC ou AMD AMF dans le tableau de bord ne garantit pas que chaque partie de la conversion s'exécute sur le GPU.

Un transcodage Jellyfin peut inclure le décodage, le désentrelacement, la mise à l'échelle, la conversion de format, le mappage de tons HDR, l'incrustation de sous-titres et l'encodage. Jellyfin note que certaines étapes peuvent rester sur le CPU en raison de limitations matérielles, de pilotes ou logicielles. L'accélération partielle peut donc entraîner une forte utilisation du CPU même lorsque l'activité GPU est visible.

Vérifiez l'ensemble du processus plutôt que la simple présence d'un GPU. Forcez un transcodage prévisible, surveillez les moteurs de décodage et d'encodage vidéo, inspectez la commande FFmpeg et recherchez les filtres qui sont passés en mode logiciel.

N'activez pas les formats de décodage que votre GPU ne peut pas gérer

La page d'accélération matérielle permet aux administrateurs de sélectionner les formats vidéo que Jellyfin peut tenter de décoder via le GPU. Activer un format non supporté n'ajoute pas cette capacité au matériel.

Si le GPU ne peut pas décoder le profil de codec exact ou la profondeur de bits, Jellyfin peut revenir au décodage logiciel ou échouer à initialiser le chemin matériel. C'est pourquoi un fichier HEVC peut fonctionner tandis qu'un autre provoque une utilisation CPU anormalement élevée.

Confirmez la génération du GPU et les profils supportés, puis activez uniquement les formats qu'il peut réellement traiter. Testez séparément les fichiers H.264 ordinaires, HEVC Main 10 et HDR au lieu de considérer tous les médias 4K comme une seule charge de travail.

Docker doit avoir accès au GPU

Un GPU détecté par le système d'exploitation hôte n'est pas automatiquement disponible à l'intérieur d'un conteneur Jellyfin. Le conteneur a également besoin du mappage correct des périphériques, du runtime, des pilotes, des groupes et des permissions.

Pour les GPU Intel et AMD sous Linux, l'hôte expose généralement les périphériques de rendu sous /dev/dri. L'utilisateur du conteneur doit pouvoir accéder au périphérique de rendu concerné. Les configurations NVIDIA nécessitent le pilote hôte et un runtime de conteneur approprié. Les vérifications Docker pratiques incluent la vérification du périphérique de rendu, son mappage dans le conteneur et l'ajout du GID correct du groupe de rendu.

Ne laissez pas le conteneur en mode privilégié comme solution permanente. Cela peut être utilisé brièvement pour confirmer que le problème sous-jacent est l'accès au périphérique, mais le déploiement final doit exposer uniquement les ressources et permissions GPU nécessaires.

Vérifiez l'activité GPU lors d'un transcodage réel

Le démarrage réussi d'un conteneur ne prouve pas que le transcodage matériel fonctionne. Jellyfin peut fonctionner normalement, scanner la bibliothèque et lire directement des fichiers sans avoir accès au GPU.

Forcez un transcodage en choisissant temporairement une qualité client inférieure à la source. Sur les systèmes Intel, surveillez les moteurs vidéo avec un outil tel que intel_gpu_topSur les systèmes NVIDIA, inspectez les processus actifs et l'activité de l'encodeur via nvidia-smiVérifiez également si l'utilisation du CPU diminue par rapport au transcodage logiciel.

S'il n'y a aucune activité GPU, vérifiez l'appareil mappé, l'utilisateur du conteneur, l'appartenance au groupe de rendu, la méthode d'accélération matérielle et le journal FFmpeg. Si le GPU est actif mais que la lecture reste lente, une autre étape du pipeline peut encore s'exécuter en logiciel.

Les Sous-titres Peuvent Déclencher un Transcodage Vidéo Complet

Un symptôme courant est une lecture fluide jusqu’à l’activation des sous-titres. Cela se produit souvent avec des sous-titres basés sur des images ou des formats stylisés que le client sélectionné ne peut pas rendre directement.

Lorsque Jellyfin doit incruster les sous-titres dans l’image, il décode chaque image, rend la couche de sous-titres et encode un nouveau flux vidéo. Cela peut transformer une session Direct Play autrement peu chargée en l’un des chemins de lecture les plus coûteux du serveur.

Désactivez les sous-titres et relancez la même scène. Si la mise en mémoire tampon disparaît, essayez une piste de sous-titres textuelle comme SRT, testez un autre client ou vérifiez si le chemin matériel sélectionné peut accélérer les opérations de décodage, filtrage et encodage environnantes.

Le Tone Mapping HDR Peut Être Plus Exigeant Que le Transcodage Normal

Si les médias 1080p et 4K SDR ordinaires sont lus correctement mais que le contenu HDR met en mémoire tampon sur un client SDR, le tone mapping est un candidat probable.

Le serveur peut devoir décoder une source HDR 10 bits, convertir sa gamme de couleurs et de luminosité pour le SDR, la redimensionner et encoder un nouveau flux vidéo. Un système capable d’un transcodage H.264 normal peut toujours être incapable d’exécuter cette charge complète en temps réel via logiciel.

Testez le même fichier HDR sur un client compatible HDR, puis forcez un transcodage SDR et comparez l’activité CPU et GPU. Le support matériel du décodage HEVC ne prouve pas automatiquement que la méthode de tone mapping sélectionnée est entièrement accélérée.

Le Client Détermine Une Grande Partie du Chemin de Lecture

Jellyfin peut faire du Direct Play d’un fichier dans un client média de bureau tout en le transcodant dans une application navigateur ou télévision. Cette différence ne signifie pas que la configuration du serveur a changé entre les sessions.

Chaque client rapporte ses codecs, conteneurs, formats audio, sous-titres, résolutions et limites de débit pris en charge. Un lecteur plus performant peut éviter la conversion, tandis qu’un lecteur restreint peut nécessiter une conversion audio, un remuxing ou une transcodification vidéo complète.

Testez le même fichier, piste audio, piste de sous-titres et connexion réseau sur deux clients. Si le problème suit un client, examinez les capacités de lecture et les paramètres de l’application de cet appareil avant de modifier le serveur.

Le Direct Play Peut Toujours Mettre en Mémoire Tampon

Le Direct Play élimine la conversion vidéo comme principal goulot d’étranglement, mais cela ne prouve pas que toutes les autres parties du chemin sont saines.

Le NAS doit toujours lire le média, le réseau doit le transmettre en continu, et le client doit le décoder et l’afficher. Des pics de débit élevés, un Wi-Fi instable, une interface client lente, des tentatives de reprise d’erreur de stockage ou un lecteur sous-dimensionné peuvent interrompre un flux autrement direct.

Copiez le fichier problématique sur le client et lisez-le localement. Si la lecture locale saccade aussi, examinez le fichier média ou le décodeur client. Si la copie locale fonctionne alors que Jellyfin Direct Play met en mémoire tampon, concentrez-vous sur le réseau et le chemin de stockage du serveur.

Testez le chemin LAN réel au lieu d’un test de vitesse Internet.

Un résultat rapide sur Internet ne mesure pas le chemin du serveur Jellyfin vers une télévision, un téléphone ou un boîtier de streaming à l’intérieur du domicile. Il ne révèle pas non plus les variations Wi-Fi, la perte de paquets, la congestion du maillage ou une interface d’appareil lente.

Un diagnostic local utile compare le débit soutenu de copie de fichier, un client filaire, un encodage à débit binaire plus faible et le fichier original à débit élevé. Les vérifications pratiques du streaming local incluent aussi tester l’Ethernet, vérifier si le client force une transcodification, et déplacer les tâches lourdes en arrière-plan hors des heures de visionnage.

Cherchez une performance soutenue plutôt que le chiffre le plus élevé affiché pendant quelques secondes. Une vidéo avec de gros pics de débit binaire nécessite une marge suffisante pour survivre à de courtes ralentissements réseau sans épuiser le tampon du client.

La mise en mémoire tampon à distance a généralement une cause différente.

Si le même média se lit correctement à la maison mais subit des mises en mémoire tampon via une connexion externe, la bande passante d’upload du serveur et le chemin distant deviennent les principaux suspects.

Le débit utilisable est limité par la vitesse d’upload de la connexion domestique, la vitesse de téléchargement du client distant, la surcharge VPN ou proxy inverse, le trafic concurrent dans le foyer et le débit du flux. Un gros remux peut dépasser la capacité d’upload disponible même s’il se lit parfaitement en Direct Play sur le LAN.

Réduisez temporairement la qualité de lecture à distance. Si cela résout la mise en mémoire tampon, définissez un débit binaire distant durable ou utilisez la transcodification matérielle pour créer un flux plus petit. Considérez ce réglage inférieur comme une preuve d’une limite de bande passante, pas comme une preuve que le fichier original est défectueux.

Le stockage est plus susceptible de tomber en panne sous une charge de travail simultanée.

Un disque dur en bon état peut généralement lire un flux vidéo ordinaire sans difficulté. Le stockage devient plus suspect lorsque la lecture se superpose à des téléchargements, sauvegardes, analyses de bibliothèque, génération de vignettes, opérations de parité, vérifications ou plusieurs utilisateurs.

Ces tâches créent des lectures, écritures et recherches concurrentes. Un disque peut afficher une vitesse séquentielle acceptable dans un benchmark tout en développant une latence élevée sous une activité mixte.

Surveillez l'utilisation et la latence pendant la mise en mémoire tampon. Mettez en pause les téléchargements et les tâches de maintenance, puis relancez la lecture du même fichier. Gardez la base de données Jellyfin, les métadonnées et le cache sur un stockage à faible latence lorsque c'est possible, tandis que les gros fichiers médias peuvent rester sur des disques orientés capacité.

Un répertoire de transcodage plein peut arrêter la lecture

La vidéo transcodée est écrite sous forme de segments temporaires avant d'être consommée par le client. Si le système de fichiers, SSD, disque RAM ou volume Docker assigné manque d'espace libre, FFmpeg ne peut plus produire de nouveaux segments.

Un problème antérieur de Jellyfin a documenté comment la lecture ne pouvait continuer que jusqu'au dernier segment créé avant que le répertoire de transcodage ne soit plein. Le rapport est ancien et clos, mais le symptôme reste une raison utile d'inspecter l'espace lorsqu'un flux transcodé s'arrête après plusieurs minutes.

Vérifiez l'espace libre, la disponibilité des inodes, le mappage du conteneur, les permissions d'écriture et la limite de capacité du chemin de transcodage. Soyez particulièrement prudent avec les petits disques RAM ou systèmes de fichiers temporaires : utiliser la mémoire peut réduire la latence de stockage, mais une limite trop basse peut provoquer une défaillance brutale de la lecture.

Un fichier problématique pointe généralement vers le média

Si de nombreux fichiers avec une résolution et un débit similaires fonctionnent correctement, un seul titre défaillant est moins susceptible de prouver que l'ensemble du serveur est sous-dimensionné.

Le fichier peut contenir un profil de codec inhabituel, des images endommagées, une disposition audio non prise en charge, une piste de sous-titres image, des horodatages incorrects ou un pic de débit extrême. Une saison d'une série peut aussi avoir été encodée différemment des autres.

Testez une autre piste audio, désactivez les sous-titres, inspectez les informations du média et comparez le fichier avec un autre titre utilisant le même codec. Un simple remux dans un nouveau conteneur peut aider à déterminer si le conteneur ou les horodatages sont en cause sans réencoder toute la vidéo.

Plusieurs flux révèlent les limites des ressources partagées

Un serveur domestique peut gérer parfaitement un flux et commencer à mettre en mémoire tampon seulement lorsqu'un autre utilisateur lance la lecture. Comparez le mode de lecture de chaque session active avant de supposer que le réseau est seul responsable.

Plusieurs sessions de lecture directe ajoutent principalement une charge de stockage et de réseau. Plusieurs transcodages vidéo se disputent également la capacité d'encodage GPU, les filtres CPU, la bande passante mémoire et l'espace du répertoire de transcodage.

Testez une session, puis ajoutez les flux un par un en surveillant l’utilisation du CPU, GPU, disque et réseau. Cela permet d’identifier si la limite pratique est le nombre de conversions, le débit média global ou l’activité mixte de stockage.

Lisez le journal FFmpeg avant de réinstaller Jellyfin

Le tableau de bord du serveur vous indique le type de lecture en cours, tandis que le journal FFmpeg correspondant explique comment Jellyfin a tenté de traiter le fichier.

Recherchez les échecs d’initialisation du matériel, erreurs de permission, profils non supportés, repli logiciel, filtres de sous-titres, filtres de cartographie des tons, erreurs d’entrée/sortie, codes de sortie de processus et erreurs d’espace de stockage.

Capturez le journal de la session exacte qui met en mémoire tampon. Un journal d’une lecture directe non liée ou d’un transcodage réussi peut mener à une mauvaise conclusion. Réinstaller le serveur ne résout que rarement une limite de codec client, un appareil GPU inaccessible ou un répertoire temporaire plein.

Utilisez le symptôme pour choisir le test suivant

Suivez cet ordre de dépannage

1. Reproduisez le problème avec le même fichier et client.
2. Ouvrez le tableau de bord Jellyfin et notez le mode de lecture.
3. Notez la raison indiquée du transcodage ou de la compatibilité.
4. Désactivez les sous-titres et testez une autre piste audio.
5. Lisez le même fichier via un autre client.
6. Vérifiez l’activité du CPU et du GPU pendant la session affectée.
7. Ouvrez le journal FFmpeg correspondant.
8. Vérifiez l’espace dans le répertoire de transcodage et les permissions d’écriture.
9. Testez le débit LAN soutenu ou la capacité de téléversement à distance.
10. Mettez en pause les téléchargements, sauvegardes, analyses et la maintenance du stockage.
11. Comparez le fichier problématique avec des médias similaires.
12. Envisagez un nouveau matériel seulement après que les preuves montrent une limite de calcul.

Cet ordre empêche que des changements non liés masquent la cause originale. Changez une variable à la fois et relancez la même scène pour que les résultats restent comparables.

Conclusion finale

Le buffering de Jellyfin ne signifie pas automatiquement que le serveur domestique a besoin d'un processeur plus rapide. Commencez par le mode de lecture actif, car le Direct Play et le transcodage vidéo pointent vers différentes parties du système.

Pour les sessions transcodées, identifiez pourquoi la conversion est nécessaire, vérifiez la chaîne complète d'accélération matérielle, testez sans sous-titres, inspectez la cartographie tonale HDR et confirmez que le chemin de transcodage dispose de suffisamment d'espace en écriture. Dans Docker, vérifiez le GPU depuis l'intérieur du conteneur plutôt que de se fier uniquement à la détection de l'hôte.

Pour le Direct Play, concentrez-vous sur le débit réseau soutenu, le décodage client, l'activité de stockage et le fichier média individuel. La combinaison du mode de lecture, du client, du codec, des sous-titres, de l'activité des ressources et des journaux FFmpeg fournit un diagnostic plus fiable que de modifier des paramètres au hasard ou de remplacer d'abord le matériel.

FAQ

Pourquoi Jellyfin met-il en tampon uniquement lorsque les sous-titres sont activés ?

Le format de sous-titres sélectionné peut nécessiter une incrustation. Jellyfin doit alors décoder la vidéo, rendre les sous-titres sur chaque image et encoder un nouveau flux. Essayez de désactiver les sous-titres, de sélectionner une piste textuelle ou d'utiliser un client capable de rendre directement le format de sous-titres.

Pourquoi Jellyfin transcode-t-il sur un appareil mais utilise Direct Play sur un autre ?

Les clients prennent en charge différentes combinaisons de conteneurs, codecs vidéo, formats audio, types de sous-titres, profils et débits binaires. L'appareil le moins compatible demande au serveur de convertir la partie du fichier non prise en charge.

Comment puis-je confirmer que l'accélération matérielle de Jellyfin fonctionne ?

Forcez un transcodage vidéo, puis inspectez les moteurs de décodage et d'encodage GPU du serveur. Confirmez également que le journal FFmpeg utilise le périphérique matériel attendu et que le conteneur peut accéder au périphérique sans erreurs de permission.

Pourquoi Jellyfin met-il en tampon même s'il indique Direct Play ?

Le Direct Play supprime le transcodage vidéo du chemin, mais le réseau, le stockage, le fichier média et le décodeur client peuvent toujours être trop lents ou instables. Testez le fichier localement sur le même client et comparez la lecture filaire et sans fil.

Jellyfin doit-il utiliser un SSD pour le transcodage ?

Un SSD peut réduire la latence des segments temporaires et est utile pour la base de données Jellyfin, les métadonnées et le cache. L'exigence la plus importante est un chemin de transcodage avec suffisamment d'espace, des écritures fiables et des permissions correctes. Un disque RAM de taille appropriée peut également fonctionner, mais un disque trop petit peut interrompre la lecture.