클라이언트 호환성과 트랜스코딩 성능: 무엇이 먼저 버퍼링을 막을까?

하나 또는 소수의 재생 장치가 라이브러리의 비디오, 오디오, 컨테이너 또는 자막 형식을 Direct Play로 재생하지 못해 버퍼링이 시작된다면, 더 많은 트랜스코딩 성능을 구매하기 전에 클라이언트 호환성 문제를 해결하세요. 여러 클라이언트에서 변환이 불가피하거나, 원격 비트레이트 제한으로 인해 낮은 화질의 스트림이 정기적으로 필요하거나, 기존 트랜스코딩 엔진이 실시간 처리를 따라가지 못한다면 서버 트랜스코딩 용량을 먼저 업그레이드하세요. 네트워크가 전송되는 비트레이트를 감당할 수 없다면 어느 업그레이드도 우선해서는 안 됩니다.

이는 일반적인 “클라이언트 대 서버” 비교가 아니라 업그레이드 순서를 결정하는 문제입니다. 첫 번째 작업은 실제 재생 경로와 경로가 변경된 이유를 파악하는 것입니다. 호환되는 클라이언트는 서버의 작업을 완전히 없앨 수 있지만, 더 빠른 서버는 여전히 필요한 작업만 더 빠르게 처리합니다.

스트림이 Direct Play로 재생되지 않는 이유부터 파악하세요

문제가 있는 스트림 하나를 시작하고 미디어 서버의 재생 정보를 확인하세요. 이를 Direct Play, Direct Stream 또는 리먹스, 오디오 전용 트랜스코딩, 비디오 트랜스코딩으로 분류하세요. 그런 다음 변환 이유를 기록하세요. 지원되지 않는 코덱, 지원되지 않는 컨테이너, 자막 번인, 비트레이트 제한, HDR 톤 매핑 또는 기타 클라이언트 기능 문제인지 확인하세요.

Plex는 Direct Play를 호환되는 미디어를 변환 없이 전송하는 방식으로, Direct Stream을 호환되는 스트림을 재패키징하는 방식으로, 트랜스코딩을 클라이언트에 맞게 미디어를 변환하는 방식으로 설명합니다. 또한 스트리밍 경로 개요에서는 자막이 원래 호환되던 재생 경로를 바꿀 수 있다고 설명합니다.

이 분류가 안정될 때까지는 아무것도 구매하지 마세요. 스트림이 이미 Direct Play로 재생되는데도 버퍼링이 발생한다면 클라이언트 코덱 지원은 첫 번째 문제가 아니며, 추가 트랜스코딩 성능을 전혀 사용하지 않을 수도 있습니다. 대신 네트워크 처리량, Wi-Fi 품질, 서버 디스크 읽기 성능, 전송되는 비트레이트를 테스트하세요.

1. 스트림이 Direct Play로 재생된다면 호환성과 트랜스코딩 비교를 중단하고 전송 문제를 조사하세요.
2. 한 클라이언트가 형식 지원 문제로 변환을 강제한다면, 호환성이 더 높은 클라이언트나 클라이언트 앱을 테스트하세요.
3. 많은 클라이언트에서 실제로 변환이 필요하다면 서버의 트랜스코딩 용량을 측정하세요.
4. 원격 대역폭 때문에 비트레이트를 낮춰야 한다면 서버 변환과 업로드 용량을 별도의 제약 조건으로 취급하세요.

호환성이 원인이라면 더 나은 클라이언트가 해결책입니다

라이브러리를 기본 디코딩할 수 있는 클라이언트는 CPU 또는 GPU를 많이 사용하는 비디오 트랜스코딩을 Direct Play로 전환할 수 있습니다. 이는 질적인 변화입니다. 서버가 해당 엔드포인트를 맞추기 위해 비디오를 디코딩한 뒤 다시 인코딩할 필요가 없어지기 때문입니다. 따라서 문제가 있는 TV나 스트리밍 스틱 하나만 대상으로 한다면 엔드포인트를 변경하는 것이 서버 컴퓨팅 성능을 추가하는 것보다 더 효과적일 수 있습니다.

Jellyfin의 최신 클라이언트 코덱 지원 표를 보면 브라우저, Android TV, iOS, Roku, Kodi, 데스크톱 클라이언트, 컨테이너, 오디오 형식, HDR 모드, 자막에 따라 호환성이 달라집니다. 라이브러리가 전반적으로 “표준”이더라도 특정 엔드포인트의 제한에 부딪힐 수 있습니다.

전환 조건은 사용자 단말의 규모입니다. 한 엔드포인트가 대부분의 트랜스코딩을 유발한다면 해당 클라이언트를 교체하거나 변경하는 것이 매력적입니다. 하지만 원격 사용자 다섯 명, 여러 구형 TV, 모바일 기기처럼 모두 서로 다른 변환이 필요하다면, 엔드포인트를 하나씩 호환시키는 것이 서버에 중앙 변환 용량을 충분히 제공하는 것보다 운영 비용이 더 클 수 있습니다.

