HLS: มันคืออะใร โปรโตคอลและหลักการทำงาน

HLS คืออะใร

HTTP Live Streaming (HLS) เป็นโปรโตคอลการสตรีมมัลติมีเดียที่พัฒนาโดย Apple ในปี 2009 และเปิดตัวครั้งแรกใน iOS 3.0 และ Safari ในปี 2017 โปรโตคอลได้รับการเสนอเป็นมาตรฐานอินเทอร์เน็ตผ่าน RFC 8216 ซึ่งยืนยันสถานะของมันในฐานะข้อกำหนดแบบเปิดที่สามารถนำไปใช้บนแพลตฟอร์มใดๆ ได้

แนวคิดหลักของ HLS คือการ แยก สตรีมมัลติมีเดียที่ต่อเนื่องออกเป็นเซกเมนต์สั้น ๆ 2–10 วินาที แต่ละเซกเมนต์เป็นไฟล์อิสระที่สามารถดาวน์โหลดผ่านคำขอ HTTP ทั่วไป การจัดการสตรีมดำเนินการผ่านรายการเล่นข้อความในรูปแบบ M3U8 ซึ่งมีการอ้างอิงถึงเซกเมนต์และเมตาดาตาสำหรับการเล่นที่ถูกต้อง

การปรับตัว เป็นข้อดีหลักของ HLS เซิร์ฟเตรียมเนื้อหาเดียวกันหลายรุ่นที่บิตเรตต่างๆ กัน ตั้งแต่ 200 Kbps สำหรับการเชื่อมต่อที่อ่อนแรงไปถึง 20+ Mbps สำหรับวิดีโอ 4K ไคลเอนต์เลือกบิตเรตที่เหมาะสมโดยอัตโนมัติตามแบนด์วิดธ์ช่องปัจจุบัน ตามงานวิจัยของ Apple (WWDC 2024) LL-HLS ลดเวลาการสลับระหว่างบิตเรตเหลือ 500 มิลลิวินาที ทำให้การเปลี่ยนคุณภาพเป็นไปอย่างราบรื่นโดยไม่มีการหยุดชัดเจน

ประวัติการพัฒนา HLS

รุ่นแรก ของ HLS (2009) รองรับเฉพาะเซกเมนต์ MPEG-2 TS กับโค้ดเสียง AAC และโค้ดวิดีโอ H.264 ใน 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 ขยาย HLS ด้วยการ รองรับ โค้ด AV1 และ EVC (Essential Video Coding) และเปิดตัว Content Steering กลไกการเปลี่ยนทิศทางไคลเอนต์แบบไดนามิกระหว่างเซิร์ฟเวอร์ CDN เพื่อการจัดเชื่อมภารที่เหมาะสม Content Steering ช่วยให้เซิร์ฟเวอร์สามารถเปลี่ยน URL ของเซกเมนต์ได้ทันที โดยเปลี่ยนทิศทางไคลเอนต์ไปยังโนด CDN ที่ใกล้ที่สุดหรือมีภารน้อยที่สุดโดยไม่ขัดจังการเล่น

HLS ทำงานอย่างไร

สถาปัตยกรรม HLS ประกอบด้วยส่วนประกอบหลักสามส่วน: ฝ่ายเซิร์ฟเวอร์ (origin-server + ตัวเข้ารหัส) เครือข่ายแจจจำหน่าย (CDN) และฝ่ายไคลเอนต์ (ตัวเล่นที่รองรับ HLS) กระบวนการทั้งหมด ตั้งแต่การจับภาพวิดีโอจนถึงการเล่นบนอุปกรณ์ของผู้ใช้ ประกอบด้วยหลายขั้นตอนต่อเนื่อง แต่ละขั้นตอนมีความสำคัญต่อคุณภาพของการสตรีม

การเข้ารหัสและการแยกเซกเมนต์

