클라우드 기반 미디어 생방송 품질 최적화 및 개선 방법 – 3) 비디어 플레이어 최적화

이 블로그 시리즈의 이전 부분에서는 클라우드 기반 미디어 생방송 품질 향상을 위해 1) 지연 시간의 정의와 측정 방법, 2) 인코딩, 패키징 및 CDN 전송 단계 최적화 방안에 대해 살펴봤습니다. 이 글에서는 지연 시간을 줄이는 데 있어서 가장 중요한 영역인 비디오 플레이어의 파라미터에 대해 살펴봅니다. 워크플로 파라미터를 업스트림으로 최적화한다 하더라도 비디오 플레이어가 짧은 지연 시간 중심의 메커니즘과 통합되지 않으면 이러한 노력이 무의미해집니다. 이 섹션에서는 오픈 소스 비디오 플레이어에 대한 최적화 제안에 대해 살펴보고 상용 플레이어의 경우 AWS Elemental 기술 파트너인 castLabs 및 Accedo의 접근 방식을 통해 이 주제에 관해 알아봅니다.

비디오 재생 최적화

비디오 플레이어는 스트림 지연 시간을 낮추는 것보다 버퍼 길이에 우선 순위를 둠으로써 최종 사용자에게 중단 없는 재생을 제공하도록 최적화됩니다. 이 말은 짧은 지연 시간을 활성화하는 옵션이 전혀 없다는 것이 아니라 각 플레이어의 초기화 설정에서 이러한 옵션이 기본적으로 활성화되지 않음을 의미합니다.

플레이어에서 스트림의 지연 시간을 최대한 낮추는 데 방해가 될 수 있는 문제의 목록은 다음과 같습니다.

• 초기 버퍼 크기: 대부분의 플레이어는 스트림 재생을 트리거하기 전에 특정 수의 세그먼트, 초 또는 MB(메가바이트)를 버퍼링하도록 설계됩니다. 일반적으로 1초 및 2초 세그먼트가 적합하며 플레이어가 4개 이상의 세그먼트를 버퍼링하지 않는 경우 10초 이하의 지연 시간을 달성할 수 있습니다. 그러나 일부 플레이어는 라이브 재생 목록/매니페스트의 DVR 기간이 긴 경우 특정 시간을 버퍼링하도록 설계될 수 있습니다. 이 경우 세그먼트가 1초 길이라 하더라도 30~40초의 버퍼링이 발생할 수 있으며 짧은 지연 시간 경험을 제공할 수 없게 됩니다. 따라서 플레이어의 기본 버퍼링 정책을 확인하고 플레이어가 너무 보수적이라면 시작 시 버퍼 길이를 제한할 방법을 찾아야 합니다. 일반적으로 버퍼를 3~4초로 제한하는 것이 지연 시간과 재생 안정성 간의 균형을 맞추기에 적절합니다. 3초 이하가 되면 지연 시간이 분명히 개선되지만 재생 세션에서 정기적인 버퍼링 단계가 발생하므로 사용자 경험에 문제가 생길 수 있습니다.
• 라이브 엣지 시간 대비 라이브 타임라인의 플레이어 초기 포지셔닝: 대부분의 플레이어에서 플레이어 포지셔닝은 이전 지점과 중복되지만 항상 그런 것은 아닙니다. 시작할 때 플레이어 설정에서 버퍼 기간을 낮게 설정하더라도 플레이어에서 스트림의 라이브 엣지 시간과 비교하여 플레이헤드를 x개의 세그먼트 또는 x초로 시작하도록 하는 다른 설정을 활용하면 시작 설정이 효과가 없을 수 있습니다. 이 설정은 나중에 사용자 지정해야 하는 상호 보완적인 설정입니다.
• 라이브 엣지 시간 유지: 라이브 엣지 시간과 비교하여 예상되는 지연 시간으로 플레이어 재생이 시작된다 하더라도 재버퍼링이 발생하면 재버퍼링 전에 마지막으로 알려진 시간 코드에서 재생이 다시 시작됩니다. 즉, 플레이어의 재버퍼링에 최소 100ms가 소요되는 경우 재버퍼링 단계 후에는 라이브 엣지 시간과 비교하여 이 시간만큼 자동으로 늦어집니다. 이는 모든 플레이어에서 기본적으로 일어나는 일이지만 일부 플레이어에는 드라이 버퍼 효과(오디오 또는 비디오 트랙의 버퍼가 0초가 되고 거기서 멈추는 경우)가 발생한 후 재생 목록/매니페스트를 다시 로드하거나 이러한 상황에서 제 시간에 포워딩하고 라이브 엣지 시간에 맞게 조정하도록 하는 옵션이 있습니다. 재생 세션에서 지연 시간을 최대한 낮추면서 라이브 세션에서 최종 사용자가 콘텐츠를 빠르게 재생할 수 있도록 하는 것이 중요하다면 이 옵션을 활용하거나 이 옵션을 오픈 소스 플레이어에 추가할 수 있습니다. 모든 경우 지연 시간을 일정하게 유지하고 싶다면 플레이어에 이 기능이 있어야 합니다.
• 세그먼트 사용 불가에 대한 복원력: 지정된 미디어 세그먼트를 전혀 사용할 수 없거나 플레이어에서 예상하는 것보다 약간 늦게 사용할 수 있는 경우 플레이어는 세그먼트 로드를 몇 회에 걸쳐 재시도합니다. 재시도 후 세그먼트를 전혀 사용할 수 없다면 재생 세션이 중지될 수 있습니다. 이러한 사용 사례에서는 재시도 횟수를 늘리는 플레이어 옵션을 찾아보거나, 낮은 비트 전송률로 전환하거나, 타임라인에서 누락된 슬라이스를 건너뛰어야 할 수 있습니다.

