HLS: giao thức và nguyên lý hoạt động

HLS là gì?

HTTP Live Streaming (HLS) là giao thức truyền tải đa phương tiện được Apple phát triển vào năm 2009 và lần đầu tiên được giới thiệu trong iOS 3.0 và Safari. Năm 2017, giao thức này đã được đề xuất như một tiêu chuẩn Internet thông qua RFC 8216, xác nhận vị thế của nó như một đặc tả mở có sẵn để triển khai trên bất kỳ nền tảng nào.

Ý tưởng chính của HLS là chia một luồng đa phương tiện liên tục thành các đoạn ngắn có độ dài 2–10 giây. Mỗi đoạn là một tệp độc lập có thể được tải xuống qua một yêu cầu HTTP thông thường. Việc quản lý luồng được thực hiện thông qua danh sách phát văn bản ở định dạng M3U8, chứa các tham chiếu đến các đoạn và siêu dữ liệu để phát lại chính xác.

Tính thích ứng là lợi thế chính của HLS. Máy chủ chuẩn bị nhiều phiên bản của cùng một nội dung ở các tốc độ bit khác nhau — từ 200 Kbps cho kết nối yếu đến hơn 20 Mbps cho video 4K. Máy khách tự động chọn tốc độ bit phù hợp dựa trên băng thông kênh hiện tại. Theo nghiên cứu của Apple (WWDC 2024), LL-HLS giảm thời gian chuyển đổi giữa các tốc độ bit xuống còn 500 mili giây, đảm bảo chuyển đổi chất lượng mượt mà mà không có độ dừng đáng chú ý.

Lịch sử phát triển HLS

Phiên bản đầu tiên của HLS (2009) chỉ hỗ trợ các đoạn MPEG-2 TS với bộ giải mã âm thanh AAC và bộ giải mã video H.264. iOS 8 (2014) đã thêm hỗ trợ cho các đoạn fMP4 (fragmented MP4), cho phép sử dụng HLS với các bộ giải mã hiện đại hơn, bao gồm HEVC (H.265). iOS 11 (2017) giới thiệu hỗ trợ HDR10 và Dolby Vision. iOS 13 (2019) giới thiệu Low-Latency HLS, giảm độ trễ từ 6–30 giây truyền thống xuống còn 2–6 giây.

Năm 2023, Apple đã mở rộng HLS với hỗ trợ cho các bộ giải mã AV1 và EVC (Essential Video Coding), và giới thiệu Content Steering — một cơ chế định hướng lại động khách hàng giữa các máy chủ CDN để cân bằng tải tối ưu. Content Steering cho phép máy chủ thay đổi URL đoạn trực tiếp, chuyển hướng khách hàng đến nút CDN gần nhất hoặc ít tải nhất mà không làm gián đoạn phát lại.

HLS hoạt động như thế nào?

Kiến trúc HLS bao gồm ba thành phần chính: phía máy chủ (máy chủ gốc + bộ mã hóa), mạng phân phối (CDN) và phía máy khách (trình phát hỗ trợ HLS). Toàn bộ quá trình — từ thu video đến phát lại trên thiết bị của người dùng — bao gồm nhiều giai đoạn tuần tự, mỗi giai đoạn đều quan trọng đối với chất lượng streaming.

Mã hóa và phân đoạn

Video nguồn trước tiên được mã hóa thành nhiều biến thể ở các tốc độ bit và độ phân giải khác nhau. Các bộ mã hóa chuyên nghiệp, như FFmpeg hoặc AWS Elemental MediaConvert, đồng thời tạo ra 4–12 biến thể luồng: từ 240p (400 Kbps) đến 4K (40 Mbps). Mỗi biến thể được chia thành các đoạn có độ dài bằng nhau, thường là 2–6 giây cho LL-HLS hoặc 6–10 giây cho HLS truyền thống.

Cho mỗi biến thể, một danh sách phát biến thể (variant playlist) được tạo ra chứa URL của tất cả các đoạn và độ dài của chúng. Ngoài ra, một danh sách phát chính (master playlist) được tạo ra kết hợp tất cả các biến thể và chứa thông tin về mỗi biến thể: độ phân giải, tốc độ bit, bộ giải mã và rãnh âm thanh. Máy khách tải danh sách phát chính trước, sau đó chọn biến thể phù hợp dựa trên phân tích tốc độ kết nối.