วิดีโอต้นฉบับจะถูก เข้ารหัส เป็นหลายรูปแบบที่มีบิตเรตและความละเอียดต่างๆ กัน ตัวเข้ารหัสอาชีพ เช่น FFmpeg หรือ AWS Elemental MediaConvert จะสร้างสตรีมพร้อมกัน 4–12 รูปแบบ ตั้งแต่ 240p (400 Kbps) ไปถึง 4K (40 Mbps) แต่ละรูปแบบจะถูกตัดเป็นเซกเมนต์ที่มีความยาวเท่ากัน โดยทั่วไป 2–6 วินาทีสำหรับ LL-HLS หรือ 6–10 วินาทีสำหรับ HLS แบบดั้งเดิม

สำหรับแต่ละรูปแบบ จะมีการสร้าง รายการเล่นรูปแบบ (variant playlist) ที่มี URL ของเซกเมนต์ทั้งหมดและความยาวของมัน นอกจากนี้ ยังมีการสร้างรายการเล่นหลัก (master playlist) ที่รวมรูปแบบทั้งหมดเข้าด้วยกันและมีข้อมูลเกี่ยวกับแต่ละรูปแบบ ความละเอียด บิตเรต โค้ดและแทร็กเสียง ไคลเอนต์จะโหลดรายการเล่นหลักก่อน แล้วเลือกรูปแบบที่เหมาะสมโดยอิงจากการวิเคราะห์ความเร็วของการเชื่อมต่อ

การจัดส่งผ่าน CDN

เซกเมนต์ และรายการเล่นจะถูกเก็บไว้ในแคชบนเซิร์ฟเวอร์ CDN ที่ตั้งอยู่ใกล้กับผู้ใช้ทางภูมิศาสตร์ การใช้โปรโตคอล HTTP มาตรฐานสำหรับการจัดส่งทำให้ HLS มีข้อดีที่สำคัญ: CDN ตัวใดๆ ตัวจัดสมดุลภาร หรือโปรกซี่เซิร์ฟเวอร์ที่รองรับ HTTP สามารถทำงานกับ 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 ประกอบด้วยรายการเล่นสองระดับและเซกเมนต์สื่อจำนวนมากที่จัดเรียงในลำดับชั้นที่เคร่งครัด

Master Playlist (รายการเล่นหลัก)

Master playlist เป็นจุดเริ่มต้นสำหรับตัวเล่น HLS ไฟล์ที่มีนามสกุล .m3u8 ประกอบด้วยการอ้างอิงไปยังทุกรูปแบบสตรีมและคุณลักษณะของมัน ตัวเล่นจะโหลดไฟล์นี้ก่อนและจากข้อมูลเกี่ยวกับบิตเรตและความละเอียด จะตัดสินใจเบื้องต้นว่าจะเลือกรูปแบบใด รายการเล่นหลักยังสามารถมีการอ้างอิงไปยังแทร็กเสียงทางเลือก คำบรรยาย และรายการเล่น I-Frame สำหรับการกรออย่างรวดเร็ว

#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 มีรายการเซกเมนต์ที่แท้จริงสำหรับหนึ่งรูปแบบสตรีม แต่ละเซกเมนต์จะระบุด้วยความยาวและ 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 แนะนำ fMP4 สำหรับโปรเจกต์ใหม่ทั้งหมดตั้งแต่ iOS 10 และ macOS Sierra

องค์ประกอบเพิ่มเติมของสตรีม HLS รวมถึง รายการเล่น I-Frame สำหรับการกรออย่างรวดเร็ว ข้อมูลเมตา ID3 สำหรับการซิงโครไนซ์คำบรรยายและเครื่องหมายโฆษณา และ Session Data สำหรับส่งข้อมูลการรับชมไปยังเซิร์ฟเวอร์วิเคราะห์ องค์ประกอบทั้งหมดนี้เป็นทางเลือก แต่การใช้งานของมันช่วยปรับปรุงคุณภาพของประสบการณ์ผู้ใช้

ข้อดีและข้อเสียของ HLS

