오디오 트랜스코딩이 미디어 서버 재생 파이프라인에 어떤 변화를 주나요?

오디오 트랜스코딩은 클라이언트가 비디오는 수용하지만 선택된 오디오 코덱, 채널 레이아웃, 샘플 형식 또는 컨테이너 조합을 디코딩할 수 없을 때 미디어 서버 재생 파이프라인을 변경합니다. 서버는 원본 비디오 비트스트림을 유지하면서 오디오 경로만 디코딩하고 재구성할 수 있습니다.

이는 전체 비디오 트랜스코딩보다 훨씬 저렴하지만 무료는 아닙니다. 서버는 여전히 코덱 협상, 오디오 디코드, 채널 리믹싱 또는 리샘플링, 인코딩, 타임스탬프 정렬, 리멕싱, 때로는 세그먼트 생성을 수행한 후에야 재생을 계속할 수 있습니다.

어떤 호환성 검사로 인해 오디오 트랜스코딩이 발생하나요?

미디어 서버는 재생 경로를 선택하기 전에 소스 스트림과 클라이언트 프로필을 비교합니다. 클라이언트 코덱 지원이 재생 방식을 결정합니다. 텔레비전은 비디오 코덱을 지원하지만 TrueHD, DTS, 다채널 AAC 또는 특정 채널 레이아웃은 거부할 수 있습니다.

Direct Play는 클라이언트가 저장된 전체 파일을 수용해야 합니다. Direct Stream은 컨테이너를 변경하면서 호환 가능한 스트림을 유지할 수 있고, 오디오 전용 트랜스코딩은 비디오를 디코딩하지 않고도 하나의 호환되지 않는 오디오 스트림을 대체할 수 있습니다.

선택한 자막, 원격 대역폭 설정, 재생 애플리케이션, HDMI 오디오 장치 또는 브라우저에 따라 결정이 달라질 수 있습니다. 호환성은 디스플레이 패널뿐 아니라 전체 재생 체인에 속합니다.

왜 비디오 스트림은 변경되지 않고 유지될 수 있나요?

미디어 컨테이너는 별도의 비디오, 오디오, 자막 스트림을 보관합니다. 비디오는 복사된 상태로 유지하면서 오디오만 변환할 수 있습니다, 이를 통해 서버는 모든 프레임을 디코딩하는 대신 압축된 비디오 패킷을 새 출력으로 복사할 수 있습니다.

비디오 스트림 복사는 원본 코덱, 해상도, 프레임 속도, HDR 정보 및 압축 품질을 유지합니다. 또한 디코드, 스케일링, 톤 매핑, 비디오 인코딩과 관련된 GPU 또는 CPU 작업 부하를 피할 수 있습니다.

출력물은 여전히 동기화된 타임스탬프와 클라이언트가 수용하는 컨테이너 또는 전달 방식을 필요로 합니다. 따라서 비디오를 변경하지 않는 것은 가장 비용이 많이 드는 변환을 제거하지만 나머지 파이프라인을 우회하지는 않습니다.

디코드, 리믹스, 리샘플, 인코드 과정에서 무슨 일이 일어날까요?

트랜스코딩은 압축된 소스를 다른 표현으로 변환합니다. 오디오 트랜스코딩은 하나의 스트림을 디코딩하고 재인코딩합니다. 오디오의 경우 서버는 먼저 압축된 샘플을 중간 PCM 유사 형식으로 디코딩합니다.

그 후 7.1 또는 5.1 채널을 스테레오로 다운믹스하거나, 채널 매핑을 변경하거나, 샘플 레이트를 조정하거나, 샘플 형식을 변환한 다음 AAC, AC-3, Opus, MP3 또는 다른 클라이언트 지원 코덱으로 인코딩할 수 있습니다.

각 단계는 CPU와 메모리 대역폭을 소비하며 샘플을 버퍼링할 수 있습니다. 오디오 인코딩은 보통 비디오 인코딩보다 훨씬 가볍지만, 여러 동시 스트림, 고해상도 오디오, 소프트웨어 전용 코덱, 또는 작은 홈 서버에서는 부하가 눈에 띌 수 있습니다.

왜 컨테이너나 전달 프로토콜도 변경될 수 있을까요?

변환된 오디오와 복사된 비디오는 호환 가능한 구조로 전달되어야 합니다. HLS 패키징은 매니페스트와 미디어 세그먼트를 추가하므로, 서버는 비디오 픽셀이 변경되지 않아도 스트림을 리멕스하고 매니페스트와 세그먼트를 생성할 수 있습니다.