오픈 소스 플레이어 사용하기

hls.js

MSE(Media Source Extensions) 환경을 위한 이 오픈 소스 HLS 플레이어의 config.js 초기화 파일에는 많은 수의 서로 다른 파라미터가 공개되어 있습니다. 따라서 실험을 통해 파라미터 중 일부를 줄일 수 있습니다.

• maxBufferLength(기본값: 30초)는 플레이어가 버퍼링을 시도하는 최대 시간(초)입니다.
• maxBufferSize(기본값: 60MB)는 플레이어가 버퍼링을 시도하는 최대 콘텐츠 크기(MB)입니다.
• maxStarvationDelay(기본값: 4초)는 재버퍼링에 허용되는 최대 시간(초)입니다. 이 값을 줄이면 플레이어를 낮은 비트 전송률로 강제 전환하여 긴 재버퍼링을 방지할 수 있습니다.
• liveSyncDurationCount(기본값: 3)는 시작 시 마지막으로 참조된 세그먼트 뒤의 세그먼트 수입니다. 이 값을 낮추면 플레이어가 라이브 엣지 시간과 근접하게 시작됩니다.

hls.js 0.9.1 이전 버전에서 1초 미만의 재생 목록 다시 로드 간격을 사용하려면 다음 level-controller.js 행에서 하드코딩된 1000 값을 줄여야 합니다.
reloadInterval = Math.max(1000, Math.round(reloadInterval));

dash.js

MSE 환경을 위한 이 오픈 소스 DASH 플레이어는 라이브 엣지 시간과 비교하여 초기 지연 시간을 설정할 수 있는 다수의 메서드를 제공합니다. player.setLiveDelayFragmentCount(기본값: 4)를 사용하면 라이브 엣지 시간 뒤의 세그먼트 수를 지정할 수 있습니다. player.setLiveDelay는 이 설정을 시간(초)으로 지정합니다. 라이브 지연 플레이어 샘플 중 하나에는 “최종적으로 달성되는 지연 시간은 세그먼트 기간, 세그먼트 경계와 관련하여 스트림이 요청된 시기 및 원본 버퍼에서 디코딩을 시작해야 하는 데이터 양의 함수”라고 명시되어 있습니다. 사용자 지정할 수 있는 다른 메서드 파라미터는 다음과 같습니다.

