RTMP Streaming: 실시간 메시징 프로토콜에 대하여

스트리밍 초기시대에 RTMP는 인터넷을 통해 비디오를 전송하기 위한 사실상 표준으로 존재했다. RTMP는 TCP 기반 프로토콜로 지속적인 연결 유지, 저지연, 더 나가아 원활한 스트리밍을 제공한다.

RTMP는 본래 Adobe Flash Player를 이용하여 live 및 주문형 스트링을 제공하기 위한 목적으로 시작되었다. Flash plugin이 전성기 시절에는 인터넷 브라우저의 98%를 차지하였기에 RTMP는 어디서나 사용되었다. 오늘날 대부분의 인코더는 RTMP를 전송할 수 있고, 대부분의 미디어 서버는 이를 수신할 수 있다. Facebook, YouTube, Twich와 같은 대규모 소셜 미디어 플레이어도 이를 수용한다. 그러나, 최근 우리가 자주 사용하는 일부 브라우져 및 단말에서 재생하는 과정에서 호환성 문제가 발생한다.

이 글에서 RTMP 스펙, 역사, 스트리밍 방법 및 대체 프로토콜 등에 대해 정리해 본다.

 

RTMP 란?

Adobe’s RTMP provides a bidirectional message multiplex service over a reliable stream transport, such as TCP [RFC0793],  intended to carry parallel streams of video, audio, and data messages, with associated timing information, between a pair of communicating peers

Adobe에서 말하는 RTMP는 상호간의 소통을 위한 양방향 메시지 다중화 서비스이다. TCP와 같은 신뢰할 수 있는 스트림 전송을 통해 비디오, 오디오, 데이터 메시지와 관련된 타이밍 정보를 병렬 스트림으로 전달하게 해준다.

 

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

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

- 재생 호환성: 보편적이지 않음

1) Flash Player (Adobe에서 중단), Adobe AIR, RTMP 호환 Player로 제한

2) iOS, 안드로이드, 대부분의 브라우저, 임베디드 플레이어 등에서 더 이상 허용되지 않음

- 장점: 저지연 (5초) 및 최소 버퍼링

- 단점: 업데이트 및 지원 중단

- 변형된 포맷: RTMPT (HTTP 터널링), RTMPE (암호화), RTMPTE (터널링 및 암호화), RTMPS (SSL 암호화), RTMFP (UDP)

 

RTMP Streaming 동작 방식

TCP 기반 데이터 전송 프로토콜로 3-way handshake를 사용한다. client가 server로 connection을 요청하고 이를 수락하여 end-to-end 간의 session을 유지한다. 이로인해 RTMP는 매우 안정적으로 오디오 및 비디오 데이터의 고성능 전송이 가능하다.

 

History

스트리밍의 역사

5초 정도의 대기시간을 가진 RTMP는 2010년대 초반까지 라이브 스트리밍의 강자로 자리잡았다. 그러나, 이 후 RTMP를 능가하는 다양한 프로토콜이 등장하기 시작했다. RTMP는 방화벽을 통과하는데 문제가 있었고, 2020년 12월 Adobe의 Flash 지원 중단을 발표하였다.

업계에서는 HTTP 기반 프로토콜을 더 선호하였으며, 로컬 서버에서 스트리밍 콘텐츠를 캐쉬할 수 있어 확장성과 시청 경험이 증가되었다. 이는 방송사들이 시청자의 장치 및 네트워크 환경에 맞춰 최적화된 콘텐츠를 제공할 수 있게 되었다.

이에 따라 Flash를 지원하는 디바이스는 점차 줄어들었고, Adobe도 기존 Flash Contents를 새로운 형식으로 마이그레이션 할 것을 권고하였다.

 

그렇다면 RTMP는 죽었는가?

2021 비디오 스트리밍 프로토콜 사용현황

Flash의 단종이 2020년에 발표되었기 때문에 여전히 많은 방송사가 RTMP 스트리밍을 사용하고 있다. 다만, 최종 Client 단까지 사용되는 프로토콜로서의 역할은 중단됐다.

 

RTMP 라이브 스트림 워크플로

라이브 비디오 스트리밍 Delivery chain

콘텐츠를 제공하기 위해 캡쳐에서 재생까지 하나의 스트리밍 프로토콜로 제한되지 않는다. 캡쳐를 위해 RTMP, RTSP/RTP, SRT, WebRTC 등을 사용하더라도 이를 재생하는 client 입장에서는 재생 친화적인 대안 (MPEG-DASH, HLS 등)으로 트랜스코딩할 수 있다.

 

RTMP 스트링 설정 방법

RTMP 스트림을 전달하기 위해서는 RTMP 호환 카메라 또는 인코더로 시작해야 한다. (OBS 소프트웨어 권장)

RTMP 스트림에 대한 소스 인코더를 선택한 후에는 비디오 트랜스코딩 및 전송을 위한 솔루션을 통해 HLS, MPEG-Dash, WebRTC 등으로 Client에게 제공해야 한다. Adobe Flash Player의 지원 중단으로 RTMP 재생 지원은 더 이상 존재하지 않는다. 즉, RTMP 스트림은 트랜스코딩이 필수적이다.

 

RTMP 라이브 스트림을 적응형 HLS 및 DASH 형식으로 트랜스코딩하는 것이 일반적인 관행이다. 또한, 500ms 미만의 저지연이 필요한 경우에는 WebRTC를 사용하여 송수신 모두에 사용해야 한다.

 

캡쳐 측면에서의 RTMP 대안

RTMP가 여전히 라이브 스트림 송출을 위해 일반적으로 사용되지만, 점차 SRT, WebRTC가 그 역할을 대행하고 있다.

 

SRT 

Legacy protocols such as real-time messaging protocol (RTMP), developed over a decade ago to encode video and move it across networks to clients, will likely be displaced by newer solutions such as Secure Reliable Transport (SRT), designed to further decrease latency and meet the demands of live and on-demand streaming.

RTMP는 대기시간을 5초로 제공한 이후 추가적인 지원이 중단되었고, 대기시간을 추가적으로 줄이도록 설계된 오픈소스 기술인 SRT와 같은 새로운 솔루션으로 대체될 것이다. SRT는 지연시간을 줄이고 라이브 및 주문형 스트리밍의 요구사항을 충족한다.

 

WebRTC

1초 미만의 스트리밍 또는 간단한 브라우저 기반 캐시가 필요한 워크플로에서 널리 사용된다. WebRTC 기반 비디오 소스용 RTMP 인코더를 교체하면 추가 장비가 필요하지 않다. 즉, 웹브라우저만 사용하여 라이브 스트림을 원할하게 방송할 수 있다.

 

전송 측면에서의 RTMP 대안

전송 시 가장 많이 사용하는 프로토콜은?

HLS and DASH

HLS는 가장 일반적인 스트리밍 프로토콜로 70% 이상이 사용하고 있다. 또한, MPEG-DASH는 HLS의 오픈소스 대안이자 업계 표준이다. DASH용 저지연 CMAF 및 저지연 HLS로 점점 더 지연속도는 짧아지고 있다.

 

 WebRTC

유일한 실시간 프로토콜의 대안은 WebRTC이다. 500ms 미만의 대기 시간으로 브라우저를 통해 직접 통신할 수 있다.