Show HN : Kyoo – navigateur multimédia auto-hébergé (alternative à Jellyfin/Plex)

 (github.com/zoriya)
4 points par GN⁺ 2024-04-07 | 1 commentaires | Partager sur WhatsApp
  • Kyoo est un serveur multimédia auto-hébergé centré sur les contenus vidéo comme les films, les séries et les anime, et se présente comme une alternative à Jellyfin ou Plex
  • Le projet vise à fonctionner sans imposer de structure de dossiers ni d’édition manuelle des métadonnées, et considère comme un bug tout cas où un média n’est pas correctement scanné à cause d’un nom de fichier étrange
  • Les fonctionnalités ne sont pas étendues via un système de plugins, mais fournies sous forme de fonctions intégrées, notamment le transcodage dynamique, les miniatures d’aperçu, la détection des intros/crédits et la prise en charge avancée des sous-titres
  • Actuellement, le client prend en charge le Web ; Android n’est pas encore disponible en v5, et la prise en charge d’iOS et de tvOS n’est pas prévue pour le moment en raison de l’achat de matériel et des frais annuels de développeur d’environ 100 $
  • Les administrateurs du serveur peuvent utiliser les fichiers du répertoire de téléchargement sans réorganisation particulière, et Kyoo limite son périmètre au streaming vidéo, pas à la musique, aux ebooks ni aux jeux

Le problème que Kyoo cherche à résoudre

  • Kyoo est un serveur multimédia auto-hébergé spécialisé dans les contenus vidéo
    • Les contenus visés sont les films, les séries et les anime
    • Il est présenté comme une alternative à Jellyfin ou Plex
  • L’objectif est de réduire la charge de maintenance
    • Aucune structure de dossiers spécifique n’est requise
    • Aucune édition manuelle des métadonnées n’est nécessaire
    • Les médias doivent être correctement scannés même avec des noms de fichiers bizarres ; sinon, c’est considéré comme un bug
  • Aucun système de plugins n’est proposé
    • L’orientation est d’intégrer autant que possible les fonctionnalités en natif

Fonctionnalités principales

  • Dynamic Transcoding

    • Les médias peuvent être transcodés dans la qualité souhaitée
    • Le changement automatique de qualité permet d’ajuster la qualité pendant la lecture
    • La navigation est immédiate, sans attendre le transcodeur

  • Video Preview Thumbnails

    • Un aperçu vidéo s’affiche au survol de la barre de progression

  • Intro/Credit detection

    • Les intros et les crédits sont détectés automatiquement via l’empreinte audio
    • La correspondance des titres de chapitres peut aussi être utilisée

  • Enhanced Subtitle Support

    • Prise en charge des sous-titres PGS/VODSUB et SSA/ASS
    • Les polices intégrées à la vidéo sont utilisées lorsque c’est possible

  • Anime Name Parsing

    • Peut faire correspondre des noms de fichiers d’anime complexes comme [Some-Stuffs] Jojo's Bizarre Adventure Stone Ocean 24 (1920x1080 Blu-Ray Opus) [2750810F].mkv

  • Helm Chart

    • Un Helm chart officiel est disponible pour le déploiement sur un cluster Kubernetes
    • Le multi-réplique est en cours de développement

  • OIDC Connection

    • Il est possible de se connecter via des services compatibles OIDC comme Google, Discord ou Authelia

Fonctionnalités pas encore réimplémentées en v5

  • Watch List Scrubbing Support

    • La synchronisation automatique de la liste de visionnage avec les services connectés n’a pas encore été réimplémentée dans la v5
    • Cela concerne SIMKL et potentiellement d’autres services à l’avenir

  • Download and Offline Support

    • Le téléchargement pour visionnage hors ligne et la prise en charge offline n’ont pas non plus encore été réimplémentés dans la v5
    • La fonctionnalité est présentée avec une synchronisation de la progression lorsque l’appareil se reconnecte

