Llama - Low Latency Adaptive Media Algorithm

Llama - Low Latency Adaptive Media Algorithm

https://eprints.lancs.ac.uk/id/eprint/152377/1/Llama_Paper.pdf

요약

• 이 논문에서는 새로운 ABR 알고리즘인 Llama를 제시하고 있다. Llama는 두 개의 독립적인 처리량 측정을 사용하는 새로운 방법을 채택하고 있다.
• Llama는 다른 ABR 알고리즘보다 우수한 성능을 보여주었으며, DASH를 사용할 때 P.1203 평균 의견 점수(MOS)를 향상시키고, 재버퍼링을 33% 줄였으며, 최저 지연 시나리오에서 CMAF를 사용할 때 68%까지 줄였다.

BackGround Knoledge

ABR(Adaptive bitrate streaming) Algorithm 이란

• 사용자의 대역폭과 CPU 사용률을 실시간으로 감지하고 이에 따라 미디어 스트림의 품질을 조정함으로써 동작. 즉, 사용자의 네트워크 상태에 적응하여 최적의 스트리밍 서비스를 제공
• HTTP 기반
• 클라이언트[3]는 이용 가능한 자원에 따라 각기 다른 인코딩을 스트리밍한다.

https://ko.wikipedia.org/wiki/적응_비트레이트_스트리밍

https://www.wowza.com/developer/flowplayer-demos/abr

• HTTP 적응형 스트리밍에서 사용자의 QoE(Quality of Experience)를 최대화하기 위해 설계
• ABR 알고리즘의 주요 목표
  • 평균 비디오 품질을 최대화하면서, 재버퍼링 이벤트의 수, 재버퍼링 상태에서 보내는 시간, 그리고 비디오 품질 변경의 빈도를 최소화
  • 이러한 목표들은 서로 상충할 수 있기 때문에, 이들 간의 합리적인 균형을 찾는 것이 중요
• 세 가지 low latency ABR 알고리즘
  1. Stallion:
     • 대역폭 기반 ABR: 네트워크의 이동 산술 평균과 표준 편차, 그리고 지연 시간을 측정. 이를 통해 네트워크의 변화를 실시간으로 감지하고 비디오 품질을 조정하여 재버퍼링을 최소화하려고 시도.
  2. Learn2Adapt (L2A):
     • 온라인 볼록 최적화 기반: 지연 시간을 최소화하는 것을 목표로 한다. 이 알고리즘은 현재 네트워크 상황에 대한 계산을 통해 최적의 스트리밍 품질을 동적으로 조정한다.
  3. LoL+:
     • 휴리스틱 및 학습 기반 접근 방식: 최적의 QoE를 제공하기 위해 설계되었다. 이 연구에서 사용된 LoL+의 변형은 학습 기반 접근법을 사용하여, 사용자 경험을 극대화하는 비디오 품질 설정을 도출한다.

QoE(Quality of Experience) Factor

• Quality of Experience (QoE)는 사용자가 비디오 스트리밍과 같은 디지털 미디어 서비스를 이용할 때의 경험과 만족도를 총체적으로 나타내는 지표이다. QoE는 다양한 요소에 의해 영향을 받으며, 이러한 요소들은 사용자의 전반적인 만족도에 직접적인 영향을 미친다.
  1. Rebuffering 이벤트:
     • Rebuffering 은 비디오가 재생 중에 멈추어 다음 데이터를 기다리는 현상을 말하며, 사용자의 불만족을 초래하는 주된 원인 중 하나이다.
     • 연구에 따르면, Rebuffering 의 발생 빈도와 지속 시간이 모두 사용자의 QoE에 큰 영향을 준다. 특히, 짧은 Rebuffering 이 두 번 발생하는 것이 긴 시간 동안 한 번 발생하는 것보다 더 성가시게 느껴질 수 있다.
     • 스트림의 시작보다 끝에 가까울 때 발생하는 Rebuffering 이 더 큰 불만을 유발한다.
  2. 품질 전환(Quality Switches):
     • 비디오 품질의 잦은 변경은 QoE를 저하시킬 수 있다. 이는 특히 품질이 자주 변할 때 더욱 심각하게 나타난다.
     • 여러 단계의 품질 변화, 즉 다수의 품질 레벨을 건너뛰는 큰 변화는 사용자 경험을 더욱 악화시킬 수 있다.
     • 그러나, 점진적인 품질 변화는 일부 사용자들에게 수용될 수 있다.
  3. 비디오 시작 지연(Video Start-up Delay):
     • 사용자는 비디오의 초기 로딩 시간이 길더라도 이후의 Rebuffering을 줄일 수 있다면 이를 용인하는 경향이 있다.
