미디어 서버가 재생 중에 CPU 사용량이 높은 이유는 무엇인가요?

미디어 재생 중 높은 CPU 사용은 보통 서버가 원본 파일을 전송하는 것 이상을 수행하고 있음을 의미합니다. 비디오를 디코딩하고 재인코딩하거나, 모든 프레임에 자막을 번인하거나, SDR 클라이언트를 위해 HDR을 변환하거나, 해상도를 다운스케일하거나, 원격 연결을 위한 낮은 비트레이트 스트림을 생성할 수 있습니다.

하지만 높은 CPU 사용이 자동으로 프로세서가 너무 약하다는 증거는 아닙니다. 하드웨어 가속이 파이프라인의 일부에서만 작동할 수 있고, 백그라운드 분석 작업이 동시에 실행 중일 수 있으며, 여러 세션이 동일한 자원을 경쟁할 수도 있습니다. 첫 번째 단계는 재생 모드와 실제로 CPU를 사용하는 프로세스를 식별하는 것입니다.

하드웨어를 탓하기 전에 재생 모드를 확인하세요

문제가 있는 스트림이 활성화된 상태에서 서버 대시보드를 열어보세요. Plex, Jellyfin, Emby 및 유사 플랫폼은 보통 세션이 다이렉트 플레이, 다이렉트 스트림 또는 리멕스, 오디오 변환, 또는 전체 비디오 트랜스코딩 중 어느 것을 사용하는지 보여줍니다.

다이렉트 플레이는 원본 컨테이너, 비디오, 오디오 및 지원되는 자막 트랙을 클라이언트에 전송합니다. 리멕스 또는 다이렉트 스트림은 종종 비디오를 재인코딩하지 않고 전달 형식의 일부만 변경합니다. 비디오 트랜스코딩은 소스를 디코딩하고 새 비디오 스트림을 생성하여 지속적인 높은 CPU 사용의 가장 가능성 높은 경로입니다.

이 구분은 다음 테스트를 결정합니다. 소프트웨어에서 처리가 이루어지는 경우 확인된 비디오 트랜스코딩 중 높은 CPU 사용은 예상될 수 있습니다. 다이렉트 플레이 중 높은 CPU 사용은 보통 다른 세션, 백그라운드 분석 작업 또는 서버에서 실행 중인 다른 프로세스를 가리킵니다.

소프트웨어 비디오 트랜스코딩이 보통 주요 원인입니다

클라이언트가 원본 코덱, 프로필, 해상도, 비트레이트, 컨테이너, 오디오 또는 자막 조합을 지원하지 않을 때 미디어 서버가 비디오를 트랜스코딩합니다. 사용자가 낮은 재생 품질을 선택했을 때도 트랜스코딩이 발생할 수 있습니다.

서버는 소스 프레임을 디코딩하고, 필요한 필터를 적용하며, 이미지를 크기 조정 또는 변환하고, 재생보다 빠르게 새 스트림을 인코딩해야 합니다. 4K HEVC 소스를 낮은 해상도의 H.264로 변환하는 것은 원본 파일을 제공하는 것보다 훨씬 더 많은 처리가 필요합니다.

이 모든 단계가 범용 CPU 코어에서 실행된다면 높은 사용률은 정상일 수 있습니다. 중요한 질문은 트랜스코더가 재생 속도보다 빠른지 여부입니다. 바쁜 CPU에서 부드러운 재생은, 클라이언트가 반복적으로 버퍼링하는 동안 CPU가 한계에 도달한 상태와 다릅니다.

CPU 필요 여부는 종종 클라이언트가 결정합니다.

같은 파일이 한 스트리밍 박스에서는 Direct Play가 가능하지만, 브라우저, TV 앱, 휴대폰, 구형 플레이어에서는 완전한 트랜스코딩을 유발할 수 있습니다. 각 클라이언트는 컨테이너, 비디오 프로필, 비트 깊이, 오디오 형식, 자막, 최대 비트레이트의 조합을 다르게 지원합니다.

비디오 코덱이 지원되더라도 호환되지 않는 오디오 트랙이나 자막 형식이 재생 경로를 변경할 수 있습니다. 클라이언트가 HEVC 비디오를 수용하지만 TrueHD 오디오 변환이 필요하거나, 선택된 자막을 로컬에서 렌더링할 수 없을 때 비디오 트랜스코딩이 필요할 수 있습니다.

