HLS: ano ito, protocol at prinsipyo ng paggana

Ano ang HLS?

HTTP Live Streaming (HLS) — ay isang protocol ng streaming media na binuo ng Apple noong 2009 at unang ipinakilala sa iOS 3.0 at Safari. Noong 2017, ang protocol ay iminungkahi bilang isang pamantayan sa internet sa pamamagitan ng RFC 8216, na nagpatunay sa katayuan nito bilang isang bukas na detalye na magagamit para sa pagpapatupad sa anumang platform.

Ang pangunahing ideya ng HLS ay ang paghahati ng tuluy-tuloy na media stream sa mga maikling segment na may tagal na 2-10 segundo. Ang bawat segment ay isang independiyenteng file na maaaring ma-download sa pamamagitan ng isang ordinaryong HTTP request. Ang pamamahala ng stream ay ginagawa sa pamamagitan ng mga text playlist sa M3U8 format, na naglalaman ng mga link sa mga segment at metadata para sa kanilang tamang pag-playback.

Adaptivity — ay ang pangunahing bentahe ng HLS. Ang server ay naghahanda ng maraming bersyon ng parehong nilalaman na may iba't ibang bitrate — mula 200 Kbps para sa mahihinang koneksyon hanggang 20+ Mbps para sa 4K video. Awtomatikong pinipili ng client ang naaangkop na bitrate batay sa kasalukuyang bandwidth ng channel. Ayon sa pananaliksik ng Apple (WWDC 2024), binabawasan ng LL-HLS ang oras ng paglipat sa pagitan ng mga bitrate hanggang 500 millisecond, na tinitiyak ang maayos na pagbabago ng kalidad nang walang kapansin-pansing pag-pause.

Kasaysayan ng pag-unlad ng HLS

Ang unang bersyon ng HLS (2009) ay sumuporta lamang sa mga MPEG-2 TS segment na may AAC audio codec at H.264 video codec. Sa iOS 8 (2014), idinagdag ang suporta para sa fMP4 (fragmented MP4) segment, na nagpapahintulot sa paggamit ng HLS sa mas modernong mga codec, kabilang ang HEVC (H.265). Ipinakilala ng iOS 11 (2017) ang suporta para sa HDR10 at Dolby Vision. Ipinakilala ng iOS 13 (2019) ang Low-Latency HLS, na binabawasan ang latency mula sa tradisyunal na 6-30 segundo hanggang 2-6 segundo.

Noong 2023, pinalawak ng Apple ang HLS gamit ang suporta para sa mga codec na AV1 at EVC (Essential Video Coding), at ipinatupad din ang Content Steering — isang mekanismo ng dynamic na pag-redirect ng mga client sa pagitan ng mga CDN server para sa pinakamainam na pag-load. Ang Content Steering ay nagpapahintulot sa server na baguhin ang mga URL ng segment on the fly, na nagre-redirect sa client sa pinakamalapit o hindi gaanong na-load na CDN node nang hindi naaantala ang pag-playback.

Paano gumagana ang HLS?

Ang arkitektura ng HLS ay binubuo ng tatlong pangunahing bahagi: bahagi ng server (origin-server + encoder), network ng pamamahagi (CDN), at bahagi ng client (player na may suporta sa HLS). Ang buong proseso — mula sa pagkuha ng video hanggang sa pag-playback sa device ng gumagamit — ay may kasamang ilang sunud-sunod na yugto, na ang bawat isa ay kritikal para sa kalidad ng streaming.

Encoding at segmentation

Ang source video ay ina-encode muna sa maraming variant na may iba't ibang bitrate at resolution. Ang mga propesyonal na encoder tulad ng FFmpeg o AWS Elemental MediaConvert ay sabay-sabay na gumagawa ng 4-12 variant ng stream: mula 240p (400 Kbps) hanggang 4K (40 Mbps). Ang bawat variant ay hinahati sa mga segment ng parehong tagal, karaniwang 2-6 segundo para sa LL-HLS o 6-10 segundo para sa tradisyunal na HLS.

