La lecture directe utilise le moins de ressources serveur, car le média original peut être diffusé sans modifier ses flux. Le flux direct sollicite davantage le serveur, qui reconditionne le média et peut convertir un flux audio ou de sous-titres incompatible, mais il peut laisser la vidéo intacte. Le transcodage complet utilise le plus de ressources, car la vidéo doit être décodée, traitée, puis encodée à nouveau. Le bon choix n'est donc pas celui qui affiche le moins d'utilisation du processeur à tout prix, mais le chemin le plus léger que le client, le réseau et les pistes multimédias sélectionnées peuvent réellement accepter.
La lecture directe ne fonctionne que si l'intégralité du fichier est compatible avec le client
La lecture directe est le premier choix à préserver, car elle envoie la vidéo et l'audio d'origine sans réencodage. Le serveur doit toujours effectuer certaines opérations — lecture depuis le stockage, authentification, gestion du protocole et livraison réseau — mais le pipeline coûteux de conversion vidéo reste inactif.
Plex définit la lecture directe comme le mode dans lequel le média peut être utilisé par le client sans conversion, tandis que sa présentation du streaming distingue ce mode du flux direct et du transcodage. Ce mode de diffusion du média d'origine fait des capacités du client le facteur décisif, plutôt que de la puissance du serveur.
La lecture directe est écartée lorsque le client rejette un élément important : codec vidéo, codec audio, conteneur, profil, résolution, débit, gestion des sous-titres ou autre contrainte de lecture. Dès qu'un élément requis n'est pas compatible, le serveur doit soit reconditionner le média, soit créer un nouveau flux.
Le flux direct est la solution intermédiaire lorsque la vidéo peut rester intacte
Le flux direct, souvent appelé remultiplexage ou transmultiplexage, est utilisé lorsque la vidéo peut être copiée, mais que le conteneur ou un autre flux doit être ajusté. Le serveur extrait les flux compatibles et les reconditionne dans un format accepté par le client, ce qui est bien moins coûteux que de décoder et de réencoder la vidéo.
La documentation d'Emby sur la lecture décrit le flux direct comme un reconditionnement en temps réel, dans lequel la piste vidéo reste intacte tandis que l'audio ou les sous-titres peuvent être convertis. Son mode de remultiplexage avec copie vidéo constitue une limite utile : la « diffusion en continu » ne signifie pas automatiquement que la vidéo est transcodée.
Ce mode convient lorsque le conteneur ou la compatibilité audio constitue le seul problème. Il n'est plus disponible lorsque la vidéo elle-même doit être modifiée, lorsque les sous-titres doivent être incrustés dans les images ou lorsque le débit ou la résolution transmis doit être réduit au-delà de ce que permet la copie du flux.
Le transcodage commence lorsque la vidéo doit être reconstruite
Le transcodage vidéo complet est la branche la plus coûteuse. Le serveur décode la source, peut redimensionner les images, appliquer une conversion de tonalité, désentrelacer, incruster les sous-titres ou filtrer les images d'une autre manière, puis encode un nouveau flux vidéo pour le client. L'audio peut être copié ou converti en parallèle.
La documentation de Jellyfin sur le transcodage distingue l'accélération matérielle du traitement logiciel et précise que les GPU modernes peuvent prendre en charge les traitements compatibles. Ce pipeline de conversion en temps réel explique pourquoi un même film peut représenter une tâche réseau légère sur un client et une tâche de calcul intensive sur un autre.
Le transcodage se justifie lorsque la compatibilité ou la bande passante exige réellement un nouveau flux vidéo. Si le client peut accepter la vidéo d'origine et que le réseau peut la transporter, forcer un réglage de qualité inférieur peut créer une charge serveur qui n'existait pas auparavant.
Comparez les trois modes selon quatre ressources communes
Les ressources serveur qui varient sont la puissance de calcul, les transferts mémoire, l'espace de stockage temporaire pour le transcodage et la bande passante réseau. La lecture directe réduit au minimum le calcul de conversion, mais peut transmettre la source à son débit maximal. Le transcodage peut réduire le débit sortant tout en augmentant la charge du processeur ou du GPU. Le flux direct se situe entre les deux, car les changements de conteneur sont généralement légers, tandis que toute conversion audio ajoute une certaine charge de calcul.
| Mode de lecture | Traitement vidéo | Demande de calcul typique | Comportement réseau | Principale limite de fonctionnement |
|---|---|---|---|---|
| Lecture directe | Vidéo et audio d'origine | La plus faible | Débit de la source | Incompatibilité du client ou du fichier |
| Flux direct | Vidéo copiée ; conteneur et éventuellement audio modifiés | Faible à modérée | Souvent proche du débit vidéo de la source | La vidéo elle-même doit être convertie |
| Transcodage | Vidéo décodée et réencodée | La plus élevée | Peut viser un débit ou une résolution inférieurs | Débit de traitement du calcul ou de l'accélérateur |
La présentation de FFmpeg sur l'accélération matérielle documente des API dédiées telles que NVENC/NVDEC et QSV pour le traitement vidéo. Cette couche de déport matériel n'est utile que pour la branche du transcodage ; elle ne rend pas la lecture directe plus directe.
Ne classez pas les modes selon une seule ressource. Un utilisateur distant sur une connexion montante lente peut avoir besoin d'un transcodage même si le serveur dispose d'une puissance de calcul suffisante, tandis qu'un client 4K local connecté en Ethernet filaire sera généralement mieux servi par une lecture directe au débit d'origine.
Les sous-titres et l'audio peuvent modifier le mode sans changer le fichier vidéo
Un utilisateur peut sélectionner une autre piste de sous-titres ou audio et faire basculer la session vers une autre branche. Les sous-titres textuels que le client peut afficher peuvent préserver la lecture directe, tandis que les sous-titres image ou un comportement de sous-titrage non pris en charge peuvent nécessiter une incrustation et donc un transcodage vidéo. Un audio multicanal non pris en charge peut déclencher une conversion audio alors que la vidéo reste copiée.
La documentation de HandBrake sur les performances est utile ici, car elle distingue le travail coûteux d'encodage vidéo des autres traitements et montre que les filtres peuvent rester des goulots d'étranglement, même avec un encodeur matériel. Cette répartition de la charge entre filtres et encodeur explique pourquoi l'activation du « transcodage matériel » ne rend pas chaque étape gratuite.
Lorsqu'un titre consomme soudainement plus de ressources serveur qu'un autre, comparez les pistes sélectionnées et la raison de la lecture avant de comparer les processeurs ou les GPU. La résolution affichée peut être identique alors que le mode de traitement est complètement différent.
Utilisez le tableau de bord de lecture comme outil de décision
Ne déduisez pas le mode de lecture à partir de la seule utilisation du processeur. Ouvrez les détails de session du serveur multimédia et vérifiez si la vidéo est lue directement, copiée ou remultiplexée, ou transcodée ; vérifiez ensuite si l'audio est copié ou converti et si les sous-titres sont rendus par le client ou incrustés dans la vidéo.
Le guide de ZimaSpace consacré à la forte utilisation du processeur pendant la lecture multimédia applique la même règle : identifiez la décision de traitement avant de considérer une forte utilisation comme un manque de puissance matérielle.
Lancez une session locale représentative, une session distante ou limitée en bande passante, ainsi qu'une session utilisant beaucoup de sous-titres. Si le tableau de bord indique déjà une lecture directe alors que la lecture s'interrompt encore, cessez de comparer la puissance de transcodage et examinez plutôt le stockage, la diffusion ou le client.
Choisissez le mode le plus léger qui respecte les contraintes de diffusion
Privilégiez la lecture directe lorsque le client prend en charge l'intégralité du fichier multimédia et que le réseau peut transporter son débit. Elle préserve la source et laisse la plus grande capacité serveur disponible pour les autres utilisateurs.
Utilisez le flux direct lorsque la compatibilité vidéo est déjà assurée, mais que le conteneur, l'audio ou le conditionnement doit être ajusté. Utilisez le transcodage uniquement lorsque la vidéo elle-même doit être modifiée pour des raisons de compatibilité, de bande passante, de résolution, de conversion HDR/SDR, d'incrustation des sous-titres ou pour toute autre contrainte réelle de diffusion.
Aucun mode ne s'impose dans tous les cas. La lecture directe réduit au minimum la charge de calcul, le flux direct résout à moindre coût les incompatibilités de conteneur et le transcodage offre une meilleure compatibilité ainsi qu'un contrôle du débit, au prix de ressources serveur supplémentaires. Une conception correcte de serveur multimédia maximise l'utilisation des deux premiers modes tout en conservant une capacité de transcodage suffisante pour les sessions qui ne peuvent éviter le troisième.
Comparaisons de produits
Plus à lire

Docker ou machine virtuelle pour Plex : quelle méthode de déploiement vous convient ?
Un verdict conditionnel sur le déploiement de Plex avec Docker, des machines virtuelles ou Docker dans une machine virtuelle, fondé sur des exigences opérationnelles...

8 Go, 16 Go ou 32 Go de RAM pour Plex : quel niveau convient à votre charge de travail ?
Choisissez 8 Go pour un Plex léger, 16 Go pour des applications partagées modérées, ou 32 Go pour les machines virtuelles et les espaces...

L’accélération matérielle dédiée offre-t-elle un avantage significatif à Plex ?
L’accélération matérielle est avantageuse pour les transcodages répétés pris en charge ; le traitement uniquement par le processeur reste adapté à la lecture directe,...

