Audio and Video Mixing Method to Enhance WebRTC

2021 / 7 / 21 iMES 세미나

Abstract

WebRTC : 웹브라우저에 JavaScript API를 호출함으로써 P2P 라이브 스트리밍 제공
- 소수의 peer로 제한되는 프로토콜 ( 다중 peer들의 real-time 스트림을 mix하기 힘듬 / mix된 스트림을 많은 수의 audience에게 분배할 수 없음 )
- 예시 : [ 회의 참여자의 오디오/비디오 스트림을 1만 이상의 audience에게 real-time mixed stream으로 방송, 동기 컨텐츠(로고, 음악) 혼합 ] -> WebRTC가 현재는 방법을 제공하지 않음
이 논문에서 위의 case를 최소한의 latency로 줄이며 동기화 mixed real-time 오디오/비디오 스트림을 제공하는 방법을 제시
- 온라인 live 회의 구현 가능함 ( 다중 peer의 화상회의 스트림을 mix / 그것을 많은 수의 청중들에게 스트림 제공 )

Introduction

W3C, IETF : WebRTC 고안 ( 웹브라우저에서 real-time으로 오디오/비디오 커뮤니케이션 실현 )
- standard / 프로토콜 / JS API의 collection - 브라우저를 통해 P2P 오디오/비디오/data 공유 가능
- 브라우저에 내장 - 별도 플러그인 필요 없음
현대 인기 웹 app : 웹브라우저와 호환
- standard JS API를 통해 필요한 모든 resource 관리 가능 ( 마이크/카메라 등 )
WebRTC 구조 : P2P 네트워크 연결
- RTP/SRTP : 미디어 스트리밍 프로토콜
- Interactive Connection Establishment ( ICE ) : 연결 수립 프레임워크
  - session traversal utility 지원 ( NAT, STUN, TURN )
  - TURN은 P2P 연결이 불가능할 경우 STUN 대신 사용됨
UDP 프로토콜 위에서 동작 -> 빠르고 안정적인 스트리밍 미디어 소통 프레임워크
문제점 : peer가 많아질수록 효율적이지 못함
- peer가 $N$명일 경우 연결이 $N-1$번 필요 ( 각 peer들과 전송/전달 스트리밍 연결을 가져야함 )
- Ex) 720p 비디오 bitrate = 1.5Mbps, $N=100$이라고 가정
  - 한 peer가 1Gbps 이상의 downlink/uplink를 유지해야함 -> 모든 사람이 회의에 참여하는 것은 힘들 것
  - 소수의 인원으로 제한됨 ( 나머지 대규모의 인원은 말하지 않는 청중이 될 것 )
스트림 전송은 WebRTC 프로토콜을 통해 이루어져야함 ( 안정성 / 낮은 latency )
- 순수 P2P 매커니즘 : 다수의 청중에게 재방송할 수 없음 ( bandwidth 제한 )
- 이 논문에서는 “오디오/비디오 스트림을 mix하여 재방송하는 효율적인 방법에 대한 논의“를 담음
  - 두 스트림의 동기화 + 실시간성을 보장하는 방법 포함

Overview of Our Study

A. Architecture

기존 WebRTC 구조에서 input -> mixing process로의 오디오/비디오 패킷을 얻기 위해, 구조를 조정함 ( WebRTC gateway에 quasi-peer 추가 )
- quasi-peer : 다른 피어들과 비슷하게 동작하여 연결되지만, 자신의 미디어 스트림을 생성하지 않음 ( 연결하여 다른 피어의 data는 수집 )
- 모든 정보들을 mix하여 ICE 등의 방법으로 audience들에게 output 분배

B. The Process inside the Quasi-Peer

멀티채널 WebRTC 스트림 믹싱 프로세스 : 오디오/비디오 data packet을 따로 병렬로 decode / buffer한 후 mix하여 syncronization / forwarding
- global timeline 있음 ( 멀티미디어 시스템 동기화에서 중요한 요소 )
구성요소
- A. 멀티채널 WebRTC data packet을 받는 모듈
  - 멀티스레드 모듈 ( 다른 peer로부터 스트림 데이터를 받음 )
- B. 오디오/비디오 data packet 전처리 모듈
  - WebRTC 사양에 의해 두 패킷은 다른 채널들에 의해 identifier를 단 헤더로 정보도 전달됨
  - 두 data pakcet은 별도로 전처리되어야 함 ( 수신 후 전처리되어야하기 때문 )
    - 전처리 과정에서 WebRTC 프로토콜에서 정의된 오디오/비디오 data 특성에 따라 data를 처리해야함
    - 오디오는 frequency가 높고 패킷이 작음 / 비디오는 frequency가 낮고 패킷이 큼 -> 비디오는 여러 패킷으로 분할되어질 것
  - 패킷 손실 판단 / 패킷 재배열 등의 문제 있음 ( WebRTC가 UDP에서 동작하기 때문 )
- C. 오디오/비디오 디코딩 / 버퍼링 모듈
  - 디코딩 프로세스 담당
  - 자신의 인코딩 사양에 따라 오디오/비디오를 디코딩
  - 다음 모듈을 위해 buffer에 저장
