원격 4K 스트리밍을 위한 Plex: 하드웨어 트랜스코딩이 워크플로를 바꾸는 방식

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

하드웨어 트랜스코딩은 원격 4K Plex를 단순 전송 작업에서 실시간 디코딩, 변환, 인코딩 및 버퍼링 파이프라인으로 바꿉니다.

호환되는 원격 클라이언트는 서버에 비디오를 다시 구성하도록 요구하지 않고도 4K를 Direct Play할 수 있습니다. 대역폭, 코덱 지원, HDR 처리, 자막 또는 클라이언트의 화질 요청으로 인해 변환이 필요해지면 작업 흐름이 달라집니다. Plex는 소스를 디코딩하고, 필요한 변환을 적용하고, 새로운 출력을 인코딩한 다음, 그 출력이 클라이언트보다 앞서도록 유지해야 합니다. 따라서 중요한 기준점은 실시간 여유를 유지하지 못하기 시작하는 첫 번째 단계입니다.

하드웨어 트랜스코딩은 클라이언트가 소스를 사용할 수 없을 때만 시작됩니다

Plex는 먼저 요청된 비디오, 오디오, 자막, 컨테이너 및 화질을 비디오 변경 없이 전송할 수 있는지 판단합니다. 클라이언트가 소스를 허용하면 Direct Play는 더 가벼운 경로를 유지합니다. 이러한 호환성 또는 전송 조건 중 하나로 인해 Plex가 다른 스트림을 만들어야 할 때만 전체 비디오 트랜스코딩이 시작됩니다.

실제 차이는 Direct Play 및 트랜스코딩 경로에서 확인할 수 있습니다. Direct Play는 원본 미디어를 전송하는 반면, 트랜스코딩은 클라이언트 요청에 맞춰 스트림을 다시 구성합니다. 이로 인해 서버의 작업은 바이트를 읽고 전송하는 것에서 실시간 변환 파이프라인을 지속적으로 유지하는 것으로 바뀝니다.

재생 결정을 첫 번째 작업 관문으로 보세요. GPU를 선택하거나 트랜스코딩 설정을 변경하기 전에 실제 클라이언트, 선택한 오디오 트랙, 자막 및 화질 제한을 사용해 원격 요청을 재현하세요. 세션이 Direct Play로 재생된다면 GPU 성능이 첫 번째 제약 조건이 아닙니다. 트랜스코딩이 발생한다면 변환으로 추가되는 단계를 계속 점검하세요.

디코딩은 압축된 4K 소스를 작업 프레임으로 변환합니다

비디오 변환이 시작되면 소스를 그대로 전달할 수 없습니다. 디코더는 HEVC, H.264 또는 지원되는 다른 코덱에서 작업 프레임을 복원하며, 이 프레임은 이후에 수행되는 크기 조정, 색상 변환, 자막 합성 또는 재인코딩의 입력이 됩니다. 이는 Direct Play가 건너뛰는 첫 번째 고부하 연산 단계입니다.

소스 코덱과 비트 심도에 더 높은 수준의 디코딩 경로가 필요하면 4K 작업의 부담이 커집니다. 따라서 프로세서를 비교하기 전에 4K 코덱 호환성을 확인해야 합니다. 해상도가 같아 보이는 4K 파일이라도 서로 다른 디코딩 작업을 발생시킬 수 있습니다.

CPU 사용량이 낮다는 이유만으로 추정하지 말고, 디코딩이 실제로 의도한 미디어 엔진을 사용하는지 확인하세요. 부분적으로 가속된 파이프라인에서는 한 단계가 여전히 소프트웨어에서 처리될 수 있습니다. 동일한 소스 파일 하나를 사용해 같은 트랜스코딩을 두 번 강제하고, 하드웨어를 변경하기 전에 CPU 사용량, GPU 비디오 엔진 활동 및 트랜스코딩 속도를 비교하세요.

변환 단계는 파이프라인의 비용이 큰 중간 구간이 될 수 있습니다