• player.setFragmentLoaderRetryInterval(기본값: 1000ms)은 실패한 조각 로드 시도 간격을 세그먼트 길이의 1/3로 설정합니다.
• player.setFragmentLoaderRetryAttempts(기본값: 3)를 늘리면 이전 사용자 지정을 보완할 수 있습니다.
• player.setBandwidthSafetyFactor(기본값: 0.9)를 0.5로 낮추면 보수적인 처리량 계산의 수가 늘어납니다.
• player.setStableBufferTime(기본값: 12초)를 크게 낮추면 시작/검색 후 버퍼 대상을 제한하고 비트 전송률을 빠르게 전환할 수 있습니다.
• player.setBufferToKeep(기본값: 20초)을 크게 낮추면 원본 버퍼 길이를 제한하고 버퍼링된 비트 전송률 변형의 사후 순환을 개선할 수 있습니다.
• player.setBufferTimeAtTopQuality(기본값: 30초)를 크게 낮추면 최고 품질을 재생할 때 내부 버퍼 대상을 제한할 수 있습니다.
• player.setLowLatencyEnabled(기본값: false)(v.2.6.8 이상) 파라미터를 ‘true’로 설정하면 기존 XHR 로딩 메커니즘 대신 브라우저 가져오기 API를 활용할 수 있습니다. 긴 DVR 기간 지연 시간에 매우 효과적입니다.

Exoplayer 활용하기

이 Android용 오픈 소스 플레이어는 HLS 및 DASH를 포함한 다수의 스트리밍 형식과 호환됩니다. HLS에서 Exoplayer는 너무 적은 세그먼트를 참조하는 재생 목록을 제대로 재생하지 못할 수 있습니다. DASH에서는 기본적으로 매니페스트로 보급되는 suggestedPresentationDelay가 준수됩니다. 짧은 지연 시간 경험을 최적화하기 위해 수정할 수 있는 일부 파라미터는 다음과 같습니다.

• HlsMediaSource 및 DashMediaSource 클래스에서 DEFAULT_MIN_LOADABLE_RETRY_COUNT(기본값: 3) 값을 늘리면 404 세그먼트의 재시도 수를 늘릴 수 있습니다.
• ChunkedTrackBlacklistUtil 클래스에서 DEFAULT_TRACK_BLACKLIST_MS(기본값: 60000) 값을 줄이면 후속 404로 인해 비트 전송률 변형이 블랙리스트에 추가될 가능성을 낮출 수 있습니다.
• 마지막으로 DefaultLoadControl 클래스에서 DEFAULT_MAX_BUFFER_MS(기본값: 3000), DEFAULT_BUFFER_FOR_PLAYBACK_MS(기본값: 2500) 및 DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS(기본값: 5000)의 기본 버퍼 값을 줄이면 검색 또는 재버퍼링 후 재생 세션이 시작될 때 로드되는 콘텐츠의 양을 세밀하게 제어할 수 있습니다.

Shaka 플레이어

MSE 환경을 위한 이 오픈 소스 HLS 및 DASH 플레이어는 보수적인 기본값과 함께 짧은 지연 시간을 달성하기 위해 수정할 수 있는 다수의 파라미터 옵션을 제공합니다.

• streaming.bufferingGoal(기본값: 10초)은 플레이어가 버퍼링을 시도하는 콘텐츠 시간(초)이며 로드되는 세그먼트의 수에 영향을 미칩니다.
• streaming.rebufferingGoal(기본값: 2초)은 플레이어가 재생을 시작하기 전에 버퍼링해야 하는 콘텐츠 시간(초)입니다. 이 파라미터는 시작 및 재버퍼링 단계에서 유효합니다. DASH 매니페스트의 minBufferTime이 이 값보다 큰 경우 값이 재정의됩니다.
• retryParameters.maxAttempts(기본값: 2)는 플레이어에 장애가 발생하기 전의 지정된 세그먼트에 대한 최대 요청 수입니다.
• retryParameters.baseDelay(기본값: 1000ms)는 재시도 사이의 기본 지연 시간입니다.
• retryParameters.timeout(기본값: 0, never와 동일함)은 요청 시간 제한을 정의하는 지연 시간(ms)입니다.
• retryParameters.backoffFactor(기본값: 2)는 재시도 사이의 지연 시간을 증폭하기 위해 baseDelay에 적용되는 승수입니다.

모든 retryParameters는 매니페스트에도 적용될 수 있습니다.

상용 플레이어

법적 고지 사항: 본 게시물의 콘텐츠 및 의견은 외부 작성자에 의해 작성된 것이며 AWS는 본 게시물의 콘텐츠 또는 정확성에 대해 책임을 지지 않습니다.

CastLabs 플레이어의 공통 구성 및 공통 ABR

플레이어 SDK의 PRESTOplay 제품군은 ‘공통 구성’ 프레임워크를 기반으로 합니다. 공통 구성은 플레이어 전체에서 동일한 JSON 객체를 사용하여 여러 디바이스 및 플랫폼에서 재생 앱을 구축할 때의 개발 시간을 단축하고 플레이어 전체의 A/B 테스트를 간소화합니다.