Para sa bawat variant, isang media playlist (variant playlist) ang nilikha na naglalaman ng mga URL ng lahat ng segment at kanilang tagal. Bukod pa rito, isang master playlist ang nilikha na pinagsasama ang lahat ng variant at naglalaman ng impormasyon tungkol sa bawat isa: resolution, bitrate, codec at audio track. Unang nagda-download ang client ng master playlist, pagkatapos ay pinipili ang naaangkop na variant batay sa pagsusuri ng bilis ng koneksyon.

Paghahatid sa pamamagitan ng CDN

Ang mga segment at playlist ay naka-cache sa mga CDN server na matatagpuan heograpikal na malapit sa mga gumagamit. Ang paggamit ng karaniwang HTTP protocol para sa paghahatid ay nagbibigay sa HLS ng isang kritikal na kalamangan: anumang CDN, load balancer o proxy server na sumusuporta sa HTTP ay gumagana sa HLS nang walang karagdagang configuration. Ito ay nagpapakilala sa HLS mula sa mga real-time protocol tulad ng RTMP o WebRTC na nangangailangan ng mga espesyal na server.

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"
])

Ang panig ng client ay gumagamit ng algorithm ng pagpili ng bitrate (ABR — Adaptive Bitrate). Ina-download ng HLS player ang master playlist, sinusuri ang mga available na variant at sinisimulan ang pag-playback sa pinakaangkop na bitrate. Sa panahon ng pag-playback, patuloy na sinusubaybayan ng player ang bilis ng pag-download ng mga segment at pagpuno ng buffer, na gumagawa ng desisyon na lumipat sa mas mataas o mas mababang bitrate. Isinasaalang-alang ng mga modernong ABR algorithm hindi lamang ang bilis ng network, kundi pati na rin ang laki ng buffer, uri ng nilalaman at maging ang konsumo ng kuryente ng device.

Istraktura ng HLS stream: mga playlist at segment

Ang pag-unawa sa istraktura ng HLS stream ay kinakailangan para sa tamang configuration ng encoding, pamamahagi at pag-debug ng mga problema sa pag-playback. Ang bawat HLS stream ay binubuo ng dalawang antas ng mga playlist at maraming media segment, na nakaayos sa isang mahigpit na hierarchy.

Master Playlist (master playlist)

Master playlist — ay ang entry point para sa HLS player. Ang file na may extension na .m3u8 ay naglalaman ng mga link sa lahat ng variant ng stream (variant streams) at kanilang mga katangian. Unang dina-download ng player ang file na ito at batay sa impormasyon tungkol sa mga bitrate at resolution, gumagawa ng paunang desisyon sa pagpili ng variant. Ang master playlist ay maaari ding maglaman ng mga link sa mga alternatibong audio track, subtitle at I-Frame playlist para sa mabilisang pag-rewind.

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

Media Playlist (media playlist)

Media playlist ay direktang naglalaman ng listahan ng mga segment para sa isang variant ng stream. Ang bawat segment ay tinukoy na may tagal at URI. Ang media playlist ay maaaring static (para sa VOD — buong listahan ng lahat ng segment) o dynamic na ina-update (para sa mga live broadcast — ang mga lumang segment ay tinatanggal, ang mga bago ay idinaragdag).

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

Mga format ng segment

Sinusuportahan ng HLS ang dalawang pangunahing format ng media segment: MPEG-2 Transport Stream (.ts) at Fragmented MP4 (.m4s o .mp4). MPEG-2 TS — ang orihinal na HLS format na nagbibigay ng maximum na compatibility. fMP4 — isang mas modernong format na sumusuporta sa HDR, HEVC at mas mahusay na compression. Inirerekomenda ng Apple ang fMP4 para sa lahat ng bagong proyekto simula sa iOS 10 at macOS Sierra.

Ang mga karagdagang elemento ng HLS stream ay kinabibilangan ng I-Frame playlist para sa mabilisang pag-rewind, ID3 metadata para sa pag-sync ng subtitle at mga marker ng advertisement, pati na rin ang Session Data para sa pagpapadala ng impormasyon ng panonood sa analytics server. Ang lahat ng elementong ito ay opsyonal, ngunit ang kanilang paggamit ay nagpapabuti sa kalidad ng karanasan ng gumagamit.

Mga kalamangan at kahinaan ng HLS