- D. 오디오/비디오 믹싱 모듈
  - 멀티채널 오디오/비디오를 하나의 시청용 오디오/비디오로 mix하는 역할
  - 통합된 타임스태프 내에서 mix될 디코딩될 data의 상대적 타임스태프를 계산
    - 하드웨어 방식으로 인코딩 ( 효율성 목적 )
- E. 동기화 / forward 모듈
  - output을 내기 위한 마지막 모듈
  - 동기화를 위해 D1과 D2에서 계산한 시간을 다시 계산
  - mix된 매채 : ICE agent에 의해 유지되는 WebRTC P2P연결을 통해 수신 터미널에 relay -> 배포 준비 완료
- 위의 단계 : WebRTC에 의해 정의된 모듈이 아님 / 또한 고립된 모듈도 아님
  - quasi-peer에 포장되어진 단계들임 ( WebRTC가 그냥 peer라고 믿게 만듬 ) // 사실 다른 peer와의 대화 없이 오디오/비디오 정보를 수집
  - quasi-peer : WebRTC가 정의한 peer가 아닌 유사 peer

Implementation in Quasi-Peer

A, C단계는 이미 연구가 많이 진행되어 특별한 노력 없이 사용 가능
- B, D, E 단계에서는 문제를 해결해야함
다른 위치에서 peer들이 회의에 참여하여 stream 생성중
- 각각 2개의 스트림으로 분리 ( 오디오 / 비디오 )
- 각 peer는 회의에 참여하는 시간이 모두 다름
  - 오디오 / 비디오를 전송할 때, 전송되는 패킷에 local timestamp 정보가 계산되어짐
mixing이 시작되는 시간 또한 정해져있지 않음 ( 시작할 때 각각의 peer에게서 수신받은 frame이 모두 다를 것 )
- quasi-peer에 각 peer들에 대한 버퍼 정렬 queue가 있음
- 현재 시간까지 완벽하게 들어온 프레임들을 수신해서 가지고 있을 것
- quasi-peer가 시작된 이후에는 mixed 오디오/비디오 stream을 생성해야함 ( 정해진 오디오 / 비디오 샘플링 frequency )
오디오 / 비디오 혼합 스트림 제작 과정 ( 주체 : quasi-peer )
- 비디오 이미지 우선순위 원리 -> quasi-peer가 가장 마지막에 받은 이미지를 이용하여 mix할 것
- 동시에 output timestamp보다 작거나 같은 최신 오디오를 사용하여 혼합
- mix 이후 참여하는 스트림의 경우에도 이와 같은 방법으로 혼합
- 각각의 local timestamp는 모두 다름 -> 기준을 하나의 peer로 잡으면 안되는 독립적인 timestamp
  - global timeline의 필요성 : quasi-peer의 local timestamp로 이해할 수 있음

각 peer가 스트림을 전송하는 시간이 모두 다름

quasi-peer가 한 작업 : 각 peer들의 시간 차이를 최소화함
but 궁극적인 목적 : 멀티미디어 스트림 data와 다른 source로부터의 상관 관계를 output mixing 멀티미디어 스트림에 유지하는 것
- 이것에는 audience들의 멀티미디어 컨텐츠도 동기화될 것
본 논문에서 제시하는 모델 : 시간적 동기화 모델

수학적 증명 ( 사용 기호 )

기호	설명
$P = \left\{ p^1,…,p^N\right\} $	$N$개의 peer
$R^x = \left\{ v^x, a^x\right\} $	peer $p^x$에서 생성된 멀티미디어 데이터셋 ( 비디오 / 오디오 )
$S^x = \left\{ s_v^x, s_a^x\right\}$	peer $p^x$으로부터 전송된 스트림 ( 비디오 / 오디오 )
$s_v^x=\left\{ f_v^x(1),…,\right\}$	스트림에 대한 각 프레임 집합
$s_{a\to v}^x=\left\{f_{a\to v}^x(1),…, \right\}$	peer $p^x$의 각 프레임에 대해 대응하는 비디오 프레임 집합
$O$	quasi-peer
$s_v^O=\left\{ f_v^O(1),…,\right\}$	quasi-peer에 의해 혼합된 output 프레임
$ts(f)$	프레임 f의 timestamp

오디오 / 비디오 프레임이 timeline에 따라 시간에서 상관관계를 가지고 있음

quasi-peer의 이상적인 목적

실제 세계에서 동시에 발생하는 모든 peer들의 스트림 혼합 + 동기화
각 peer의 컴퓨팅 파워 / 네트워크 조건 / clock 정확도 차이 등에 의해 P2P 분산 모드에서는 허용 가능한 수준에서만 stream을 동기화할 수 있음 ( interstream 동기화에 외부 참조 stream이 없음 )

이상적이라면 mixed frame을 만들 때 지금까지 온전히 받은 가장 최신의 frame을 사용할텐데, 현실적으로 불가능함

그러나 차이가 $T = [-100ms, 25ms]$라면 사람이 보기에 수용 가능할 것

이에 의해 $f_v^O(k), f_a^O(m)$을 재정의함 ( output video / audio frame )

