Show HN: Kyoo – 자체 호스팅 미디어 브라우저(Jellyfin/Plex 대안)

 (github.com/zoriya)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 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: 저작권이 없는 영화로 구성된 라이브 데모 제공됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 데모가 예쁘고 잘 만들어졌음. 오디오는 Plexamp, 비디오는 Apple TV용 Plex 앱을 쓰는 만족스러운 Plex 사용자라 갈아탈 생각은 없지만, 관심 있던 기술을 배우기 위한 샌드박스 프로젝트에서 시작해 점점 커졌다는 이유는 무언가를 만들기에 정말 좋은 동기라고 봄

    • 오디오북도 듣는다면 Bookcamp도 확인해볼 만함. Plexamp로도 가능하겠지만, Bookcamp는 Audible 같은 느낌에 가까움
    • Plexamp를 어떻게 쓰는지 궁금함. 앨범을 내려받아 거기서 스트리밍하면서 Spotify 비슷한 대안으로 쓰는 방식인지?
    • Plexamp가 계속 Plex에 남아 있게 만드는 유일한 이유임
      Plex가 언젠가 enshittification 단계에 들어갈 때를 대비해 Jellyfin도 병행해서 구성해뒀지만, 2012년에 산 평생 멤버십은 지금까지 충분히 값어치를 했음

  • Plex에서 Jellyfin으로 갈아타려 했는데, Jellyfin은 라이브러리 관리에 별 관심이 없어 보이고 파일 구조에 지나치게 강한 가정을 두는 점이 가장 큰 한계였음
    위키에는 파일 이름을 올바르게 짓는 방법만 따로 설명한 섹션이 있는데, 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#은 웹 서버 쪽에서 빛을 발하니 이상하진 않음. 다만 개인적으로는 점점 덜 좋아하게 됨
      Kyoo도 일부 구성 요소에는 Python과 Go를 쓰고, 프런트엔드에는 TypeScript를 사용함
    • 이 프로젝트는 여러 언어로 작성된 것처럼 보임. C#, Go, Python이 보이고, 프런트엔드 코드도 있을 수 있지만 그쪽은 알레르기가 있음

  • Postgres와 RabbitMQ를 둘 다 쓰는 건 과해 보임. 운영 부담을 줄이기 위해 Postgres 하나로 맞추는 PR을 받아줄지 궁금함
    데스크톱으로 돌아가면 미디어 서버에서 RabbitMQ가 정확히 무엇을 하는지 살펴봐야겠음

    • RabbitMQ는 서비스 간 통신에 사용됨. 막 도입했지만 앞으로 클라이언트와의 웹소켓 통신, 새 항목 생성과 재스캔 요청을 위한 작업 큐, 외부 서비스와의 시청 목록 동기화, 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에 바로 연결되는 훅을 만들어서 캘린더 항목을 클릭하면 플레이어로 바로 이동할 수 있으면 좋겠음
    법적 문제 때문에 직접 만들기를 꺼릴 가능성은 있겠지만, 셀프 호스팅 미디어와 해적판 관리 기능을 하나의 인터페이스에 합치면 편리할 듯함

  • 좋아 보임. 데모 페이지에서 몇 개 영화를 눌러보고 임의로 탐색해봤는데 모든 게 완벽하게 동작했음
    확장성이 궁금함. 서버 하나가 어느 정도 사용자 수를 감당하는지, 어떤 종류의 서버가 필요한지 알고 싶음. 데모 페이지는 무엇 위에서 돌고 있으며, 사용자가 얼마나 많아지면 과부하가 걸릴지도 궁금함

    • 데모는 README의 docker-compose를 Oracle VPS Always Free 티어에서 돌리는 구성임
      서버 벤치마크는 해본 적 없지만, 제한 요인은 거의 확실히 머신의 인코딩 속도일 것임. 모든 클라이언트가 서로 다른 h265 8K 영화를 동시에 트랜스코딩해야 한다면, 같은 수의 사용자가 직접 재생하는 경우와는 완전히 다른 수준의 GPU/CPU 성능이 필요함
답변달기