Show HN: Kyoo – セルフホスト型メディアブラウザ（Jellyfin/Plexの代替）

 (github.com/zoriya)
4 ポイント 投稿者 GN⁺ 2024-04-07 | 1件のコメント | WhatsAppで共有
  • Kyooは映画、シリーズ、アニメのような映像コンテンツに特化したセルフホスト型メディアサーバーで、JellyfinやPlexの代替です
  • フォルダ構成の強制や手動でのメタデータ編集なしで動作することを目指しており、奇妙なファイル名のせいでメディアが正しくスキャンされない場合はバグと見なします
  • 機能はプラグインシステムで拡張せず、組み込み機能として提供する方針で、動的トランスコーディング、プレビューサムネイル、イントロ/クレジット検出、高度な字幕サポートを含みます
  • 現在クライアントはWebをサポートしており、Androidはv5ではまだ提供されておらず、iOSとtvOSのサポートはハードウェア購入と年間開発者費用約**$100**のため現時点では計画されていません
  • サーバー管理者はダウンロードディレクトリのファイルを別途整理せずに利用でき、Kyooは音楽・電子書籍・ゲームではなく映像ストリーミングに範囲を絞っています

Kyooが解決しようとしている問題

  • Kyooは映像コンテンツに特化したセルフホスト型メディアサーバーです
    • 対象コンテンツはMovies、Series、Animeです
    • JellyfinまたはPlexの代替として提示されています
  • メンテナンス負担を下げることを目指しています
    • 特定のフォルダ構成は不要です
    • 手動のメタデータ編集は不要です
    • 変わったファイル名でもメディアが正しくスキャンされるべきで、失敗した場合はバグとして扱います
  • プラグインシステムは提供しません
    • 機能は可能な限り組み込みで提供する方針です

主な機能

  • Dynamic Transcoding

    • メディアを希望する品質にトランスコードできます
    • 自動品質切り替えにより、再生中の品質変更が可能です
    • トランスコーダーを待たずにすぐシークできます

  • Video Preview Thumbnails

    • 動画の進行バーにマウスを乗せると映像プレビューを確認できます

  • Intro/Credit detection

    • オーディオフィンガープリンティングでイントロとクレジットを自動検出します
    • チャプタータイトルのマッチングも利用できます

  • Enhanced Subtitle Support

    • PGS/VODSUBおよびSSA/ASS字幕をサポートします
    • 可能な場合は動画に埋め込まれたフォントを使用します

  • Anime Name Parsing

    • [Some-Stuffs] Jojo's Bizarre Adventure Stone Ocean 24 (1920x1080 Blu-Ray Opus) [2750810F].mkv のような複雑なアニメのファイル名もマッチできます

  • Helm Chart

    • Kubernetesクラスターにデプロイできる公式Helm chartがあります
    • 複数replicaは作業中です

  • OIDC Connection

    • Google、Discord、AutheliaなどOIDC互換サービスでログインできます

まだv5に再実装されていない機能

  • Watch List Scrubbing Support

    • 連携サービスに視聴リストを自動同期する機能は、v5ではまだ再実装されていません
    • 対象はSIMKLおよび今後の他サービスです

  • Download and Offline Support

    • インターネットなしで視聴するためのダウンロードとオフラインサポートも、v5ではまだ再実装されていません
    • デバイスが再びオンラインになったときに進行状況を同期する機能として紹介されています

クライアントとプラットフォーム

  • 現在サポートされているクライアントはWebです
  • Androidクライアントはv5ではまだ提供されておらず、「soon」状態です
  • 追加プラットフォームは検討中です
  • フロントエンドはReact-NativeとExpoで作られています
  • Appleデバイスのサポートは現在計画されていません
    • 対象はiOSとtvOSです
    • 理由はハードウェア購入と年間開発者費用約**$100**です

Jellyfin/Plexとの違い

  • JellyfinとPlexは、技術的にはSQLiteに依存し、単一コンテナ内にすべてを収める方式として説明されています
  • Kyooは必要に応じて追加コンテナを使うアプローチを取っています
    • 例としてtranscoderが挙げられています
  • 運用思想は「一度設定したら忘れられる」方式です
    • 手動のファイル名変更を要求しません
    • 特定のフォルダ構成を要求しません
    • ダウンロードディレクトリのファイルをそのまま利用することを目指しています
  • 対象範囲は映画、TVショー、アニメのストリーミングに限定されています
    • 音楽、電子書籍、ゲームは扱いません