원본 MKV 컨테이너를 거부하는 클라이언트도 분할 MP4, MPEG-TS 또는 다른 스트리밍 형식 내 동일한 비디오를 수락할 수 있습니다. 이 경로는 압축이 호환 스트림에 대해 유지되고 패키징만 변경되므로 종종 직접 스트림(Direct Stream)이라고 불립니다.

세분화는 버퍼링과 타임스탬프 경계를 도입합니다. 서버는 탐색, 트랙 변경, 불연속성, 라이브 재생 목록 업데이트 동안 새로 인코딩된 오디오를 복사된 비디오와 정렬 상태로 유지해야 합니다.

오디오 선택이 동기화, 품질, 서버 부하에 어떤 영향을 미칠까요?

모든 손실 재인코딩은 품질을 변경할 수 있으며, 트랜스코딩은 호환성을 위해 계산 자원과 품질을 교환합니다. 낮은 비트레이트나 스테레오 다운믹스는 전송 요구사항을 줄이지만 원본 몰입형 트랙의 모든 특징을 보존할 수는 없습니다.

오디오 필터는 지연을 추가하며 프레젠테이션 타임스탬프를 유지해야 합니다. 잘못된 타임스탬프 처리, 긴 인코더 버퍼, 또는 파이프라인 재시작은 비디오 스트림 자체가 재인코딩되지 않았음에도 립싱크 어긋남을 초래할 수 있습니다.

Hardware acceleration may help video but not the selected audio codec, so a dashboard can show video stream copy beside nonzero CPU use. The correct comparison is audio-only transcoding versus full video transcoding, not versus a completely idle server.

하드웨어 가속은 비디오에는 도움이 될 수 있지만 선택된 오디오 코덱에는 도움이 되지 않을 수 있으므로 대시보드에 비디오 스트림 복사와 함께 0이 아닌 CPU 사용량이 표시될 수 있습니다. 올바른 비교는 오디오 전용 트랜스코딩과 전체 비디오 트랜스코딩 간의 비교이지, 완전히 유휴 상태인 서버와의 비교가 아닙니다.

오디오 트랜스코딩이 전체 비디오 트랜스코딩으로 확대되는 경우는 언제인가요?

자막 번인은 비디오 스트림 자체를 변경합니다. 호환되지 않는 비디오 코덱, 해상도 제한, 비트레이트 제한, 톤 매핑 요구 사항 또는 이미지 자막도 마찬가지로 서버가 비디오를 디코딩하고 인코딩하도록 강제할 수 있습니다.

파이프라인은 훨씬 무거워집니다: 비디오 디코딩, 필터링, 스케일링 또는 톤 매핑, 비디오 인코딩, 오디오 변환 및 멕싱이 모두 함께 작동할 수 있습니다. 오디오 호환성 문제는 원본 파일을 직접 전달할 수 없었던 한 가지 이유일 뿐입니다.

자주 묻는 질문

오디오 트랜스코딩이 비디오 품질을 저하시킬까요?

비디오 스트림이 변경 없이 복사될 때는 그렇지 않습니다. 비디오 품질은 서버가 비디오를 디코딩하고 재인코딩할 때만 변경됩니다.

왜 스테레오 클라이언트가 트랜스코딩을 유발하나요?

소스가 지원되지 않는 코덱이나 다채널 레이아웃을 사용할 경우 서버가 디코딩, 다운믹스, 호환 가능한 스테레오 트랙 인코딩을 해야 할 수 있습니다.

오디오 트랜스코딩이 버퍼링을 유발할 수 있나요?

서버가 충분히 빠르게 인코딩할 수 없거나 세그먼트 생성이 지연되거나 타임스탬프가 어긋나거나 네트워크 및 저장 경로가 제한될 때 그렇습니다.

Direct Stream과 Direct Play는 같은 것인가요?

아니요. Direct Play는 원본 파일 구조를 전송하는 반면, Direct Stream은 호환 가능한 스트림을 리멕스하고 지원되지 않는 스트림만 트랜스코딩할 수 있습니다.

최종 요점

오디오 트랜스코딩은 호환되지 않는 오디오 스트림을 교체하면서 종종 원본 비디오 비트스트림을 유지합니다. 서버는 여전히 미디어를 디코딩, 리믹스, 리샘플링, 인코딩, 동기화 및 재패키징하므로 세션은 Direct Play보다 더 많은 리소스를 사용하지만 전체 비디오 트랜스코딩보다는 훨씬 적은 리소스를 사용합니다. 실제 파이프라인을 이해하려면 스트림별 재생 상태를 진단하세요.