RTMP 와 HLS

RTMP

정의

Real-Time-Messaging Protocol 의 약자로  Adobe에서 만든 Flash 플레이어와 서버간에 
인터넷을 통한 오디오 및 데이터 스트리밍을 사용하는데 사용되는 프로토콜
현재는 Adobe Player 중단된 이유로 서버로부터 클라이언트에게 보낼 때는 사용이 중단되고
인코더에서 미디어서버로 보낼 때 즉 , 송출 과정에서만 사용된다

특징

• TCP 기반
• 데이터는 Chunk 단위로 fragmentation되어 송신 후 수신 단에서 조합하여 온전한 메시지가 된다.
• 청크는 데이터와 헤더로 나뉘어있다.

장점

• 최소한의 버퍼링
• 짧은 지연시간
• 비용 효율적인 스트리밍
• 폭 넓은 호완성

단점

• 보안 취약
• 다국어 지원 및 광고 삽입
• 고정된 비트레이트 (CBR)에 최적화

---

과정

HandShake

• 클라이언트가 서버로 3개의 Chnuk인 C0,C1,C2를 보낸다.
• 이후 서버는 클라이언트에게 S0,S1,S2를 보낸 후 HandShake 과정을 끝낸다.
• C0/S0: 프로토콜 버전을 확인.
• C1/S1: 각자의 타임스탬프와 임의의 데이터를 교환하여 서로의 존재와 연결 상태를 확인.
• C2/S2: 서로의 데이터를 응답하여 핸드셰이크가 무결하게 이루어졌는지 확인.

Connect

• 클라이언트와 서버가 AMF(Action Message Format) 언어로 코딩된 대화를 교환하는 연결 단계
• Chunk 단위로 fragmentation되어 보내진다.
• RTMP 연결은 multiplex 될 수 있으므로, 각각의 스트림을 구분하기 위해 chunk stream ID를 이용
• chunk 포맷은 다음과 같으며 각각의 요소가 가변적인 크기를 갖는다.

 

Basic Header

Basic Header는 1~3bytes까지 존재하며 RTMP Chunk Header에 반드시 포함되며
Type 1(a) / Type 2(b) / Type 3(c)로 구성되어 있다.

• fmt: Chunk format, Message Header의 타입을 결정
• cs id: 앞에서 설명한 Chunk Stream ID이다.

Message Header

다음에 오는 Message Header는 위의 fmt에 따라 Type 0(a) / Type 1(b) / Type 2(c) / Type 3으로 나뉜다.

Message Types

• Type 0 
  • 11 byte
  • chunk stream의 시작 혹은 seek에 의해 timestamp가 뒤로 갔을 때 사용된다.
• Type 1 
  • 7 byte
  • 이전 message와 message stream ID가 같으며, chunk size가 변하는 경우에 사용.
• Type 2 
  • 3 byte
  • 이전 message와 message stream ID가 같으며, chunk size가 일정한 message에 사용.
• Type 3 
  • 0 byte
  • 하나의 message가 여러 개의 chunk로 나눠진 경우 가장 앞의 chunk만 message header를 붙인다
  • 이후의 chunk들은 Type 3로 전달.

Common Header Fields

• timestamp 
  • 24 bit
  • Absolute timestamp, 16777215 (0xFFFFFF) 이상일 때는 0xFFFFFF로 기록
  • 실제 데이터는 Extended timestamp에 기록.

•  timestamp delta 
  • 24 bit
  • 이전 chunk의 timestamp와의 차이. 16777215 (0xFFFFFF) 이상일 때는 0xFFFFFF로 기록
  • 실제 데이터는 Extended timestamp에 기록.
•  message length
  • 24 bit
  • Message의 길이
  • 일반적으로 Message가 여러 개의 chunk로 나눠지기 때문에 마지막 chunk까지의 chunk payload 크기를 모두 합친 값.
• message type id
  • 8 bit
  • message의 type
•  message stream id
  • 32 bit
  • Message Stream ID. Multiplexing을 하지 않는 이상 하나의 chunk stream id 안에서 message stream id는 같다
  • 따라서 type 0 message는 연결된 이후 한번만 보낸다.

Extended timestamp

• Timestamp에 기록해야 하는 숫자가 16777215 (0xFFFFFF) 이상일 때
• 더 많은 bit (32bit)를 이용하여 timestamp를 기록하기 위한 영역.
• message Header가 Type 0 / Type 1 / Type 2의 timestamp영역이 0xFFFFFF인 경우에만 존재.

Chunk Data

• 실질적인 데이터 영역
• Message Header의 Message Length가 Chunk Data 사이즈보다 큰 경우 데이터는 쪼개져서 들어온다.

---

HLS

정의

2009년 애플에서 개발한 HTTP Live Streaming 프로토콜로 HTTP 기반의 단방향 미디어 스트리밍 프로토콜이다.

목표

기존의 RTMP는 고정된 비트레이트로 콘텐츠를 스트리밍하기 때문에 호환성이 높은 HTTP를 기반으로
가변 비트레이트를 최적화하여 안정적이고 효율적인 수단을 제공하는 것을 목표로한다. 