오디오 트랙, 자막 선택, 품질 설정을 동일하게 유지한 채 두 클라이언트에서 같은 파일을 비교하세요. 높은 CPU 사용량이 특정 클라이언트에서만 발생한다면, 서버 하드웨어를 교체하기 전에 해당 클라이언트의 기능과 설정에 집중하세요.

낮은 품질이 서버 CPU 사용량을 증가시킬 수 있습니다.

더 낮은 품질 설정을 선택하면 서버 작업 부하가 줄어들 것 같지만, 실제로는 요청된 해상도나 비트레이트가 소스와 다를 때 서버가 새로운 스트림을 생성해야 합니다.

예를 들어, 4K 고비트레이트 파일에서 8 Mbps의 1080p를 요청하면 디코딩, 스케일링, 재인코딩이 필요합니다. 원본 품질을 선택하면 클라이언트가 소스 형식을 지원하고 네트워크가 비트레이트를 감당할 수 있을 때 Direct Play가 가능할 수 있습니다.

로컬 네트워크에서 진단 테스트로 원본 품질을 사용하세요. 이것이 만능 해결책은 아닙니다: 호환되지 않는 코덱, 부족한 대역폭, 지원되지 않는 자막이 있는 클라이언트는 여전히 변환이 필요할 수 있습니다.

자막 번인은 가벼운 스트림을 무거운 스트림으로 바꿀 수 있습니다.

CPU 사용량이 자막이 활성화된 후에만 증가한다면, 선택된 자막 트랙이 유력한 원인입니다. SRT와 같은 텍스트 자막은 종종 클라이언트에서 렌더링되지만, PGS와 VobSub는 이미지 기반 형식입니다. ASS와 SSA는 텍스트를 포함하지만 일부 클라이언트가 재현할 수 없는 스타일링과 위치 지정이 포함될 수 있습니다.

클라이언트가 자막 트랙을 렌더링할 수 없을 때, 서버는 자막을 영상에 번인할 수 있습니다. 이는 비디오를 디코딩하고, 각 프레임에 자막을 합성한 후, 새로운 비디오 스트림을 인코딩하는 작업을 필요로 합니다.

Plex는 하드웨어 트랜스코딩 중 자막 번인 성능 개선에 특별히 노력했으며, 결과는 운영 체제, GPU 유형 및 파이프라인에 톤 매핑이 남아 있는지 여부에 따라 달라집니다. 이 때문에 동일한 자막 테스트가 서버마다 다른 CPU 사용량을 나타낼 수 있습니다.

자막 트랙을 별도로 테스트하세요

자막을 비활성화한 상태로 동일한 장면을 다시 재생하세요. CPU 사용량이 즉시 떨어지고 세션이 Direct Play로 돌아가면, 추가 작업을 유발하는 것은 소스 비디오가 아니라 자막 경로입니다.

다음으로 외부 SRT 트랙, 다른 자막 언어 또는 더 넓은 자막 지원을 제공하는 클라이언트를 시도해 보세요. 또한 서버가 단순 자막 전달이 아닌 자막 번인을 보고하는지 확인하세요.

모든 자막 포맷이 동일한 비용을 요구한다고 가정하지 마세요. 스타일이 적용된 텍스트 트랙은 한 클라이언트에서는 쉽지만 다른 클라이언트에서는 전체 비디오 처리가 필요할 수 있으며, 블루레이의 이미지 자막은 번인 없이 제공하기 특히 어려울 수 있습니다.

GPU가 작동한다고 해서 전체 파이프라인이 가속화된 것은 아님

CPU 사용량이 높은 상태에서도 GPU 활동이 나타날 수 있습니다. 하드웨어 가속은 비디오를 디코딩하고 인코딩할 수 있지만, CPU는 여전히 자막 렌더링, 오디오 변환, 스케일링, 톤 매핑 또는 다른 필터를 처리할 수 있습니다.

커뮤니티 문제 해결 사례에서는 자막 번인과 오디오 변환으로 인한 높은 CPU 사용량과 함께 GPU 트랜스코딩이 작동하는 경우가 있었습니다. 이 사례는 모든 최신 버전에 대한 고정된 규칙으로 간주해서는 안 되지만, GPU 사용률만으로는 불완전한 증거임을 보여줍니다.

