RTMP란?

RTMP는 Real-Time Messaging Protocol의 약자이며, 라이브 온라인 비디오 스트리밍을 지원하는 데이터 전송 기술이다. Adobe에 따르면, RTMP는 적절한 전송 프로토콜(Ex) TCP)을 통해 멀티미디어 전송 스트림(Ex) 오디오, 비디오 및 대화형 콘텐츠)을 멀티플렉싱 및 패킷화하도록 설계된 응용 프로그램 수준 프로토콜이라고 한다.

RTMP에서 지원하는 비디오/오디오 코덱

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

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

+) 오디오와 비디오 코덱에 대해 더 알고 싶다면? 👉🏻 라이브 스트리밍에 적합한 오디오 코덱, 비디오 코덱에 대해

장점/단점

• 짧은 대기 시간(5초)
• 최소 버퍼링

+) 더 많은 정보를 얻고 싶다면? 👉🏻 Latency 및 Buffering

---

• 더 이상 지원하지 않는다.

낮은 호환성

원래도 RTMP는 Flash Player, Adobe AIR 등 RTMP 호환 플레이어만 지원하고 모바일 스트리밍과 호환되지 않았다. 2020년 이후로 Adobe Flash Player가 공식적으로 중단되었기 때문에, 브라우저에서 RTMP를 사용한 스트리밍도 중단되었다. 따라서 RTMP는 이제 iOS, Android, 브라우저 및 대부분 내장 가능한 플레이어에서 지원되지 않는다.

Flash 비디오 플레이어가 지원 중단되었다고 해서 RTMP가 사용되지 않는 것이 아니다. 여전히 RTMP는 여전히 스트리밍 서버와 인코더 간에 소스 전송용으로 널리 쓰이고 있다.

앞에서 말했듯이, RTMP는 Flash 비디오 플레이어와 함께 전송하는 데 사용되었었다.

예전의 RTMP의 작업 흐름은 이와 같다.

출처 : https://youtu.be/gL-yqay_-D4?si=lt2DaS-ihpryeacv

1. 압축되지 않은 디지털 오디오 및 비디오 신호가 카메라에서 인코더로 이동한다.
2. 인코더에서는 해당 신호를 압축하여 스트리밍 미디어 서버로 전송된다.
3. 해당 미디어 서버에서는 저장된 데이터들을 전 세계의 수많은 플래시 플레이어와 함께 브라우저로 전송하는 것이다.

이제 RTMP는 비디오 수집(video ingestion)에 사용된다. 소프트웨어 인코더에서 스위처, 비디오 플레이어, 서버로 비디오 파일을 가져오게 된다. 예를 들어 방송 소스(카메라나 캡처 카드 등)를 인코더에서 RTMP로 전송한 후, 유튜브나 트위치와 같은 서비스에서 이를 다시 HLS로 변환하여 최종 사용자에게 제공하는 방식인 것이다. (그래서 비디오 수집은 RTMP, 사용자에게 전송하는 것은 HLS. 같은 형태가 자주 보이는 것) 이렇게 RTMP는 인코더와 플랫폼 간 연결에 자주 사용된다.

HLS같은 프로토콜이 라이브 스트리밍 전달에 도입됨에 따라 스트리밍 미디어 서버는 변화하는 환경을 처리하도록 조정되었다. RTMP는 First-mile(위에서 말한 1단계)에서 미디어 서버에 의해 여전히 수집되었지만 필요에 따라 플레이어의 필요에 맞는 프로토콜로 변환히 필요하게 됐다. RTMP는 여전히 많은 스트리밍 플랫폼들이 사용하고 있지만 SRT와 WebRTC와 같은 다른 프로토콜들이 주목받고 있어 지켜봐야 할 것 같다.

RTMP 수집(Ingest)란?

오디오 및 비디오 콘텐츠를 캡처 및 인코딩하고, RTMP 서버와의 연결을 설정하고, 인코딩된 데이터를 스트리밍을 위해 서버로 보내는 프로세스이다. RTMP 기술을 사용하여 라이브 영상을 촬영하는 카메라/인코더에서 온라인 스트리밍 플랫폼으로 데이터를 전달한다. 방송사와 스트리밍 플랫폼에서 일반적으로 인코더, 카메라 및 기타 소스로부터 라이브 비디오 피드를 수신하여 사용자가 시청할 수 있도록 하는 데 사용된다.

