지난 몇 년 동안 비디오 스트리밍 업계에서는 지연 시간이 짧은 비디오 스트리밍 프로토콜에 대한 관심이 매우 높았습니다. 대부분의 관심은 5초 미만의 지연 시간으로 동영상을 전송하여 라이브 방송 TV 시스템의 지연과 비슷한 수준으로 만드는 것에 집중되어 있습니다. 라이브 스포츠, 게임, 온라인 학습, 인터랙티브 비디오 애플리케이션 등을 스트리밍하는 데 있어 지연 시간을 낮추는 것은 매우 중요합니다.
저지연 스트리밍을 위한 기술 개발
HLS 및 DASH와 같은 기존 라이브 OTT 스트리밍 기술의 지연 시간은 훨씬 더 깁니다. 이는 상대적으로 긴 세그먼트(4~10초)와 재생 전에 각 미디어 세그먼트를 완전히 전송해야 하는 세그먼트 기반 전송 모델로 인해 발생합니다. HLS 또는 DASH 스트리밍 클라이언트에서 사용하는 버퍼링 전략과 결합하면 일반적으로 10~30초 또는 그 이상의 지연이 발생합니다.
지연 문제를 해결하기 위해 최근 저지연 HLS(LL-HLS) 및 저지연 DASH(LL-DASH)로 알려진 HLS 및 DASH 표준이 진화하면서 두 가지 주요 도구가 도입되었습니다:
- 청크 비디오 인코딩. 청크 인코딩은 훨씬 더 짧은 하위 세그먼트 또는 청크의 시퀀스로 구성된 비디오 세그먼트를 생성하는 인코딩 전략입니다.
- 청크 세그먼트 전송. 짧은 비디오 청크가 생성되는 즉시 스트리밍 클라이언트에 전송할 수 있는 HTTP 전송 모드입니다.
스트리밍 클라이언트는 세그먼트 경계 또는 청크 경계에서 라이브 트랜스코더가 제공하는 모든 SAP(스트림 액세스 포인트)에서 지연 시간이 짧은 라이브 스트림에 참여할 수 있습니다. 일단 참여하면 플레이어는 인코더에서 생성된 최신 비디오 청크를 디코딩 및 렌더링하기 전에 버퍼링만 하면 됩니다. 각 세그먼트가 여러 개의 청크(일반적으로 4~10개)로 분할될 수 있다는 점을 고려하면 지연이 크게 줄어듭니다.
현재 브라이트코브의 서버를 포함하여 여러 오픈 소스 및 독점 구현의 저지연 서버와 플레이어가 시중에 나와 있습니다. 이들 중 다수는 단일 비트 전송률 스트림만 사용하거나 고속 네트워크 연결을 통해 스트리밍할 때 스트리밍 지연이 줄어드는 것으로 입증되었습니다. 그러나 보다 복잡하고 실제적인 배포 환경에서의 성능은 제대로 연구되지 않았습니다.
저지연 스트리밍 성능 테스트하기
ACM 마일-하이-비디오 2023에 게재된 논문(링크 추후 공개 예정)과 Facebook@Scale의 프레젠테이션을 통해 저지연 비디오 시스템의 성능을 테스트한 몇 가지 결과를 보고한 바 있습니다.
먼저, 저희는 LL-HLS와 LL-DASH 시스템 모두에 대한 평가 테스트베드를 개발했습니다. 그런 다음 이 테스트베드를 사용해 Dash.js, HLS.js, 샤카 플레이어, 테오 플레이어 등 다양한 저지연 플레이어를 평가했습니다. 또한 저지연 라이브 플레이어에 최적화된 여러 최신 비트레이트 적응 알고리즘도 평가했습니다. 평가는 일련의 라이브 스트리밍 실험을 기반으로 이루어졌습니다. 이러한 실험은 동일한 비디오 콘텐츠, 인코딩 프로필, 네트워크 조건(실제 네트워크의 흔적을 사용하여 에뮬레이션)을 사용하여 반복되었습니다.
표 1은 멀티 비트레이트, 저지연 DASH/HLS 스트림을 생성하기 위한 라이브 비디오 인코딩 프로필을 보여줍니다.
| 렌더링 | 동영상 해상도(픽셀) | 비디오 코덱 및 프로필 | 비트 전송률(kbps) |
|---|---|---|---|
| 낮음 | 768 x 432 | H.264 메인 | 949 |
| mid | 1024 x 576 | H.264 메인 | 1854 |
| 높은 | 1600 x 900 | H.264 메인 | 3624 |
| top | 1920 x 1080 | H.264 메인 | 5166 |
표 1. 라이브 비디오 인코딩 프로파일
그림 1은 지연 시간이 짧은 DASH 및 HLS 스트리밍 테스트베드의 워크플로우를 보여줍니다.
그림 1. 지연 시간이 짧은 플레이어를 평가하는 데 사용되는 시스템 설정.
그림 2는 에뮬레이트된 LTE 모바일 네트워크의 가용 네트워크 대역폭을 보여줍니다. 지연 시간이 짧은 플레이어의 다운로드 대역폭은 네트워크 에뮬레이션 도구와 네트워크 추적을 통해 제어됩니다.
그림 2. 에뮬레이트된 LTE 모바일 네트워크의 가용 대역폭(Verizon 및 T-Mobile)
실험에서 다양한 시스템 성능 지표(평균 스트림 비트 전송률, 다운로드된 미디어 데이터의 양, 스트리밍 지연 시간)와 버퍼링 및 스트림 전환 통계가 캡처되어 보고되었습니다.
이러한 결과는 이후 LL-HLS와 LL-DASH 플레이어 및 시스템의 성능에서 관찰된 차이를 설명하는 데 사용되었습니다.
연구 결과의 몇 가지 플롯은 아래 그림에서 확인할 수 있습니다.
그림 3. LL-HLS 및 LL-DASH 플레이어가 보고하는 비트레이트 전환의 역학.
그림 4. LL-HLS와 LL-DASH 플레이어가 보고한 지연 시간 변화 비교.
성능 통계 - T-Mobile LTE 네트워크
| 플레이어/알고리즘 | 평균 비트레이트 [kbps] | 평균 높이 [픽셀] | 평균 지연 시간 [초] | 지연 시간 var. [초] | 속도 가변 [%] | 스위치 개수 | 버퍼 이벤트 | 버퍼 비율 [%] | 로드된 MB | 로드된 개체 |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.js 기본값 | 2770 | 726 | 3.06 | 0.21 | 10.4 | 93 | 38 | 7.99 | 352.2 | 256 |
| DASH.js LolP | 3496 | 853 | 5.65 | 4.59 | 22.7 | 70 | 53 | 21.96 | 369.4 | 210 |
| DASH.js L2all | 3699 | 908 | 4.14 | 3.18 | 19.9 | 5 | 19 | 7.99 | 368 | 147 |
| 샤카 플레이어(대시) | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| THEO 플레이어(대시) | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.js 기본값 2020 | 1763 | 562 | 10.08 | 10.91 | 8.1 | 26 | 2 | 9.8 | 130.7 | 589 |
| HLS.js LolP 2020 | 1756 | 560 | 5.97 | 0.2 | 6.1 | 24 | 0 | 0 | 148.1 | 688 |
| HLS.js L2all 2020 | 1752 | 560 | 6 | 0.23 | 5.9 | 34 | 0 | 0 | 133.1 | 686 |
| HLS.js 기본값 2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| 샤카 플레이어(HLS) | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
표 2. 성능 통계 - T-Mobile LTE 네트워크
저지연 스트리밍의 성능 평가하기
LL-HLS와 LL-DASH는 제약이 없는 네트워크 환경에서는 잘 작동했지만, 대역폭이 낮거나 가변성이 큰 네트워크(모바일 배포에서 흔히 볼 수 있는)에서는 어려움을 겪었습니다. 관찰된 영향으로는 매우 가변적인 지연, 버퍼링을 방지하지 못함, 잦은 대역폭 전환 또는 사용 가능한 네트워크 대역폭을 사용할 수 없음 등이 있었습니다. 일부 플레이어는 이러한 까다로운 네트워크 조건에서 지연 시간이 짧지 않은 스트리밍으로 전환하기도 했습니다.
LL-HLS나 LL-DASH가 이론적으로는 유망하지만, 아직 이러한 기술이 발전할 여지가 남아 있습니다.
브라이트코브는 지연 시간이 짧은 스트리밍 클라이언트를 위한 동급 최강의 알고리즘 구현과 인코더 및 서버 측 최적화를 위해 지속적으로 노력하고 있습니다. 이를 통해 저지연 스트리밍에 대한 지원을 확장성과 안정성이 뛰어나고 프라임 타임에 완벽하게 대비할 수 있도록 할 계획입니다.
이 블로그는 원래 유리 레즈닉이 2021년에 작성했으며 정확성과 포괄성을 위해 업데이트되었습니다.
