Adapting the Playout Point (음성 플레이 포인트지점을 조율하기)

RTP책을 참조하여 정리를 했다.약간의 오역이 있을수 있다.

Playout Adaptation for Audio with Silence Suppression
Silence Suppression을 가지고 오디오를 이한 적절한 플레이아웃 시점을 조율해보자.
오디오는 계속적으로 미디어 포맷을 가지고 있다.
이말은 즉, 각각의 오디오 프레임은 일정한 시간에 데이타가 체워지게 된다. 그리고
체워진후 즉시 다음스케줄을 통해서 데이타가 체워지는 것이다.
이러한 Routine은 Silence Suppression을 사용하지 않은 이상 프레임사이의 갭(약간의 Silence)이 발생하지 않는다.
그리고 게다가 Playout 시간을 조절을 적절히 쉽게 할수 없다.
이러한 이유로 Silence Suppression의 존재는 Playout buffer 알고리즘의 디자인에 중요한 영향을 준다.

대화식 음성신호인경우 100ms마다 신호가 발생한다. silent 기간에 의해서 분리되어 진다.
아래의 그림을 참조하면,
speech 시그널안에는 talk spurts가 존재하는것을 알수있다.
그리고 그들사이에는 약간의 갭이 존재한다.
보낸쪽에서 침묵 기간을 나타내는 프레임을 감지하고 억압하고 해야 한다.
만약 그렇지 않으면 그 프레임은 RTP패킷을 생성하게 된다.
그 결과 연속적인 시퀀스 번호와 패킷의 순서이다.
그러나 패킷은 침묵기간의 길이에 따라 RTP Timestamp에 끼어들게 된다.



talk spurts사이의 침묵기간의 작은변화는 눈에 뛰지 않는다.
Playout 알고리즘 디자인의 중요한 키포인트는,
만약 가능하다면 단지 침묵기간을 적절히 조율하는 것이다.
그러나 그것은 일반적으로 받는쪽에서 talk spurt의 시작점을 감지하는 것은 약간의 문제가 있다.
왜냐하면, 보내는쪽은 침묵기간이후 첫번째 패킷안에 marker bit(rtp header의 bit)를 세팅하는게 필요하다. talk spurt의 시작을 가르키는 표시를 제공한다.
가끔씩은 그러나 talk spurt안에 있는 첫번째 패킷을 읽어버릴때,
그것은 대게 감지가 가능하다. 새로운 talk spurt는 시작되었다. 왜냐하면 sequence number/ timestampe의 관계는 아래의 그림과 같이 talk spurt의 시작점을 함축적으로 제공해주고 있다.

Implicit Indication of the Start of a Talk Spurt


한번은 talk spurt의 시작점이 위치해 있다.
우리는 침묵기간의 약간의 변화에 의해 적절히 조절할수 있다.
그 playout delay는 talk spurt안에 패킷들 모드를 위해서 잠시 hold한다.
적절한 playout delay는 각각의 talk spurt동안에 계산되어 진다.

아래의 가설은 talk spurt사이의 두드러지는 변화가 없다는 가정하에이다.


int
should_adjust_playout(rtp_packet curr, rtp_packet prev, int contdrop) {
if (curr->marker) {
return TRUE; // Explicit indication of new talk spurt
}
delta_seq = curr->seq – prev->seq;
delta_ts = curr->ts - prev->ts;
if (delta_seq * inter_packet_gap != delta_ts) {
return TRUE; // Implicit indication of new talk spurt
}
if (curr->pt == COMFORT_NOISE_PT) || is_comfort_noise(curr)) {
return TRUE; // Between talk spurts
}
if (contdrop > CONSECUTIVE_DROP_THRESHOLD) {
contdrop = 0;
return TRUE; // Something has gone badly wrong, so adjust
}
return FALSE;
}



contdrop : playout time의 부적절한 시간때문에 삭제된 패킷숫자
예를들어 route의 변화에 따른 너무 늦게 도착한 패킷

consecutive_drop_threshold에 적절한 값 : 3
만약 should_adjust_playout함수에서 리턴값이 true라면,
그 음성듣는쪽은 침묵구간이거나 잘못된 playout point지점인 것이다.

그 계산된 playout point지점이 현재사용된 값에서 나온것이라면, 그것은 미래의 패킷을 위하여 적절한(스케줄 playout time에 의한) playout point을 조절해야 한다.


총평:
좀더 유연하게 플레이를 하기위해서는 적절한 침묵구간을 넣는것이 좋을듯싶다.
네트웍 딜레이에의해 입력패킷이 적절히 오지 못하면 플레이하는데 패킷의 부족으로 인해
잦은 버퍼링이 생기게 된다. 이런한점을 해결하기 위해서는 침묵구간을 적절히 활용하면
패킷의 부족을 막을수가 있다. 이것이 유연한 playout 알고리즘 방식같다.
또한 이런한 침묵구간을 적용하게 되면 너무 많은 패킷이 싸일수가 있으므로
패킷에 timestamp의 총양을 구해서 delay시간을 설정하여 버퍼의 총시간이 delay설정시간을
초과한경우는 과감히 침묵구간을 플레이하지않구 삭제해주는 것이 필요하다.

댓글

가장 많이 본 글