현재 점유율을 봐도 HLS로 많이 전향하는 추세인 것 같다.

특징

• TCP 기반 , HTTP 기반 프로토콜
• ABR
• H.264, H.265 인코딩 사용
• 미디어 세그먼트와 플레이리스트 
• 광범위한 지원
• 보안과 암호화
• Lazy Loading

장점

• 높은 접근성과 넓은 호환성
  • HTTP 기반이라 방화벽 문제가 없고 다양한 장치에 스트리밍이 가능하다.
• ABR
  • Adaptive Bitrate Streaming
  • 스트리밍이 끊김없이 이루어질 수 있도록 네트워크 상태가 안좋으면 낮은 해상도, 좋으면
    고해상도로 자동으로 비트레이트를 조절
• 보안성
  • DRM을 통해 콘텐츠 보호와 AES-128 암호화 방식을 지원하여 불법 복제를 방지하고 보안을 강화한다.

단점

• 높은 지연 시간
  • HLS은 실제 재생하기 전까지 세그먼트를 가져오지 않으므로 대기 시간이 길어진다.

---

HLS의 Playlist

정의

HLS의 플레이리스트는 재생할 미디어에 관한 접근 가능한 정보 및 상태가 들어있는 파일을 말한다.

종류

• Media Playlist
• Multivariant Playlist

두 파일 모두 Descriptive Tag와 URL을 포함한 UTF-8 텍스트 파일이다.

 

Media Playlist

정의

특정 비트레이트와 해상도를 가진 개별 스트림의 미디어 세그먼트 목록을 제공

 

특징

• 네트워크 상황에 따라 변동하지 않는 고정 품질의 스트리밍에 사용
• 각 미디어 세그먼트의 URL, 길이, 재생 순서가 포함되어 있어, 특정 품질의 비디오/오디오 데이터 조각을 순서대로 다운로드하여 재생할 수 있도록 제공

💡 미디어 세그먼트란?

미디어 세그먼트는 스트리밍 콘텐츠를 일정한 길이로 나눈 작은 비디오 및 오디오 데이터 조각이며
미디어 세그먼트는 주로 2~10초 정도의 길이로 구성되어 있다.

 

예시

형식

#EXTM3U // Format의 식별자 태그, 반드시 플레이리스트 첫번 째 줄
#EXT-X-TARGETDURATION: n초 // 모든 미디어 세그먼트가 n초 이하의 길이

#EXTINF:[duration],[<title>] // 미디어 세그먼트 길이를 선언
http: ~~ // 분활된 미디어 세그먼트에 접근할 수 있는 URL

 

Multivariant Playlist

 

정의

Variant Streams 세트를 제공하는 플레이리스트

 

특징

• ABR 제공
• 여러 개의 미디어 플레이리스트를 가리키는 URL을 포함하며, 각 플레이리스트에는 다른 해상도와 비트레이트 옵션이 들어있다.
• 네트워크 상황에 따라 화질을 자동 조정하고자 할 때 사용

💡 Variant Streams 란?

동일한 컨텐츠에 대하여 비트레이트, 해상도, 오디오 품짐등을 구분할 수 있는 여러 버전을 제공하여
ABR , 즉 네트워크 조건에 따라 다양한 스트림으로 전환을 가능케한다.

 

예시

형식

#EXTM3U // Format 식별자 태그
#EXT-X-STREAM-INF: // 각각의 Variant Stream을 정의
- BANDWIDTH: 스트림의 비트레이트(예: 300kbps, 800kbps, 1.5Mbps, 2.5Mbps)
- RESOLUTION: 스트림의 해상도(예: 640x360, 1280x720, 1920x1080, 3840x2160)
- CODECS: 스트림에 사용된 비디오 및 오디오 코덱 (H.264(avc1), AAC(mp4a) 등..)

 

 

---

M3U8이란?

정의

HLS 프로토콜에서 사용되는 위에서 언급한 플레이리스트 파일 형식이며 .m3u8 확장자를 가진다

특징

스트리밍 콘텐츠의 미디어 세그먼트 URL, 품질 옵션, 메타데이터 등을 정의하여 플레이어가 콘텐츠를 재생하는 데 필요한 정보를 제공 
기본적으로 UTF-8 인코딩을 사용하는 텍스트 파일 형식이며, 각 세그먼트의 정보를 포함한 리스트를 제공한다.

형식

#EXTM3U: 파일이 M3U 형식임을 명시.
#EXT-X-VERSION: HLS 버전을 명시.
#EXTINF: 각 세그먼트의 지속 시간.
#EXT-X-STREAM-INF: 각 스트림의 비트레이트, 해상도 등의 속성.
#EXT-X-ENDLIST: 플레이리스트의 끝을 표시(라이브 스트리밍이 아닐 경우).

---

HLS의 동작 원리

---

참고

RTMP

 

HLS (HTTP Live Streaming)

 

Using Apple’s HTTP Live Streaming (HLS) Tools | Apple Developer Documentation