• 주요 QoE 요소

Latency(대기 시간)

• Latency: 예상하지 못한 시간(time)이 데이터 전달에 소요되는 현상.
• HTTP를 통한 적응형 스트리밍에서 지연 원인
  1. 클라이언트 버퍼:
     • 이 버퍼는 재생을 위해 대기 중인 비디오 세그먼트를 보관한다.
     • 버퍼의 크기는 ABR 알고리즘이 변화하는 네트워크 상황에 적응할 수 있는 능력에 의해 결정된다.
     • ABR 알고리즘이 네트워크 상태를 측정하고 Rebuffering이 발생하기 전에 비디오 품질을 변경할 수 있도록 충분히 큰 버퍼가 필요.
  2. 비동기 미디어 세그먼트 가져오기: 클라이언트는 Segment가 제공된 후 어느 시점에 HTTP GET 요청을 할 수 있다.
  3. HTTP 다운로드 시간: Segment 크기와 사용 가능한 대역폭이 Segment를 가져오는 속도를 결정합니다.
  4. 세분화 지연: 비디오가 Segment로 나뉘어져 있어 적어도 하나의 Segment 길이만큼의 지연이 발생합니다.
• HTTP를 통한 적응형 스트리밍에서 지연의 주된 원인은 클라이언트 버퍼이다.

CMAF (Common Media Application Format)

CMAF의 기능과 특징

• CMAF는 Segment를 청크의 연속으로 생성할 수 있게 하여, 첫 번째 청크가 서버에 쓰여지는 즉시 Segment를 요청할 수 있도록 한다. 이는 DASH와 달리 Segment가 완전히 서버에 저장된 후에야 요청 가능한 것과 대비된다.
• 이 방식은 라이브 스트리밍의 최소 지연 시간을 한 Segment의 길이에서 한 청크의 길이로 줄여준다. 하지만 비디오 비트레이트는 여전히 Segment의 경계에서만 변경할 수 있다.

HTTP/1.1 청크 전송(CTE)의 역할:

• CTE는 Segment의 청크가 사용 가능해지면 추가 요청 없이 즉시 전달되도록 한다. 이는 Segment 전송 시 발생할 수 있는 지연을 최소화한다.

CMAF의 성능 개선 효과:

• 연구에 따르면, CMAF는 저지연 시나리오에서 ABR(적응형 비트 레이트) 알고리즘의 성능을 개선하여 재버퍼링을 43%에서 71%까지 줄일 수 있다. 그러나 모든 ABR 알고리즘이 CMAF와 함께 더 나은 성능을 보이는 것은 아니다.

CMAF는 라이브 스트리밍의 Latency를 줄이고 더 효율적인 비디오 전송을 가능하게 함으로써 사용자의 QoE를 향상시킬 수 있다.

Definitions

• Rebuffering: 재생 버퍼의 연속적인 흐름이 중단되는 것을 의미.
  • 간단히 말해서 스트리밍 중인 콘텐츠가 더 많은 데이터를 로드하기 위해 일시 중지될 때 발생하는 가동 중지 시간.
• bandwidth: 대역폭
  • 일정한 시간 내에 데이터 연결을 통과할 수 있는 정보량의 척도
• Throughput vs bandwidth파이프를 100% 사용할 때 초당 흐르는 물의 양이 bandwidth 값이다. 파이프 자체가 클 수록 더 많은 물이 흐를 수 있다.

• 파이프의 폭 외에 외부적 요인에 의해 80%만 실질적으로 사용한다면, 이때의 값이 Throughput이다.
• 예시
• Throughput
  • 네트워크에서 초당 실제로 처리되는 패킷의 양을 나타내는 실용적인 지표
  • 네트워크 출력(혹은 출력률, 쓰루 풋)이란 얼마나 많은 데이터가 단위 시간 내 목적지에 전달될 수 있는지에 대한 지표입니다.
  • 예를 들어 100bytes의 데이터를 전달하는데 1초가 걸렸다면 이 시스템의 네트워크 출력은 800bps이다.
• Bandwidth
  • 네트워크가 단위 시간 내 전달할 수 있는 최대 크기의 전달 용량을 의미
  • 대역폭이 높을수록 많은 데이터가 네트워크에 실려서 전달하고 전달 받을 수 있다.
  • 대역폭 자체는 전달 속도와는 관계가 없으며 오히려 용량(capacity)과 관계가 있다.
