자막이 포함된 Jellyfin 및 HDR 재생을 위한 홈 서버 사양 정하기

HDR과 자막을 지원하는 Jellyfin 서버의 규모를 정하려면 Direct Play, 톤 매핑 또는 번인을 유발하는 정확한 클라이언트-파일-자막 조합을 테스트하세요.

HDR을 지원하는 클라이언트가 원본 비디오, 오디오, 컨테이너 및 자막 경로를 그대로 처리하면 서버의 HDR 재생은 간단하며, 같은 파일도 다른 화면에서는 무거운 변환 작업이 될 수 있습니다. 간단한 작업 부하 매트릭스를 만들고, 피할 수 없는 비디오 작업에는 하드웨어 가속을 할당하며, 필터링 및 폴백 단계에 필요한 CPU 여유를 확보하세요. RAM을 늘리거나 GPU를 추가하거나 연산과 스토리지를 분리하기 전에 가정 내 최악의 상황을 검증해야 합니다.

클라이언트, HDR 형식 및 자막 유형으로 크기 산정 매트릭스 만들기

중요한 화면을 목록으로 정리하세요. 주 HDR TV, SDR TV 또는 프로젝터, 브라우저, 휴대폰, 태블릿 및 원격 클라이언트를 포함합니다. 각각에 대해 자막 없이 재생하는 4K HEVC HDR 파일, 단순 텍스트 자막 파일, 그리고 실제 라이브러리에 있는 이미지 기반 또는 스타일이 적용된 자막 형식을 대표하는 파일을 테스트하세요.

기기에 “4K 지원”이라고 적는 대신 실제 재생 경로를 기록하세요. 같은 클라이언트도 HDR 콘텐츠 하나는 Direct Play로 재생하고, 다른 콘텐츠는 컨테이너나 오디오 때문에 리먹스하며, 자막을 로컬에서 렌더링할 수 없으면 비디오 변환이 필요할 수 있습니다. 이 경로가 서버 규모 산정의 입력값입니다.

실제로 보유한 비트레이트와 프레임 속도로 테스트하세요. 짧은 데모 클립만으로는 고비트레이트 영화 전체, 특수한 자막 트랙 또는 원격 화질 제한도 같은 경로를 따를 것이라고 입증할 수 없습니다.

기본 HDR 재생과 HDR-SDR 변환을 분리해서 보기

HDR을 지원하는 클라이언트가 소스를 그대로 처리할 수 있으면 서버는 대부분 데이터를 전송하기만 하므로 필요한 연산 성능도 크지 않습니다. 목적지가 SDR이거나 호환되지 않는 다른 출력 형식을 요구해 서버가 비디오를 디코딩하고 색상과 밝기를 변환한 뒤 새 비디오 스트림으로 인코딩해야 할 때 어려운 상황이 발생합니다.

변환이 불가피하다면 대시보드 옵션이 활성화되어 있다는 이유만으로 GPU가 작동한다고 가정하지 말고, 실제 호스트에서 하드웨어 가속 Jellyfin 트랜스코딩을 구성하고 검증하세요. 하드웨어 미디어 엔진은 일반 CPU 작업을 크게 줄일 수 있지만, 전체 경로는 코덱, 드라이버, 필터, 권한 및 클라이언트 요청에 따라 달라집니다.

라이브러리의 모든 HDR 파일이 아니라 실제로 필요한 변환을 기준으로 규모를 정하세요. 원격 SDR 기기 한 대만 톤 매핑을 필요로 한다면 검증된 고부하 경로 하나가 관련 기준입니다. 가정 내 사용자 두 명이 동시에 이 경로를 실행할 수 있다면 서버가 충분하다고 판단하기 전에 두 개의 동시 세션을 테스트하세요.

자막 번인을 별도의 규모 산정 기준으로 다루기

서버 예산에서 자막은 사소한 장식이 아닙니다. 클라이언트가 렌더링할 수 있는 텍스트 트랙은 Direct Play를 유지할 수 있지만, 이미지 기반이거나 호환되지 않는 자막은 서버가 모든 비디오 프레임에 자막을 렌더링해야 하므로 부하가 낮은 세션을 전체 비디오 파이프라인으로 바꿀 수 있습니다.

자막으로 인한 트랜스코딩에 관한 별도 가이드에서는 클라이언트가 PGS와 VobSub을 직접 렌더링하지 못할 때 Jellyfin이 번인을 수행하게 되는 일반적인 사례로 설명합니다. 콘텐츠에 적합하다면 텍스트 기반 SRT 옵션을 유지하되, 품질이나 스타일이 중요하면 원본 트랙을 보존하고 여전히 번인이 필요한 클라이언트를 기준으로 서버 규모를 정하세요.