$\forall k, f_v^O(k) \in s_v^O, \exists Y \subseteq \left\{ 1…N \right\} : f_v^O(k)=\sum_{x \in Y} f_v^x (?) \tag{1}$
$\forall m, f_a^O(m) \in s_a^O, \exists Y \subseteq \left\{ 1…N \right\} : f_a^O(m)=\sum_{x \in Y} f_a^x (??) \tag{2}$

기호	설명
$k$, $m$	프레임 번호
$Y$	$\left\{ 1 … N\right\}$의 subset
$f_v^O(k)$	$Y$의 peer set으로부터 제공되는 프레임의 혼합 프레임
$f_v^x(?)$	peer $p^x$로부터 제공되는 프레임

WebRTC 사양에 따라 $s_v^x, s_a^x$는 local timeline을 기반으로 함 ( data 생성 / 전송에서의 동기화 보장 목적 )

위 2개의 공식을 조합하여, quasi-peer의 혼합 출력 스트림의 오디오/비디오 동기화 skew가 각 peer의 이미지 / 오디오 사이의 offset의 축적 / 합으로 구성됨을 정의할 수 있음

새로 정의

기호	설명
$\sum_{x \in Y} ts(f_v^x (?))$	혼합 스트림에서 $k$번째 오디오 프레임에 대응하는 비디오 프레임의 timestamp 합
$\sum_{x \in Y} ts(f_{a \to v}^x (??))$	각각의 원래 스트림에서 혼합 스트림에서 $k$번째 오디오 프레임에 대응하는 비디오 프레임의 timestamp 합
$D(f_a^O(k), f_{a \to v}^O(k))$	위 2개의 변수의 skew value

$D(f_a^O(k), f_{a \to v}^O(k))$
$= |\sum_{x \in Y}ts(f^x_v(?)) - \sum_{x \in Y} ts(f_{a \to v}^x(??)) |$
$= \sum_{x \in Y} |ts(f^x_v(?)) - ts(f_{a \to v}^x(??)) | \tag{3}$

위 식을 이용하여, 전체 동기화 프로세스 -> time offset을 최소화하는 최적화 문제로 변환 가능
$\min \left(\sum_{k}D(f_a^O(k), f_{a \to v}^O(k)) \right)$
$= \sum_{k} \min \left( \sum_{x \in Y}|ts(f^x_v(?)) - ts(f_{a \to v}^x(??))| \right) \tag{4}$

A. Multichannel WebRTC Data Packets Received in Module A

WebRTC : 오디오 / 비디오 채널이 여러개 존재 -> 처리를 위한 여러개의 thread 필요
- 각 thread : 오디오 / 비디오 채널 1개의 data 수신 역할

B. Audio ( Video ) Data Packet Preprocess Module in B1 & B2

WebRTC 사양에 의해 스트리밍 data를 패킷화할 때 표준 RTP 포맷 사용
- RTP 패킷 header에는 seq_number와 timestamp가 중요
  - seq_number : 패킷의 serial number
  - timestamp : 패킷이 물리적으로 만들어진 때의 timestamp ( 주로 상대적인 시간 )
- WebRTC는 UDP 위에서 동작한다 -> 패킷 정렬 / 손실 판단 / 손실 재배열 등을 수행해야함 ( 다음 단계에서 성공적인 decoding을 위함 )
패킷을 정렬할 때 순서를 결정하기 위해 timestamp를 비교해야하는데, 이것은 peer stream의 local timeline에서 비교되어야함
- RTP 패킷 표준에서 local timeline의 시작점의 상대시간은 0이 될 수 없음
  - RTP 패킷의 timestamp 시간을 실시간으로 변환해야함 ( 공식 5 사용 )
- 실시간을 얻기 위해서는 전처리 시작 단계에서 패킷 정렬 / 삽입 / 폐기 / 무행동 등을 판단해야함 -> 패킷 실제 생성 시간 real_ts를 알아야 함
  - start_ts : 첫 패킷 스트림 생성 실제 시간
  - timestamp : 시작으로부터 경과된 상대시간
    $\text{real_ts} = \text{start_ts} + \frac{\text{timestamp}}{\text{timebase}} \tag{5}$
- 오디오 전처리는 비교적 간단
  - WebRTC에서의 오디오 샘플링 주파수 : 48000
    - WebRTC 패킷은 OPUS 형식에 따라 960개의 인코딩된 data 샘플 운반
    - 그래서 data 패킷의 길이 = $960/48000=20\text{ms}$
  - 인간이 20ms의 data 손실을 감지할 수는 없으므로, 패킷 손실 및 재전송 등의 처리를 건너뛸 수 있음
    - timestamp를 이용한 패킷 분류 / 정렬 등을 수행
  - 각 peer는 오디오 버퍼 queue가 설정됨
    - 큐가 데이터를 추가할 때마다 패킷의 timestamp와 현재 수신된 최신 데이터 패킷 사이의 gap이 threshold를 초과하는지 여부를 판단함
      - 실험상 0.5s 이하로 설정하는 것이 좋음
    - 버퍼 큐 존재 이휴 : UDP 패킷의 out-of-order를 방지하기 위함
