HLS: 정의, 프로토콜 및 작동 원리

HLS란?

HTTP Live Streaming (HLS)는 2009년 Apple이 개발하고 iOS 3.0과 Safari에서 가 처음 소개된 미디어 스트리밍 프로토콜입니다. 2017년에는 RFC 8216을 통해 인터넷 표준으로 제안되어, 어느 플랫폼에서나 구현 가능한 개방 규격으로서의 위상을 확인받았습니다.

HLS의 주요 아이디어는 연속적인 미디어 스트림을 2–10초의 깨이밊은 세그먼트로 분할하는 것입니다. 각 세그먼트는 독립적인 파일로, 일반 HTTP 요청을 통해 다운로드할 수 있습니다. 스트림 관리는 세그먼트에 대한 참조와 정확한 재생을 위한 메타데이터를 포함한 M3U8 포멧의 텍스트 플레이리스트를 통해 수행됩니다.

적응성은 HLS의 핵심 장점입니다. 서버는 약한 연결을 위한 200 Kbps부터 4K 비디오를 위한 20+ Mbps까지 서로 다른 비트레이트로 동일한 콘텐츠의 여러 버전을 준비합니다. 클라이언트는 현재 채널 대역폭에 기반하여 적절한 비트레이트를 자동으로 선택합니다. Apple 연구(WWDC 2024)에 따르면, LL-HLS는 비트레이트 간 전환 시간을 500밀리초로 줄여 둘겨보이는 일정 없이 부드러운 품질 변경을 보장합니다.

HLS 개발 역사

첫 번째 버전 HLS(2009년)는 AAC 오디오 코덱과 H.264 비디오 코덱을 사용한 MPEG-2 TS 세그먼트만 지원했습니다. iOS 8(2014년)은 fMP4(fragmented MP4) 세그먼트 지원을 추가하여 HLS를 HEVC(H.265)를 포함한 더 현대적인 코덱과 사용할 수 있게 했습니다. iOS 11(2017년)은 HDR10과 Dolby Vision 지원을 도입했습니다. iOS 13(2019년)은 Low-Latency HLS를 도입하여 지연을 기존 6–30초에서 2–6초로 줄였습니다.

2023년, Apple은 AV1 및 EVC(Essential Video Coding) 코덱에 대한 지원으로 HLS를 확장하고, Content Steering(최적의 라운드 백런스를 위해 CDN 서버 간에 클라이언트를 동적으로 재지정하는 메커니즘)을 도입했습니다. Content Steering은 서버가 재생을 중단하지 않고 클라이언트를 가장 가까운 또는 가장 부하가 적은 CDN 노드로 재지정하면서 세그먼트 URL을 실시간으로 변경할 수 있습니다.

HLS의 작동 원리

HLS 아키텍쳐는 서버 측(원본 서버 + 인코더), 봰포 네트워크(CDN), 그리고 클라이언트 측(HLS 지원 플레이어)의 세 가지 주요 구성 요소로 구성됩니다. 비디오 캡처부터 사용자 기기에서의 재생까지의 전체 과정은 여러 순차적인 단계를 포함하며, 각 단계는 스트리밍 품질에 중요합니다.

인코딩 및 세그먼테이션

원본 비디오는 먼저 서로 다른 비트레이트와 해상도의 여러 변체로 인코딩됩니다. FFmpeg이나 AWS Elemental MediaConvert와 같은 전문 인코더는 240p(400 Kbps)부터 4K(40 Mbps)까지 동시에 4–12개의 스트림 변체를 생성합니다. 각 변체는 동일한 길이의 세그먼트로 나누어지며, 일반적으로 LL-HLS의 경우 2–6초, 기존 HLS의 경우 6–10초입니다.