• Harmonic mean 조화평균실수 a1, ..., _an_이 주어졌을 때, 조화 평균 H는 다음과 같다.

• 조화 평균은 주어진 수들의 역수의 산술 평균의 역수를 말한다. 평균적인 변화율을 구할 때에 주로 사용된다.
• Dash Dynamic Adaptive Streaming over HTTP

---

LLAMA

두 가지(비디오 품질 저하에 대한 결정, 비디오 품질 향상에 대한 결정 ) 독립적인 처리량 측정을 구현하는 새로운 아이디어를 사용하는 Llama라는 ABR 알고리즘을 개발

main goal

• 시청자 QoE 극대화
• 평균 비디오 품질 최대화
• 재버퍼링 이벤트 수, 재버퍼링 상태에서 소요되는 시간 및 비디오 품질 변경 빈도 최소화
  위의 것들이 서로 절충(in competition) -> 적절한 trade off가 필요

Fig. 1. Sample trace with base measurements and moving harmonic mean plotted

design goal #1 - Rebuffering 방지

• Low latency live streaming에서 Rebuffering을 피하기 위해 ABR 알고리즘은 네트워크 상태가 악화되는 첫 징후에 반응하여 클라이언트 버퍼가 고갈되기 전에 세그먼트의 요청 품질을 낮춰야 한다.
• 가장 최근 비디오 세그먼트를 가져온 비트레이트를 측정.
• Llama는 이 측정값을 기반으로 더 낮은 품질의 표현으로 전환할지 여부를 결정.
• 현재 표현의 비트레이트가 마지막 세그먼트의 처리량보다 높으면 Lama는 다음 하위 품질 표현으로 전환 ⇒ 이 결정은 다른 모든 ABR 결정보다 우선시 된다

design goal #2 - 품질 안정성 향상

높은 품질 편차가 전체 QoE에 해로울 수 있으므로 품질 안정성을 높이는 것

표 I에서 볼 수 있듯이 더 높은 품질로 전환할지 여부를 결정하기 위해 위와 동일한 Throughput 측정 방법을 사용했다면 사용 가능한 대역폭의 일시적인 변경에 따라 품질이 증가하거나 감소하기 때문에 품질에 큰 변동이 발생할 수 있다.

이 문제를 방지하기 위해 지난 20개의 세그먼트 각각이 가져온 비트레이트의 조화평균으로 계산된 두 번째 처리량 측정을 구현하기로 결정

• 이 추정치는 Llama에서 더 높은 품질로 다음 세그먼트를 요청할지 여부를 결정하는 데 사용,
• 조화평균 비트 전송률이 고품질 세그먼트의 인코딩된 비트 전송률보다 높을 때 요청.
• harmonicMean > nextQualityBitrate
• 이를 통해 ABR 알고리즘은 사용 가능한 대역폭이 짧은 시간 동안만 증가할 때 일시적인 품질 향상을 방지할 수 있다.

harmonicMeanSize : 조화 평균 계산에 사용되는 Segment 수를 지정

기본적으로 harmonicMeanSize는 청크가 Segment로 집계되는 DASH 및 CMAF 모두에 대해 20개의 세그먼트로 설정됩니다.

• 사용되는 Segment가 많을수록 처리량 측정에 더 많은 평활화가 적용되고 더 높은 품질로 전환하기 위한 결정이 더 보수적으로 내려집니다.
• 사용되는 Segment가 적을수록 더 많은 품질 변동을 대가로 평균 비디오 품질이 높아진다.

Methology

5개의 ABR 알고리즘 모두에 대한 광범위한 평가를 합리적인 시간 내에 수행하기 위해 DASH 및 CMAF를 지원하는 시뮬레이션 모델을 개발했습니다.

Simulation Model

• 라이브 DASH와 CMAF 청크를 지원
• 구현은 주문형 DASH를 지원하는 기존 모델[25]을 기반으로
• 라이브 DASH, 지연 시간 구성, CMAF 청크, 더 많은 ABR 알고리즘 및 클라이언트와 서버 간의 정확한 트래픽 셰이핑을 지원하도록 모델을 확장

parameters:

Mode, ABR Algorithm, Throughput Profile, Live Delay 및 Join Offset의 5가지 매개변수가 있습니다.

Mode: DASH or CMAF mode