はじめ方と連携資料

  • API Documentation: Kyooを他サービスと統合するためのAPIドキュメント
  • Join the discord: 質問、開発議論、機能要望、バグ共有のためのDiscord
  • weblate: Kyooがまだ対応していない言語の翻訳を追加できます
  • kyoo.zoriya.dev: 著作権のない映画で構成されたライブデモが提供されています

関連記事

1件のコメント

 
GN⁺ 2024-04-07
Hacker Newsのコメント

  • デモは見栄えがよく、よくできている。オーディオは Plexamp、ビデオは Apple TV 向けの Plex アプリを使っていて満足している Plex ユーザーなので乗り換えるつもりはないが、興味のあった技術を学ぶためのサンドボックスプロジェクトとして始まり、だんだん大きくなっていったというのは、何かを作る動機として本当に良いと思う

    • オーディオブックも聴くならBookcampも見てみる価値がある。Plexamp でもできるのかもしれないが、Bookcamp の方が Audible のような感覚に近い
    • Plexamp をどう使っているのか気になる。アルバムをダウンロードして、そこからストリーミングしつつ Spotify に近い代替として使う感じなのか？
    • Plexampこそが、今も Plex に留まっている唯一の理由だ
      Plex がいつかenshittificationの段階に入ることに備えて Jellyfin も並行して構築してあるが、2012年に買った生涯メンバーシップは今までで十分元を取っている

  • Plex から Jellyfin へ乗り換えようとしたが、Jellyfin はライブラリ管理にあまり関心がないように見え、ファイル構造に対して過度に強い前提を置いているのが最大の限界だった
    Wiki にはファイル名を正しく付ける方法だけを説明する独立したセクションがあるが、Plex では気にしなくていい部分だ。Kyoo も似たようなアプローチなのか、それとももっとユーザーフレンドリーなのか気になる。Plex の収益化のやり方はばかげているが、Jellyfin はまだ本格的に使うには準備不足な感じがする

    • その点は本当に変だと思う。Kyoo の目標はライブラリを代わりに整理してくれることで、ダウンロードフォルダをそのままライブラリフォルダとして使っても、名前を変更せずすぐ動くようにすることだ
      まだ例外ケースはあり、とくに追加映像のような項目はうまく処理できないことがある。それでも "[SomeGroup] Jojo's bizzare adventure - golden wings 12.mkv" のような変なアニメのファイル名も処理できる
    • なぜメディアサーバーが構造にそこまで厳格である必要がないのか気になる。Jellyfin ではボタンをいくつか押せば勝手に処理してくれるのがよくて、自分で構造を考えなくて済むので楽だ
    • Jellyfin は使っているが、ファイル管理は**TMM(tiny media manager)**でやっている。Jellyfin は TMM が作る結果をうまく受け入れてくれる方だ
      正直、メディア管理コードは一切なく、ストリーミングだけをする軽量な Jellyfin も見てみたい
    • もちろん環境によるが、Jellyfin は手動タグ付けを使うには十分しっかり対応している。ファイルブラウザで見やすいように作ったフォルダ構造を壊したり、ファイル名を変えたりする必要はなく、ファイルやフォルダで「Identify」を押してタイトルや IMDB 番号で有効化したデータベースを検索すればよい
      フォルダがどの TV ショーか一度指定すれば、エピソードは自動認識されるようだ。フォルダ名が「正しく」ないと最初の段階が自動で進まないだけで、Tiny Media Manager で NFO ファイルを大量生成すれば回避できそうだ
    • Plex の収益化がなぜばかげているのか気になる。オープンソースに比べればプレミアム部分課金モデルは理想的ではないが、4年前に Plex Pass の生涯サブスクリプションを喜んで買ったし、今のところまったく後悔していない

  • 良さそうだ。メディアサーバープロジェクトはとくに**C#**を好む傾向があるようで興味深い。技術的な理由があるのか、それとも大きなプロジェクトが標準を作った結果に近いのか気になる

    • 関連ソフトウェアの大半、とくに***arr 系**も .NET で書かれている。開発者体験を犠牲にせず、それでいて性能も悪くないプラットフォームだ
    • C# は Web サーバー側で力を発揮するので不思議ではない。ただ個人的には、だんだん好きではなくなってきている
      Kyoo も一部のコンポーネントには Python と Go を使い、フロントエンドには TypeScript を使っている
    • このプロジェクトはいくつもの言語で書かれているようだ。C#、Go、Pythonが見えるし、フロントエンドのコードもあるのかもしれないが、その手のものにはアレルギーがある

  • Postgres と RabbitMQの両方を使うのはやりすぎに見える。運用負荷を減らすため、Postgres ひとつに寄せる PR を受け入れるのか気になる
    デスクトップに戻ったら、メディアサーバーで RabbitMQ が正確に何をしているのか見てみたい

    • RabbitMQ はサービス間通信に使っている。導入したばかりだが、今後はクライアントとの WebSocket 通信、新規項目作成や再スキャン要求のためのジョブキュー、外部サービスとの視聴リスト同期、Kubernetes デプロイ時の複数レプリカ間同期に使う予定だ
      ただし Kubernetes 側の同期はまだ作業が必要だ
    • RabbitMQは素晴らしい。プログラムの一部が他の部分より本質的に遅いときに、とくに役に立った
      非常に堅牢で実績のあるキューシステムを提供しつつ、実行負荷は小さい。そのおかげで構成をシンプルに保てる

  • 興味深いプロジェクトだ。ただ、「トランスコーダーを待たずに簡単にシークできる」という部分が気になる
    コンテナとコーデックによっては、これは常に問題だった。どう解決したのか、libavを使っていないのか気になる

    • 小さな動画区間ごとにffmpegを起動し、現在のトランスコード位置からあまりに離れた場所へシークすると新しい ffmpeg プロセスを作る
      難しいのは、それらの区間を途切れや問題なく視聴できるようにし、音声や映像の区間が重複しないことを保証することだ。十分に関心があるなら、詳しく説明するブログ記事を書くこともできる

  • 音楽を扱わないのが残念だ。Plex を使う主な理由は音楽ライブラリ管理で、Plex でも音楽は副次的な焦点のように感じるが、それでも十分実用になる

  • 数日前に n100 に Jellyfin と Tailscale を設定した。
    ローカルではうまく動いていたが、地球の反対側にいる家族に Tailscale で共有したところ、何かがおかしかった。アップロード速度は十分速いのに、ストリームが始まるまで 1 分ほどかかり、レイテンシーが関係しているのかもしれない。これを一度試してみる予定。

    • 似たような問題があった。WireGuard 上のリバースプロキシの背後に Jellyfin を置いていたが、大陸間の訪問者のようにレイテンシーが高い場合、最初は転送速度がそこそこ出ても、数秒以内に使い物にならないほど遅くなった。問題が パケット輻輳 に関係していると突き止めるまでかなり時間がかかった。
      Jellyfin とリバースプロキシサーバーで Linux のデフォルト輻輳制御（net.ipv4.tcp_congestion_control）を bbr に変更してみることを勧める。細かいことはよく分からず、副作用があるかもしれないし [1]、もっと良い輻輳制御アルゴリズムがあるかもしれないが、私の場合はこれで問題が完全に解決した。以前は静かで最適なネットワーク条件でも、接続が回線速度の 10% 未満、時には 1% まで落ち込んで止まっていた。
      また、Caddy はデフォルトで HTTP/3 を有効にするので、HTTP/2 に強制した。今後はさらに新しいバージョンの bbr も見てみる必要がありそうだ。
      [1] https://news.ycombinator.com/item?id=37408406

  • 本当に良さそう。TV に キャスト できるのか気になる。これだけが Plex に縛られている理由で、それ以外では Plex は好きではない。

    • まだできない。かなり重要な機能なので今後 6 か月以内に 提供する予定だが、その前にまずクライアント機能の大半を仕上げたい。
    • Jellyfin のキャストは以前はかなり微妙だったが、最近はずっと良くなっている。最後に不便を感じたのがいつだったか思い出せないほどだ。
    • Mac のブラウザで開いて AirPlay で Apple TV に送ればよい。Windows でもキャスト系の機能で同様にできる。

  • Plex が向かっている方向を見ると、選択肢が増えるのはうれしい。Sonarr/Radarr に直接つながるフックを作って、カレンダー項目をクリックしたらプレーヤーに直接移動できるとよさそう。
    法的な問題のために直接作るのを避ける可能性はあるが、セルフホストのメディアと海賊版管理機能を 1 つのインターフェースに統合できれば便利そうだ。

  • 良さそう。デモページでいくつか映画をクリックして適当に見て回ったが、すべてが完璧に動作した。
    スケーラビリティ が気になる。サーバー 1 台でどの程度のユーザー数をさばけるのか、どんな種類のサーバーが必要なのか知りたい。デモページが何の上で動いているのか、どれくらいユーザーが増えると過負荷になるのかも気になる。

    • デモは README の docker-compose を Oracle VPS Always Free ティアで動かしている構成。
      サーバーのベンチマークはしたことがないが、制限要因はほぼ確実にマシンのエンコード速度になる。すべてのクライアントが異なる h265 8K 映画を同時にトランスコードしなければならないなら、同じ人数がダイレクト再生する場合とはまったく別レベルの GPU/CPU 性能が必要になる。