- 비디오 전처리 단계는 좀 많이 복잡함
  - WebRTC에 의해 지정된 단일 RTP 패킷이 연속적인 이동 프레임 data를 모두 담을 수 없으므로, 인코딩된 하나의 frame data는 여러개의 패킷으로 분할되어짐
    - 분할된 패킷은 동일한 timestamp, 연속적인 번호의 seq_number를 가지게 됨
  - 인코딩된 비디오 프레임은 여러개의 연속 RTP 패킷으로 전송됨
    - 만약 $p^1$의 마지막 전송된 RTP 패킷의 seq_number = 12이고 프레임에서 3개의 RTP 패킷이 필요한 경우, 필요한 RTP 패킷의 seq_number = 13, 14, 15일 것
  - B2 ( 비디오 데이터 패킷 전처리 모듈 ) 에서의 수도코드
    1 2 3 Procedure 1 Input : The pkt_cur Receives the WebRTC Packet to Be Preprocessed, and the QVs Is the Packet Buffer Queue in Desending Order of seq_number and timestamps
```
1| Generic WebRTC data packets preprocess()
2|  Parse the pkt_cur header and the data area to obtain video extension information;
3|  Determine whether it is an invalid data packet comprehensively, iscard invalid data packets according the information in line 2;
4|  Copy pkt_cur and insert the copied packets into the queue QV in descending order by the packet's seq_number;
5|  for (pkt_q in QV)
6|    Discard all the current packets if the difference between timestamp of pkt_q and the timestamp of pkt_q and the timestamp of pkt_cur bigger than θ;
7|    Go backwards to judge whether the seq_number of the packet with the timestamp of pkt_q is continuous, and the packet loss management is started if it is not continuous;
8|    If all the WebRTC packets of a complete video frame are received, parse the video encoding header information of the WebRTC packet payload data to obtain the height and width information of the video image and determine whether there is any change;
```
    1 2 Output : timestamp of the first complete video frame in QV, buffer queue QV, current video image height and width information
    - 1~6번 줄 : buffer queue에서 충분히 오래된 늦은 video frame data의 backlog를 탐지할 때 트리거됨
      - video buffer queue는 각 peer에 대해 설정됨 / 수신된 video frame은 frame의 timestamp의 내림차순으로 넣어짐
      - 큐에 data를 넣을 때마다, 큐의 패킷의 timestamp와 수신된 패킷 사이의 시간 차이가 threshold를 넘는지 판단
        임계값은 경험에 의해 설정하거나 이전 오디오 threshold값과 같을 수 있음
    - 7번 줄 : 불연속적인 패킷이 있는지의 여부 결정 ( 패킷 손실이 제어 가능한 정도인지 결정하기 위함 )
      - 제어 가능한 정도라면 RTCP 제어 프로토콜을 이용하여 sender에게 재전송 통보
      - 불가능하다면 frame loss management가 trigger
        손실된 프레임의 누적 data 계산
        RTCP을 이용하여 피드백 전송
        stream data 전송 종료
      - buffer overflow 방지를 위해 너무 오래된 백업 data는 폐기
  - 요약
    - PCM 형식으로 복호화하기 위해 Procedure 1에서 설명한 Audio data packet Preprocessing 수행
    - Video WebRTC packet의 경우 Procedure 1에서 표시된 전처리 후 완전한 최신 video frame으로 복호화

C. Audio ( Video ) Decoding and Buffering Module in C1 & C2

권장 오디오 인코딩 형식 : OPUS // 권장 비디오 인코딩 형식 : H.264, VP8
- 다른 표준 알고리즘 또한 사용 가능
표준 디코딩 알고리즘을 사용하기 때문에 구현이 비교적 간단할 것

D. Audio ( Video ) Mixing with a Universal Timestamp Module in D1 & D2

오디오 mixing : 어떤 constant 파라미터에 따라 메모리 크기를 계산해야함
- WebRTC 오디오 data packet은 960개의 샘플 전송 // PCM으로 디코딩한 샘플은 2개의 data channel 포함
- 하나의 채널의 data는 16-bit 정수 data로 간주할 수 있음
- => $2\times 2\times 960=3840$bytes의 메모리 저장공간이 필요
- 오디오 샘플의 left/right 채널 data : left/right interleaved mode에 저장됨
가정
- left/right interleaved mode에 저장된 두 오디오 샘플 $L_1R_1$, $L_2R_2$ : 하나의 오디오 샘플로 mix될 것
- 혼합 오디오 PCM buffer : buff_out
- β : 혼합된 소리의 popping sound를 억제하기 위한, 실제 필요에 따라 조정할 수 있는 떨림조정계수
공식 도출 가능 ( 실시간 멀티채널 오디오 mixing할 때 )
- 수신된 오디로를 PCM data로 직접 변환해야함
- $Lout$, $Rout$ 위치에 해당하는 오디오의 mixing value를 순차적으로 계산해야함
  $Lout=(L_1+L_2)*β$
  $Rout=(R_1+R_2)*β$
  $β=[0.5, 0.8] \tag{6}$
비디오 mixing : peer들의 비디오를 audience에게 뿌릴 하나의 비디오로 꿰메야함
- 모든 비디오들의 pixel 해상도는 다를 수 있음
- 대신 종횡비는 동일해야하므로, 혼합 비디오 프레임 layout은 대중적인 2가지 경우를 사용함
  - Multiple squares layout
  - Overlapped layout
