불안정한 네트워크에서 고품질 고해상도 영상 전송 #2

가용 대역폭의 변화

다시 데이터 전송과 네트워크 불확실성으로 돌아와서 간단한 실험을 진행하고자합니다. 앞서 정의한 불확실성의 척도를 결정하는 요소는 대역폭, 딜레이, 패킷 유실률로 구성되어 있습니다. 이 글에서는 실험의 복잡도를 낮추기 위해서 패킷 유실률에 대해서 가용 대역폭의 변화를 살펴보고자 합니다.

리눅스에서 구동하는 iproute2를 활용한다면 원하는 네트워크 상태를 에뮬레이션 할 수 있습니다.

 $ sudo tc qdisc add dev eno1 root netem loss 10% 

실험이 끝난 후에 에뮬레이션한 값을 삭제하기 위해서는 del 파라미터를 사용해야 합니다.

 $ sudo tc qdisc del dev eno1 root netem loss 10% 

로컬 네트워크에서 패킷 유실률을 0%에서 10%까지 증가시켰을때 HTTP를 이용한 다운로드시에 사용한 대역폭의 변화는 다음 그래프와 같이 나타납니다.

패킷 유실률에 따른 대역폭 변화

실제 사용하는 네트워크 환경에서 10%까지의 패킷 유실률이 발생할 수 있을지는 의문이지만, 주목할만한 것은 패킷 유실률이 3%임에도 거의 1/2 수준으로 가용 대역폭이 줄어드는 것을 알수 있습니다.

이러한 급격한 변화는 TCP 네트워크의 혼잡제어(Congestion Control) 방식과 관련이 있습니다. TCP 내부에서는 전송한 패킷에 대하여 ACK가 확인되지 않거나 NACK가 발생하는 경우 해당 패킷을 재전송하게 되며, 일정 시간동안 재전송 패킷을 수신할 수 있도록 ‘윈도우’라고 불리는 내부 버퍼의 크기를 증가시키고 대기하게 됩니다. 이렇게 온전한 데이터를 수신할 때까지 추가된 재전송 및 대기 시간 때문에 결과적으로 단위 시간당 전송할 수 있는 패킷의 수가 줄어들게 되며, 이는 대역폭의 감소 현상으로 보이게 되는 것입니다.

실시간 고해상도 영상 전송

영상 파일을 전송하고, 온전한 영상 파일을 획득한 이후 시청한다고 하면 일반적인 파일 전송과 다를바 없습니다. 그러나 영상을 전송하면서 동시에 시청하고자 한다면 사용자가 인지하는 영상 재생 품질의 확보 때문에 영상 전송에서 네트워크 불확실성의 극복은 앞으로도 계속해서 이슈가 될 것으로 생각됩니다.

지연시간, 패킷 유실률, 가용대역폭을 개선하여 네트워크의 불확실성을 줄인다고 하더라도 또 다시 문제가 되는 부분은 고해상도와 고품질이라고 정의한 영상이 얼마나 더 많은 대역폭을 앞으로 요구할 것인가를 알수 없다는 것입니다.

앞선 실험에서 확인한바와 같이 네트워크 혼잡도가 증가하는 경우에는 최종적으로 가용 대역폭의 축소로 나타나며, 수신부에서는 영상 재생에 필요한 데이터를 충분히 확보하지 못하고 버퍼가 비어있는 Underrun 현상이 발생하게 됩니다. Underrun 상태에서 어떠한 이유로 인하여 혼잡도가 해소 된다면 줄어든 대역폭 때문에 수신부까지 도달하지 못했던 패킷들이 다시 도착을 해서 순서대로 버퍼를 채우다보면 가용한 버퍼의 크기를 초과하는 Overrun 현상을 초래하게 됩니다. Overrun 상태에서 버퍼의 크기를 초과한 데이터 패킷은 버려지게 되고, 버려진 패킷만큼 또다시 버퍼가 비워지는 상황이 됩니다. 만약 버려진 패킷에 대해서 재전송 요청을 하였다면, 요청된 패킷을 전송하기 위해서 더 많은 대역폭을 사용하게 됩니다. 즉, Overrun과 Underrun의 발생은 무엇이 먼저 발생을 하였던 서로간의 트리거로 작용을 하게 됩니다.

네트워크 혼잡도에 따른 버퍼 상태 변화

실시간 영상 전송 중에 발생한 Underrun과 Overrun은 단순히 영상 품질의 저하 뿐만아니라 영상 재생 자체가 단절되는 현상으로 나타나며, 이를 방지하기 위한 방법은 불확실성 척도를 결정하는 요소와 관련된 문제를 해소하는 것입니다. 그러나 대역폭, 딜레이, 패킷 유실률 이 세가지 요소 중에 딜레이 요소는 네트워크 인프라스트럭처와 관련된 항목이기 때문에 소프트웨어 입장에서는 개선점을 찾기란 쉽지 않으며, 대역폭은 영상 품질, 패킷 유실률은 실시간성과 관련되는 요소이기 때문에 실시간 고해상도 영상 전송이라는 과제는 상반된 성질의 요구사항을 수용해야하는 문제라고 정의할 수 있습니다.

  • 대역폭 확보: 낮은 bitrate의 영상 송출 (저해상도/저품질)
  • 패킷 유실률: 재전송을 위한 충분한 버퍼 확보 (지연시간 증가)