GPU 디코드 및 인코드 엔진을 모두 확인한 후 트랜스코더 로그에서 소프트웨어 필터를 검사하세요. 자막을 끄고 호환되는 오디오 트랙을 선택하며 테스트에서 톤 매핑을 제거한 상태에서 CPU 사용량을 비교하세요.

하드웨어 가속이 소프트웨어로 대체될 수 있음

호스트 드라이버, 장치 권한, 런타임 또는 선택한 코덱이 제대로 작동하지 않아도 서버 인터페이스에서 하드웨어 가속 옵션을 활성화할 수 있습니다.

일부 소스 포맷은 GPU를 성공적으로 사용할 수 있지만, 다른 포맷은 CPU로 대체될 수 있습니다. GPU는 H.264 및 HEVC Main을 지원할 수 있지만 특정 파일에 필요한 정확한 비트 깊이, 크로마 포맷, 인코딩 대상 또는 톤 매핑 경로는 지원하지 않을 수 있습니다.

알려진 트랜스코딩을 강제로 실행하고 서버를 실시간으로 모니터링하세요. 하드웨어 디코더와 인코더가 활성화되어 있는지 확인하고, 트랜스코더 명령을 검사하며, 초기화 실패나 소프트웨어 폴백 메시지를 찾아보세요. 단순히 활성화 체크박스에만 의존하지 마세요.

Docker는 별도의 GPU 접근 계층을 추가합니다.

미디어 서버가 Docker에서 실행될 때, 호스트에서 GPU를 감지하는 것만으로는 애플리케이션이 컨테이너 내부에서 GPU를 사용할 수 있음을 증명하지 못합니다. 컨테이너는 장치, 호환되는 사용자 공간 라이브러리, 올바른 런타임 및 비디오 기능 접근 권한이 필요합니다.

NVIDIA 배포 환경에서는 먼저 호스트 드라이버를 확인하고, Docker가 NVIDIA 런타임을 인식하는지 검증하며, 컨테이너 내부에 필요한 라이브러리와 장치가 존재하는지 확인하고, 강제 트랜스코딩 중 인코더 활동을 관찰하는 것이 유용한 검증 순서입니다. 컨테이너가 nvidia-smi 실행 환경에 미디어 서버에 필요한 라이브러리나 기능이 누락될 수 있습니다.

따라서 실용적인 Docker 설정은 컨테이너 내부에서 NVIDIA 런타임, 사용자 공간 라이브러리, 장치 노출 및 인코더 활동을 검증해야 합니다. 권한 모드를 영구적인 해결책으로 사용하지 말고, 서비스에 필요한 자원만 노출하세요.

가상 머신은 동일한 실패 패턴을 만들 수 있습니다.

가상 머신은 미디어 트랜스코딩에 필요한 하드웨어 인코딩 및 디코딩 기능에 접근하지 못한 채 디스플레이 어댑터를 감지할 수 있습니다. GPU 패스스루, 중재 장치, 드라이버 및 게스트 권한이 결과에 영향을 미칩니다.

게스트 운영체제 내부와 미디어 서버 프로세스에서 GPU를 검증하세요. 호스트 수준의 GPU 활동만으로는 게스트 애플리케이션이 의도한 엔진을 사용하고 있음을 증명하지 못합니다.

네이티브 설치가 하드웨어 가속을 사용하는 반면, 동일한 VM 설치가 높은 CPU 사용량을 보인다면, 코덱 설정 변경이나 라이브러리 재인코딩 전에 장치 노출과 로그를 비교하세요.

HDR 톤 매핑은 CPU에 상당한 부하를 남길 수 있습니다.

HDR 미디어가 SDR 디스플레이에서 재생되거나 원본 HDR 스트림을 수용할 수 없는 클라이언트를 통해 재생될 때, 서버는 일반 트랜스코딩 외에 톤 매핑을 수행해야 할 수도 있습니다.

파이프라인에는 10비트 디코딩, 색 공간 변환, 밝기 매핑, 스케일링, 자막 합성 및 인코딩이 포함될 수 있습니다. 소스 코덱에 대한 하드웨어 지원이 있다고 해서 모든 단계가 GPU에서 처리된다는 보장은 없습니다.

