Pourquoi la lecture Jellyfin diffère entre les clients natifs et les navigateurs

La lecture dans Jellyfin diffère, car les applications natives et les navigateurs annoncent des capacités différentes en matière de codecs, de sous-titres, de HDR, de décodage et de mise en mémoire tampon.

Le même fichier peut être lu en lecture directe dans l’application d’un téléviseur, mais déclencher un remuxage ou un transcodage complet dans un navigateur. Cela modifie à la fois la sortie et les ressources mobilisées côté serveur. Conservez le média, le réseau et le serveur constants, et ne changez que le client afin que la différence observée soit liée aux capacités ou au comportement de rendu.

La négociation des capacités détermine le parcours

Jellyfin compare le conteneur source, la vidéo, l’audio, le mode HDR et les sous-titres avec ce que le client peut accepter. Une capacité manquante transforme un mode de diffusion peu coûteux en travail de conversion supplémentaire.

Notez le mode du profil des capacités du client pour un fichier connu sur les deux clients avant d’évaluer la qualité de lecture.

C’est pourquoi « le même média » n’implique pas la même charge de travail pour le serveur.

Les limites des navigateurs peuvent transférer le travail au serveur

Les navigateurs utilisent souvent un ensemble de capacités multimédias plus limité ou différent de celui des applications natives. Un format audio, un HDR, des sous-titres ou des conteneurs non pris en charge peuvent nécessiter un remuxage ou un transcodage vidéo, même si le navigateur lui-même semble rapide.

Une comparaison réelle de la charge de transcodage aide à montrer quand la prise en charge par le client modifie le parcours côté serveur.

Si le scénario avec navigateur utilise un parcours plus lourd, la différence de sortie est une conséquence de la compatibilité, et non une préférence mystérieuse du serveur.

Le décodage côté client modifie également la fluidité

Un appareil natif peut utiliser le décodage matériel, tandis qu’un navigateur peut emprunter un autre décodeur ou une autre stratégie de mise en mémoire tampon. Cela influe sur le démarrage, la recherche, les images perdues et la batterie, sans nécessairement modifier le débit côté serveur.

L’article sur le comportement des clients Jellyfin distingue la prise en charge des codecs, le décodage matériel et la réactivité de l’interface comme des mesures différentes.

Gardez les tests de lecture et d’interface séparés : une grille d’affiches rapide ne prouve pas qu’un flux à haut débit est fluide.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez un contrôle client avec un fichier connu

Lisez un fichier sur l’application native et dans le navigateur, dans les mêmes conditions réseau et serveur. Notez le mode de lecture, le délai avant la première image, le niveau de mise en mémoire tampon en régime stable et le comportement des images côté client.

Utilisez la comparaison des clients Jellyfin dans l’article sur le comportement des clients Jellyfin uniquement après avoir identifié le parcours de lecture ; sinon, la latence de l’interface peut être confondue avec un échec de diffusion du flux.

Arrêtez-vous lorsque la capacité du client modifiée explique la sortie et les métriques du serveur. N’adaptez pas le matériel du serveur à une limite de rendu propre au client.