클라우드 기반 미디어 생방송 품질 최적화 및 개선 방법 – 2) 인코딩, 패키징 및 전송 최적화

이 블로그 시리즈의 1부에서는 OTT 스트리밍에서 지연 시간이 문제가 되는 이유와 전체 지연 시간에서 서로 다른 워크플로 단계가 차지하는 비율을 측정하는 방법에 대해 살펴봤습니다. 이 글에서는 인코딩, 패키징 및 CDN 전송 단계를 시작으로 가능한 최적화에 대한 과정을 시작해 보겠습니다. 언급된 파라미터를 조작하면 뷰어를 위해 최적화된 짧은 지연 시간의 라이브 스트림을 준비할 수 있습니다.

인코딩 최적화

앞서 AWS Elemental Live에서 [Low Latency Mode] 입력 파라미터를 사용하여 캡처 지연 시간을 최적화하는 방법을 간략히 설명했습니다. 이 파라미터를 사용하면 입력 타임스탬프가 연속적이지 않을 경우 삭제되는 오디오 패킷이 증가할 수 있습니다. [Input Buffer Size] 파라미터를 사용하여 입력 단계에서 버퍼링되는 프레임 수를 최소한으로 줄일 수 있지만 이 경우 일부 프레임이 삭제될 위험이 있습니다.

[Video Encoding] 섹션의 일부 파라미터는 지연 시간에 영향을 줄 수 있습니다.

Lookahead: 이 값을 낮게 설정하면 지연 시간이 개선되지만 까다로운 장면의 출력 품질이 떨어집니다. 그러나 장면 변화가 없거나 적은 경우에는 낮게 설정해도 문제가 없습니다.
GOP 파라미터: 1초 기간의 폐쇄형 GOP를 사용하는 것이 좋습니다. 필요한 경우 나중에 2초 세그먼트로 재패키징할 수 있습니다. B 프레임이 없는 소형 GOP를 사용하면 일반적으로 비디오 품질이 저하됩니다.
B Frames: GOP에 사용되는 B 프레임이 많을수록 인코딩 지연 시간이 증가할 가능성이 높아집니다. B 프레임을 추가할 때마다 몇 프레임씩 증가합니다. 인코딩 엔진이 B 프레임을 구성하려면 다음 P 프레임을 미리봐야 하기 때문입니다. 이 지연 시간 영향을 피하기 위해 B 프레임을 사용하지 않을 수도 있지만 B 프레임을 사용할 때와 동일한 품질 수준을 유지하려면 인코딩 비트 전송률을 높여야 합니다.
Temporal Adaptive Quantization: 이 옵션을 끄면 지연 시간이 몇 프레임까지 줄어듭니다. 다른 [Adaptation Quantization] 옵션은 지연 시간에 영향을 미치지 않습니다.
Encoder Buffer Size: 기본값은 비디오 비트 전송률(비트)의 2배이며 인코더에서 2초의 지연을 야기합니다. 1x 비트 전송률로 설정하면 1초 지연이 발생하며 비디오 품질에 약간 영향을 미칩니다. 지연 시간을 매우 공격적으로 낮추려는 경우 버퍼 크기를 비트 전송률의 절반으로 설정할 수 있으며 이 경우 GOP 지연은 절반(1/2초)으로 줄어듭니다. 물론 비디오 품질도 더 많은 영향을 받습니다. 1/2x 비트 전송률에서는 비디오 품질에 미치는 영향이 훨씬 심각합니다.
Video Preprocessors: Deinterlacer 프로세서가 필요한 경우 짧은 지연 시간의 보간 알고리즘을 선택해야 합니다.

AWS Elemental MediaLive에서는 화면에 표시되지 않은 마지막 파라미터를 제외하고 [Stream Settings] > [Frame Rate] 섹션의 [Progressive] 스캔 유형 다음에서 동일한 설정을 사용할 수 있습니다. 인코딩 단계의 측면에서는 단계의 끝 부분에 경량 스트림을 추가하여 네트워크 조건이 열악한 모바일 디바이스에서 세그먼트 길이가 평소보다 짧은 경우에도 스트림에 액세스할 수 있도록 하는 것이 좋습니다.

패키징 최적화