RTMP 스트리밍(Streaming)이란?

RTMP 서버에서 트랜스코딩된 오디오 및 비디오 데이터를 미디어 플레이어 또는 웹 브라우저와 같은 하나 이상의 클라이언트로 전달하는 프로세스를 나타낸다. HLS 또는 DASH와 같은 다른 호환 가능한 프로토콜을 사용할 수 있다.

위의 호환성 주제에서도 말했지만 RTMP 스트리밍은 Flash 비디오 플레이어와 함께 작동하도록 설계되었었고, 모바일 스트리밍 미지원, 지원의 끊김 등등 때문에 잘 사용하지 않는 추세이다. 이제 업계에서는 기존 웹 서버를 사용하는 HTTP 기반 프로토콜(Ex) HLS)을 선호한다. 이러한 기술을 사용하면 로컬 서버가 스트리밍 콘텐츠를 캐시할 수 있으므로 확장성과 시청 경험이 향상된다. 따라서 ABR 방식이 더욱 보편화되어졌고, 방송사가 시청자의 기기 및 연결에 맞춰 콘텐츠를 최적화할 수 있게 되었다고 한다.

RTMP 동작 방식

이 과정은 크게 Handshake, Connect, Stream 3단계로 나뉜다.

먼저, RTMP 연결은 Handshake로 시작한다. RTMP는 TCP 위에 있기 때문에 데이터를 전송할 때 three-way handshake를 사용한다.

Handshake : 서버와 초기 연결 설정

C0~2, S0~2는 모두 정적 크기 chunk이다.

• C0과 S0 패킷 형식 : 8비트 정수 필드를 가진 단일 옥텟(== 1 byte)
  

• version : C0 패킷에서 이 필드는 스트리밍되는 RTMP 프로토콜 버전을 서버에 알려주는 것이고, S0에서 이 필드는 서버에서 선택한 RTMP 버전을 식별하기 위한 것이다. 버전은 주로 3을 사용한다. 만약, 클라이언트가 요청한 버전을 인식하지 못하는 서버는 3으로 응답해야만 한다.

  • 0 ~ 2 : 이전 독점 제품에선 더 이상 사용 X, 4 ~ 31 : 예약되어 있음, 32 ~ 255 : 허용 X
    
    
    

• C1과 S1 패킷 형식 : 1536 byte

  

• time : 타임스탬프가 포함된다. 이 타임스탬프는 엔드포인트 간의 전송될 예정인 모든 chunk들에 대한 기간(epoch)으로 사용해야 한다. 여러 chunk stream을 동기화하기 위해 엔드포인트는 다른 chunk stream의 타임스탬프의 현재 값을 보낼 수 있다.

• zero : 다 0이어야 한다. 왜냐면, 이는 예약된 필드이기 때문!

• random data : 무작위 값. 보안이 요구되는 값은 아니다.
  
  
  

• C2과 S2 패킷 형식 : 1536 byte

  

  C2와 S2는 각각 C1과 S1의 echo에 가깝다. 타임스탬프의 복사본 느낌?
  

• time : 이 필드에는 상대방이 이전 응답에서 보낸 타임스탬프가 포함된다.

  • C2의 경우 S1, S2의 경우 C1

• time2 : 상대방이 보낸 이전 패킷(S1 또는 C1)을 읽은 타임스탬프가 포함된다.

• random echo
  

Handshake는 클라이언트(인코딩 소프트웨어 또는 하드웨어)가 C0 및 C1 패킷을 보내는 것으로 시작된다. 이때, 클라이언트는 C0 에 대한 응답을 기다리지 않고 C1 을 전송할 수 있다. 다만, C2를 보내기 전에 S1이 수신될 때까지 기다려야 하고, 그 외 데이터들을 보내기 전에는 S2가 수신될 때까지 기다려야 한다. (위 다이어그램 참고)

Uninitialized 상태에서 클라이언트는 먼저 프로토콜 버전(C0)을 전송한다. 이때, 클라이언트와 서버 모두 초기화되지 않았다. 만약 서버가 해당 버전을 지원한다면, 응답으로 S0 및 S1을 보낸다. 만약 지원하지 않는다면 연결되지 않는다.

