Live & VOD Streaming Media server 구축 (6) - 미디어컨텐츠 전송 프로토콜 선정 (RTMP vs SRT 등등)

미디어컨텐츠를 전송하는 프로토콜은 여러가지가 있지만, 사용할 프로토콜을 선택한 과정을 기록해두려고 한다.

 

요구사항

- 1 : N 라이브 스트리밍

 

 

먼저 wowza에서 각 프로토콜의 지연시간을 나타낸 그림이 있었다.

 

미디어 컨텐츠 전송 프로토콜 지연시간

 

스트리밍 프로토콜 선정기준

1. Adaptive Bitrate Streaming
2. low-latency 
3. 확장성 (HTTP 기반 프로토콜)
4. 라이센스 
5. 개발자료

 

선정기준은 내가 생각하는 중요도에 따른 순서대로 매겼다. 

 

1. 사용자의 대역폭에 따라 품질이 자동으로 변해야 영상이 끊기지 않게 시청할 수 있으므로 사용자 경험에서 가장 중요하다고 생각했다.

2. 어느 누구도 지연시간이 긴 라이브 스트리밍을 보고싶어하진 않을 것이다. 

3. 클라이언트가  IOS , Android, Web 이므로 egress에서는 다른 Player plug-in 없이 영상을 볼 수 있어야 사용자 경험이 좋아진다고 판단했다. 

4. 소스코드 공개의무가 없는 오픈소스여야된다고 판단했다.

5. 미디어서버를 개발해본 경험이 없기 때문에 개발자료도 중요하지만 영상의 품질이 중요하다고 생각하여 가장 마지막 기준으로 배치했다. 

 

 

스트리밍 프로토콜 리스트업

 

Ingest

 

1. RTMP
2. SRT
3. WebRTC

 

egress

 

1. HLS
2. MPEG-DASH

 

 

 

 

고려한 프로토콜들의 목록은 이러하고 먼저 하나씩 살펴보기 전에 프로토콜마다 OSI 7계층 중 전송계층(Transfer Layer)에서 TCP와 UDP로 나뉘어지기 때문에 TCP, UDP에 대한 개념이 없다면 OSI 7계층 먼저 공부하는 것이 좋다. 

 

간단하게 둘의 차이점에 대해 설명하자면

TCP는 통신과정에서 handshaking 을 통해 연결을 강제한 후 데이터를 전송하기 때문에 데이터를 잃어버릴 일이 없다.

하지만 UDP는 수신자를 정확하게 확인하지 않고 데이터를 전송하기 때문에 데이터를 잃을 수 있다. 그렇기때문에 handshaking이 없는 UDP는 TCP보다는 빠르게 전송할 수 있지만 데이터가 모두 잘 왔는가?는 확인할 수 없다.

 

RTMP - TCP

Real Time Messaging Protocol로 Adobe 독점 프로토콜 규약이다. 

원래 Adobe가 개발한 것은 아니고, Macromedia에서 개발하고 2005년에 Adobe가 인수했다. 

현재 미디어컨텐츠 전송 프로토콜로 가장 많이 사용되고 있으며 지속적이고 안정적인 연결을 유지하고 대기 시간이 짧은 통신을 허용한다. 

하지만 전송한 미디어컨텐츠를 재생하기 위해서는 별도의 Flash Player plug-in이 필요한데 Adobe가 공식적으로 Player에 대한 지원을 종료했다.

RTMP는 기본적으로 1935 port를 사용하며 암호화되지 않은 프로토콜이다. (암호화된 프로토콜은 RTMPS)

 

TCP 기반의 프로토콜이어서 처음에 HandShaking을 진행한다. 

 

handshaking

• c0/s0: RTMP version 정보

• c1/s1: 동기화 할 시간, peer를 구분할 random data

• c2/s2: 각자 peer의 c1/s1에 대한 echo

 

 

연결과정인 handshaking이 끝나면 Message는 Chunk 단위로 분할해서 보내게 된다.

Message는 Chunk Header와 Chunk Data로 구성되어 있다.

 

Chunk Header 

- 각각의 Stream을 구분할 Stream ID 존재

- stream의 시간에 따른 필요한 내용들 존재 

- 등등

 

Chunk Data

- 실제 미디어컨텐츠 데이터들

 

 

이런식으로 신뢰성있는 연결을 통해 미디어컨텐츠를 전달하지만, 지연시간이 5~30초로 다른 프로토콜들에 비해 길지 않고 짧기 때문에 라이브 스트리밍 프로토콜로 많은 기업에서 사용하고 있다.

(하지만 SRT나 WebRTC같은 신기술들이 치고 올라오는중)

 

지원하는 코덱들은 다음과 같다. 

 

RTMP

Audio Codecs : AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex

Video Codecs : H.264, VP8, VP6, Sorenson Spark®, Screen Video v1 & v2

 

 

 

결론적으로 Flash Player의 공식 지원 중단으로 클라이언트가 직접 방송하는 영상을 시청할땐 사용할 수 없겠지만 처음에 영상을 인코딩하고 미디어서버에 보낼 때는 사용할만 하다는 생각이 들었다. 

 

 

---

SRT - UDP + TCP 

SRT(Secure Reliable Transport) 는 예측할 수 없는 네트워크에서 스트리밍 성능을 최적화하는 UDP 기반 전송 기술이다.

하지만 오류 복구 매커니즘을 통해 일반적으로 UDP 통신에서 발생하는 스트림의 패킷 손실을 최소화하기 때문에 UDP + TCP로 적어놓았다. 