video codec의 부담을 줄이기 위해 YUV data processing에서 video frame stitching이 수행됨
- YUV : 2가지 형식으로 나누어짐 색상 코딩 방법 ( packed / planer format )
  - packed : Y, U, V가 배열로써 저장됨 ( RGB와 비슷한 방식 )
  - planer : Y, U, V를 서로 다른 행렬에 저장
- 이후 단계를 쉽게 하기 위해 planer 방식 채용

비디오 mixing 과정

가정
- 출력 비디오 프레임의 예상 높이 $H$ * 폭 $W$
- 입력 비디오 프레임의 높이 $H_{in}$, 폭 $W_{in}$
- 출력 비디오 프레임의 높이 $H_{\text{in_scale}}$, 폭 $W_{\text{in_scale}}$
- 출력 비디오 프레임의 왼쪽 상단 모서리의 좌표 $(x, y)$
- 대상 비디오 프레임에서 U와 V의 시작 위치 $U_{pos}$, $V_{pos}$

알고리즘 ( 멀티채널 비디오를 mixing하는 방법 )

Procedure 2
    Input : The height and width of the output video frame are H * W,
    the height and width of the input video frame are H_in * W_in,
    the expected scale is H_in_scale * W_in_scale,
    and the upper left corner position is (x, y)

 1| Multichannel video mix()
 2|   Calculate the scale ratio and scale the input frame to the target size;
 3|   for (i in H_in_scale)
 4|     Calculate the target copy start position Y_pos of the line where the Y component of the i-th line of the input frame is scaled in the target output frame;
 5|     Copy the i-th ine of the scaled input frame Y cmponent to the target space starting with Y_pos;
 6|     for (i in H_in_scale)
 7|       Calculate the U_pos of the U component of the i-th line scaled by the input frame according to the halved height-width information in the target output frame;
 8|       Copy the i-th line of the scaled U frame of the input umage to the target space starting with U_pos;
 9|       Calculate the V_pos of the V component of the i-th line scaled by the input frame according to the halved height-width information in the target output frame;
10|       Copy the i-th line of the scaled V frame of the input umage to the target space starting with V_pos;

    Output : the frame after mixing

요약
- D1, D2 : 각각의 혼합 thread를 가지고 있음
  - 오디오 mixing thread : 최신 혼합 오디오 데이터를 인코딩, 패킷화
  - 비디오 mixing thread : 출력 캔버스에 최신 프레임을 인코딩

E. Synchronization and Forwarding Module E

end-to-end 데이터 전송을 위한 WebRTC 프로토콜 : 평균 latency가 500ms까지 낮아질 수 있도록 보장 ( 오디오와 비디오의 동기화를 보장하기 위함 )
- RTCP 제어 프로토콜 / 혼잡 제어 프로토콜 / 패킷 손실 제어 메커니즘 / 에코 제거 / 네트워크 상태 적응 / jitter buffer 등의 기술 이용
peer간에 적응적으로 제어할 수 있도록 신호처리
- WebRTC 게이트웨이 : RTCP 프로토콜을 통해 peer와 상호작용하여 WebRTC 게이트웨이에서 수신된 오디오 / 비디오 스트림이 동기화되도록 함
WebRTC 기능을 기반으로 멀티스트림 미디어를 혼합할 때, 혼합 스트림에서 각 오디오 / 비디오를 동시에 동기화 + 각 peer에서 각 스트림을 혼합하는 것이 필요
- 즉, $\left|ts(f^x_v(?)) - ts(f_{a \to v}^x(??)) \right|$를 최소화하는 문제
- 고려해야하는 중요 요소
  - 여러 채널에서 실시간으로 수신된 최신 오디오 / 비디오 데이터를 혼합하는 것
  - 혼합 미디어 데이터가 준비되면 audience의 단말기가 설정한 연결로 효율적인 실시간 data 전송을 수행하는 것
- 위 요인에 의해 WebRTC에서 2가지 전략을 채택하여 문제를 해결할 것
  - 수신된 오디오 / 비디오 각 채널은 품질을 희생하더라도 동기화할 수 있는 거 높은 우선순위를 가져야함
    - $\left|ts(f^x_v(?)) - ts(f_{a \to v}^x(??)) \right|$가 가장 높은 우선순위로 최소화해야 함 ( realtime 전송을 보장하기 위해 )
  - 각 연결의 평균 latency는 멀티스레드 작업환경에서 약 500ms이며, 각 스트림은 다른 스트림을 기다리지 않고 최소의 latency로 대상에게 stream data를 전송해야함
    - mixing frame의 동기화 보장을 전제로, 각 출력 프레임의 동기화 skew value인 $D(f_a^O(k), f_{a \to v}^O(k))$를 최소화해야 함
  - 현재로써는 latency와 quality를 모두 잡는 것은 어려움
    - 그러나 다른 상황 ( 대화 시나리오 등 ) 에서는 오디오 / 비디오 품질 등이 realtime 전송보다 우선순위가 낮음
    - 그래서 우선적으로 낮은 latency를 가지기 위해 위 전략을 받아드려야한다고 주장

동기화 / forwarding 알고리즘

Procedure 3
    Input : Real Time at width the start_v video start to be sent,
    and the currently accumulated video time sum_v