그 다음, 패킷 S1을 기다리고 서버는 패킷 C1을 기다리고 있는 Version Sent 상태가 된다. 그렇게 각각 S1 과 C1 을 받으면 클라이언트는 패킷 C2를 보내고 서버는 패킷 S2를 보낸다. 그러면 Ack Sent 상태가 된다.

Ack Sent 상태에서 기다리고 있는 S2와 C2 를 받으면 비로소 Handshake가 완료되었다! 이제 클라이언트와 서버가 메시지를 교환할 수 있다.

---

Connect

연결 단계에서 클라이언트와 서버는 AMF(Action Message Format) 인코딩을 사용하여 메시지를 보낸다.(하나 이상의 Chunk Stream을 멀티플렉싱) 클라이언트는 메시지에 연결 URL, 오디오 코덱, 비디오 코덱과 같은 세부 정보를 표시하고, Set Peer Bandwidth , Window Acknowledgement Size 에 대한 메시지도 교환한다. 서버가 먼저 응답하여 연결이 모두 설정되면 서버가 비디오 데이터를 스트리밍할 수 있게 된다.

---

Stream

• 이는 비디오 스트리밍 프로세스에서 RTMP 프로토콜을 사용할 때 발생하는 과정이다.(요즘은 HLS가 추세)

Handshake 및 Connect 단계를 완료했으므로 이제 스트리밍 데이터를 보낼 수 있다. 또한, createStream, play, receiveAudio, seek, pause 등과 같은 명령을 사용하여 비디오가 지시에 따라 전송되도록 할 수 있다.

본격적으로 RTMP 톺아보기

RTMP 용어 정리

RTMP에 대해서 본격적으로설명하기 전에 먼저 공식 문서에 나오는 개념들에 대한 설명을 하고자 한다.

(Adobe RTMP Specification 내용을 바탕으로 작성되었습니다.)

Payload : 패킷에 포함된 데이터(Ex) 오디오 샘플 또는 압축된 비디오 데이터)

Packet : 고정 헤더와 Payload 데이터로 구성된 데이터 패킷

Port : 전송 프로토콜이 지정된 호스트 컴퓨터 내의 여러 대상을 구별하는 데 사용한다. (TCP/IP 프로토콜은 작은 정수(숫자)를 사용해서 Port를 구분)

Transport address : 전송 레벨의 엔드포인트를 식별하는 네트워크 주소와 Port의 조합(Ex) IP 주소 + TCP Port). Packet은 이 전송 주소를 사용해 출발지에서 목적지로 이동한다.

Message Stream : 메시지가 흐르는 통로. Ex) 실시간 스트리밍에서 비디오 데이터가 흐르는 논리적 통로

Message Stream ID : 각 메시지가 어느 Message Stream에서 흘러가고 있는지 식별할 수 있는 식별 번호. 즉, 어떤 스트림의 일부인지를 확인할 수 있다.

Chunk : 큰 메시지를 여러 조각으로 나눈 작은 데이터 조각이다. 메시지는 네트워크를 통해 전송되기 전, 더 작은 부분으로 나뉘고 인터리브(interleave)된다. 하지만 Chunk는 여러 스트림에 걸쳐 모든 메시지의 타임스탬프 순서에 따라 엔드투엔드로 전달된다.

• 인터리브(interleave)된다라는 뜻은? 인터리브는 여러 데이터 스트림의 청크를 번갈아 가며 섞어서 보내는 과정이다. 예를 들어, 비디오 청크(A1, A2)와 오디오 청크(B1, B2)가 있다면, A1 → B1 → A2 → B2 순서로 번갈아가며 보내는 것. 이렇게 섞어서 보내지만, 각 메시지의 순서가 뒤바뀌지 않도록 타임스탬프에 기반해 순서를 유지한다. 예를 들어, 비디오 스트림의 A1 청크가 먼저 전송되고, 다음 비디오 청크인 A2가 그 다음 순서로 도착하도록 보장된다. 즉, 여러 스트림을 섞어서 보내더라도, 각 스트림 내에서는 메시지가 올바른 순서대로 도착한다.
  

Chunk Stream : 한 방향으로만(클라이언트 → 서버, 서버 → 클라이언트) 청크들이 흐르는 논리적 통로

Chunk Stream ID : 각 청크가 어느 Chunk Stream에 속해 있는지 식별할 수 있는 식별 번호.