HLS ครองตลาดสตรีมมิ่งวิดีโอด้วยข้อดีทางสถาปัตยกรรมหลายประการ แต่ก็มีข้อจำกัดที่ต้องพิจารณาเมื่อเลือกโปรโตคอลสำหรับโปรเจกต์เฉพาะ มาเปรียบเทียบ HLS กับโปรโตคอลการจัดส่งวิดีโอทางเลือกกัน

ข้อดีหลัก ของ HLS คือการรองรับแบบดั้งเดิมบนอุปกรณ์ Apple ทั้งหมด (iPhone, iPad, Apple TV, Mac) ผ่าน AVPlayer ในตัว ทำให้ HLS เป็นมาตรฐานโดยพฤตินัยสำหรับแอปพลิเคชัน iOS/macOS นอกจากนี้ การใช้ HTTP มาตรฐานสำหรับการจัดส่งช่วยให้สามารถแคชเนื้อหาบน CDN และเซิร์ฟเวอร์พร็อกซีใดๆ ได้โดยไม่ต้องกำหนดค่าเพิ่มเติม ซึ่งช่วยลดความซับซ้อนของโครงสร้างพื้นฐานการจัดส่งได้อย่างมาก

ข้อเสียของ HLS รวมถึง ความหน่วงที่สูงกว่า เมื่อเทียบกับ RTMP หรือ WebRTC สำหรับการถ่ายทอดสด แม้จะใช้ LL-HLS ความหน่วงขั้นต่ำก็ยังคงอยู่ที่ 2–6 วินาที ซึ่งไม่สามารถยอมรับได้สำหรับสถานการณ์แบบโต้ตอบตามเวลาจริง นอกจากนี้ HLS ยังสร้างไฟล์บนเซิร์ฟเวอร์มากขึ้น (แต่ละเซกเมนต์เป็นไฟล์แยกต่างหาก) ซึ่งอาจสร้างภาระให้กับระบบไฟล์เมื่อมีสตรีมพร้อมกันจำนวนมาก

HLS ในแอปพลิเคชันมือถือ

การรวม HLS เข้ากับแอปพลิเคชันมือถือแตกต่างกันไปตามแพลตฟอร์ม บน iOS และ macOS HLS ได้รับการรองรับในระดับระบบปฏิบัติการผ่าน AVFoundation และ AVPlayer ซึ่งให้การถอดรหัสแบบเร่งด้วยฮาร์ดแวร์และการใช้พลังงานน้อยที่สุด บน Android HLS ไม่ได้รับการรองรับโดย MediaPlayer ในตัว แต่สามารถใช้งานได้ผ่าน ExoPlayer — ตัวเล่นสื่ออย่างเป็นทางการของ Google

HLS บน iOS ผ่าน AVPlayer

บนแพลตฟอร์ม Apple การเล่น HLS นั้นง่ายที่สุดเท่าที่จะเป็นไปได้ด้วยการรองรับในตัวใน AVPlayer เพียงสร้าง AVPlayer ด้วย URL ของรายการเล่นหลัก ระบบจะจัดการการสลับบิตเรตแบบปรับตัว การเลือกแทร็กเสียง และการประมวลผลคำบรรยายโดยอัตโนมัติ นักพัฒนายังได้รับการควบคุมการเล่นอย่างเต็มที่ผ่าน 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()
}

HLS บน Android ผ่าน ExoPlayer

สำหรับ Android จะใช้ ExoPlayer ซึ่งรองรับ HLS ผ่านโมดูลส่วนขยายแยกต่างหาก 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 รูปแบบบิตเรต เพื่อประหยัดการรับส่งข้อมูลบนเครือข่ายมือถือ เซิร์ฟเวอร์ควรส่งเซกเมนต์ด้วยส่วนหัว HTTP Cache-Control ซึ่งช่วยให้สามารถแคชเนื้อหาบนเซิร์ฟเวอร์พร็อกซีตัวกลางของผู้ให้บริการโทรคมนาคม