HDR 지원 클라이언트에서 동일한 파일을 테스트한 후 SDR 출력과 비교하세요. 일반 SDR 트랜스코딩은 효율적이지만 HDR-대-SDR 세션에서 CPU 사용량이 높다면 모든 4K 미디어를 동일하게 취급하기보다는 톤 매핑 방식과 하드웨어 지원을 조사하세요.

오디오 변환은 보통 비디오 트랜스코딩만큼 무겁지 않습니다

TrueHD, DTS, 다채널 오디오 또는 지원되지 않는 오디오 코덱은 클라이언트가 재생할 수 있는 형식으로 변환될 수 있습니다. 서버는 서라운드 사운드를 스테레오로 다운믹스할 수도 있습니다.

오디오 트랜스코딩은 처리 능력을 소모하지만, 일반적으로 전체 비디오 스트림을 디코딩하고 재인코딩하는 것보다 가볍습니다. 컨테이너 리멕싱은 비디오 스트림을 보존하며 보통 비디오 변환보다 훨씬 적은 계산을 필요로 합니다.

대시보드가 오디오 트랜스코딩만 보고하면서 CPU가 거의 한계에 가까운 경우, 자막 처리, 백그라운드 분석, 다른 활성 세션 또는 별도의 트랜스코더 프로세스를 확인하세요. 보이는 오디오 라벨만으로 전체 작업량을 설명한다고 가정하지 마세요.

높은 CPU 사용량의 Direct Play는 보통 다른 작업이 실행 중임을 의미합니다

Direct Play는 여전히 파일 읽기, 인증, 애플리케이션 로직, 네트워크 전송이 필요하므로 CPU 사용량이 완전히 0이 되지는 않습니다. 일반적으로 소프트웨어 트랜스코딩과 관련된 무거운 비디오 처리를 요구하지 않습니다.

Plex는 인트로 및 크레딧 감지, 미리보기 썸네일, 음성 분석, 광고 감지, 미디어 최적화, 다운로드 준비에 상당한 CPU를 사용할 수 있습니다. 이러한 작업 중 일부는 아무도 미디어를 적극적으로 시청하지 않을 때도 트랜스코더를 호출합니다.

전체 CPU 그래프만 보는 대신 운영 체제의 프로세스 목록을 확인하세요. 현재 스트림의 트랜스코더, 예약된 분석 프로세스, 라이브러리 스캐너 또는 관련 없는 컨테이너 중 어느 것이 원인인지 식별하세요.

예약된 분석은 재생 부하처럼 보일 수 있습니다

누군가 시청을 시작할 때쯤 백그라운드 작업이 시작될 수 있어 재생 자체가 CPU 급증을 일으킨 것처럼 보일 수 있습니다. 유지 관리 작업은 종종 야간이나 새 콘텐츠가 추가된 직후에 실행됩니다.

한 Unraid 토론에서는 명백히 유휴 상태인 CPU 부하가 예약된 미디어 분석과 이후 인트로 및 크레딧 감지 때문임을 추적했습니다. 이는 모든 유휴 부하 사례가 동일한 원인이라는 증거라기보다는 커뮤니티 사례입니다.

미리보기 생성, 인트로 감지, 크레딧 감지, 최적화 및 심층 미디어 분석을 일시 중지하세요. 활성 스트림을 변경하지 않고 CPU 사용량이 감소하면 재생 설정을 변경하는 대신 해당 작업을 다른 유지 관리 시간대로 옮기세요.

여러 스트림은 다양한 유형의 작업을 곱합니다

하나의 직접 재생 세션은 주로 저장소와 네트워크 수요를 추가합니다. 하나의 오디오 트랜스코드는 더 작은 변환 작업을 추가합니다. 하나의 소프트웨어 4K 비디오 트랜스코드는 여러 직접 스트림보다 훨씬 더 많은 연산을 소모할 수 있습니다.

다른 사용자가 재생을 시작하면 각 세션을 개별적으로 검사하세요. 두 사용자가 반드시 동일한 작업량을 두 배로 만드는 것은 아닙니다. 한 명은 직접 재생하는 반면 다른 한 명은 HDR 트랜스코드에 자막을 입힐 수 있습니다.