각 변체에 대해 모든 세그먼트의 URL과 길이를 포함한 변체 플레이리스트가 생성됩니다. 추가로 모든 변체를 결합하고 각 변체에 대한 정보(해상도, 비트레이트, 코덱, 오디오 트랙)를 포함한 마스터 플레이리스트가 생성됩니다. 클라이언트는 먼저 마스터 플레이리스트를 로드한 다음, 연겱 속도 분석에 기반하여 적절한 변체를 선택합니다.

CDN을 통한 전달

세그먼트와 플레이리스트는 사용자와 지리적으로 근처에 위치한 CDN 서버에 캐시됩니다. 전달에 표준 HTTP 프로토콜을 사용하면 HLS에 중요한 이점을 제공합니다: HTTP를 지원하는 모든 CDN, 로드 밸런서 또는 프록시 서버가 추가 설정 없이 HLS와 작동합니다. 이는 HLS를 전문 서버가 필요한 RTMP나 WebRTC 같은 실시간 프로토콜과 차별화합니다.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

클라이언트 측은 적응 비트레이트 알고리즘(ABR)을 사용합니다. HLS 플레이어는 마스터 플레이리스트를 로드하고, 사용 가능한 변체를 분석하여 가장 적합한 비트레이트로 재생을 시작합니다. 재생 중에 플레이어는 지속적으로 세그먼트 다운로드 속도와 버퍼 채우기 수준을 모니터링하며, 더 높거나 더 낮은 비트레이트로 전환할 것을 결정합니다. 현대 ABR 알고리즘은 네트워크 속도만 아니라 버퍼 크기, 콘텐츠 유형 그리고 기기의 전력 소비까지 고려합니다.

HLS 스트림 구조: 플레이리스트와 세그먼트

인코딩과 봰포를 올바르게 설정하고 재생 문제를 디버깅하려면 HLS 스트림의 구조를 이해하는 것이 필수적입니다. 각 HLS 스트림은 두 레벨의 플레이리스트와 엄격한 계층으로 구성된 수많은 미디어 세그먼트로 구성됩니다.

마스터 플레이리스트

마스터 플레이리스트는 HLS 플레이어의 입구 점입니다. .m3u8 확장자의 파일은 모든 스트림 변체와 그 특성에 대한 참조를 포함합니다. 플레이어는 먼저 이 파일을 로드하고, 비트레이트와 해상도에 대한 정보를 기반으로 어느 변체를 선택할지 초기 결정을 낵니다. 마스터 플레이리스트는 대체 오디오 트랙, 자막 그리고 빠른 검색을 위한 I-프레임 플레이리스트에 대한 참조도 포함할 수 있습니다.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

미디어 플레이리스트

미디어 플레이리스트는 하나의 스트림 변체에 대한 실제 세그먼트 목록을 포함합니다. 각 세그먼트는 길이와 URI로 지정됩니다. 미디어 플레이리스트는 정적(VOD의 경우 — 모든 세그먼트의 완전한 목록) 또는 동적으로 업데이트되는(라이브 방송의 경우 — 고온 세그먼트가 제거되고 새로운 것이 추가됨) 것이 가능합니다.

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

세그먼트 포멧

HLS는 두 가지 주요 미디어 세그먼트 포멧을 지원합니다: MPEG-2 Transport Stream (.ts) 그리고 Fragmented MP4 (.m4s 또는 .mp4). MPEG-2 TS는 원래 HLS 포멧으로 최대 호환성을 제공합니다. fMP4는 HDR, HEVC 및 더 효율적인 압축을 지원하는 더 현대적인 포멧입니다. Apple은 iOS 10 및 macOS Sierra부터 시작하는 모든 새 프로젝트에 fMP4를 권장합니다.

추가 HLS 스트림 요소로는 빠른 검색을 위한 I-프레임 플레이리스트, 자막과 광고 마커를 동기화하기 위한 ID3 메타데이터, 그리고 분석 서버에 시청 정보를 전송하기 위한 Session Data가 있습니다. 이러한 요소들은 모두 선택사항이지만, 이들을 사용하면 사용자 경험의 품질이 향상됩니다.

HLS의 장점과 단점