Multiplexing : 개별 오디오/비디오 데이터를 하나의 통합된 스트림으로 만들어 여러 비디오와 오디오를 동시에 전송할 수 있도록 하는 프로세스. Ex) 영상과 소리를 따로 보내지 않고, 하나의 스트림으로 만들어 전송하는 것

DeMultiplexing : 멀티플렉싱의 반대 과정으로, 하나로 합쳐진 오디오/비디오 데이터를 다시 분리하여 원래의 개별 데이터로 복원하는 과정이다.

RPC : 클라이언트나 서버가 서로 원격에서 함수를 호출할 수 있는 요청이다. Ex) 클라이언트가 서버에 있는 특정 기능을 호출할 수 있는 방식

Metadata : 데이터에 대한 설명

Application Instance : 클라이언트가 연결을 요청하는 서버에 있는 응용 프로그램의 실행 인스턴스를 말한다. 각 클라이언트는 특정 응용 프로그램 인스턴스에 연결되어 통신을 한다.

AMF : AMF는 ActionScript 객체를 직렬화(컴퓨터에서 쉽게 전송하고 저장할 수 있는 형태로 변환)하는 데 사용되는 이진 형식이다. AMF 0과 AMF 3 두 가지 버전이 있다.

RTMP는 영상, 음성, 데이터를 동시에 전송하고, 각 메시지 유형의 우선순위에 따라 어떤 데이터를 먼저 처리할지 결정하는 프로토콜이다.

RTMP Chunk Stream

RTMP 메시지를 전송할 때 사용하는 전송 방식으로, 각 청크 스트림은 하나의 메시지 스트림에서 한 가지 유형의 메시지를 전달할 수 있다. 여기에는 Connection 관리 메시지, Stream 생성/제어 메시지, 실제 미디어 데이터가 들어가며 Chunk Stream을 통해 Connection, Stream에서 데이터를 전송한다.

청크를 사용하면 상위 수준 프로토콜의 큰 메시지를 더 작은 메시지로 나눌 수 있다. 생성된 각 청크에는 Chunk Stream ID라는 식별자가 있는데, 이 식별자로 수신자 측에서 메시지로 조립된다. 청크 크기가 클수록 CPU 사용량이 줄어들지만, 쓰는 시간이 오래 걸려 대역폭이 낮은 연결에서 다른 콘텐츠를 지연시킬 수 있다. 또한, 너무 작은 청크는 높은 비트 전송률 스트리밍에 적합하지 않다.

Chunk Format

각 청크는 헤더와 데이터로 구성되는데, 헤더 자체는 세 부분으로 나뉜다.

Basic Header

• 청크 유형(fmt)와 Chunk Stream ID(cs id)를 인코딩
• 가변 길이 필드인 cs id ID에 따라 1 ~ 3 byte로 결정(0은 2byte, 1은 3byte)
• 구성 요소
  • fmt(2 bit) : 인코딩된 메시지 헤더의 형식을 결정
  • cs id(2 bit) : 2-63 사이의 값에 대한 Chunk Stream ID
  • cs id - 64(8 or 16 bit) : Chunk Stream ID에서 64를 뺀 값.
  • Ex) ID 365는 cs id는 1로 표시, cs id - 64는 16비트 301로 표시한다.

Message Header

• Basic Header 의 fmt 값에 따라 0, 3, 7, 11 byte의 길이를 가진다.

• 전송 중인 메시지에 대한 정보(전체 또는 일부)를 인코딩

• 공통 헤더 필드

  • Timestamp Delta (3 bytes)
    • Type 1, Type 2 청크에서 사용
    • 이전 청크와 현재 청크의 시간 차이를 표시
    • 16777215 미만이면 실제 delta 값 사용
    • 16777215(0xFFFFFF) 이상이면 Extended Timestamp 필드 사용
  • Message Length (3 bytes)
    • Type 0, Type 1 청크에서만 사용
    • 전체 메시지의 길이를 나타냄
    • 청크 페이로드 길이와는 다를 수 있음
      • 일반 청크: 최대 청크 크기
      • 마지막 청크: 남은 데이터 크기
      • 작은 메시지: 전체 길이가 될 수 있다.
  • Message Type ID (1 byte)
    • Type 0, Type 1 청크에서만 사용
    • 메시지의 종류를 나타낸다.
  • Message Stream ID (4 bytes)
    • Type 0 청크에서만 사용
    • Little-endian 형식으로 저장
    • 여러 메시지 스트림을 하나의 청크 스트림으로 멀티플렉싱 가능 (but 헤더 압축 이점 상실)

