다이렉트 플레이 vs 다이렉트 스트림 vs 트랜스코딩: 어떤 방식이 서버 리소스를 사용할까요?

Direct Play는 원본 미디어의 스트림을 변경하지 않고 전달할 수 있으므로 서버 컴퓨팅 자원을 가장 적게 사용합니다. Direct Stream은 서버가 미디어를 다시 패키징하고 호환되지 않는 오디오 또는 자막 스트림을 변환할 수 있어 서버 작업이 더 많이 필요하지만, 비디오는 그대로 유지할 수 있습니다. 전체 트랜스코딩은 비디오를 디코딩하고 처리한 다음 다시 인코딩해야 하므로 가장 많은 컴퓨팅 자원을 사용합니다. 따라서 올바른 경로는 어떤 대가를 치르더라도 CPU 사용량이 가장 낮은 경로가 아니라, 클라이언트와 네트워크, 선택한 미디어 트랙이 실제로 수용할 수 있는 가장 가벼운 경로입니다.

전체 파일이 클라이언트에 맞을 때만 Direct Play가 유지됩니다

Direct Play는 재인코딩 없이 원본 비디오와 오디오를 전송하므로 가장 먼저 유지해야 할 경로입니다. 스토리지 읽기, 인증, 프로토콜 처리, 네트워크 전송 등 서버 작업은 여전히 발생하지만, 비용이 큰 비디오 변환 파이프라인은 작동하지 않습니다.

Plex는 미디어를 변환 없이 클라이언트에서 사용할 수 있는 경로를 Direct Play로 정의하며, 스트리밍 개요에서 이를 Direct Stream 및 트랜스코딩과 구분합니다. 이 원본 미디어 전달 경로에서는 서버 성능보다 클라이언트의 지원 여부가 결정적인 기준이 됩니다.

클라이언트가 비디오 코덱, 오디오 코덱, 컨테이너, 프로필, 해상도, 비트레이트, 자막 동작 또는 기타 재생 조건 중 중요한 요소를 거부하면 Direct Play는 사용할 수 없습니다. 필요한 요소 중 하나라도 충족되지 않으면 서버는 미디어를 다시 패키징하거나 새로운 스트림을 만들어야 합니다.

비디오를 그대로 유지할 수 있을 때 Direct Stream이 중간 경로가 됩니다

Direct Stream은 흔히 리먹싱 또는 트랜스먹싱이라고도 하며, 비디오는 복사할 수 있지만 컨테이너나 다른 스트림을 조정해야 하는 파일에 사용됩니다. 서버는 호환되는 스트림을 추출해 클라이언트가 수용할 수 있는 형식으로 다시 패키징합니다. 이는 비디오를 디코딩하고 재인코딩하는 것보다 훨씬 가볍습니다.

Emby의 재생 문서에서는 Direct Stream을 비디오 트랙은 그대로 유지하면서 오디오나 자막을 변환할 수 있는 실시간 재패키징 방식으로 설명합니다. Emby의 비디오 복사 리먹스 경로는 중요한 경계를 보여 줍니다. ‘스트리밍’이라고 해서 항상 비디오 트랜스코딩을 의미하는 것은 아닙니다.

컨테이너 또는 오디오 호환성만 문제가 될 때 이 경로가 가장 적합합니다. 비디오 자체를 변경해야 하거나, 자막을 프레임에 삽입해야 하거나, 스트림 복사만으로는 전달 비트레이트 또는 해상도를 충분히 낮출 수 없을 때는 Direct Stream을 사용할 수 없습니다.

비디오를 다시 만들어야 할 때 트랜스코딩이 시작됩니다

전체 비디오 트랜스코딩은 비용이 큰 분기입니다. 서버는 소스를 디코딩하고, 필요에 따라 크기 조정, 톤 매핑, 디인터레이싱, 자막 삽입 또는 기타 프레임 필터링을 수행한 다음 클라이언트용 새 비디오 스트림을 인코딩합니다. 이 과정에서 오디오는 복사하거나 변환할 수 있습니다.

Jellyfin의 트랜스코딩 문서는 하드웨어 가속과 소프트웨어 처리를 구분하며, 최신 GPU가 지원되는 경로를 오프로딩할 수 있다고 설명합니다. 이 실시간 변환 파이프라인은 같은 영화라도 한 클라이언트에서는 네트워크 작업이 가벼울 수 있고, 다른 클라이언트에서는 컴퓨팅 작업이 무거울 수 있는 이유를 보여 줍니다.

호환성 또는 대역폭 때문에 실제로 새 비디오 스트림이 필요할 때 트랜스코딩을 사용해야 합니다. 클라이언트가 원본 비디오를 수용할 수 있고 네트워크가 이를 전송할 수 있다면, 품질 설정을 강제로 낮추는 것은 이전에는 없던 서버 부하를 만들 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

네 가지 공통 자원으로 세 가지 경로 비교하기