PRESTOplay SDK는 다음을 가능하게 하는 고유한 기능을 제공합니다.

• 모든 castLabs의 PRESTOplay SDK에서 동일한 구성 사용
• 개발 프로세스 간소화 및 최종 사용자 경험 통합
• “공통 ABR”: 추론 및 버퍼링 개선(짧은 지연 시간의 라이브 스트리밍을 위한 고유한 최적화 기능 포함)
• 표준 스트림 유형의 “안전 요구 사항”을 수동으로 재정의(예: HLS의 3개 세그먼트 지연 시간 극복)하여 동급 최강의 지연 시간 달성

공통 구성은 당사의 ‘공통 ABR’ 기능으로 보완됩니다. 공통 ABR은 castLabs PRESTOplay 제품의 고유한 기능으로, 동일한 적응형 비트 전송률 추론/알고리즘 및 버퍼링 논리를 모든 플레이어 플랫폼에서 활용합니다. 여기에는 다른 플레이어 공급업체가 표준 ABR 및 버퍼링 논리를 사용하는 기본 플레이어를 통해서만 지원할 수 있는 iOS가 포함됩니다. castLabs는 현재 스트리밍 프로토콜의 일반적인 보증/표준 이상의 보증/표준을 제공하고 업계 평균 지연 시간 미만의 긴밀하게 제어되는 매우 짧은 지연 시간을 달성하기 위해 고유한 기능을 포함하는 공통 ABR을 개발했습니다.

당사는 5초 미만의 지연 시간을 달성할 수 있으며 플레이어의 정확성을 +/-0.5초까지 맞출 수 있습니다(인코더에서 생성되는 세그먼트가 2초 이하인 경우). castLabs의 플레이어는 MPEG-DASH의 1초 세그먼트로 최대 2.5초의 지연 시간을 달성할 수 있습니다.

당사의 공통 구성에는 라이브 지연 시간이 짧은 시나리오에 대한 플레이어 초기화 설정이 포함됩니다. 예를 들어 재생 지연 시간을 낮추는 것과 관련된 아래의 옵션은 당사의 브라우저, Android 및 iOS 플레이어 기술 전체에서 동일합니다. 또한 향후에 당사가 지원하는 모든 플레이어 플랫폼에도 동일하게 적용됩니다. 아래의 공통 구성 옵션은 모든 PRESTOplay 플레이어 플랫폼에서 동일하게 작동하여 고유한 공통 ABR 짧은 지연 시간 모드를 활성화합니다.

{
…
“lowLatencyMode”: true,
“suggestedPresentationDelayMs”: 0,
“lowLatencyCatchupMode”: “speedup|seek|none”,
“lowLatencyCatchupThresholdMs”: 3000,
“lowLatencyCatchupRate”: 1.1
...
}

“lowLatencyMode”가 활성화되면 플레이어가 라이브 상태를 유지하고 최대한 근접한 재생을 시도합니다. 명시적으로 지정되지 않은 경우 짧은 지연 시간 모드에서 라이브 엣지의 거리는 0으로 설정됩니다. “suggestedPresentationDelayMs” 파라미터를 사용하여 추가로 조정할 수 있습니다.

동적 라이브 엣지 추적

“lowLatencyCatchupMode”를 사용하면 플레이어가 현재 라이브 엣지보다 뒤쳐질 때의 플레이어 동작을 구성할 수 있습니다. 버퍼 부족으로 인해 플레이어가 데이터를 기다려야 하는 경우를 예로 들 수 있습니다. 이 파라미터를 [none]으로 설정하면 플레이어가 데이터를 기다리지 않고 재생을 계속합니다. [speedup]으로 설정하면 현재 재생 위치가 현재 라이브 엣지보다 “lowLatencyCatchupThresholdMs” 밀리초 이상 뒤쳐진 경우 플레이어가 재생 속도를 높입니다. [speedup] 속도는 “lowLatencyCatchupRate” 파라미터를 통해 제어할 수 있으며 플레이어가 다시 라이브 엣지에 충분히 근접하면 1.0으로 재설정됩니다. 이 파라미터를 [seek]로 설정하면 플레이어가 구성된 임계값보다 뒤쳐질 경우 플레이어가 라이브 엣지로 건너뜁니다.