CPU, GPU, 네트워크, 디스크 지연 시간 및 트랜스코드 속도를 관찰하면서 테스트 세션을 하나씩 추가하세요. 이를 통해 실제 한계가 소프트웨어 인코딩, 하드웨어 인코더 용량, 저장소 경쟁 또는 총 대역폭인지 알 수 있습니다.

라이브 TV는 추가 처리가 필요할 수 있습니다

라이브 TV는 재생 클라이언트가 직접 수용할 수 없는 코덱, 해상도, 인터레이스 형식 또는 비트레이트로 도착할 수 있습니다. 서버는 디인터레이스, 비디오 변환, 오디오 변경 또는 낮은 비트레이트 스트림 생성을 해야 할 수 있습니다.

이 작업들은 라이브 재생을 직접 재생하는 일반 영화보다 CPU 집약적으로 만들 수 있습니다. 녹화 및 광고 분석도 시청과 함께 실행되어 서버 작업을 추가할 수 있습니다.

라이브 세션의 소스 코덱, 디인터레이싱 상태, 재생 모드 및 선택한 품질을 저장된 미디어 라이브러리와 별도로 확인하세요. 라이브 TV 문제는 모든 로컬 파일이 동일한 하드웨어를 필요로 한다는 증거가 아닙니다.

원격 재생은 종종 새로운 비트레이트를 강제합니다

고비트레이트 파일은 홈 LAN에서 직접 재생될 수 있지만 서버의 인터넷 업로드 속도를 초과할 수 있습니다. 이 경우 원격 클라이언트나 서버 제한이 더 작은 스트림을 요청합니다.

비트레이트를 줄이면 서버가 일반적으로 새 비디오 출력을 생성해야 합니다. 따라서 동일한 클라이언트가 집에서 적은 서버 연산을 사용하더라도 원격 재생 중에는 CPU 사용량이 증가할 수 있습니다.

소스 비트레이트를 지속 가능한 업로드 용량 및 클라이언트의 원격 품질 설정과 비교하세요. 스트림을 낮추면 소프트웨어 트랜스코딩이 발생할 수 있으며, 올바르게 구성된 하드웨어 가속이나 사전 인코딩된 원격 버전이 CPU 부담을 줄일 수 있습니다.

짧은 CPU 급증은 정상일 수 있습니다

일부 트랜스코더는 버퍼를 만들기 위해 재생 위치보다 앞서 작업합니다. CPU 사용량은 시작 시 급격히 상승할 수 있고, 충분한 세그먼트가 생성되면 감소하며, 더 많은 출력이 필요할 때 다시 증가할 수 있습니다.

짧은 피크와 부드러운 재생, 안정적인 온도는 반드시 수정이 필요한 것은 아닙니다. 지속적인 최대 사용, 트랜스코드 속도 저하, 반복 버퍼링 또는 열 스로틀링은 더 의미 있는 용량 문제를 나타냅니다.

단일 CPU 스크린샷에 의존하지 말고 몇 분 동안 작업 부하를 관찰하세요. 프로세서가 계속 고정되는지, 트랜스코더가 앞서 나가는지, 온도 상승에 따라 서버 클럭 속도가 떨어지는지 기록하세요.

전체 라이브러리를 먼저 재인코딩하지 마세요

모든 파일을 광범위하게 지원되는 형식으로 변환하면 향후 실시간 트랜스코딩을 줄일 수 있지만, 많은 소스에 대해 시간, 추가 저장 공간 및 또 다른 손실 인코딩 단계가 필요합니다.

자막 번인, HDR 톤 매핑, 원격 비트레이트 제한, 백그라운드 분석 또는 도커 내부의 GPU 접근 문제로 인한 높은 CPU는 실제 원인을 해결하지 못할 수 있습니다.

실제로 사용하는 클라이언트에서 반복적으로 실패하는 조합을 먼저 식별하세요. 문제 빈도가 높은 미디어에 대해서만 최적화된 복사본을 만들거나, 라이브러리 여러 버전을 유지하는 것보다 더 간단한 더 강력한 클라이언트를 사용하세요.

이 문제 해결 순서 사용