1| Video synchronize function()
2|   while (live is not stopping)
3|     if (should send video)
4|       Get the system time cur_ts in nanoseconds, set pts according to the number of frames, and then encode the video frame;
5|       Recalculate pts and dts according to the difference between current time cur_ts and start_v; then pack the corresponding data packets to forward to the ICE Agent according to the WebRTC specification;
6|     Determine whether the audio and video time lag is within the controllable range and sleep if exceeding a specific interval;

1| Audio synchronize function()
2|   while (live is not stopping)
3|     if (should send audio)
4|       Determine the system time cur_ts in nanoseconds, increment 960 to pts, then encode the audio;
5|       Recalculate pts and dts according to the difference between current tume cur_ts and start_v; then pack the corresponding data packets to forward to the ICE Agent according to the WebRTC specification;
6|     Determine whether the audio and video time lad is within the controllable rage and sleep if exceeding a specific interval;

Output : WebRTC data packets

각각의 function을 2개의 thread로 이해할 수 있음
알고리즘은 외부 instruction에 의해 재귀조건을 만족함

오디오 / 비디오는 일정한 간격으로 생성됨
- line 3, 11 : 이전에 보낸 혼합 스트림의 시간으로부터 간격이 도달했는지를 판단하는 부분 ( 오디오 : 20ms / 비디오 : 40ms )
  - 도달했다면 line 4, 12에서 system global time을 가져옴
  - pts를 frame count에 따라 증가시킴 // 이후 비디오 프레임을 encode
    - 하나의 오디오 프레임은 960 샘플을 포함하므로, 오디오에서는 pts를 960개 증가시켜야함
line 5, 12 : pts와 dts를 재생성
- cur_ts - start_v라는 그들의 timebase 값에 따라 재생성
- 이후 WebRTC 사양에 따라 해당 data packet을 ICE agent로 전달하기 위해 pack
오디오 / 비디오 프레임 간격이 다르므로 WebRTC peer는 전송할 때 다른 video fps를 설정할 수 있음
- 다중 thread mutex waiting 환경에서는 quasi-peer가 보낸 mixed stream에서 각 프레임에 대한 정확한 동일간격을 달성하기 어려움
- line 6, 13 : 실제 비디오 / 오디오 스트림 중 하나는 reference로 잡음
  - 비디오가 6프레임 들어왔다면, 이상적인 상황에서는 오디오가 12프레임 들어와야함
  - 만약 적게 들어왔다면 다음 프레임과의 간격을 적절히 감소시킴 ( 반대라면 더 키움 )
오디오 / 비디오가 모두 전송될 준비가 되기 전, 각각의 전송 data buffer의 최신 data가 먼저 인코딩된 후 전달됨
- line 6, 13 : 오디오 / 비디오 상호적응의 동기화 매커니즘 도입
  - 이론적으로, 오디오 / 비디오는 주파수가 고정되있다면 동기화될 수 없음
    - 오디오 주파수가 비디오에 비해 매우 높음 + 컴퓨터 부동소수점 번호가 thread 자원의 상호배제 중에서 처리됨 -> 오디오 / 비디오 사이에는 상당한 시차가 있음
  - global timeline에서 dts, pts를 올바르게 재설정하여 오디오 / 비디오의 동기화를 조정하는 매커니즘 도입
    - dts : Decoding TimeStamp ( 디코더가 디코딩될 시기 )
    - pts : Presentation TimeStamp ( playback 중에 프레임이 표시될 시기 )
요약
- ICE agent에 준비하기 위해 Procedure 3의 media data 최종 확정
- WebRTC network / 일반 CDN 등에서 청중에게 궁극적으로 배포를 위한 제공

Experiments

quasi-peer와 시스템 전체를 다른 네트워크 조건 / 해상도 / bit rate 등의 조건을 달리하며 테스트 진행
합리적인 mainstream running 환경에서 수용 가능한 latency / 동기화 quality를 가져야하므로, 총 3가지의 테스트 실행
- latency 테스트
- 동기화 테스트
- 성능 테스트
테스트 구성
- WebRTC 게이트웨이 : iMac, Intel Core i5 3.2 GHz, 16 GB memory
- STUN/TURN : Intel(R) Core(TM) i7-6700 CPU @ 3.40 GHz, 8GB memory
- 웹캠 등의 다른 device들은 실제 영향을 크게 미치지 않으므로 설명 제외

A. Latency

quasi-peer와 시스템 전체인 경우 2가지의 구성 테스트
- 실험결과를 FFmpeg를 기반으로 한 유사 모델과 비교
- 실험결과를 WebRTC, CDN의 표준 latency와 비교

The Quasi-peer Module

WebRTC 게이트웨이의 quasi-peer의 latency data와 제어 그룹에 적합한 quasi-peer의 대응 요소를 결정할 수 없음 -> 동일한 사양으로 진행되는 FFmpeg 기반 소프트웨어의 latency data를 그룹으로 사용
FFmpeg 자체가 mixed stream 방법을 제공하지 않음
- 다른 교수가 만들어낸 FFmpeg를 기반으로 실험

실험집단 : 4개의 peer에 대해 모든 과정 수행 // 통제집단 : 거의 동일한 스트림 파일을 입력으로 사용