다음은 AWS Elemental 테스트 스트림 및 castLabs 플레이어를 사용하여 측정된 결과입니다. 테스트는 AWS Elemental 팀을 통해 수행되었습니다.

Accedo는 유료 비디오 사용자 경험을 활성화하는 데 주력하며 회사 자체의 독점적 플레이어를 제공하지는 않지만 비디오 및 라이브 피드 스트리밍과 관련된 모범 사례를 준수합니다. 구체적으로 Accedo는 스트림 시작 시간 및 버퍼 지연 시간에 대한 모범 사례를 준수합니다.

첫 번째 파라미터는 UX에 직접적인 영향을 미칩니다. “지연”이라는 개념이 추가되면 이 준비 단계가 더 길어지기 때문입니다. 두 번째 파라미터는 버퍼가 안정적인 피드를 제공할 만큼 충분히 크지 않은 경우 사용자 경험에 영향을 줄 수 있습니다. 당사의 개발자는 스트림 시작 시간을 최적화하기 위해 다음을 고려합니다.

• 스트림을 시작하기 전에 수행되는 동기화 호출(예: 동시성 검사)을 제한(가능하면 제거)하여 스트림이 시작된 후 비동기식 호출을 수행합니다.
• 재생이 예상되는 경우 라이선스를 미리 가져옵니다(예: 사용자가 자료 세부 정보 페이지에 있는 경우 재생 요청으로 연결될 가능성이 높음).
• 권한을 미리 가져오고 사용자가 자료를 스트리밍할 권한이 있는지 확인합니다.
• QoE 도구를 사용하여 첫 번째 프레임 재생 시간 및 시작 실패를 분석하여 리전별로 다른 네트워크 특성에 따라 설정을 조정합니다.

버퍼 지연 시간의 경우 버퍼 크기와 지연 시간 사이의 균형을 맞춰야 합니다. 세그먼트 크기에 대한 Apple HLS 지침을 고려하지 않는다면 더 작은 크기의 청크를 고려하고, 시작 시 버퍼링할 미디어 기간, 스트리밍 중에 버퍼링할 미디어 기간, 재버퍼링 이벤트 후 버퍼링할 미디어 기간 및 버퍼의 최대 크기 같은 파라미터가 지연 시간 감소에 미치는 영향을 확인하는 것이 좋습니다.

iOS 테스트
iOS 11.2.5에서 default-buffer-control=true 및 AVPlayer automaticallyWaitsToMinimizeStalling = true로 수행된 테스트.

Android 테스트
Android 7.0에서 Exoplayer 2.5.4를 사용하여 default-buffer-sizes-for playback-start=2.5s, default-buffer-sizes-after-rebuffer=5s, stream-download-buffe-minimum=15s, stream-download-buffe-maximum=30s 파라미터로 수행된 테스트

이러한 테스트는 세그먼트 크기를 줄여 지연 시간을 낮추는 방법을 보여줍니다. 그러나 스트림 안정성의 중요성을 간과해서는 안 됩니다. Accedo에서는 AWS 기반 Accedo One Cloud 플랫폼의 버퍼 관련 파라미터를 고객이 제어하고 최적의 값을 찾을 수 있도록 설정합니다. 전송 체인은 서비스 배포(인코딩, 패키징, CDN, 지역별 네트워크)에 따라 고유하며 모든 서비스는 안전한 구성으로 출시되어야 하지만 고객이 사용하는 고유한 기술 체인에 맞게 이러한 파라미터를 사용자 지정하면 지연 시간을 최대한 낮출 수 있습니다. 당사는 Optimise라는 이름의 A/B 테스트 서비스를 제공하여 고객이 서로 다른 구성을 테스트하고 UX(재버퍼링, 재생 보존 시간 등)에 미치는 영향을 평가함으로써 고유하게 최적화된 설정을 정의할 수 있도록 합니다.

마지막 글에는 AWS Elemental 제품 및 서비스를 활용하는 다수의 솔루션 아키텍처와 참조 플레이어를 사용해 측정된 전체 지연 시간의 측면에서 이와 관련된 테스트 결과를 살펴봅니다.

– Nicolas Weil, AWS Elemental의 수석 솔루션스 아키텍트

이 글은 AWS Media Blog의 Part 3: How to Compete with Broadcast Latency Using Current Adaptive Bitrate Technologies 한국어 번역입니다.