두 요구 사항이 겹칠 수 있으므로 동일한 HDR 파일에 자막을 적용해 테스트하세요. 한 요청에서 서버가 디코딩, 자막 렌더링, HDR-SDR 톤 매핑, 크기 조정 및 인코딩을 모두 수행해야 할 수 있습니다. “4K” 자체가 아니라 이 결합된 경로가 규모가 부족하거나 가속이 부분적으로만 적용된 설정을 드러낼 가능성이 가장 높은 시나리오입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

CPU, 미디어 엔진 및 메모리를 서로 다른 역할로 할당하기

플랫폼이 지원한다면 하드웨어 비디오 엔진을 사용해 디코딩, 필터링, 톤 매핑 및 인코딩 단계를 가속하세요. Jellyfin 자체, 오디오 변환, 소프트웨어로 폴백되는 자막 관련 작업, 데이터베이스 작업 및 호스트를 공유하는 다른 서비스에는 CPU 성능을 남겨 두세요.

메모리는 일반적으로 HDR 재생의 첫 번째 병목이 아니므로 32GB를 비디오 품질 향상으로 여기지 마세요. 작업 부하가 대부분 Direct Play라면 Jellyfin 중심 호스트는 적은 메모리로도 충분할 수 있습니다. 다른 컨테이너, 가상 머신, 대형 캐시 또는 동시에 실행되는 백그라운드 서비스로 측정 가능한 메모리 부족이 발생할 때 메모리를 추가하세요.

규모 산정을 멈출 기준은 목표 파이프라인에서 나타나는 리소스 동작입니다. GPU 또는 비디오 엔진에 여유가 있고, 폴백 단계로 인해 CPU가 과부하되지 않으며, 메모리 스와핑이 발생하지 않고, 재생 버퍼 여유가 유지된다면 테스트한 스트림의 성능은 코어 또는 RAM을 더 추가해도 향상되지 않습니다.

앱 데이터를 빠른 저장소에 두고 트랜스코딩 임시 공간에 충분한 처리량 제공하기

Jellyfin 구성, 데이터베이스, 메타데이터 및 캐시는 지연 시간이 짧은 SSD 저장소에 배치하세요. 대용량 영화와 에피소드는 원본 비트레이트를 안정적으로 전달할 수 있는 용량 중심 저장소에 보관하고, 긴 세션 동안 시스템 디스크가 가득 차지 않도록 트랜스코딩 작업 공간을 충분한 처리량을 제공하는 경로에 두세요.

미디어가 별도의 NAS에 있다면 연산 장치와 스토리지 사이의 연결도 테스트에 포함하세요. 고부하 트랜스코딩은 새 출력을 클라이언트로 보내기 전에 해당 경로를 통해 원본 소스를 읽으며, 동시에 실행되는 백업이나 파일 전송이 같은 연결을 사용할 수도 있습니다.

재생에 문제가 발생하면 자막 또는 HDR 변환 상황에서 Jellyfin 버퍼링 진단하기에 설명된 것과 같은 단계별 방법을 사용하세요. 먼저 Direct Play인지 트랜스코딩인지 확인한 다음 자막, 톤 매핑, 하드웨어 가속, 스토리지 및 네트워크 동작을 각각 분리해 점검하세요. 실제 병목을 확인하기 전에는 더 많은 연산 성능을 구매하지 마세요.

최악의 스트림 하나를 검증한 뒤 동시성을 신중하게 추가하기

가장 부담이 큰 HDR 소스, 번인이 필요할 가능성이 가장 높은 자막 형식 및 실제로 지원하는 클라이언트 중 성능이 가장 낮은 클라이언트를 포함하는 반복 가능한 검증 세트를 만드세요. 한 세션으로 시작해 재생 상태, CPU, GPU 또는 비디오 엔진 사용률, 트랜스코딩 속도 또는 버퍼 상태, 메모리 및 온도를 기록하세요.

한 경로가 안정적으로 작동한 뒤에야 실제 가정 내 동시 사용을 나타내는 두 번째 동시 사용자 또는 백그라운드 작업을 추가하세요. 목적은 보편적인 스트림 수를 찾는 것이 아니라, 특정 단계 하나를 고갈시키지 않고 정확한 미디어, 클라이언트 및 하드웨어가 지속할 수 있는 동시성 수준을 찾는 것입니다.

예상되는 가장 바쁜 조합이 여유를 두고 반복적으로 통과하면 규모 확장을 멈추세요. 측정된 실패에 명확한 원인이 있을 때만 하드웨어를 추가하거나 변경하세요. 누락된 코덱 경로에는 다른 미디어 엔진이 필요하고, 반복되는 소프트웨어 폴백에는 더 강력한 CPU 또는 더 나은 가속이 필요하며, 스토리지 경합에는 토폴로지 변경이 필요합니다. 감당할 수 없는 높은 동시 사용량에는 전용 트랜스코딩 노드를 고려할 수 있습니다.