• 유형 0

  

  • 11 byte
  • 청크 스트림을 시작할 때, 타임스탬프가 역방향으로 이동한다면(Ex) 영상 10초 전으로 돌리기?) 반드시 이 유형을 사용해야 한다.
  • 만약 TimeStamp가 16777215(0xFFFFFF)보다 크거나 같다면 Extended Timestamp가 있음을 알리는 16777215을 저장하다.
  • 3 bytes(24비트)로는 최대 16777215까지만 표현 가능하므로 더 큰 값은 Extended Timestamp에 저장하고 현재 Timestamp에는 Extended Timestamp에 원본 시간이 저장되어 있음을 알리는 16777215을 저장하는 것이다.

• 유형 1

  

  • 메시지 스트림 ID를 제외한 7 byte의 길이
  • 이전 청크와 동일한 스트림 ID를 사용하는 유형
  • 동영상 같은 가변 크기 메시지가 있는 스트림은 첫 번째 메시지 이후 각 새 메시지의 첫 번째 청크에 이 유형을 사용해야 한다.
  • Timestamp Delta는 절대 시간이 아닌 이전 메시지와의 시간 차이를 전송하는 것이다. 더 적은 비트로 표현 가능하여 네트워크 대역폭을 절약할 수 있다.

• 유형 2

  

  • 스트림 ID나 메시지 길이는 포함하지 않는 3 byte의 길이
  • 이전 청크와 동일한 스트림 ID 및 메시지 길이를 가진다.
  • 일정한 크기 메시지를 가진 스트림은 첫 번째 메시지 이후 각 메시지의 첫번쨰 청크에 대해 이 유형을 사용해야 한다.
  • 유형 3
  • 메시지 헤더, 스트림 ID, 메시지 길이 및 Timestamp Delta 필드가 존재하지 않는 경우의 유형이다.
  • 메시지들의 크기, 스트림 ID, 시간 간격이 모두 동일하거나, 하나의 메시지가 여러 청크로 분할될 때 반드시 유형 3을 사용해야 하고, 첫 메시지와 두 번째 메시지의 타임스탬프 차이가 첫 메시지의 타임스탬프와 동일할 때 유형 3을 사용할 수 있다.

Extended Timestamp

• 6777215(0xFFFFFF)보다 큰 타임스탬프 또는 타임스탬프 델타를 인코딩하기 위해 사용한다.
• 각 Chunk Type별 사용 조건
  • Type 0 : 타임스탬프 필드가 0xFFFFFF일 때 사용
  • Type 1, 2 : 타임스탬프 델타 필드가 0xFFFFFF일 때 사용
  • Type 3 : 같은 chunk stream ID를 가진 가장 최근의 청크가 Extended Timestamp 필드를 가지고 있었을 때만 사용

Chunk Data

• 가변 크기
• 청크의 페이로드. 즉, 패킷에 포함된 데이터

RTMP Messages

RTMP는 원래 RTMP 청크 스트림과 함께 사용하도록 설계되었지만 다른 전송 프로토콜(Ex) TCP/IP, WebSocket 등)을 사용해서 RTMP Message를 보낼 수 있다. 이 RTMP Message는 헤더와 페이로드로 구성되어 있으며 오디오, 비디오, 데이터 또는 기타 메시지가 포함될 수 있다. 메시지 유형으로는 오디오 메시지, 비디오 메시지, 명령 메시지, 공유 객체 메시지, 데이터 메시지 및 사용자 제어 메시지가 있다.

• Message Header

  

  • Message Type (1 byte): 메시지 유형을 나타낸다.
  • Payload Length (3 byte) : 페이로드의 크기를 byte로 나타낸다.
  • Timestamp(4 byte) : 메시지의 타임스탬프
  • Message Stream Id(3 byte) : 메시지 스트림을 식별하기 위한 값

• Message Payload

  • 메시지에 포함된 실제 데이터 (Ex) 일부 오디오 샘플 또는 압축된 비디오 데이터)

