자막 번인(Burn-In)이 미디어 서버 트랜스코딩 비용을 증가시키는 이유는 무엇인가요?

자막 번인은 자막이 별도의 선택 가능한 트랙으로 제공되지 않기 때문에 미디어 서버의 트랜스코딩 비용을 증가시킵니다. 서버는 각 큐를 비디오 이미지에 렌더링하여 새로운 픽셀을 생성해야 하며, 이는 소스를 디코딩, 필터링, 인코딩하여 대체 스트림을 만들어야 함을 의미합니다.

이로 인해 호환 가능한 Direct Play 또는 Direct Stream 세션이 전체 비디오 트랜스코딩으로 전환될 수 있습니다. 비용은 해상도, 코덱, 프레임 속도, 자막 형식, 스타일링, 하드웨어 가속, 클라이언트가 자막 트랙을 로컬에서 렌더링할 수 있었는지 여부에 따라 달라집니다.

자막이 비디오에 번인되면 무엇이 달라지나요?

번인된 자막은 각 프레임의 일부가 됩니다. 더 이상 플레이어가 활성화, 비활성화, 크기 조정 또는 교체할 수 있는 독립적인 텍스트나 비트맵 스트림이 아닙니다.

별도의 자막 트랙은 타이밍과 텍스트, 스타일링 또는 이미지를 포함합니다. 클라이언트는 해당 형식과 렌더링 기능을 지원할 때 재생 시 디코딩된 비디오와 그 트랙을 결합할 수 있습니다.

번인은 합성 단계를 서버로 이동시킵니다. 미디어 서버는 압축된 프레임에 글리프, 윤곽선, 색상, 위치, 애니메이션이 이미 포함된 새 비디오 표현을 생성해야 합니다.

왜 번인이 전체 비디오 트랜스코딩을 유발하나요?

자막 번인은 전체 비디오 트랜스코딩을 유발합니다 왜냐하면 압축된 비디오 패킷에 자막 텍스트를 첨부하여 변경할 수 없기 때문입니다. 자막은 디코딩 후와 새 인코딩 전 사이에 적용되어야 합니다.

리멕싱은 호환 가능한 비디오 패킷을 다른 컨테이너로 복사할 수 있고, 오디오 트랜스코딩은 비디오를 건드리지 않을 수 있습니다. 번인(Burn-in)은 비디오 스트림의 실제 이미지 내용을 변경하기 때문에 다릅니다.

소스 해상도와 비트레이트가 허용 범위 내에 있더라도 변경된 픽셀은 새로운 압축 비트스트림을 필요로 합니다. 서버는 원본 인코딩 비디오를 유지하면서 자막이 모든 표시된 프레임에 포함되어 있다고 주장할 수 없습니다.

트랜스코딩 파이프라인에서 비용이 많이 드는 단계는 무엇인가요?

서버는 비디오를 디코딩, 필터링, 재인코딩합니다. 자막 파싱 및 렌더링은 소스 디코딩과 출력 인코딩 사이의 필터 단계에 삽입됩니다.

4K 또는 고프레임 속도에서는 파이프라인이 매 프레임마다 수백만 개의 픽셀을 처리합니다. 폰트 셰이핑, 외곽선, 그림자, 스케일링, 색상 변환, 톤 매핑, 크기 조정이 자막 오버레이와 결합될 수 있습니다.

서버는 또한 실시간보다 빠르게 유지되고 출력 버퍼를 유지해야 합니다. 0.8배속으로 인코딩하는 파이프라인은 처음 몇 초가 성공적으로 시작되더라도 결국 멈춥니다.

왜 자막 형식이 비용에 영향을 미치나요?

이미지 자막은 픽셀 오버레이가 필요합니다. PGS와 VobSub는 이미 비트맵 그래픽을 포함하고 있으며, ASS나 SSA는 폰트, 위치, 색상, 효과, 애니메이션 스타일링을 포함할 수 있습니다.

간단한 SRT 또는 WebVTT 텍스트는 많은 클라이언트가 직접 렌더링하기 더 쉽습니다. 복잡한 ASS 스타일링은 지원되지 않거나 다르게 렌더링될 수 있어, 서버가 의도한 모양을 유지하기 위해 번인 처리할 수 있습니다.