Clients et plateformes

  • Le client actuellement pris en charge est le Web
  • Le client Android n’est pas encore disponible en v5 et est indiqué comme « soon »
  • D’autres plateformes sont à l’étude
  • Le frontend est construit avec React-Native et Expo
  • La prise en charge des appareils Apple n’est actuellement pas prévue
    • Cela concerne iOS et tvOS
    • La raison invoquée est l’achat de matériel et les frais annuels de développeur d’environ 100 $

Différences avec Jellyfin/Plex

  • Jellyfin et Plex sont décrits comme reposant techniquement sur SQLite et sur une approche qui regroupe tout dans un seul conteneur
  • Kyoo adopte une approche utilisant des conteneurs supplémentaires si nécessaire
    • Le transcoder est donné en exemple
  • La philosophie d’exploitation est celle du « configurer une fois puis oublier »
    • Aucun renommage manuel des fichiers n’est requis
    • Aucune structure de dossiers spécifique n’est imposée
    • L’objectif est d’utiliser directement les fichiers du répertoire de téléchargement
  • Le périmètre est limité au streaming de films, de séries TV et d’anime
    • La musique, les ebooks et les jeux ne sont pas pris en charge

Démarrage et ressources d’intégration

  • API Documentation : documentation API pour intégrer Kyoo à d’autres services
  • Join the discord : Discord pour les questions, discussions de développement, demandes de fonctionnalités et signalements de bugs
  • weblate : possibilité d’ajouter des traductions pour les langues que Kyoo ne prend pas en charge
  • kyoo.zoriya.dev : démo live composée de films libres de droits

À lire aussi