자주 사용되는 RTMP 송출 + HLS 스트리밍 방식

RTMP와 HLS를 함께 사용하면 대기 시간을 너무 높이지 않고도 호환성을 극대화할 수 있다. 과정은 아래와 같다.

1. RTMP로 송출

스트리머는 OBS(오픈 브로드캐스터 소프트웨어) 또는 XSplit과 같은 인코딩 도구를 사용하여 RTMP 프로토콜을 통해 스트리밍 서버로 스트림을 보낸다.

2. 트랜스코딩 및 프로토콜 변환

스트리밍 서버는 수신된 RTMP 스트림을 받아서 트랜스코딩을 진행한다. 트랜스코딩은 원본 스트림을 다양한 해상도(720p, 1080p 등)와 비트레이트로 변환하는 과정이다. 이를 통해 시청자의 네트워크 상태에 맞춰 적응형 스트리밍을 제공할 수 있게 된다. 이 과정에서 RTMP 프로토콜로 전송된 데이터를 HLS 프로토콜에 맞게 변환한다.

3. HLS 스트리밍

변환된 HLS 스트림은 스트리밍 서버에서 시청자에게 제공된다. HLS는 청크 단위로 비디오 데이터를 전송하므로 네트워크 상태에 따라 시청자의 재생 환경에 맞는 화질로 실시간 조정이 가능하다.

4. 시청자는 HLS로 스트림 재생

시청자는 HLS 프로토콜을 통해 비디오를 스트리밍 받는다. 비디오 플레이어는 서버에서 제공하는 M3U8 파일(비디오 청크 목록)을 읽어 와서, 네트워크 상태에 따라 적절한 비트레이트를 선택해 재생한다.

🤔 궁금한 점

1️⃣ 구글 미트나 페이스타임 같은 화상회의를 위해서는 주로 WebRTC 프로토콜을 사용한다. 왜 화상회의를 위해서 주로 WebRTC 프로토콜을 사용할까?

우선 화상회의 프로토콜이 가져야하는 중요한 점이 무엇인지를 알아야 한다.

1. 딜레이가 짧아야 한다. (주로 0.5초 내외)
2. 화질이 엄청 좋을 필요는 없다.
3. 높은 호환성을 가져야 한다. (Ex) 안드로이드, 아이폰 상관없이 줌을 사용할 수 있다.)

이러한 점들을 가지는 프로토콜로는 WebRTC 프로토콜이 적합하다. WebRTC는 피어 투 피어(P2P) 방식으로 작동해 중간 서버를 거치지 않고 직접 연결되므로, 영상 및 음성 데이터가 빠르게 전달된다. 또한, 별도의 플러그인 설치 없이도 대부분의 최신 웹 브라우저에서 기본적으로 지원되므로 사용자는 손쉽게 브라우저에서 바로 화상회의에 참여할 수 있다.

그렇다면 RTMP는 불가능한가? 🤔 불가능이라기 보다 부적합하다는 것이 맞는 것 같다. RTMP는 주로 스트리밍 서비스에 사용되며, 방송 송출 시 일정한 지연 시간이 발생할 수 밖에 없다. 따라서 실시간으로 상호작용이 중요한 화상회의에는 적합하지 않다. 또한, RTMP는 서버 기반으로 작동하기 때문에 참가자 수가 많을 경우 서버 부담이 증가된다.

2️⃣ HLS을 사용해서 RTMP 대신 비디오를 수집(Ingest)/송출할 수 없나?

가능하지만, RTMP가 여전히 라이브 스트림 인코더(Ex) OBS Studio)들 중에서 가장 호환되는 옵션이다. 또 다른 이점은 훨씬 짧은 대기 시간으로 스트리밍할 수 있다는 것이다. 

+) RTMP로 비디오 수집/송출을 했을 때의 장점 👉🏻 클릭

+) 라이브 스트림 인코더 종류 살펴보기 👉🏻 클릭

참고 자료

Adobe RTMP Specification · RTMP

What is RTMP?

RTMP Streaming: The Real-Time Messaging Protocol Explained (Update)

RTMP and HTML5 Video Players - What Broadcasters Need to Know

What is RTMPS and Why is it Important to Secure Streaming?

What is RTMP Ingest? And How Significant is it to Live Streaming