이미지 자막 트랙은 인식 없이는 일반 텍스트로 변환할 수 없습니다. 서버는 해당 비트맵 큐를 올바른 시간에 합성하고 비디오 출력에 맞게 크기를 조정해야 합니다.

왜 하드웨어 가속이 병목 현상을 남길 수 있나요?

하드웨어 가속은 파이프라인의 일부만 커버할 수 있습니다. 디코드와 인코드는 GPU나 미디어 엔진에서 실행되지만, 자막 파싱, 폰트 렌더링 또는 일부 필터 작업은 CPU에서 처리됩니다.

프레임이 하드웨어 디코드에서 시스템 메모리로 이동해 CPU 오버레이를 거친 후 다시 하드웨어 인코드로 돌아갈 때, 메모리 복사와 동기화가 가속화 이점의 일부를 상쇄할 수 있습니다. 하드웨어 지원이 없는 필터가 하나라도 있으면 제로 카피 경로 유지가 더 어렵습니다.

결과는 오해를 불러일으킬 수 있습니다: GPU 디코드와 인코드는 활성화되어 있지만, CPU에 의존하는 자막 단계 하나가 전체 파이프라인을 제한합니다. 제한하는 렌더러가 소수의 스레드만 사용할 때 전체 CPU 사용량은 보통으로 보일 수 있습니다.

홈 미디어 서버가 번인 비용을 피하는 방법은 무엇인가요?

클라이언트 호환 자막은 프레임 렌더링을 피합니다. SRT 또는 WebVTT와 같은 텍스트 형식은 재생 클라이언트가 지원할 때 가장 쉬운 옵션인 경우가 많습니다.

라이브러리의 일반 자막 형식을 렌더링하는 클라이언트를 선택하거나, 미디어 옆에 외부 텍스트 자막을 유지하거나, 라이브러리 준비 중에 호환 가능한 자막 트랙을 생성하세요. 자주 보는 콘텐츠는 사전 생성된 버전을 사용해 인코딩 비용을 재생 시간 외부로 옮길 수 있습니다.

더 빠른 하드웨어 구매 전에 세션의 트랜스코딩 이유를 확인하세요. 자막 처리가 버퍼링 병목 현상이 될 수 있습니다. 같은 파일도 자막이 비활성화되거나 다른 클라이언트가 렌더링할 때는 Direct Play가 원활할 수 있습니다.

자주 묻는 질문

모든 자막 트랙이 비디오 트랜스코딩을 강제하나요?

아니요. 호환 가능한 클라이언트는 많은 텍스트 및 이미지 자막 형식을 독립적으로 렌더링할 수 있습니다. 번인은 클라이언트가 선택한 트랙을 렌더링할 수 없거나 서버가 강제로 번인을 설정했을 때 발생합니다.

하드웨어 트랜스코딩이 자막 번인을 없앨 수 있나요?

아니요. 하드웨어는 디코딩, 스케일링, 인코딩을 가속할 수 있지만 자막 파싱과 오버레이는 여전히 처리 부하를 추가하거나 하드웨어와 시스템 메모리 간 프레임 전송이 필요할 수 있습니다.

왜 SRT는 직접 재생되는데 ASS는 번인을 유발하나요?

SRT는 많은 클라이언트가 지원하는 간단한 타임드 텍스트를 포함합니다. ASS는 클라이언트가 재현할 수 없는 글꼴, 위치, 스타일, 효과를 요구할 수 있어 서버가 의도한 결과를 비디오에 렌더링합니다.

자막 변환이 이미지 품질을 떨어뜨리나요?

이미지 자막을 텍스트로 변환하면 스타일이 손실되거나 인식 오류가 발생할 수 있습니다. 복잡한 ASS를 SRT로 변환하면 고급 서식이 보통 제거되지만 원본 비디오는 변경되지 않을 수 있습니다.

최종 요약

자막 번인은 단순히 메타데이터가 아니라 비디오 픽셀을 변경하기 때문에 비용이 많이 듭니다. 미디어 서버는 소스를 디코딩하고, 타이밍 신호를 렌더링하며, 영향을 받는 모든 프레임에 합성하고, 재생에 충분히 빠른 새 스트림을 인코딩해야 합니다. 클라이언트 호환성, 더 간단한 자막 형식, 완전한 하드웨어 필터 지원, 사전 생성된 버전을 통해 가벼운 스트림이 실시간 전체 트랜스코딩으로 변하는 것을 피할 수 있습니다.