혼잡제어 개선과 실시간 고해상도 영상 전송

불확실성 척도의 요소 중 대역폭과 패킷 유실률에 대해서 좀더 고민을 해본다면 대역폭의 변화는 결국 유실한 패킷에 대한 처리 방법 때문에 발생하는 것이라고 단순화할 수 있습니다. 또한 영상 전송에 한정하여 본다면 앞서 제시한대로 유실한 패킷을 모두 온전하게 다시 받아와야하는 것은 아니고, 경우에 따라서는 무시하고 진행을 할수 있다는 것이 결국 실시간 고해상도 영상 전송의 실마리가 됩니다.

UDP 기반의 SRT(Secure Reliable Transport)는 자체적인 혼잡 제어 방식을 가지고 있는 데이터 전송 프로토콜 중에 하나입니다. SRT가 혼잡 제어에 공헌하고 있는 방식은 크게 두가지 입니다. 첫번째는 사용자가 인지하는 지연 시간 내에서 전송 버퍼를 운용하는 방법이고, 두번째는 유실된 패킷을 전송하는 전략입니다.

버퍼와 흐름제어

SRT에서 권장하는 흐름제어를 위한 버퍼의 크기는 다음과 같은 기본 공식에 의하여 설정하는 것입니다.

  FCW (packets) = Bandwidth (bits) / 8 (bits/byte) * RTT (sec) / Chunk(bytes)

주목할 만한 것은, FCW를 계산하는 인자로 네트워크 대역폭(Bandwidth)와 전송 지연 시간(RTT)를 고려하고 있는 부분으로, 실제 데이터를 전송하기 전에 네트워크 정보를 알고 있다면 최적화된 FCW를 구할 수 있다는 것을 의미합니다.

실제 예를 들어본다면, 2Gbps의 대역폭을 가진 네트워크에서 150ms의 RTT가 측정이 되었다면 다음과 같이 계산할 수 있습니다.

  FCW = 2 * 100,000,000 / 8 * 0.15 / 1,472 = 25,475 (packets)

SRT에서 사용하고 있는 전송 단위는 헤더를 포함하여 1,472 bytes 이며 이를 Chunk의 값으로 사용하였습니다. 계산결과에 따르면 FCW는 25,475 packets 로 나타나고, 이는 약 300 Mbits (≈ 25,475 packets * 1472 bytes / packet * 8 bits / byte)를 의미합니다

즉, 이 네트워크의 경우 송신자가 데이터를 보내고, ACK를 수신하기 전까지 300Mbits의 데이터가 네트워크 상에 머무르고 있다는 것을 의미하며, 한번에 최대 300Mbits의 연속된 데이터를 전송과정에서 유실할 수 있다는 것을 의미하기도 합니다. 그렇기 때문에 SRT는 유실한 패킷을 재전송하기 위해 최소 버퍼로 FCW 크기보다 더 큰 값의 전송 버퍼를 유지할 것을 권장하고 있습니다.

Packet delivery

SRT 전송 방법은 패킷을 유실한 경우에 TSBPD(TimeStamp-Based Packet Delivery)와 TLPD(Too-Late Packet Drop)라는 두가지 전략을 통해서 패킷을 재전송하거나 재전송을 포기하는 방식을 취할 수 있습니다.

이 두가지 전송 전략은 실시간 영상 전송에 매우 효과적인 방식으로, 전송하는 데이터(패킷)을 원하는 시간에 사용할 수 있는가를 지표로 동작하도록 설계되어있습니다.

영상은 프레임 단위로 디코딩을 하게 되며, 하나의 프레임을 완성할 수 있을 때까지 데이터를 버퍼에 보관하고 있습니다. 한 프레임을 구성하는 패킷 중 일부가 유실된 경우, 해당 프레임을 재생할때까지 남은 시간보다 재 전송 시간이 짧으면 재전송을 요구하여 온전한 프레임을 구성하고, 반대의 경우라면 재전송 자체를 포기하거나 재전송이 진행 중에 있더라도 도착한 패킷을 버리는 전략을 수행하여 송/수신 버퍼를 효율적으로 운영하고 있습니다.

Timestamp-based packet delivery

TSBPD: Timestamp-based packet delivery

Too-Late packet drop

TLPD: Too-Late packet drop

고해상도 영상 전송 실험

다음은 5%의 패킷 유실 환경에서 각기 다른 프로토콜을 이용하여 4K 영상을 송출한 결과입니다.

프로토콜에 따른 영상 품질 비교

왼쪽 상단부터 시계방향으로 1)원본, 2)SRT 전송, 3)WebRTC(STUN), 4)RTSP 전송에 따른 영상 품질 결과 입니다. 패킷 유실률이 5%인 경우 SRT를 이용한 전송만 유일하게 영상 식별이 가능함을 알수 있습니다.

또한 SRT를 기반으로 하는 실시간 영상 전송 플랫폼인 황새울 프로젝트의 데모에서는 실제 비행하는 드론에서 RTSP와 SRT를 이용하여 동시에 영상을 전송하였을 응답 속도와 영상 품질 확보면에서 SRT가 유리함을 보여주고 있습니다.

Comments