다중 사용자 스트리밍이 Jellyfin의 트랜스코딩 워크플로를 어떻게 바꾸는가

다중 사용자 스트리밍은 Jellyfin을 단일 재생 경로에서 공유 대기열로 바꾸며, 병목은 각 클라이언트의 호환성과 비트레이트에 따라 달라집니다.

한 가정에서 몇 분 안에 TV에서 직접 재생되는 스트림 하나, 자막이 포함된 태블릿 세션 하나, 원격 휴대폰 세션 하나가 시작될 수 있습니다. 이러한 요청은 동일한 리소스를 소비하지 않습니다. 하나는 저장 장치에서 파일을 읽기만 할 수 있고, 다른 하나는 비디오 트랜스코딩 과정에서 자막을 삽입할 수 있으며, 원격 클라이언트는 업로드 제약까지 추가할 수 있습니다. 사용자 수만 세는 것보다 이러한 불균등한 작업량을 이해하는 편이 더 유용합니다.

사용자 요청 하나가 네 가지 경로로 나뉠 수 있습니다

Jellyfin은 먼저 미디어 컨테이너, 비디오 코덱, 오디오 코덱, 자막, 해상도, 비트레이트를 요청한 클라이언트가 처리할 수 있다고 보고한 조건과 비교합니다. 이 비교 결과에 따라 직접 재생, 리먹싱, 오디오 변환 또는 전체 비디오 트랜스코딩이 선택되므로, 같은 제목을 연 두 사용자도 서버에 전혀 다른 작업을 발생시킬 수 있습니다.

원본 파일을 지원하는 클라이언트는 대부분 서버를 파일 리더로 만들지만, 호환되지 않는 브라우저는 디코딩 및 인코딩 단계를 요구할 수 있습니다. 직접 재생 동작에 대한 실용적인 설명은 변환을 피하면 재생 경로에서 상당한 처리 작업이 제거되는 이유를 보여 줍니다.

그 결과 부하가 비대칭적으로 나타납니다. 요청 하나가 호환성 경계를 넘기 전까지는 스트림 수가 늘어도 CPU 사용량이 그에 맞춰 증가하지 않을 수 있습니다. 따라서 올바른 단위는 “사용자 수”가 아니라 직접 재생, 리먹싱, 오디오 트랜스코딩, 비디오 트랜스코딩 세션의 구성입니다.

동시 트랜스코딩은 특정 파이프라인 단계에서 경쟁합니다

전체 트랜스코딩은 읽기, 디코딩, 필터링, 인코딩, 임시 세그먼트 쓰기, 전달이 이어지는 과정입니다. 여러 세션이 하드웨어 비디오 엔진, CPU 기반 자막 렌더러, 트랜스코딩 캐시 또는 외부 네트워크 링크처럼 동일한 희소 단계에 의존할 때 동시성이 중요해집니다.

하드웨어 가속은 일반 CPU 코어에서 디코딩 및 인코딩 작업을 분리할 수 있지만, 필터링, 자막, 저장 장치 또는 네트워크 비용까지 없애지는 않습니다. 실제 사용 사례를 다룬 하드웨어 가속 트랜스코딩 설명에서도 GPU 오프로딩과 파이프라인 전체가 비용 없이 작동하는 것은 구분됩니다.

가장 느린 공유 단계가 재생 시 소비되는 속도보다 빠르게 미디어를 생성하지 못하면 대기열이 늘어나고 클라이언트의 버퍼가 소진됩니다. 다른 곳의 더 빠른 구성 요소로는 이를 보완할 수 없습니다. 남는 CPU로 포화된 업로드 문제를 해결할 수 없고, 남는 대역폭으로 소프트웨어 자막 삽입 문제를 해결할 수도 없습니다.

오픈 소스 제어가 용량 계획을 바꿉니다

Jellyfin은 재생 결정을 공개하고 FFmpeg 기반 변환을 사용하며, 하드웨어 가속을 구독 요금제 뒤에 숨기지 않습니다. 따라서 작업 흐름을 확인하고 구성할 수 있지만, 드라이버, 장치 접근 권한, 코덱, 클라이언트 동작을 서로 맞추는 책임도 운영자에게 있습니다.

이러한 제어의 가치는 홈 서버에서 여러 애플리케이션을 실행할 때 드러납니다. 소유자는 어떤 작업이 GPU를 공유할지, 백그라운드 작업을 언제 실행할지 결정할 수 있습니다. 클라이언트 제한 파이프라인은 단일 세션의 기반을 제공하며, 다중 사용자 계획에서는 이러한 파이프라인 간의 경쟁까지 고려해야 합니다. 전체 전달 경로를 고려하면 동일한 운영 경계는 직접 재생 동작에도 일관되게 적용됩니다.

따라서 오픈 소스는 변환에 드는 물리적 비용이 아니라 누가 시스템을 조정할 수 있는지를 바꿉니다. 제어 기능이 많아진다고 처리량이 자동으로 증가하는 것은 아니며, 가속 경로가 잘못 구성되면 인터페이스가 여전히 사용 가능한 것처럼 보여도 CPU 작업으로 조용히 폴백할 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

사용자 수로 성능을 예측하기 어려워지는 지점

대부분의 클라이언트가 직접 재생을 사용할 때는 사용자 수가 성능을 제대로 예측하지 못합니다. 호환되는 1080p 세션 여러 개보다 까다로운 HDR 자막 세션 두 개가 더 큰 비용을 유발할 수 있습니다. 또한 저장 장치나 업로드가 이미 포화된 경우에도 이 기준은 더 이상 적용되지 않습니다. 이때는 변환 용량이 제어 변수이지 않기 때문입니다.

원격 동시 접속은 표시된 다운로드 속도가 아니라 실제로 사용할 수 있는 업스트림 용량과 비교해야 합니다. 업로드 속도를 스트림 비트레이트로 나누는 방식에 기반한 대역폭 계획 예시는 제한 관계를 명확하게 보여 주지만, 원본 비트레이트가 순간적으로 높아질 수 있으므로 여유 용량도 필요합니다. 별도의 현장 보고서 역시 눈에 보이는 증상만으로 병목을 추정하기보다 세션 수준의 트랜스코딩 지표를 사용해야 한다는 점을 뒷받침합니다.

하드웨어를 변경하기 전에 네 줄짜리 세션 기록을 작성하세요. 동시에 연결된 각 클라이언트에 대해 재생 모드, 원본 및 전달 비트레이트, 자막 방식, 활성 CPU/GPU 엔진을 기록하면 됩니다. 반복 테스트에서 동일한 단계가 포화된 것으로 확인될 때만 업그레이드하고, 그렇지 않다면 먼저 호환되지 않는 클라이언트, 미디어 버전 또는 대역폭 목표를 변경하세요.