변화하는 서버 자원은 컴퓨팅, 메모리 이동, 임시 트랜스코딩 스토리지, 네트워크 대역폭입니다. Direct Play는 변환 컴퓨팅을 최소화하지만 소스의 전체 비트레이트로 전달할 수 있습니다. 트랜스코딩은 나가는 비트레이트를 줄일 수 있는 대신 CPU 또는 GPU 작업량을 늘릴 수 있습니다. Direct Stream은 패키징 변경이 대체로 가볍고 오디오 변환이 필요한 경우에만 일부 컴퓨팅 자원이 추가되므로 그 중간에 해당합니다.

FFmpeg의 하드웨어 가속 개요에서는 NVENC/NVDEC 및 QSV와 같은 전용 API를 비디오 처리용으로 설명합니다. 이 하드웨어 오프로딩 계층은 트랜스코딩 분기에서만 중요하며, Direct Play를 더 직접적인 방식으로 만들어 주지는 않습니다.

하나의 자원만으로 경로를 순위 매기지 마세요. 업로드 속도가 느린 환경의 원격 사용자는 서버에 충분한 컴퓨팅 자원이 있어도 트랜스코딩이 필요할 수 있고, 유선 이더넷을 사용하는 로컬 4K 클라이언트는 원본 비트레이트의 Direct Play가 더 적합할 수 있습니다.

영화 파일을 변경하지 않아도 자막과 오디오가 경로를 바꿀 수 있습니다

사용자가 다른 자막 또는 오디오 트랙을 선택하면 세션이 다른 분기로 전환될 수 있습니다. 클라이언트가 렌더링할 수 있는 텍스트 자막은 Direct Play를 유지할 수 있지만, 이미지 자막이나 지원되지 않는 자막 동작은 자막 삽입을 필요로 하므로 비디오 트랜스코딩으로 이어질 수 있습니다. 지원되지 않는 다채널 오디오는 비디오는 복사된 상태로 유지하면서 오디오 변환을 유발할 수 있습니다.

HandBrake의 성능 문서는 고비용 비디오 인코딩 작업을 다른 처리와 구분하고, 하드웨어 인코더를 사용하더라도 필터가 병목이 될 수 있음을 보여 주므로 여기서 유용합니다. 이 필터와 인코더 작업 분리는 “하드웨어 트랜스코딩 활성화”가 모든 단계의 비용을 없애 주지는 않는 이유를 설명합니다.

어떤 콘텐츠 하나가 다른 콘텐츠보다 예기치 않게 더 많은 서버 자원을 사용한다면, CPU나 GPU를 비교하기 전에 선택한 트랙과 재생 사유를 확인하세요. 표시되는 해상도는 같아도 처리 경로는 완전히 다를 수 있습니다.

재생 대시보드를 판단 도구로 사용하세요

CPU 사용률만으로 경로를 추정하지 마세요. 미디어 서버의 세션 세부 정보를 열어 비디오가 Direct Play인지, 복사/리먹스인지, 트랜스코딩인지 기록한 다음 오디오가 복사 또는 변환되는지, 자막이 클라이언트에서 렌더링되는지 아니면 비디오에 삽입되는지도 확인하세요.

미디어 재생 중 높은 CPU 사용률에 관한 ZimaSpace 가이드도 같은 원칙을 적용합니다. 높은 사용률을 하드웨어 부족으로 판단하기 전에 먼저 어떤 처리 결정이 내려졌는지 파악해야 합니다.

대표적인 로컬 세션 하나, 원격 또는 대역폭이 제한된 세션 하나, 자막을 많이 사용하는 세션 하나를 실행해 보세요. 대시보드에 이미 Direct Play라고 표시되는데도 재생이 버퍼링된다면 트랜스코딩 성능 비교를 중단하고 스토리지, 전송 환경 또는 클라이언트를 점검하세요.

전송 제약을 충족하는 가장 가벼운 경로를 선택하세요

클라이언트가 전체 미디어 파일을 지원하고 네트워크가 해당 비트레이트를 전송할 수 있다면 Direct Play를 우선 사용하세요. 원본을 유지하면서 다른 사용자에게 제공할 수 있는 서버 용량도 가장 많이 남겨 둡니다.

비디오 호환성은 이미 해결되었지만 컨테이너, 오디오 또는 패키징을 조정해야 한다면 Direct Stream을 사용하세요. 호환성, 대역폭, 해상도, HDR/SDR 변환, 자막 삽입 또는 기타 실제 전송 제약 때문에 비디오 자체를 변경해야 할 때만 트랜스코딩을 사용하세요.

모든 상황에서 우세한 경로는 없습니다. Direct Play는 컴퓨팅 자원을 최소화하고, Direct Stream은 패키징 불일치를 저렴하게 해결하며, 트랜스코딩은 서버 자원을 사용하는 대신 호환성과 비트레이트 제어를 제공합니다. 올바른 미디어 서버 설계는 앞의 두 경로를 최대한 활용하면서도 세 번째 경로를 피할 수 없는 세션에 충분한 트랜스코딩 용량을 확보하는 것입니다.