디코딩된 프레임은 인코딩 전에 크기 조정, HDR-SDR 톤 매핑, 색상 변환 또는 자막 번인 처리가 추가로 필요할 수 있습니다. 이러한 변환은 디코딩과 인코딩 사이에 위치하므로 두 코덱을 모두 지원하는 GPU라도 중간 단계가 지원되지 않거나 CPU로 대체되거나 추가 중간 버퍼를 만들어야 하면 어려움을 겪을 수 있습니다.

기본적인 트랜스코딩이 이미 작동하더라도 HDR 및 자막 작업에 따라 경로가 크게 달라질 수 있습니다. HDR 및 자막 처리는 자막을 끄고 SDR 미디어만 사용하는 단순한 벤치마크가 아니라 실제 클라이언트가 발생시키는 변환을 테스트해야 한다는 점을 보여주는 좋은 예입니다.

SDR 크기 조정, HDR 톤 매핑 및 가정에서 실제로 사용하는 자막 형식에 대해 별도의 부하 테스트를 구성하세요. 한 가지 경우에만 처리가 뒤처진다면 전체 서버를 업그레이드하지 말고 해당 변환 단계에서 원인을 진단하세요. 더 넓은 범위의 4K 설정은 4K Plex 서버 경로를 기준으로 확인할 수 있습니다.

-15% OFF

인코딩은 원격 환경에 맞는 새로운 비디오 스트림을 생성합니다

변환이 끝나면 Plex는 작업 프레임을 원격 세션에 요청된 출력 코덱, 해상도 및 비트레이트로 압축합니다. 하드웨어 인코딩은 요청된 출력 경로가 지원되고 컨테이너가 가속기에 액세스할 수 있을 때 이 반복적인 프레임 단위 작업을 전용 미디어 엔진으로 옮길 수 있습니다.

디코딩과 인코딩은 서로 별도의 관문으로 다뤄야 합니다. 한 시스템이 한쪽만 가속하고 다른 쪽은 가속하지 못할 수 있기 때문입니다. 실용적인 하드웨어 트랜스코딩 안내에서는 하드웨어 디코딩 및 인코딩을 하나의 켜짐/꺼짐 설정으로 묶지 말고 서로 다른 단계로 확인해야 한다고 설명합니다.

스트림이 안정된 후와 탐색 또는 화질 변경 중에 트랜스코딩 속도를 확인하세요. 인코더가 재생보다 앞서지 못하면 저장 장치와 업로드 상태가 양호하더라도 원격 세션은 결국 버퍼를 소진합니다. 인코더에 여유가 있다면 임시 저장 공간, 네트워크 전송 및 클라이언트 버퍼링으로 점검 범위를 넓히세요.

변환된 스트림이 원활하게 느껴지는지는 버퍼링과 전송이 결정합니다

인코딩된 프레임은 패키징된 후 임시로 기록되거나 버퍼링되고, 서버 네트워크 인터페이스를 통해 전송되어 원격 경로를 거친 다음 클라이언트 버퍼에 충분히 일찍 도착해야 합니다. 하드웨어 트랜스코딩은 하나의 연산 병목을 제거하지만, 나머지 전송 체인을 무제한으로 만들어 주지는 않습니다.

원격 4K는 변환과 전송이 모두 재생보다 앞서 있을 때만 안정적입니다. 따라서 버퍼 고갈 증상은 GPU가 너무 느리다는 증거로 단정하지 말고 트랜스코딩 속도 및 네트워크 처리량과 함께 해석해야 합니다.

완전한 승인 테스트를 진행하세요. 재생 모드를 확인하고, 하드웨어 디코딩과 인코딩을 검증하고, 필요한 변환 중 가장 부하가 큰 작업을 실행한 다음, 같은 세션에서 트랜스코딩 속도와 업로드 및 클라이언트 동작을 측정하세요. 하드웨어 트랜스코딩은 연산 단계를 추가하여 작업 흐름을 바꾸지만, 원활한 원격 4K 재생은 여전히 모든 후속 단계가 충분한 여유를 유지하는지에 달려 있습니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.