거의 모든 플레이어에서는 세그먼트 기간이 지연 시간에 기계적 영향을 미칩니다. 1초 기간의 세그먼트를 사용하는 경우 5초의 지연 시간에 도달할 수 있습니다. 2초 기간의 세그먼트를 사용하는 경우 거의 불가능하지만 플레이어 설정에 중대한 최적화를 적용하지 않는 한 7~10초의 지연 시간이 발생합니다. 1초 세그먼트에서는 약간의 플레이어 버퍼가 자동으로 생성되므로 드라이 버퍼를 빠르게 극복할 수 있는 특정 메커니즘이 플레이어에 없다면 재생 세션이 견고하더라도 큰 도움이 되지 않습니다.

따라서 요구 사항에 적합한 세그먼트 크기를 선택하는 것이 중요합니다. 7초 미만의 지연 시간에 도달할 필요가 없다면 1초 세그먼트를 사용하지 말고 7~10초의 지연 시간을 생성하는 2초 세그먼트를 대신 사용하십시오. 플레이어를 위해 2초 세그먼트를 사용하는 경우 다음과 같은 이점도 있습니다.

GOP 길이를 1초에서 2초로 늘려 일관적인 비트 전송률에서 인코딩 품질을 높일 수 있습니다.
오리진에서 수집할 때(HLS를 수집 형식으로 사용하는 경우) 2초 세그먼트를 사용하면 오리진 스토리지 및 패키징 계산 시 스트레스가 줄어듭니다.

인덱스 기간(DVR 기간의 길이) 또한 지연 시간에 영향을 줍니다. 일부 플레이어는 마지막 3개 세그먼트만 참조하는 재생 목록/매니페스트가 있을 때보다 재생 목록/매니페스트의 DVR 기간이 1시간일 때 더 많은 버퍼링을 수행합니다.

AWS Elemental Live에서는 평소보다 빠르게 네트워크 전송 오류를 수정해야 하므로 HLS/DASH 재시도 간격 게시 값을 낮춰야 합니다. 이 값을 2초 세그먼트에 대해 1초로 설정하고 1초 세그먼트의 경우 0초로 설정하십시오.

컨텐츠 전송 최적화

컨텐츠 전송(CDN) 구성에서 지연 시간을 줄이기 위해 변경할 수 있는 항목은 많지 않습니다. Amazon CloudFront는 체인에 인공 버퍼를 추가하지 않습니다. 다른 CDN을 AWS Elemental 오리진 서비스와 함께 사용하는 경우 CDN 아키텍처에 의해 의도적으로 생성된 CDN 기본 버퍼를 볼 수 있습니다. 이 경우 CDN 전문 서비스에 문의하여 가능하다면 전송 구성에서 이 기본 버퍼를 비활성화하십시오.

HLS 재생 목록 및 DASH 매니페스트의 경우 플레이어에서 gzipped 형식의 압축을 지원한다면 CDN 구성이 이러한 형식의 압축 서비스를 허용하는지 확인해야 합니다. 이 형식을 사용하면 HLS 또는 DASH/SegmentTimeline에 사용되는 DVR 기간이 긴 경우 로드 작업이 쉬워집니다.

짧은 지연 시간 모드의 플레이어는 라이브 엣지 시간과 비교하여 일반적으로 더 많은 수의 요청을 전송하므로 향후에 세그먼트를 요청하여 엣지에서 404가 발생할 수 있습니다. 각 CDN에는 이러한 404의 캐시에 대한 고유한 기본 TTL 값이 있으며 일반적으로 이 값은 짧은 지연 시간의 스트림에 적합하지 않으므로 이 값을 조정해야 합니다. Amazon CloudFront 배포의 경우 [Configuration] 패널의 [Error Pages] 섹션에서 이 값을 1초로 설정할 수 있습니다.

‘Origin’ 수신 헤더는 오리진에서 반환되는 모든 다운스트림 CORS 정책의 주요 트리거이므로 이 헤더를 화이트리스트에 추가하여 CDN이 헤더를 오리진으로 전달할 수 있도록 해야 합니다. 이는 짧은 지연 시간과는 무관하지만 워크플로에 여전히 중요한 사항입니다. Amazon CloudFront의 경우 [Configuration] 패널의 [Behaviors] 섹션에서 이 값을 설정할 수 있습니다.

마지막으로 HLS 재생 목록 또는 DASH 매니페스트 TTL이 CDN 측에 설정된 경우 HLS 분할 간격 또는 DASH 매니페스트 업데이트 간격 이하인지 확인해야 합니다.

3부에서는 비디오 플레이어에 적용할 수 있는 최적화 옵션에 대해 살펴봅니다.

Nicolas Weil는 AWS Elemental의 수석 솔루션스 아키텍트입니다.