Ang HLS ay nangingibabaw sa merkado ng video streaming dahil sa isang serye ng mga arkitektural na kalamangan, ngunit mayroon ding mga limitasyon na dapat isaalang-alang kapag pumipili ng protocol para sa isang partikular na proyekto. Ikumpara natin ang HLS sa mga alternatibong protocol ng paghahatid ng video.

Ang pangunahing bentahe ng HLS — native na suporta sa lahat ng Apple device (iPhone, iPad, Apple TV, Mac) sa pamamagitan ng built-in na AVPlayer. Ginagawa nitong de facto standard ang HLS para sa iOS/macOS application. Bukod pa rito, ang paggamit ng karaniwang HTTP para sa paghahatid ay nagpapahintulot sa pag-cache ng nilalaman sa anumang CDN at proxy server nang walang karagdagang configuration, na makabuluhang nagpapasimple sa imprastraktura ng paghahatid.

Ang mga kahinaan ng HLS ay kinabibilangan ng mas mataas na latency kumpara sa RTMP o WebRTC para sa mga live broadcast. Kahit na may LL-HLS, ang minimum na latency ay 2-6 segundo, na hindi katanggap-tanggap para sa mga interactive na real-time scenario. Gumagawa rin ang HLS ng mas maraming file sa server (bawat segment ay isang hiwalay na file), na maaaring lumikha ng load sa file system sa malaking bilang ng sabay-sabay na broadcast.

HLS sa mga mobile app

Ang pagsasama ng HLS sa mga mobile app ay nag-iiba depende sa platform. Sa iOS at macOS, ang HLS ay sinusuportahan sa antas ng operating system sa pamamagitan ng AVFoundation at AVPlayer, na nagbibigay ng hardware acceleration ng decoding at minimal na konsumo ng kuryente. Sa Android, ang HLS ay hindi sinusuportahan ng built-in na MediaPlayer, ngunit available sa pamamagitan ng ExoPlayer — ang opisyal na media player mula sa Google.

HLS sa iOS sa pamamagitan ng AVPlayer

Sa platform ng Apple, ang pag-playback ng HLS ay napakasimple dahil sa built-in na suporta sa AVPlayer. Sapat na gumawa ng AVPlayer na may URL ng master playlist, at awtomatikong hahawakan ng system ang adaptive bitrate switching, pagpili ng audio track at pagproseso ng subtitle. Ang developer ay may access sa buong kontrol sa pag-playback sa pamamagitan ng AVPlayerItem at 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()
}

HLS sa Android sa pamamagitan ng ExoPlayer

Para sa Android ginagamit ang ExoPlayer, na sumusuporta sa HLS sa pamamagitan ng isang hiwalay na extension module. Ang ExoPlayer ay nagbibigay ng mas pinong kontrol sa HLS stream: ang pagpili ng bitrate ay maaaring pamahalaan, ang buffering ay maaaring i-configure at ang mga error sa pag-load ng segment ay maaaring iproseso nang isa-isa. Para sa LL-HLS kinakailangan ang ExoPlayer bersyon 2.14.0 at mas mataas.

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()

Pag-optimize ng HLS para sa mga mobile network

Ang mga mobile app ay nangangailangan ng espesyal na diskarte sa configuration ng HLS dahil sa kawalan ng katatagan ng mga cellular network at mga limitasyon sa trapiko. Ang mga pangunahing rekomendasyon ay kinabibilangan ng: pagtatakda ng paunang bitrate batay sa uri ng network (Wi-Fi o cellular), paggamit ng mas maikling tagal ng segment (2-4 segundo) para sa mas mabilis na adaptasyon, paunang pag-load ng buffer kapag lumilipat sa Wi-Fi at pagbibigay-priyoridad sa audio track sa mahinang signal.

Apple sa dokumentasyon ng HLS Authoring Specification for Apple Devices (2024) ay inirerekomenda ang paggamit ng laki ng segment na hindi hihigit sa 6 segundo para sa mga mobile device at hindi bababa sa 4 na variant ng bitrate. Para makatipid ng trapiko sa mga mobile network, ang server ay dapat maghatid ng mga segment na may HTTP header na Cache-Control, na nagpapahintulot sa pag-cache ng nilalaman sa mga intermediate proxy server ng mga telecom operator.