1. 동일 파일과 클라이언트로 높은 CPU 세션 재현
2. 직접 재생, 리멕스, 오디오 트랜스코드 또는 비디오 트랜스코드 여부 기록
3. CPU를 소비하는 정확한 프로세스 식별
4. 변환 사유 기록
5. 로컬 네트워크에서 원본 품질 테스트
6. 자막 비활성화 및 다른 오디오 트랙 선택
7. 다른 클라이언트에서 동일 파일 재생
8. GPU 디코드 및 인코드 엔진 모니터링
9. 트랜스코더 또는 FFmpeg 로그에서 소프트웨어 폴백 점검
10. 도커 또는 가상 머신 내부에서 GPU 접근 확인
11. 미디어 분석, 미리보기 생성 및 최적화 작업 일시 중지
12. 스트림을 하나씩 추가
13. 온도 및 CPU 클럭 속도 확인
14. 병목 현상이 확인된 후에만 하드웨어 업그레이드

최종 요약

미디어 재생 중 높은 CPU 사용량은 보통 처리 결정의 결과이지 자체 진단은 아닙니다. 전체 소프트웨어 비디오 트랜스코딩이 가장 흔한 원인이지만, 자막 번인, HDR 톤 매핑, 부분 하드웨어 가속, 원격 품질 제한, 동시 세션도 유사한 부하를 일으킬 수 있습니다.

먼저 재생 모드와 CPU를 사용하는 정확한 프로세스를 확인하세요. 세션이 트랜스코딩 중이라면 클라이언트 호환성, 원본 품질, 자막, 오디오 트랙, 전체 하드웨어 가속 파이프라인을 테스트하세요. Direct Play 중이라면 백그라운드 분석 및 다른 활성 작업을 점검하세요.

로그와 통제된 테스트에서 필요한 실시간 처리가 사용 가능한 컴퓨팅 능력을 초과하는 경우에만 서버를 업그레이드하세요. 많은 고CPU 문제는 재생 경로 변경, Docker GPU 접근 수정, 시청 시간 외 분석 예약, 또는 원본 미디어를 Direct Play할 수 있는 클라이언트 선택으로 해결할 수 있습니다.

자주 묻는 질문

자막을 활성화하면 왜 CPU 사용량이 증가하나요?

클라이언트가 선택한 자막 형식을 렌더링할 수 없을 수 있습니다. 이 경우 서버는 모든 비디오 프레임에 자막을 입히는데, 이는 비디오 디코딩과 재인코딩을 필요로 합니다. 자막을 비활성화하거나 지원되는 텍스트 기반 트랙을 선택해 테스트하세요.

하드웨어 트랜스코딩이 활성화되어 있는데도 CPU 사용량이 높은 이유는 무엇인가요?

GPU는 비디오 디코딩과 인코딩만 가속할 수 있으며, CPU는 자막, 오디오, 톤 매핑, 스케일링 또는 다른 필터를 처리합니다. Docker나 가상 머신 내에서는 하드웨어 접근이 완전하지 않을 수도 있습니다.

Direct Play는 CPU를 전혀 사용하지 않나요?

아니요. Direct Play도 파일 접근, 네트워킹, 인증 및 애플리케이션 처리가 필요합니다. 일반적으로 비디오 트랜스코딩보다 훨씬 적은 CPU를 사용하므로 지속적인 높은 부하는 백그라운드 작업이나 다른 프로세스를 점검해야 합니다.

스트리밍 품질을 낮추면 왜 CPU 사용량이 증가하나요?

해상도나 비트레이트가 낮아지면 서버가 새로운 비디오 스트림을 생성해야 하는 경우가 많습니다. 원본 파일이 Direct Play가 가능했다면, 낮은 품질 선택은 세션을 트랜스코딩으로 변경하여 서버 처리량을 증가시킵니다.

영화 재생 중에 미디어 스캔이 CPU 사용량을 높일 수 있나요?

예. 미리보기 썸네일 생성, 소개 또는 크레딧 감지, 최적화, 음성 분석 및 기타 백그라운드 작업은 재생과 동시에 실행될 수 있습니다. 모든 CPU 사용량을 활성 스트림에만 귀속시키기 전에 프로세스 목록과 예약 작업 상태를 확인하세요.