전송이 병목일 때는 어느 쪽 업그레이드도 해결책이 아닙니다

재생 형식이 완전히 호환되고 서버의 트랜스코딩 용량에 여유가 있어도 버퍼링은 발생할 수 있습니다. 약한 Wi-Fi를 통한 고비트레이트 파일, 제한된 WAN 업로드 대역폭, 또는 혼잡한 클라이언트 연결은 모든 컴퓨팅 그래프가 정상적으로 보여도 재생에 필요한 데이터를 부족하게 만들 수 있습니다.

Android의 미디어 문서에는 플랫폼 디코딩 및 컨테이너 지원이 나와 있지만, 지원되는 미디어 형식은 기기가 해당 형식을 처리할 수 있는지만 알려줄 뿐, 네트워크가 스트림을 충분히 빠르게 전송할 수 있는지는 알려주지 않습니다. 호환성과 전송 용량은 서로 독립적인 관문입니다.

이는 이 프레임워크에서 가장 중요한 중단 규칙입니다. 서버가 처리 능력보다 낮은 수준으로 데이터를 전송하는 동안 Direct Play 세션이 버퍼링되고, 네트워크 측정에서 손실이나 처리량 부족이 확인된다면 코덱 문제를 이유로 클라이언트를 교체하거나 더 강력한 트랜스코더를 구매하지 마세요. 먼저 전송 경로를 해결하세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

대규모로 변환이 불가피할 때는 트랜스코딩 성능이 중요합니다

모든 가정에서 모든 엔드포인트나 네트워크 환경을 표준화할 수 있는 것은 아닙니다. 원격 사용자는 더 낮은 비트레이트가 필요할 수 있고, 구형 TV는 최신 코덱을 지원하지 않을 수 있으며, 가족 구성원의 기기는 소유자가 제어할 수 없을 수도 있습니다. 이러한 변환이 빈번하고 정당하게 발생한다면 중앙 트랜스코딩 용량을 확보하는 것이 확장성을 높이는 방법입니다.

FFmpeg는 스트림 복사와 디코드, 필터, 인코드 작업을 구분합니다. 트랜스코딩 문서는 변환이 필요해진 이후에만 서버 성능이 중요한 이유를 설명합니다. 호환되는 스트림을 복사하면 코덱 작업을 피할 수 있지만, 변환하면 디코드 및 인코드 단계가 추가되고 필터가 더해질 수 있습니다.

측정된 트랜스코딩이 실시간 속도를 유지하지 못하거나, 비디오 엔진이 포화되거나, 피할 수 없는 동시 변환 작업이 현재 시스템의 용량을 초과할 때 서버를 업그레이드하세요. 같은 파일을 Direct Play할 수 있었던 저렴한 클라이언트 하나를 보완하기 위해 더 빠른 GPU를 사용하지 마세요.

자막과 HDR은 호환되는 것처럼 보이는 스트림의 처리 방식을 바꿀 수 있습니다

기기가 비디오 코덱을 지원하더라도 선택한 자막이나 HDR 요구 사항 때문에 높은 처리 부하가 발생할 수 있습니다. 일부 클라이언트에서는 이미지 기반 자막을 비디오에 번인해야 할 수 있으며, 디스플레이나 클라이언트 경로에서 원본을 올바르게 표시할 수 없을 때 HDR-to-SDR 톤 매핑이 추가 처리 단계로 들어갈 수 있습니다.

Apple이 공개한 Apple TV 재생 사양에는 지원되는 비디오 형식, 프로필, 프레임 레이트, HDR 모드 및 오디오 기능이 나와 있습니다. 기기 형식 사양은 “HEVC 지원” 또는 “4K 지원”만으로는 완전한 호환성 테스트가 될 수 없는 이유를 보여 줍니다. 프로필, 컨테이너, HDR, 오디오 및 자막 처리 방식도 실제 재생 경로에 영향을 줄 수 있습니다.

하드웨어를 교체하기 전에 정확히 문제가 발생하는 조합을 테스트하세요. 자막을 비활성화하고, 텍스트 자막을 선택하고, SDR 버전을 사용하거나, 오디오 트랙을 변경한 뒤 비디오 트랜스코딩이 중단되는지 확인하세요. 특정 기능 하나로 세션의 처리 방식이 바뀐다면 전체 서버를 확장하는 것보다 해당 호환성 문제를 해결하는 편이 저렴할 수 있습니다.

하나의 엔드포인트를 수정하는 비용과 모든 스트림을 수정하는 비용 비교

클라이언트 업그레이드는 개별적인 해결책입니다. 거실의 한 기기가 문제를 일으킬 때 효율적이며, 해당 엔드포인트에서 향후 발생하는 모든 세션에 필요한 서버 전력 사용량을 줄일 수 있습니다. 단점은 반복성입니다. 호환되지 않는 클라이언트마다 자체 앱, 설정 또는 하드웨어 변경이 필요할 수 있습니다.

