Un utilisateur de ZimaOS exécutant Jellyfin sur un système Intel N100 doté de 16 Go de RAM a signalé une différence nette dans le comportement de lecture : les contenus allant jusqu’à la 1080p fonctionnaient normalement, mais un flux 4K nécessitant un transcodage faisait grimper l’utilisation du processeur à 100 % et devenait trop saccadé pour être regardé. Jellyfin fonctionnait avec le réseau Host et le serveur ne disposait d’aucun GPU dédié.
La discussion de la communauté n’a pas abouti à une solution finale unique et confirmée. Elle s’est plutôt transformée en enquête pratique sur le transcodage logiciel, le circuit graphique intégré d’Intel, VA-API, la compatibilité des codecs, le mappage des tons HDR et l’endroit approprié pour vérifier qu’un transcodage est actif. L’utilisateur d’origine a finalement activé l’accélération matérielle et a pu lire un flux transcodé, même si l’utilisation du processeur restait d’environ 95 à 98 %.
Le problème initial de transcodage 4K avec Jellyfin
Le serveur utilisait un processeur Intel N100 et 16 Go de mémoire. Jellyfin servait de serveur multimédia local et son type de réseau Docker était défini sur Host. La lecture ordinaire en 1080p ne posait aucun problème.
Le problème apparaissait uniquement lorsqu’un fichier 4K nécessitait un transcodage. À ce moment-là, l’utilisation du processeur atteignait 100 %, la lecture saccadait et le flux devenait pratiquement impossible à regarder. L’utilisateur voulait donc savoir quels réglages de Jellyfin pouvaient améliorer les performances de transcodage sans carte graphique dédiée.
Cette différence entre la 1080p et la 4K est devenue l’indice central des réponses. Les membres de la communauté se sont moins intéressés au réseau et à la mémoire qu’à ce que Jellyfin convertissait, à l’utilisation éventuelle du circuit graphique intégré du N100 et à la capacité du client sélectionné à lire directement le format source.
Pourquoi la compatibilité des codecs et des clients est entrée dans la discussion
goultron a décrit le transcodage 4K sur un système de classe N100 comme une charge de travail exigeante, en particulier lorsque le serveur se rabat sur le processeur. De son côté, il préférait éviter de gérer une bibliothèque 4K et privilégier les contenus H.264, car ils sont lus directement sur un plus grand nombre d’appareils.
La réponse a également souligné un point pratique important : même une vidéo H.264 peut nécessiter une certaine forme de conversion. L’appareil récepteur, les formats audio pris en charge et la vitesse du réseau disponible peuvent tous influer sur le parcours de lecture final. goultron soupçonnait que la conversion audio était responsable de certains flux qui continuaient à être transcodés malgré l’utilisation de la vidéo H.264.
Ils ont opposé cela à une grande partie des contenus 4K disponibles, qui utilisent généralement H.265/HEVC. Certains appareils de lecture et téléviseurs plus petits peuvent ne pas prendre directement en charge tous les profils H.265. Dans ce cas, Jellyfin doit convertir la source pour le client, reportant la charge de travail sur le serveur.
Diagnostic principal de gelbuilding : vérifiez d’abord l’iGPU du N100
gelbuilding considérait le comportement du N100 comme normal si Jellyfin effectuait un transcodage 4K logiciel. Son explication était simple : une petite unité centrale peut être utilisée à pleine capacité par cette tâche, ce qui explique la lecture fluide en 1080p de l’utilisateur initial et le transcodage 4K inutilisable.
La première vérification proposée consistait à déterminer si Jellyfin utilisait réellement le moteur multimédia Intel intégré au N100. Le N100 n’a pas besoin d’une carte graphique distincte pour exposer un iGPU, mais Jellyfin doit disposer de l’accélération matérielle activée et pouvoir accéder à ce périphérique depuis son conteneur.
Le chemin d’accès aux paramètres indiqué dans la réponse était :
- Ouvrez l’interface d’administration de Jellyfin.
- Ouvrez Lecture.
- Ouvrez Transcodage.
- Activez l’accélération matérielle.
- Sélectionnez VA-API pour la configuration évoquée dans le fil.
Le résultat attendu était que le traitement passe du processeur, où il était effectué par logiciel, à l’iGPU Intel. gelbuilding a également averti qu’il ne fallait pas s’attendre à ce que l’iGPU du N100 convertisse sans difficulté toutes les sources 4K. Certains fichiers HEVC à débit binaire élevé ont notamment été identifiés comme des tâches pouvant encore basculer vers un traitement logiciel.
La communauté a corrigé l’emplacement où vérifier VA-API
La première réponse suggérait de vérifier dans Tableau de bord → Activité la présence d’une mention VA-API pour H.264 ou HEVC. goultron a testé ce conseil avec Jellyfin 10.10.7 et a constaté que la page Activité affichait uniquement des événements tels que VideoPlayback et VideoPlaybackStopped.
gelbuilding a ensuite corrigé l’instruction. La page Activité n’était pas censée indiquer si le transcodage utilisait VA-API ou le logiciel. Les informations pertinentes doivent être vérifiées pendant que le flux 4K est activement transcodé dans :
- Tableau de bord
- Lecture
- Transcodage
La session active devrait afficher une ligne sous le codec. La mention VA-API indique que l’accélération matérielle est utilisée ; la mention Software indique que le processeur effectue la conversion. Si la zone de transcodage est vide, le fichier est peut-être lu directement ou diffusé directement, ce qui signifie qu’aucun transcodage vidéo actif n’est en cours.
Pourquoi btop n’a pas permis de répondre clairement dans ce fil
goultron a également tenté de vérifier l’activité de l’iGPU avec btop. L’iGPU Intel n’apparaissait pas clairement dans la section GPU, même si ce même iGPU avait déjà été transmis avec succès à Frigate et que Frigate indiquait qu’il utilisait bien le périphérique.
gelbuilding a répondu que, dans ce contexte ZimaOS, btop affichait principalement les GPU dédiés et pouvait donc ne pas afficher l’iGPU Intel même lorsqu’il était actif. Ils ont donc recommandé de considérer la vue active « Transcodage » de Jellyfin comme la méthode de confirmation directe.
Zima-Jerry a ensuite ajouté que btop pouvait être utilisé pour observer l’utilisation du GPU. Ces deux affirmations n’ont pas été conciliées avant la fin de la discussion. La discussion communautaire recommande donc d’utiliser btop comme outil d’observation supplémentaire, mais pas comme seule preuve ; les informations de transcodage actives de Jellyfin restent nécessaires pour distinguer le traitement VA-API du traitement logiciel.
Configuration du mappage des tons HDR de Zima-Jerry
Zima-Jerry a mis en lien une autre configuration communautaire axée sur l’accélération matérielle de Jellyfin et le mappage des tons HDR sur l’Intel N100. Dans ce cas antérieur, il avait été signalé que la version de Jellyfin alors disponible dans l’App Store rencontrait un problème de conversion des tons de couleur.
L’alternative suggérée était l’image conteneur Jellyfin nyanmisaka, accompagnée d’une configuration YAML personnalisée. Il s’agissait d’une solution de contournement proposée par la communauté, liée aux versions de Jellyfin et de ZimaOS utilisées à cette époque ; elle doit donc être comparée à la version actuelle de l’App Store avant de remplacer une installation existante.
Le résultat partagé dans cette discussion connexe ne correspondait pas à un transcodage 4K illimité. Zima-Jerry a estimé que les graphiques intégrés du N100 pouvaient convertir de manière fluide des vidéos Dolby Vision en environ 4K à 30 images/s ou moins dans la configuration testée.
Ce qui a changé après l’activation de l’accélération matérielle par l’utilisateur initial
Après avoir examiné les réponses, Heimwerkerking a activé l’accélération matérielle pour le transcodage. Cela a produit une amélioration notable : au moins un flux transcodé est devenu lisible.
Les informations de lecture active affichées dans le tableau de bord étaient 48,7 Mbit/s MP4 H264 AAC. Cependant, l’utilisation du processeur est restée comprise entre 95 et 98 %, si bien que l’utilisateur ne savait toujours pas si l’iGPU Intel prenait réellement en charge la conversion vidéo.
Ce résultat n’a pas prouvé que le problème était entièrement résolu. Il a montré que la modification de la configuration améliorait la lecture, mais la discussion ne comportait toujours aucune étiquette VA-API confirmée, aucun résultat FFmpeg complet ni mesure cohérente de l’iGPU. La dernière réponse suggérait à nouveau d’observer l’utilisation du GPU avec btop, et aucune confirmation ultérieure n’a été publiée.
Ce que cette discussion de la communauté établit réellement
La discussion confirme fortement que le transcodage 4K logiciel est la première explication possible à l’utilisation du processeur à 100 % par un N100. Elle établit également une méthode de vérification corrigée : lancer un transcodage 4K et inspecter la session active dans les sections Lecture et Transcodage de Jellyfin, plutôt que l’historique d’activité.
Les réponses ajoutent plusieurs limites liées à la charge de travail. La compatibilité H.265 du client, la conversion audio, le débit élevé de la source, le mappage des tons HDR et le conteneur Jellyfin utilisé peuvent tous modifier le résultat. L’activation de VA-API a amélioré la capacité de l’utilisateur d’origine à lire un flux transcodé, mais l’utilisation du processeur est restée élevée.
La discussion n’établit pas un nombre universel de flux pour le N100 et ne prouve pas qu’un GPU Intel Arc soit nécessaire. gelbuilding a présenté deux étapes possibles pour les utilisateurs qui ont toujours besoin d’une conversion 4K stable : réduire le débit de la source ou ajouter un petit GPU Intel Arc. La discussion s’est terminée avant que l’une ou l’autre option ne soit testée par l’auteur du message initial.
FAQ issue de la discussion de la communauté
Pourquoi la lecture en 1080p fonctionnait-elle alors que le transcodage 4K saccadait ?
La communauté a attribué cette différence à la charge logicielle beaucoup plus importante générée lorsque le fichier 4K devait être converti. Le N100 d’origine atteignait une utilisation complète du processeur pendant ce processus.
Où faut-il vérifier VA-API dans Jellyfin ?
Lancez un flux 4K qui force le transcodage, puis examinez la session active sous Tableau de bord, Lecture et Transcodage. Il a été démontré que l’historique des événements d’activité ne fournissait pas l’étiquette VA-API ou Logiciel nécessaire.
Que signifie l’absence de transcodage actif dans la vue ?
D’après la correction de gelbuilding, cela peut signifier que le fichier est lu directement ou diffusé directement, et qu’aucun transcodage vidéo n’est actuellement actif.
L’activation de l’accélération matérielle a-t-elle complètement résolu le problème ?
Non. Cela a permis de lire un flux transcodé, mais la charge du processeur restait comprise entre 95 et 98 %, et la discussion s’est terminée sans confirmation définitive que l’iGPU gérait l’ensemble du pipeline.
Quelles options la communauté a-t-elle suggérées si la 4K restait instable ?
Les réponses suggéraient de privilégier, lorsque cela est possible, des fichiers multimédias compatibles H.264, de réduire le débit de la source 4K, de tester la configuration Jellyfin personnalisée partagée par Zima-Jerry ou d’ajouter un petit GPU Intel Arc pour disposer d'une solution de transcodage matériel plus performante.