4개의 오디오 / 비디오 채널 집합 생성
3단계의 해상도 사용 ( 480p, 720p, 1080p )
5개의 bit rates ( 128k, 512k, 1M, 2M, 3M bps )
최소 1만 프레임의 경과 시간을 테스트 후 산술평균 도출

결과

	->	480p	->	720p	->	1080p
	quasi	FFmpeg	quasi	FFmpeg	quasi	FFmpeg
128k	1.295	7.822	3.338	20.644	5.516	44.627
512k	1.412	9.245	3.345	22.848	5.647	46.951
1M	1.485	10.373	3.452	24.794	5.923	49.684
2M	1.516	12.546	3.486	29.071	6.104	54.461
3M	1.532	14.394	3.523	29.623	6.153	59.183

제안한 방법이 훨씬 낮은 latency를 가지고 있는 것으로 확인
비디오 해상도의 증가 -> latency의 증가라는 상관관계 확보
Q. bit rate가 바뀌면 디코딩 / 인코딩 과정 latency에 영향을 미칠까?
- A. 자신들의 방법은 차이가 거의 없으며, FFmpeg는 비디오 해상도가 높아질수록 더 빠르게 증가
- FFmpeg : 범용 멀티미디어 process를 위한 프레임워크 -> filter processing이 pipeline 방식으로 수행되므로 간단한 프레임 스케일링 작업도 여러 프로세스에 의해 완료되어야함
- 또한 각 step은 완벽한 frame processing flow를 가져야함
자신들의 방법 또한 해상도에서 어느 정도의 latency 증가를 겪음

요약
- quasi-peer의 latency 시험 결과 : WebRTC 프로토콜에서 요구하는 낮은 latency와 효율적 / 호환적임

B. The System as a Whole

전체 latency를 평가하는데 사용되는 중요 요인 : RTT
- 송신기 : local timestamp $T1$를 갖는 ping packet을 수신기로 보냄
- 수신기 : 송신자에게 $T1$을 사용하여 운반하는 pong packet 구축하여 전송
- 송신기 : pong packet의 local timestamp $T2$를 얻음
- 이 두개의 차이 $T2 - T1$을 RTT로 지정
WebRTC : 발신자가 오디오 / 비디오 수집 과정에 직접 개입할 수 없음
- 추가 ping data를 전달하기 위해 packet을 직접 수정할 수 없음
- So, RTT를 직접 관찰할 수 없음
대신 발신자 / 수신자 간의 시차를 얻을 수 있음
- 모바일 : 카메라를 표준 시간 웹 페이지에 조준
- PC : 동일한 표준 시간 웹 페이지 개방 + 동시에 mixed stream 재생
  - 이 때 컴퓨터 화면에 두개를 time로 만든 후 스크린샷을 통해 timestamp를 2개 얻을 수 있음
  - 이렇게 얻어진 2개의 timestamp의 차이를 계산 후 산술평균하여 이 시간차를 바탕으로 일정수준 평가할 수 있음
- quasi-peer : 약 500ms의 latency가 있는 WebRTC에서 실행중 // 일부 프로세스 소유
  - 시간차는 500ms가 약간 넘지만, 그 이상은 아니어야한다
- 일반적으로 CDN latency는 약 5s -> quasi-peer에 의한 혼합 스트림이 궁극적으로 일반 CDN에 전달될 때 latency 요구사항을 보장하기 위해 5s보다 작아야함
실제 시나리오 시뮬레이션하기 위해 아래와 같은 상황에서 비교 테스트
- 다른 네트워크
  - 유선 ( 1000M ) / 무선 WIFI ( 300M )
- 다른 해상도
  - 480p / 720p / 1080p
- live screenshot를 통해 발신기 / 수신기에서 timestamp를 얻을 수 있고, 그것의 차이로 시차를 얻을 수 있음
위의 방법을 이용하여 실제 latency는 아니지만, latency라고 부를 수 있는 시차를 계산할 수 있음
- 서로 다른 네트워크 / 해상도에서 15번 시도하여 관찰
- 결과 : 일반적인 latency = 약 600ms
  - 케이블 네트워크가 가장 빠르고 변동이 적었음
요약
- 제안한 방법은 서로 다른 네트워크에 적응 + 상대적으로 낮은 latency 달성 가능
- 많은 시청자에게 여러 peer의 시나리오에 적응할 수 있음을 보임

C. Synchronization

공식 (3)을 ITU-R BT.1359 표준과 결합하면 새로운 공식으로 단순화할 수 있음

오디오 / 비디오 동기화를 정량적으로 평가하는데 사용 가능

$T = (pt_v - gt_v) - (pt_a - gt_a) \tag{7}$

기호	설명
$T$	특정 표준시간에 대한 시간 차이
$gt_a$	오디오가 생성된 특정 표준시간
$gt_v$	비디오가 생성된 특정 표준시간 ( 위와 이상적으로는 같아야 함 )
$pt_v$	사용자가 live로 그림을 보는 실제 시간
$pt_a$	사용자가 live로 오디오를 듣는 실제 시간

$T$가 클수록 방송의 동기화가 불가능해짐