서버 업그레이드는 중앙 집중식으로 이루어집니다. 더 강력한 트랜스코더 하나로 성능이 낮은 여러 클라이언트를 지원할 수 있으므로 각 엔드포인트를 변경할 필요가 없습니다. 하지만 그 대신 서버가 더 많은 전력, 냉각, 드라이버 및 하드웨어 가속 관련 복잡성을 감당해야 합니다. 인접한 ZimaSpace의 소형 x86 미디어 서버와 Android TV 박스 비교에서는 더 넓은 기기 역할의 맥락을 제공하며, 이 프레임워크에서는 버퍼링의 원인에 따라 선택 범위를 좁힙니다.

불가피한 변환 사례의 수가 늘어날수록 결정은 클라이언트 우선에서 서버 우선으로 바뀝니다. 호환되지 않는 엔드포인트가 하나뿐이라면 해당 엔드포인트를 수정하는 편이 유리합니다. 여러 클라이언트가 혼재하고 원격 변환이 자주 발생한다면 중앙 트랜스코딩 용량을 늘리는 편이 유리하지만, 네트워크가 제한 요소가 아니어야 합니다.

이 업그레이드 순서 결정 트리 사용

이 프레임워크는 일반적인 권고가 아니라 실행 가능한 순서로 끝나야 합니다. 가능하면 동일한 문제가 있는 콘텐츠를 최소 두 개의 클라이언트에서 재생하고, 서버의 재생 사유를 확인한 다음, 클라이언트의 제한을 서버의 제한으로 오인하지 않도록 한 번에 하나의 변수만 변경하세요.

각 단계 후 결과를 테스트할 수 있어야 합니다. 클라이언트 우선 변경은 세션이 Direct Play 또는 더 가벼운 Direct Stream 경로로 전환될 때 성공한 것입니다. 서버 우선 변경은 예상되는 동시 스트림 수에서 필요한 트랜스코딩이 여유 용량을 확보한 채 재생을 유지할 때 성공한 것입니다.

어느 변경도 문제가 발생하는 스트림을 개선하지 못한다면 첫 번째 관문으로 돌아가 전송, 저장 장치 또는 애플리케이션이 보고한 원인을 점검하세요. 의사결정 트리는 관련 없는 업그레이드를 중단할 수 있을 때만 유용합니다.

자주 묻는 질문

더 빠른 트랜스코더가 Direct Play을 개선하나요?

아니요. Direct Play에서는 비디오 변환을 수행하지 않으므로 CPU나 GPU 트랜스코딩 용량을 추가해도 클라이언트가 원본 스트림을 더 빠르게 디코딩하지는 못합니다. Direct Play에서 버퍼링이 발생한다면 네트워크 전송, 클라이언트 재생 동작, 저장 장치를 대신 조사하세요.

자막만으로 비디오 트랜스코딩이 강제될 수 있나요?

그렇습니다. 일부 자막 형식이나 클라이언트 조합에서는 자막을 비디오에 직접 삽입해야 하므로, 원래는 호환되는 스트림도 비디오 처리 작업으로 전환됩니다. 비디오 코덱을 탓하기 전에 같은 파일을 자막 없이 테스트해 보세요.

트랜스코딩을 피하려면 오래된 클라이언트를 모두 교체해야 하나요?

반드시 그렇지는 않습니다. 문제가 있는 엔드포인트 하나를 교체하는 것은 효율적일 수 있지만, 서로 다른 클라이언트 전체를 교체하는 것은 그렇지 않을 수 있습니다. 호환되는 클라이언트는 Direct Play로 유지하고, 실제로 변환을 피할 수 없는 기기나 원격 환경에 맞춰 서버 트랜스코딩을 구성하세요.

재생 경로에서 가장 먼저 나타나는 원인을 해결하세요

소수의 엔드포인트 때문에 불필요한 트랜스코딩이 발생한다면 클라이언트 호환성을 우선 선택하세요. 최선의 결과는 더 빠른 트랜스코딩이 아니라 불필요한 변환을 없애 서버가 원본 미디어를 전송하도록 하는 것입니다.

여러 기기나 원격 세션에서 실제로 변환이 필요하고 현재 서버가 실시간 처리를 유지하지 못할 때는 트랜스코딩 성능을 우선 선택하세요. 가정에서 사용하는 정확한 코덱, 자막, HDR 모드, 출력 해상도를 기준으로 하드웨어 가속 지원과 동시 처리 용량을 확인하세요.

스트림이 이미 Direct Play 상태이거나 네트워크가 전송되는 비트레이트를 감당하지 못한다면, 이 두 업그레이드를 더 이상 비교하지 마세요. 올바른 첫 번째 해결책은 벤치마크 수치가 더 큰 부품이 아니라 재생 경로에서 가장 먼저 측정된 병목을 해결하는 것입니다.