Pour le choix précis entre la RX 6400 et l’Intel Arc A310 dans ce fil consacré à ZimaOS/Jellyfin, l’Arc A310 est la solution la plus adaptée au transcodage multimédia. La raison n’est pas que les GPU AMD soient universellement incompatibles avec ZimaOS ; cette affirmation est apparue dans une première réponse et a été contestée dans le même fil. La différence la plus durable concerne les capacités des codecs et la prise en charge actuelle de l’accélération Linux par Jellyfin.
L’utilisateur a finalement installé l’A310, configuré VA-API/QSV, puis montré de véritables intel_gpu_top activité du moteur vidéo pendant le transcodage avec FFmpeg. C’est une preuve bien plus solide que la présence ou non d’un widget GPU dans le tableau de bord de ZimaOS.
Pourquoi l’Arc A310 était plus adaptée que la RX 6400
Le guide actuel d’accélération des GPU Intel de Jellyfin indique que QSV est privilégié sur les GPU Intel courants et prend explicitement en charge le matériel Arc de série A sous Linux. Les cartes Arc de série A prennent également en charge l’encodage AV1, ce qui est précieux pour une carte dédiée au transcodage multimédia.
Le guide actuel de compatibilité des GPU de ZimaOS répertorie les Intel A310, A380, A580, A750 et A770 dans son tableau de compatibilité des cartes Intel de série A.
La lecture directe peut donner l’impression qu’un GPU fonctionnel est inactif
L’une des corrections les plus utiles du fil était que la lecture locale peut utiliser la lecture directe du fichier source. Dans ce cas, Jellyfin a peu de raisons de solliciter fortement le GPU. Pour valider le transcodage matériel, forcez délibérément un débit inférieur, un chemin utilisant un codec incompatible, l’incrustation des sous-titres ou une autre condition imposant une conversion.
QSV et VA-API sont tous deux pertinents sous Linux
La communauté est passée de VA-API à Intel Quick Sync. Cela correspond aux recommandations actuelles de Jellyfin : QSV est généralement privilégié sur le matériel Intel grand public pris en charge, tandis que VA-API reste disponible et important pour les configurations plus anciennes ou axées sur la compatibilité.
Ne sélectionnez pas aveuglément toutes les cases de codecs. Activez uniquement les formats réellement pris en charge par le matériel et la pile de pilotes.
Redémarrer Jellyfin après avoir modifié les paramètres d’accélération
Dans Jellyfin, plusieurs paramètres ne sont appliqués qu’après le redémarrage du processus serveur. L’utilisateur a également activé l’accélération matérielle pour le trickplay, ce qui peut réduire la charge du processeur lors de la génération des images d’aperçu, mais ajoute une charge supplémentaire sur le GPU pendant le traitement de la bibliothèque.
Un champ de périphérique QSV vide ne prouve pas un échec
L’utilisateur s’inquiétait du fait que Jellyfin n’affichait pas le nom du périphérique QSV de la même manière qu’un autre système. Les réponses de la communauté suggéraient de laisser le champ vide et de tester le comportement réel du transcodage plutôt que de tirer des conclusions à partir du seul libellé de l’interface.
Vérifier le GPU sur l’hôte et pendant un transcodage réel
L’élément de preuve le plus solide dans le fil concernait l’activité en temps réel : intel_gpu_top montrait que le moteur vidéo était occupé lorsqu’un processus FFmpeg était actif. Cela constitue une preuve plus solide qu’une simple liste statique des périphériques, car cela montre que le moteur multimédia travaillait au moment du transcodage.
Le guide sur l’accélération matérielle explique la même distinction entre la lecture directe et le transcodage, tandis que le guide du matériel Jellyfin aide à déterminer si un GPU dédié est réellement nécessaire.
La source et la version de l’application comptent également
Le fil abordait également les catégories de sources de l’App Store et les versions ultérieures de Jellyfin. Un GPU hôte fonctionnel ne garantit pas que chaque image de conteneur expose /dev/dri ou inclut les mêmes bibliothèques FFmpeg/multimédias. Lorsque l’accélération cesse de fonctionner après la mise à jour d’une application, comparez la définition du conteneur et les mappages de périphériques avant d’accuser la carte.
La lecture dans un navigateur constitue une couche de compatibilité distincte
La discussion sur les formats audio DTS et Dolby est distincte de la détection du GPU. Un navigateur peut forcer le transcodage ou ne pas transmettre un format audio qu’un client Jellyfin dédié peut gérer directement. Tenez compte du type de client et des informations de lecture pour déterminer si un « problème de GPU » est en réalité un problème de compatibilité avec le client multimédia.
Ce que l’utilisateur a finalement obtenu
À la fin du fil, l’utilisateur a indiqué que le transcodage fonctionnait globalement bien. Le parcours de configuration a néanmoins révélé quelques difficultés — libellés d’interface manquants, comportement différent avec les anciens médias et une certaine incertitude concernant les paramètres — mais l’A310 effectuait bien un véritable traitement vidéo.
Conclusion
Pour une carte de transcodage Jellyfin compacte sous Linux/ZimaOS actuel, l’Intel Arc A310 est un choix défendable, car Jellyfin prend en charge QSV/VA-API sur les cartes Arc et ZimaOS répertorie actuellement l’A310 dans son tableau de compatibilité Intel. Vérifiez le bon fonctionnement avec un transcodage forcé réel et l’activité du moteur GPU, plutôt qu’avec le seul widget du tableau de bord ZimaOS.