• DASH mode: 클라이언트는 세그먼트가 서버에 완전히 기록된 후 서버에서 세그먼트를 요청하고, 그런 다음 서버에서 전체 세그먼트로 전달.
• CMAF mode: 클라이언트는 각 세그먼트의 첫 번째 청크가 서버에 기록되는 즉시 서버에서 세그먼트를 요청합니다. 서버는 CMAF 청크를 사용할 수 있게 되는 즉시 CMAF 청크를 전달하여 응답하며, HTTP 청크 전송 인코딩을 사용하여 전송될 때 CMAF 청크의 전달을 에뮬레이트합니다.
• Live Delay :
  • Live Delay 값이 1일 경우: 클라이언트는 서버에서 가장 최근에 사용 가능한 세그먼트를 첫 번째로 요청합니다. 이는 클라이언트가 가능한 한 실시간에 가깝게 스트림을 시청하고자 할 때 사용됩니다.
  • Live Delay 값이 2일 경우: 클라이언트는 가장 최근 세그먼트가 아니라 그 다음으로 최근에 사용 가능해진 세그먼트를 처음으로 요청합니다. 이 설정은 클라이언트에게 약간의 버퍼를 제공하여, 네트워크 지연이나 데이터 패킷의 손실로 인한 재생 중단을 방지하는 데 도움이 됩니다.
  • Live Delay 값이 더 높을 경우: 클라이언트는 더 이전의 세그먼트부터 재생을 시작하게 됩니다. 이는 더 큰 버퍼를 확보하려고 할 때 사용되며, 이로 인해 재생 안정성은 높아지지만 실시간 방송과의 시간 차이도 커지게 됩니다.
  • 간단히 말해, Live Delay는 스트리밍의 실시간성과 안정성 사이의 균형을 조절하는 데 중요한 역할을 합니다. 값이 낮을수록 스트림은 더 실시간에 가까워지고, 값이 높을수록 버퍼링으로 인해 재생 중단의 위험이 감소하지만 실시간 방송과의 지연이 증가합니다.
• 클라이언트가 처음으로 요청하는 세그먼트를 지정합니다. 이 매개변수의 값이 클라이언트의 행동을 어떻게 결정하는지 설명드리겠습니다:
• Join Offset : 서버에서 세그먼트를 사용할 수 있는 시간을 기준으로 클라이언트가 세그먼트를 처음 요청하는 시간을 결정합니다. 이 매개변수는 클라이언트가 서버에서 미디어 세그먼트를 요청하기 시작하는 시간을 결정합니다. 예를 들어 조인 오프셋이 1초로 설정되고 각 세그먼트의 지속 시간이 2초라면, 클라이언트는 세그먼트가 서버에서 사용 가능해진 후 1초가 지난 후에 세그먼트 요청을 시작합니다.
• Join Delay라는 새로운 매개변수는 Live Delay와 Join Offset을 결합한 값입니다. 이 매개변수는 세그먼트가 생성된 후 클라이언트가 해당 세그먼트를 요청하기까지의 시간을 세그먼트 기간 단위로 측정하여 정의합니다. 구체적으로 Join Delay는 Live Delay와 Join Offset의 합을 세그먼트의 지속 시간(예를 들어 2초)으로 나눈 값으로 계산됩니다.
  • Join Delay:**예시 설명**
  • 예를 들어, 세그먼트의 지속 시간이 2초이고, Live Delay가 4초, Join Offset이 2초인 경우:
    • Join Delay = (Live Delay + Join Offset) / 세그먼트 지속 시간
    • Join Delay = (4초 + 2초) / 2초 = 3
    • 이 계산 결과, Join Delay는 3입니다. 이는 클라이언트가 첫 번째 세그먼트가 생성된 후 3개의 세그먼트 기간이 지난 후에 세그먼트를 요청한다는 것을 의미합니다. 이 매개변수는 실시간 스트리밍에서 클라이언트가 세그먼트를 언제 요청할지를 결정하는 데 중요한 역할을 합니다.
    • _Join Delay*_를 사용하면, 스트리밍 시스템의 실시간성과 버퍼 안정성을 동시에 관리할 수 있습니다. 클라이언트가 너무 빨리 요청하여 버퍼에 문제가 생기는 것을 방지하면서도, 너무 늦지 않게 요청하여 실시간 스트리밍의 지연을 최소화할 수 있습니다. 이렇게 조정된 지연 시간은 스트리밍 경험의 질을 향상시키는 데 도움을 줍니다.