Phân phối qua CDN

Các đoạn và danh sách phát được lưu trong bộ nhớ đệm trên các máy chủ CDN đặt gần về mặt địa lý với người dùng. Việc sử dụng giao thức HTTP tiêu chuẩn để phân phối mang lại cho HLS một lợi thế quan trọng: bất kỳ CDN, bộ cân bằng tải hoặc máy chủ proxy nào hỗ trợ HTTP đều có thể làm việc với HLS mà không cần cấu hình thêm. Điều này phân biệt HLS với các giao thức thời gian thực như RTMP hoặc WebRTC, yêu cầu các máy chủ chuyên dụng.

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

Phía máy khách sử dụng thuật toán tốc độ bit thích ứng (ABR). Trình phát HLS tải danh sách phát chính, phân tích các biến thể có sẵn và bắt đầu phát ở tốc độ bit phù hợp nhất. Trong quá trình phát, trình phát liên tục giám sát tốc độ tải đoạn và mức đệm, quyết định có chuyển sang tốc độ bit cao hơn hoặc thấp hơn hay không. Các thuật toán ABR hiện đại xem xét không chỉ tốc độ mạng mà còn kích thước bộ đệm, loại nội dung và thậm chí cả mức tiêu thụ điện của thiết bị.

Cấu trúc luồng HLS: danh sách phát và đoạn

Hiểu cấu trúc của luồng HLS là cần thiết để cấu hình chính xác việc mã hóa, phân phối và gỡ lỗi các vấn đề phát lại. Mỗi luồng HLS bao gồm hai cấp danh sách phát và nhiều đoạn phương tiện được tổ chức trong một hệ thống phân cấp nghiêm ngặt.

Danh sách phát chính (Master Playlist)

Danh sách phát chính là điểm vào cho trình phát HLS. Tệp có phần mở rộng .m3u8 chứa các tham chiếu đến tất cả các biến thể luồng và đặc điểm của chúng. Trình phát tải tệp này trước và dựa trên thông tin về tốc độ bit và độ phân giải, đưa ra quyết định ban đầu về biến thể nào sẽ chọn. Danh sách phát chính cũng có thể chứa các tham chiếu đến các rãnh âm thanh thay thế, phụ đề và danh sách phát I-Frame để tìm kiếm nhanh.

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

Danh sách phát phương tiện (Media Playlist)

Danh sách phát phương tiện chứa danh sách thực tế các đoạn cho một biến thể luồng. Mỗi đoạn được chỉ định với độ dài và URI của nó. Danh sách phát phương tiện có thể tĩnh (cho VOD — danh sách đầy đủ tất cả các đoạn) hoặc được cập nhật động (cho phát sóng trực tiếp — các đoạn cũ bị xóa, các đoạn mới được thêm vào).

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

Định dạng đoạn

HLS hỗ trợ hai định dạng đoạn phương tiện chính: MPEG-2 Transport Stream (.ts) và Fragmented MP4 (.m4s hoặc .mp4). MPEG-2 TS là định dạng HLS gốc, cung cấp khả năng tương thích tối đa. fMP4 là định dạng hiện đại hơn hỗ trợ HDR, HEVC và nén hiệu quả hơn. Apple khuyến nghị sử dụng fMP4 cho tất cả các dự án mới bắt đầu từ iOS 10 và macOS Sierra.

Các yếu tố bổ sung của luồng HLS bao gồm danh sách phát I-Frame để tìm kiếm nhanh, siêu dữ liệu ID3 để đồng bộ phụ đề và đánh dấu quảng cáo, và Dữ liệu phiên (Session Data) để truyền thông tin xem đến máy chủ phân tích. Tất cả các yếu tố này là tùy chọn, nhưng việc sử dụng chúng cải thiện chất lượng trải nghiệm người dùng.

Ưu điểm và nhược điểm của HLS

