Plex 하드웨어 트랜스코딩은 호환되지 않는 입력을 어떻게 원활한 재생으로 바꿀까요?

Plex 하드웨어 트랜스코딩은 소스를 디코딩하고, 변경이 필요한 부분을 변환한 뒤, 클라이언트가 수용할 수 있는 새 스트림으로 인코딩하여 호환되지 않는 재생을 원활하게 처리합니다.

이 결과는 Direct Play가 아닙니다. Direct Play는 호환되는 소스 스트림을 비디오 변환 없이 전송합니다. 하드웨어 트랜스코딩은 Plex가 요청된 클라이언트, 화질, 자막, 오디오 또는 네트워크 조건에서 원본 조합을 사용할 수 없다고 판단한 경우에만 관련됩니다. 이 과정은 요청 불일치에서 새로운 전달용 스트림 생성까지 이어지는 파이프라인으로 이해하는 것이 가장 좋으며, 각 단계마다 실패 지점이 존재합니다.

파이프라인은 호환성 불일치에서 시작됩니다

Plex는 먼저 요청된 미디어를 그대로 전달할 수 있는지, 패키징만 다시 구성할 수 있는지, 아니면 변환해야 하는지를 판단합니다. Direct Play는 가장 간단한 경로이고, Direct Stream은 호환되는 기본 스트림을 유지하면서 패키징만 변경합니다. 트랜스코딩은 클라이언트 또는 전송 제약을 충족하기 위해 비디오, 오디오 또는 둘 다를 변경합니다.

이 구분이 중요한 이유는 비디오 트랜스코딩이 Direct Play의 더 빠른 형태가 아니라 디코딩과 인코딩 작업이기 때문입니다. 변환이 시작되면 서버는 원본 바이트를 단순히 읽어 전달하는 대신 소스를 새 형식으로 만들어 냅니다.

트리거는 클라이언트의 코덱 지원 여부, 요청 해상도, 비트레이트, HDR 처리, 자막 또는 전체 재생 경로를 바꾸는 오디오 조합일 수 있습니다. 따라서 작동 원리를 설명할 때는 GPU 모델이 아니라 불일치에서 시작해야 합니다.

하드웨어 디코딩은 압축된 소스를 처리 가능한 프레임으로 변환합니다

압축된 소스는 H.264 또는 HEVC 같은 형식에서 비디오 프레임과 참조 상태를 복원하는 디코더로 전달됩니다. 하드웨어 가속을 사용하면 지원되는 디코딩 작업이 미디어 엔진에서 처리되어 이 단계에 필요한 일반 CPU 작업량이 줄어듭니다.

하드웨어 디코딩과 인코딩은 서로 다른 단계입니다. 하드웨어 디코딩이 작동하려면 미디어 엔진이 입력 코덱을 지원해야 합니다. 지원하지 않더라도 Plex는 이후 인코딩 단계에서 가속기를 사용하는 동안 소프트웨어 방식으로 디코딩할 수 있습니다.

이 때문에 대시보드는 단일 켜기/끄기 표시가 아니라 파이프라인 상태를 나타내는 지표로 읽어야 합니다. 일부 단계만 가속되면 여전히 비용이 큰 단계가 CPU에서 실행될 수 있으며, CPU 사용률이 낮다고 해서 모든 변환이 하드웨어에서 처리된다는 의미는 아닙니다.

스케일링, 톤 매핑 및 자막 처리는 프레임을 변경합니다

디코딩 후 Plex는 화면 크기를 조정하거나 색상 처리를 변경하고, HDR을 SDR에 맞게 변환하거나, 출력 인코딩 전에 자막을 영상에 합성할 수 있습니다. 이러한 작업은 파이프라인의 중간 단계이며, 디코딩과 인코딩이 모두 지원되더라도 하드웨어 경로를 바꿀 수 있습니다.

HDR 및 자막 처리는 파이프라인 중간 단계가 계속 효율적으로 작동할 수 있는지를 바꿀 수 있습니다. 여기서 중요한 주장은 특정 설정 방법보다 범위가 좁습니다. 디코딩과 인코딩 사이의 변환은 클라이언트가 단순한 코덱 변경 이상의 작업을 요구할 때 비용이 큰 단계가 될 수 있습니다.

HDR 톤 매핑이나 자막 번인이 활성화된 경우에만 재생 속도가 느려진다면, 인코더가 반드시 병목이라는 뜻은 아닙니다. GPU 성능이나 비트레이트 설정을 변경하기 전에 해당 변환을 제거한 동일한 소스와 비교해 보세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

하드웨어 인코딩은 클라이언트 호환 출력물을 생성합니다

처리 가능한 프레임이 준비되면 인코더는 세션에 선택된 출력 형식과 화질에 맞게 프레임을 압축합니다. 가속기가 요청된 출력을 지원하고 Plex가 해당 가속기에 액세스할 수 있다면, 하드웨어 비디오 인코딩은 CPU 부하를 크게 줄일 수 있습니다.

하드웨어 인코딩을 활성화한 후 실제 비디오 변환이 발생하면 CPU 사용률만 높아지는 것이 아니라 하드웨어 활동으로 표시되어야 합니다. 이 확인을 통해 단계의 작동 위치를 파악할 수 있지만, 단계 자체의 작업 내용이 바뀌는 것은 아닙니다.

그런 다음 인코딩된 비디오는 선택된 오디오 및 컨테이너 또는 스트림 패키징과 결합됩니다. 클라이언트는 요청에 맞는 새 스트림을 수신하며, 저장 장치의 원본 소스는 변경되지 않습니다.

원활한 재생은 전체 출력 경로에 달려 있습니다

빠른 인코딩은 변환이 필요할 때만 필수이며, 그 자체만으로는 충분하지 않습니다. 트랜스코딩 임시 저장 공간, 네트워크 전송, 클라이언트 버퍼 및 클라이언트 디코더도 모두 처리 속도를 따라가야 합니다. 따라서 성능이 충분한 GPU가 제때 프레임 처리를 완료하더라도 다른 단계에서 눈에 띄는 버퍼링이 발생할 수 있습니다.

소스가 이미 호환되는 경우 원활한 4K 재생은 여전히 Direct Play 요구 사항에 달려 있습니다. 클라이언트가 원본 파일을 수용할 수 있다면 더 빠른 변환 경로를 구축하는 것보다 변환을 피하는 편이 일반적으로 더 간단합니다.

실제 클라이언트 불일치가 있을 때만 다음 선택지로 클라이언트 호환성 또는 트랜스코딩 성능을 고려하세요. 하드웨어 트랜스코딩은 호환성을 연결하는 수단이며, Direct Play는 같은 파이프라인의 마지막 단계가 아닌 별도의 경로입니다.