1 commentaires

 
GN⁺ 2024-04-07
Avis sur Hacker News

  • La démo est jolie et bien réalisée. Je suis un utilisateur satisfait de Plex, avec Plexamp pour l’audio et l’app Plex sur Apple TV pour la vidéo, donc je n’ai pas l’intention de migrer, mais je trouve que partir d’un projet bac à sable pour apprendre des technologies qui t’intéressaient, puis le voir prendre de l’ampleur, est une excellente motivation pour créer quelque chose.

    • Si tu écoutes aussi des livres audio, Bookcamp vaut le coup d’œil. Plexamp peut probablement le faire aussi, mais Bookcamp se rapproche davantage de l’expérience Audible.
    • Je me demande comment tu utilises Plexamp. Tu télécharges des albums puis tu les streames depuis là, comme une sorte d’alternative à Spotify ?
    • Plexamp est la seule raison qui me retient chez Plex.
      J’ai aussi configuré Jellyfin en parallèle au cas où Plex entrerait un jour dans une phase d’enshittification, mais l’abonnement à vie que j’ai acheté en 2012 a largement été rentabilisé jusqu’ici.

  • J’ai essayé de passer de Plex à Jellyfin, mais la plus grosse limite de Jellyfin, à mes yeux, c’est qu’il semble assez peu s’intéresser à la gestion de bibliothèque et qu’il fait des hypothèses très fortes sur la structure des fichiers.
    Le wiki a même une section dédiée expliquant comment nommer correctement les fichiers, ce dont on n’a pas à se soucier avec Plex. Je me demande si Kyoo adopte une approche similaire, ou s’il est plus convivial. Le modèle de monétisation de Plex est aberrant, mais Jellyfin ne me semble pas encore prêt pour un usage sérieux.

    • Je trouve ça vraiment étrange. L’objectif de Kyoo est justement d’organiser la bibliothèque à ta place, et tu devrais pouvoir utiliser directement ton dossier de téléchargements comme dossier de bibliothèque, sans rien renommer.
      Il reste encore des cas particuliers, et les éléments comme les vidéos bonus ne sont pas toujours bien gérés. Mais même des noms de fichiers d’anime bizarres comme "[SomeGroup] Jojo's bizzare adventure - golden wings 12.mkv" sont pris en charge.
    • Je me demande pourquoi un serveur média devrait être moins strict sur la structure. J’aime le fait que Jellyfin s’en sorte en appuyant sur quelques boutons, sans avoir à réfléchir moi-même à l’organisation.
    • J’utilise Jellyfin, mais je gère mes fichiers avec TMM (tiny media manager). Jellyfin accepte plutôt bien les résultats produits par TMM.
      Honnêtement, j’aimerais aussi voir un Jellyfin léger, qui ne fasse aucune gestion de médias et se contente du streaming.
    • Bien sûr, ça dépend des environnements, mais Jellyfin prend suffisamment bien en charge le taggage manuel pour être utilisable. Il n’est pas nécessaire de casser la structure de dossiers que tu as créée pour qu’elle soit pratique dans un navigateur de fichiers, ni de renommer les fichiers : il suffit de cliquer sur "Identify" depuis un fichier ou un dossier et de rechercher dans les bases de données activées par titre ou numéro IMDB.
      Une fois que tu as indiqué à quelle série TV correspond un dossier, les épisodes semblent être reconnus automatiquement. La seule chose qui ne se fait pas automatiquement, c’est la première étape quand le nom du dossier n’est pas « correct », et générer en masse des fichiers NFO avec Tiny Media Manager permettrait probablement de contourner ça.
    • Je me demande en quoi la monétisation de Plex est aberrante. Par rapport à l’open source, un modèle freemium premium est certes moins idéal, mais j’ai acheté volontiers un Plex Pass à vie il y a 4 ans et je ne l’ai absolument pas regretté depuis.

  • Ça a l’air bien. Je trouve intéressant que les projets de serveurs média semblent avoir une préférence particulière pour C#. Je me demande s’il y a une raison technique, ou si c’est plutôt parce que les gros projets ont fini par imposer un standard.

    • La plupart des logiciels liés, notamment la famille *arr, sont aussi écrits en .NET. C’est une plateforme assez performante sans sacrifier l’expérience développeur.
    • C# brille côté serveurs web, donc ce n’est pas surprenant. Cela dit, personnellement, je l’apprécie de moins en moins.
      Kyoo utilise aussi Python et Go pour certains composants, et TypeScript pour le frontend.
    • Ce projet semble écrit dans plusieurs langages. On voit du C#, Go, Python, et il y a peut-être aussi du code frontend, mais j’y suis allergique.

  • Utiliser à la fois Postgres et RabbitMQ me paraît excessif. Je me demande s’ils accepteraient une PR pour tout ramener à Postgres afin de réduire la charge d’exploitation.
    Quand je serai de retour sur desktop, il faudra que je regarde ce que RabbitMQ fait exactement dans un serveur média.

    • RabbitMQ est utilisé pour la communication entre services. Il vient tout juste d’être introduit, mais il est prévu pour la communication WebSocket avec les clients, les files de tâches pour la création de nouveaux éléments et les demandes de rescan, la synchronisation de la liste de visionnage avec des services externes, et la synchronisation entre plusieurs réplicas lors d’un déploiement Kubernetes.
      Cela dit, la partie synchronisation Kubernetes demande encore du travail.
    • RabbitMQ est excellent. Il s’est montré particulièrement utile quand certaines parties d’un programme sont intrinsèquement plus lentes que d’autres.
      Il fournit un système de file très robuste et éprouvé, tout en restant peu contraignant à exécuter. Ça permet de garder une architecture simple.

  • Projet intéressant. En revanche, je m’interroge sur la partie « naviguer facilement sans attendre le transcodeur ».
    Selon le conteneur et le codec, ça a toujours été un problème. Je me demande comment ils l’ont résolu, et s’ils n’utilisent pas libav.

    • ffmpeg est lancé pour chaque petit segment vidéo, et si l’on navigue trop loin de la position de transcodage actuelle, un nouveau processus ffmpeg est créé.
      La partie difficile consiste à faire en sorte que ces segments puissent être regardés sans coupure ni problème, et à garantir qu’aucun segment audio ou vidéo ne se répète. S’il y a assez d’intérêt, je pourrais écrire un billet de blog qui l’explique en détail.

  • Dommage que la musique ne soit pas prise en charge. La principale raison pour laquelle j’utilise Plex, c’est la gestion de bibliothèque musicale ; même dans Plex, la musique semble être un sujet secondaire, mais ça reste suffisamment utilisable.

  • Il y a quelques jours, j’ai configuré Jellyfin et tailscale sur un n100.
    En local, ça marchait bien, mais quand je l’ai partagé via tailscale avec ma famille à l’autre bout du monde, quelque chose ne fonctionnait pas correctement. Même avec une vitesse d’upload largement suffisante, il fallait environ une minute pour que le stream démarre ; c’est peut-être lié à la latence. Je compte essayer ça

    • J’ai eu un problème similaire. J’avais placé Jellyfin derrière un reverse proxy au-dessus de WireGuard, et dans les cas de forte latence, comme avec des visiteurs intercontinentaux, le débit montait correctement au début puis devenait inutilisablement lent en quelques secondes. Il m’a fallu longtemps pour identifier que le problème était lié à la congestion des paquets.
      Je recommande d’essayer de passer le contrôle de congestion Linux par défaut (net.ipv4.tcp_congestion_control) à bbr sur Jellyfin et sur le serveur de reverse proxy. Je ne connais pas les détails et il peut y avoir des effets de bord [1], et il existe peut-être de meilleurs algorithmes de contrôle de congestion, mais dans mon cas cela a complètement résolu le problème. Avant, même dans des conditions réseau calmes et optimales, la connexion plafonnait à moins de 10 % du débit de la ligne, parfois jusqu’à 1 %.
      Par ailleurs, Caddy active HTTP/3 par défaut, donc je l’ai forcé en HTTP/2. Il faudra aussi que je regarde plus tard des versions plus récentes de bbr.
      [1] https://news.ycombinator.com/item?id=37408406

  • Ça a vraiment l’air bien. Je me demande s’il est possible de caster vers une TV. C’est la seule raison qui me retient sur Plex, et à part ça je n’aime pas Plex

    • Pas encore. C’est une fonctionnalité assez importante, donc je prévois de la proposer dans les 6 prochains mois, mais avant ça j’aimerais d’abord finaliser la plupart des fonctionnalités des clients
    • Le cast de Jellyfin était assez mauvais auparavant, mais il s’est beaucoup amélioré récemment. Je ne me souviens même plus de la dernière fois où ça m’a posé problème
    • Il suffit de l’ouvrir dans un navigateur sur Mac et de l’envoyer vers l’Apple TV avec AirPlay. Sous Windows, on peut faire quelque chose de similaire avec les options de cast

  • Vu la direction que prend Plex, c’est agréable d’avoir davantage d’options. Ce serait bien de créer des hooks qui se connectent directement à SONARR/RADARR, afin qu’un clic sur un élément du calendrier mène directement au lecteur.
    Ils hésiteront peut-être à le faire eux-mêmes pour des raisons juridiques, mais combiner le média self-hosted et les fonctions de gestion du piratage dans une seule interface serait pratique

  • Ça a l’air bien. J’ai cliqué sur quelques films sur la page de démo et navigué au hasard, et tout fonctionnait parfaitement.
    Je me pose la question de la scalabilité. J’aimerais savoir combien d’utilisateurs un seul serveur peut supporter et quel type de serveur est nécessaire. Je me demande aussi sur quoi tourne la page de démo, et à partir de combien d’utilisateurs elle risquerait d’être surchargée

    • La démo correspond à la configuration du docker-compose du README, exécutée sur le niveau Always Free d’un VPS Oracle.
      Je n’ai jamais fait de benchmark du serveur, mais le facteur limitant sera presque certainement la vitesse d’encodage de la machine. Si tous les clients doivent transcoder simultanément des films h265 8K différents, il faudra un niveau de performances GPU/CPU complètement différent de celui nécessaire au même nombre d’utilisateurs en lecture directe