HLS thống trị thị trường streaming video nhờ một số lợi thế kiến trúc, nhưng cũng có những hạn chế cần xem xét khi chọn giao thức cho một dự án cụ thể. Hãy so sánh HLS với các giao thức phân phối video thay thế.

Ưu điểm chính của HLS là hỗ trợ gốc trên tất cả các thiết bị Apple (iPhone, iPad, Apple TV, Mac) thông qua AVPlayer tích hợp sẵn. Điều này làm cho HLS trở thành tiêu chuẩn thực tế cho các ứng dụng iOS/macOS. Ngoài ra, việc sử dụng HTTP tiêu chuẩn để phân phối cho phép lưu nội dung vào bộ nhớ đệm trên bất kỳ CDN và máy chủ proxy nào mà không cần cấu hình thêm, giúp đơn giản hóa đáng kể cơ sở hạ tầng phân phối.

Nhược điểm của HLS bao gồm độ trễ cao hơn so với RTMP hoặc WebRTC cho phát sóng trực tiếp. Ngay cả với LL-HLS, độ trễ tối thiểu là 2–6 giây, không thể chấp nhận cho các kịch bản tương tác thời gian thực. Ngoài ra, HLS tạo ra nhiều tệp hơn trên máy chủ (mỗi đoạn là một tệp riêng biệt), có thể gây tải cho hệ thống tệp khi có số lượng lớn các luồng đồng thời.

HLS trong ứng dụng di động

Việc tích hợp HLS vào các ứng dụng di động khác nhau tùy thuộc vào nền tảng. Trên iOS và macOS, HLS được hỗ trợ ở cấp hệ điều hành thông qua AVFoundation và AVPlayer, cung cấp khả năng giải mã tăng tốc phần cứng và mức tiêu thụ điện tối thiểu. Trên Android, HLS không được hỗ trợ bởi MediaPlayer tích hợp sẵn nhưng có sẵn thông qua ExoPlayer — trình phát đa phương tiện chính thức của Google.

HLS trên iOS qua AVPlayer

Trên nền tảng Apple, việc phát HLS rất đơn giản nhờ hỗ trợ tích hợp sẵn trong AVPlayer. Chỉ cần tạo AVPlayer với URL danh sách phát chính, hệ thống sẽ tự động xử lý việc chuyển đổi tốc độ bit thích ứng, chọn rãnh âm thanh và xử lý phụ đề. Nhà phát triển cũng có toàn quyền kiểm soát phát lại thông qua AVPlayerItem và 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 trên Android qua ExoPlayer

Đối với Android, ExoPlayer được sử dụng, hỗ trợ HLS thông qua một mô-đun mở rộng riêng biệt. ExoPlayer cung cấp khả năng kiểm soát chi tiết hơn đối với luồng HLS: có thể quản lý việc chọn tốc độ bit, cấu hình bộ đệm và xử lý lỗi tải đoạn riêng lẻ. LL-HLS yêu cầu ExoPlayer phiên bản 2.14.0 trở lên.

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

Tối ưu hóa HLS cho mạng di động

Các ứng dụng di động yêu cầu một cách tiếp cận đặc biệt đối với cấu hình HLS do sự bất ổn của mạng di động và giới hạn lưu lượng. Các khuyến nghị chính bao gồm: cấu hình tốc độ bit ban đầu dựa trên loại mạng (Wi-Fi hoặc di động), sử dụng độ dài đoạn ngắn hơn (2–4 giây) để thích ứng nhanh hơn, tải trước bộ đệm khi chuyển sang Wi-Fi và ưu tiên rãnh âm thanh khi tín hiệu yếu.

Apple trong tài liệu HLS Authoring Specification for Apple Devices (2024) khuyến nghị sử dụng kích thước đoạn không quá 6 giây cho thiết bị di động và ít nhất 4 biến thể tốc độ bit. Để tiết kiệm lưu lượng trên mạng di động, máy chủ nên phân phối các đoạn với tiêu đề HTTP Cache-Control, cho phép lưu nội dung vào bộ nhớ đệm trên các máy chủ proxy trung gian của nhà khai thác viễn thông.