HLS는 여러 아키텍쳐적 장점 덕분에 비디오 스트리밍 시장을 지배하지만, 특정 프로젝트를 위해 프로토콜을 선택할 때 고려해야 할 제한 사항도 있습니다. HLS를 대체 비디오 전달 프로토콜과 비교해 보겠습니다.

주요 장점은 내장 AVPlayer를 통해 모든 Apple 기기(iPhone, iPad, Apple TV, Mac)에서 네이티브 지원된다는 점입니다. 이로 인해 HLS는 iOS/macOS 애플리케이션의 사실상 표준이 되었습니다. 또한, 전달에 표준 HTTP를 사용하면 추가 설정 없이 어느 CDN 및 프록시 서버에서나 콘텐츠를 캐시할 수 있어 전달 인프라를 현저히 간소화합니다.

HLS의 단점으로는 라이브 방송에서 RTMP나 WebRTC에 비해 더 높은 지연을 들수 있습니다. LL-HLS에서도 최소 지연은 2–6초로, 실시간 대화형 시나리오에서는 헉당된 수준입니다. 또한 HLS는 서버에 더 많은 파일을 생성하며(각 세그먼트가 별도 파일), 대량의 동시 스트림이 있을 때 파일 시스템에 부하를 줄 수 있습니다.

모바일 애플리케이션에서의 HLS

모바일 애플리케이션으로의 HLS 통합은 플랫폼에 따라 다릅니다. iOS와 macOS에서는 HLS가 AVFoundation과 AVPlayer를 통해 운영체제 레벨에서 지원되어, 하드웨어 가속 디코딩과 최소 전력 소비를 제공합니다. Android에서는 HLS가 내장 MediaPlayer에서 지원되지 않지만, Google의 공식 미디어 플레이어인 ExoPlayer를 통해 사용할 수 있습니다.

AVPlayer를 통한 iOS에서의 HLS

Apple 플랫폼에서는 AVPlayer의 내장 지원 덕분에 HLS 재생이 가능한 한 간단합니다. 마스터 플레이리스트 URL로 AVPlayer를 생성하면 된 시스템이 자동으로 p 적응 비트레이트 전환, 오디오 트랙 선택 및 자막 처리를 처리합니다. 개발자는 AVPlayerItem과 AVAssetResourceLoader를 통해 재생을 완전히 제어할 수 있습니다.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

ExoPlayer를 통한 Android에서의 HLS

Android에서는 별도의 확장 모듈을 통해 HLS를 지원하는 ExoPlayer가 사용됩니다. ExoPlayer는 HLS 스트림을 더 세밀하게 제어할 수 있으며, 비트레이트 선택을 관리하고, 버퍼링을 구성하고, 세그먼트 로딩 오류를 개별적으로 처리할 수 있습니다. LL-HLS에는 ExoPlayer 버전 2.14.0 이상이 필요합니다.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

모바일 네트워크에 대한 HLS 최적화

모바일 애플리케이션은 셀룰러 네트워크의 불안정성과 트래픽 제한으로 인해 HLS 구성에 특별한 접근법이 필요합니다. 주요 권장 사항으로는 네트워크 유형(Wi-Fi 또는 셀룸러)에 기반한 초기 비트레이트 설정, 더 빠른 적응을 위한 짧은 세그먼트 길이(2–4초) 사용, Wi-Fi로 전환할 때 버퍼 사전 로드, 그리고 약한 신호에서 오디오 트랙 우선순위 부여가 있습니다.

Apple HLS Authoring Specification for Apple Devices (2024)에서는 모바일 기기에 대해 권장되는 세그먼트 크기는 최대 6초이고 최소 4개의 비트레이트 변체입니다. 모바일 네트워크에서 트래픽을 절약하기 위해 서버는 Cache-Control HTTP 헤더를 사용하여 세그먼트를 전달해야 하며, 이를 통해 통신 사업자의 중간 프록시 서버에서 콘텐츠를 캐시할 수 있습니다.