• 오디오 코덱: 코덱에 구애받지 않음
• 비디오 코덱: 코덱에 구애받지 않음
• 재생 호환성: 제한적(VLC Media Player, FFPlay, Haivision Play Pro, Haivision Play, Larix Player, Brightcove)
• 이점: 차선의 네트워크를 통한 고품질, 저지연 비디오
• 단점: 비디오 재생에 대해 널리 지원되지 않음
• 대기 시간: 3초 이하, 패킷 손실을 위해 교환하려는 대기 시간에 따라 조정 가능

 

지금까지의 미디어 컨텐츠 전송 프로토콜들의 어려움이나, 안좋은점을 개선하기 위해 나온 프로토콜이기 때문에 성능도 좋고 오픈소스이다. 안좋은점이라고하면 재생호환성이 아쉬운 점 뿐이다. 

 

---

MPEG-DASH vs HLS 

 

DASH와 HLS는 http 기반에서 유명한 경쟁 프로토콜들이기 때문에 같이 비교했다. 

 

HLS

미디어서버에서 시청자의 화면으로 전송하기위한 HTTP기반의 라이브 스트리밍 프로토콜

 

비디오 코덱 : H.265, H.264

오디오 코덱 : AAC-LC, HE-AAC+ v1 및 v2, Apple Lossless, FLAC

 

특징

- Adaptive bandwidth를 지원

- Live / VoD 모두를 지원하기에 적합

- Media encryption을 지원

 

MPEG-DASH

MPEG의 미디어를 스트리밍하기위한 적응형 HTTP 기반의 국제 표준 프로토콜

 

비디오 코덱 : 구애받지 않음

오디오 코덱 : 구애받지 않음

 

특징

- Adaptive bandwidth를 지원

- 국제 표준

- 코덱에 구애받지 않는다.

 

 

두 프로토콜은 데이터를 전송하는 방식도 비슷하고, http를 기반으로 스트리밍을 하기 위해 만들어진 프로토콜이라 여러 클라이언트들과 호환성이 좋지만, 가장 큰 차이점은 MPEG-DASH에서는 IOS safari 를 지원하지 않는다. 

이유는 애플에서 막았기 때문에.. 우리 클라이언트에 IOS가 있어서 MPEG-DASH는 배제했다. 

HLS vs MPEG-DASH

---

WebRTC

P2P 기반의 지연시간이 매우 짧은 스트리밍 형식으로 웹 브라우저 간에 플러그인 도움 없이 서로 통신할 수 있도록 설계된 API

비디오 코덱 : H.264 , VP8, VP9

오디오 코덱 : Opus, iSAC, iLBC

지원 플랫폼 : 웹, IOS, Android 모두 지원

장점

- 대기시간

- 장치 의존성 없음

- 오픈소스 및 표준화

 

WebRTC의 네트워크 연결 구조 

 

 

 

Benchmark

Intel Xeon 8 cores CPU E5-2686 v4 @ 2.30 GHz, 32 Gb RAM

다음 사진은 8코어의 CPU에서 WebRTC, RTMP 등에서 800p의 화질에서 연결 수에 따른 CPU 사용률을 체크한 논문에서 발췌한 사진이다. WebRTC는 1000명의 연결에서 바로 CPU의 70% 이상을 사용했다. 

논문의 내용을 봤을때 합리적으로 실험을 한 결과인 것 같아 참고했다.

 

WebRTC는 1 : N 라이브 스트리밍을 하기에는 서버 리소스를 너무 많이 소모한다. 여러명이서 화상회의를 할 때는 고려해볼만 하지만, 방송같은 스트리밍 서비스에서는 사용하기 어렵다. (결국 WebRTC는 1대1 화상통화가 필요한 기능에 사용했다)

 

---

 

ingest : 현재 RTMP로 구현을 한 후이다. 하지만 다시 선정한다면 SRT를 선택할 것 같다. 선정할 땐 SRT가 하드웨어 인코더가 꼭 필요해야 한다고 생각했고, 재생호환성이 좋지 않아 안좋다고 생각했지만 결국 ingest와 egress는 분리되고, 지연시간이 RTMP보다 SRT가 훨씬 짧기 때문에 개발자료가 없어도 4~5초의 지연시간을 줄이는 부분은 필요할 것 같다. 

 

egress : HLS로 선정했다. HLS와 MPEG-DASH는 http 기반의 프로토콜들로 클라이언트들과 호환성이 좋은게 egress 프로토콜들의 선정기준으로 들어간게 가장 컸다. 하지만 크리티컬한 부분이 MPEG-DASH의 IOS safari 를 지원하지 않는 부분이기 때문에 HLS로 선정했다. 

- SRT는 시간 및 시퀸스 값이 1대1 통신에 사용하는 종류의 프로토콜이기 때문에 빠르지만 1:N multicast에는 사용할 수 없는 프로토콜이다. 대부분의 유료 미디어서버도 다시 다 hls로 재패키징하거나 transcording해서 배포함

https://github.com/Haivision/srt/issues/93

 

 

 

 

참조

https://antmedia.io/srt-streaming-the-secure-reliable-transport-protocol/

https://haivision.github.io/srt-rfc/draft-sharabayko-srt.html

https://www.epiphan.com/blog/why-srt-hls-mpegdash-streaming/

https://getstream.io/blog/streaming-protocols/

https://www.wowza.com/blog/streaming-protocols

https://www.dacast.com/blog/video-streaming-protocol/

https://yoooonghyun.gitbook.io/documents/multimedia/overview/rtp

https://restream.io/blog/streaming-protocols/