ITU-R BT.1359 표준에 따르면, $T$의 값에 따라 sync가 다름을 알아차림
- $T = [-100ms, 25ms]$인 경우 차이를 느끼지 못함
- $T < -125$ms or $T > 45$ms인 경우 차이를 느끼지만 적응할 수 있음
- $T < -185$ms or $T > 90$ms인 경우 동기화 문제를 분명하게 알아챔

인간 오류나 편향을 없애기 위해 간단하고 객관적인 방법을 사용하려 함
- Snagit를 이용하여 혼합 오디오 / 비디오에 tapping event를 넣음
- 소리 / 화면 등을 이용하여 오디오 / 비디오의 차이 $T$를 계산
- 만약 $T$가 $[-100ms, 25ms]$보다 작다면 동시에 일어나는 것처럼 보이며, 동기화되었다고 판단할 수 있음
- 총 20번의 랜덤 tapping event를 넣어본 결과 $T = [-10ms, 10ms]$라는 결과를 얻음
  - 오디오 / 비디오가 성공적으로 동기화되었음을 보임

D. Performance

수신기의 품질 테스트 필요
- audience들이 비디오 품질에 만족하는가?
quasi-peer의 CPU, 메모리 소비량 등 테스트 필요
- 실행 비용이 합리적인가?
테스트 방법 : Gateway에 내장된 quasi-peer 내에 network conversation 설정
- 이후 수신기 -> Chrome 브라우저까지 WebRTC traffic 상태 / 자원소비 등을 모니터링

1. The Receiver

현재 stream의 안정성을 보여주는 그림이 있음 ( Chrome이 혼합 매체를 재생하는 상태 )
video frame rate 안정성 : 곡선의 변동에 의해 직접 결정됨
- 비디오 형식으로 정의된 프레임 속도 근처에서 안정적이라면, 비디오 또한 안정적이라고 인식 가능
- 만약 곡선이 안정적이지 못하다면 비디오 또한 불안정해 보일 것
결과 : 톱니 모양의 직선과 유사한 모양을 나타냄 ( 혼합 비디오가 수신기에 매우 유창하게 들어가고 있음 -> 혼합 비디오가 안정적으로 출력되고 있음 )

2. The Quasi-peer

1080p traffic의 채널 4개를 포함하는 quasi-peer를 시뮬레이션
- 이후 15개의 다른 시점에서 무작위로 CPU / 메모리 사용량을 체크
결과 : 사용량이 합리적이라고 보임
- 메모리 사용량
  구분 사용량
  최대 118MB
  중앙값 108MB
  75% ~ 25% 107 ~ 110.6MB
- CPU 사용량
  구분 사용량
  최대 42%
  중앙값 41.2%
  75% ~ 25% 40.9 ~ 41.5%
- 여러 peer -> 다수의 audience로 제공하는 시나리오에서, quasi-peer를 이용한 시스템이 순조롭게 운영되고 있음을 보임
- 하드웨어 자원 소비도 합리적일 것 ( WebRTC 게이트웨이 test 머신과 동일한 사양을 가진 서버의 비용 또한 중저가가 될 것이기 때문 )

구분	사용량
최대	118MB
중앙값	108MB
75% ~ 25%	107 ~ 110.6MB

구분	사용량
최대	42%
중앙값	41.2%
75% ~ 25%	40.9 ~ 41.5%

Conclusion

멀티채널 WebRTC live 스트림을 효율적으로 혼합하는 방법 제안
여러 peer들이 생성한 WebRTC 프로토콜 스트리밍 media data를 실시간으로 조합
- 성능을 유지하며 오디오 / 비디오 동기화를 보장, 합리적인 실행비용 보장
latency, 동기화, 성능에 대한 실험으로 어느 정도 수준에서 문제를 해결할 수 있음을 보임
quasi-peer가 오디오 / 비디오를 동기화할 수 있음 -> WebRTC 이외의 일단 CDN과 같은 일반 릴레이 서버에서도 다른 media 형식의 output를 쉽게 생성 가능
개발자가 gateway 서버의 몇가지 간단한 설정을 제외하면 실제 WebRTC에서 하는 작업보다 많은 일을 할 이유는 없음
- quasi-peer가 audience들에게 peer들로 적용할 수 있는 길을 열어준다고 생각함
아직 더 많은 개선이 필요함
- 인코딩 / 디코딩 효율 향상을 위해 CUDA와 같은 병령 컴퓨팅 framework를 도입할 수 있음
- 네트워크 한계 / 컴퓨팅 용량 등을 증가시키기 위해 WebRTC gateway에 SDN을 도입 가능
  - 여러 WebRTC gateway와 협력하여 스트림 forwarding / mixing 개선
  - 전체 시스템을 확장할 수 있도록 함
- peer와 audience 포함하여 모든 참여자에게 전체 시스템간의 스트림 distribute를 빠르게 하기 위해, 머신러닝 기법을 도입할 수 있음
  - 각각의 네트워크 조건 / habit에 대한 역사적 정보를 바탕으로, 스트림을 전달하기 위한 가장 가까운 경로를 찾아야 함
- 동기화 / latency 문제를 계속해서 해결해나갈 것
  - 현재의 기술적 장애 및 많은 비용 문제를 해결해갈 것