Adaptive Bitrate ในแอปมือถือ — คืออะไร อัลกอริทึม และโปรโตคอล

Adaptive Bitrate คืออะไร?

Adaptive Bitrate (ABR) เป็นวิธีการสตรีมมิงเนื้อหาสื่อที่ไฟล์วิดีโอถูกเข้ารหัสเป็นหลายรูปแบบด้วยบิตเรตและความละเอียดที่แตกต่างกัน และเครื่องเล่นจะเลือกรูปแบบที่เหมาะสมโดยอัตโนมัติแบบเรียลไทม์ ผู้ใช้จะได้รับคุณภาพสูงสุดเท่าที่เป็นไปได้โดยไม่ต้องบัฟเฟอร์ตามความเร็วอินเทอร์เน็ตปัจจุบัน

ต่างจากการดาวน์โหลดแบบโปรเกรสซีฟแบบดั้งเดิม ABR ไม่จำเป็นต้องโหลดไฟล์ทั้งหมด — เครื่องเล่นจะขอ ส่วนสั้น ๆ ในคุณภาพที่ต้องการและสามารถสลับไปยังบิตเรตอื่นระหว่างส่วนต่าง ๆ ได้ ทำให้เทคโนโลยีนี้จำเป็นสำหรับแอปพลิเคชันมือถือซึ่งความเร็วเครือข่ายเปลี่ยนแปลงตลอดเวลา

ประวัติของ ABR

เทคโนโลยีสตรีมมิงแบบปรับเปลี่ยนได้ถูกนำมาใช้เชิงพาณิชย์ครั้งแรกโดย Move Networks ในปี 2006 สำหรับการออกอากาศช่อง ABC ในปี 2009 Apple ได้เปิดตัว HTTP Live Streaming (HLS) ซึ่งกลายเป็นมาตรฐาน ABR แรกที่ใช้ HTTP อย่างแพร่หลายและยังคงครองระบบนิเวศ iOS

ในปี 2012 MPEG ได้เผยแพร่มาตรฐาน MPEG-DASH (Dynamic Adaptive Streaming over HTTP) เป็นรูปแบบ ABR สากลที่ไม่ผูกติดกับผู้จำหน่ายรายใด DASH รองรับโดยแพลตฟอร์มหลักทั้งหมดและเป็นมาตรฐาน ABR เดียวที่ได้รับการรับรองโดย ISO

ABR ทำงานอย่างไร?

กระบวนการสตรีมมิง ABR เริ่มต้นในขั้นตอนการเตรียมเนื้อหา: วิดีโอต้นฉบับถูกเข้ารหัสเป็นหลายรูปแบบด้วยบิตเรตต่างกัน — ตัวอย่างเช่น 144p, 360p, 720p, 1080p และ 4K แต่ละรูปแบบถูกแบ่งเป็นส่วนที่มีระยะเวลาเท่ากัน โดยทั่วไปคือ 2, 4, 6 หรือ 10 วินาที

ไฟล์แมนิเฟสต์ ถูกสร้างขึ้นบนเซิร์ฟเวอร์เพื่ออธิบายรูปแบบที่มีอยู่ บิตเรต ความละเอียด โคเดก และลิงก์ไปยังส่วนต่าง ๆ เครื่องเล่นดาวน์โหลดแมนิเฟสต์ วิเคราะห์ และเริ่มเล่นที่บิตเรตต่ำสุดเพื่อการเริ่มต้นที่รวดเร็ว

โครงสร้างแมนิเฟสต์ ABR (MPD ของ MPEG-DASH)

<!-- MPEG-DASH MPD manifest -->
<MPD profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period>
    <AdaptationSet mimeType="video/mp4">
      <Representation id="720p" bandwidth="2800000"
                     width="1280" height="720">
        <SegmentTemplate duration="4"
                        media="seg_$Number$.m4s"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

การสลับบิตเรตแบบไดนามิก

ระหว่างการเล่น อัลกอริทึม ABR ฝั่งไคลเอ็นต์จะตรวจสอบสภาพเครือข่ายและสถานะบัฟเฟอร์อย่างต่อเนื่อง หากแบนด์วิดท์ลดลง เครื่องเล่นจะขอส่วนถัดไปด้วย บิตเรตที่ต่ำกว่า เพื่อหลีกเลี่ยงการบัฟเฟอร์ เมื่อเครือข่ายดีขึ้น บิตเรตจะเพิ่มขึ้น

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

โปรโตคอล ABR: HLS, MPEG-DASH, Smooth Streaming

โปรโตคอล ABR หลักสามโปรโตคอล ครองตลาดวิดีโอสตรีมมิง: HLS จาก Apple, MPEG-DASH เป็นมาตรฐานเปิด และ Smooth Streaming จาก Microsoft แต่ละโปรโตคอลกำหนดรูปแบบแมนิเฟสต์ วิธีการแบ่งส่วน และกลไกการเข้ารหัส

HTTP Live Streaming (HLS)

HLS เป็นโปรโตคอล ABR ที่แพร่หลายที่สุด ซึ่งรวมอยู่ใน iOS, tvOS และ Safari บน macOS รูปแบบแมนิเฟสต์ขึ้นอยู่กับเพลย์ลิสต์ M3U แบบขยาย โดยเพลย์ลิสต์หลักมีลิงก์ไปยังสตรีมรูปแบบต่าง ๆ ด้วยบิตเรตและความละเอียดที่แตกต่างกัน

แต่ละรูปแบบอ้างอิงถึงเพลย์ลิสต์สื่อของตนเองพร้อมรายการส่วนต่าง ๆ HLS รองรับ การถ่ายทอดสด ผ่านกลไกหน้าต่างเลื่อนซึ่งส่วนเก่าจะถูกลบออกและส่วนใหม่จะถูกเพิ่มเมื่อมาถึง

MPEG-DASH

MPEG-DASH เป็นมาตรฐาน ABR เดียวที่ได้รับการรับรองเป็น ISO/IEC 23009-1 ในปี 2012 ต่างจาก HLS ตรงที่ DASH ใช้แมนิเฟสต์ XML (MPD — Media Presentation Description) และไม่ผูกติดกับรูปแบบคอนเทนเนอร์เฉพาะ — รองรับ fMP4, WebM และอื่น ๆ

DASH ให้ การแบ่งส่วนที่ยืดหยุ่น: ส่วนต่าง ๆ สามารถมีระยะเวลาต่างกันภายในสตรีมเดียวกัน ซึ่งปรับสมดุลระหว่างความหน่วงและโอเวอร์เฮดของคำขอ HTTP สำหรับการถ่ายทอดสด DASH รองรับรูปแบบ SegmentTemplate

การเปรียบเทียบประสิทธิภาพของโปรโตคอล

ตามการทดสอบของ Bitmovin (2025) HLS และ DASH แสดง ประสิทธิภาพที่เทียบเคียงได้ ในด้านเวลาเริ่มต้นและความถี่ในการสลับบิตเรต HLS ให้ความหน่วงต่ำกว่าบน iOS เนื่องจากการรองรับฮาร์ดแวร์ ในขณะที่ DASH เป็นที่นิยมบน Android เนื่องจากการกำหนดค่าอัลกอริทึม ABR ที่ยืดหยุ่นกว่า

อัลกอริทึมบิตเรตแบบปรับเปลี่ยนได้

หัวใจของ ABR คืออัลกอริทึมการเลือกบิตเรตที่กำหนดว่าจะขอรูปแบบใดต่อไป มีอัลกอริทึมหลักสามตระกูล: แบบอิงปริมาณงาน แบบอิงบัฟเฟอร์ และแบบผสม แต่ละวิธีมีจุดแข็งและข้อจำกัดของตัวเอง

อัลกอริทึมแบบอิงปริมาณงาน

อัลกอริทึม แบบอิงปริมาณงาน ประมาณการแบนด์วิดท์เครือข่ายตามความเร็วในการดาวน์โหลดของส่วนก่อนหน้า อัลกอริทึมเลือกบิตเรตสูงสุดที่ไม่เกิน 80–90% ของปริมาณงานที่วัดได้ เพื่อเหลือระยะเผื่อสำหรับความผันผวน

ข้อเสียของวิธีนี้คือ ความไว ต่อการเพิ่มขึ้นของความเร็วในระยะสั้น หากเครือข่ายลดลงอย่างรุนแรงระหว่างการดาวน์โหลดส่วน ค่าประมาณปริมาณงานจะต่ำเกินไป ทำให้คุณภาพลดลงโดยไม่จำเป็น

อัลกอริทึมแบบอิงบัฟเฟอร์

อัลกอริทึม แบบอิงบัฟเฟอร์ ตัดสินใจตามการเติมของบัฟเฟอร์ของเครื่องเล่น หากบัฟเฟอร์เต็มมากกว่า 70% อัลกอริทึมจะเพิ่มบิตเรต หากบัฟเฟอร์ลดลงต่ำกว่า 20% จะลดคุณภาพลงอย่างรวดเร็วเพื่อป้องกันการบัฟเฟอร์

ข้อได้เปรียบหลักคือ ไม่มีการลดคุณภาพที่ผิดพลาด ระหว่างที่เครือข่ายลดลงในระยะสั้น เนื่องจากบัฟเฟอร์ช่วยปรับความผันผวนให้เรียบ ข้อเสียคือการตอบสนองช้าต่อการเปลี่ยนแปลงแบนด์วิดท์ที่ยาวนาน

อัลกอริทึมแบบผสมและการเรียนรู้ของเครื่อง

เครื่องเล่นสมัยใหม่เช่น ExoPlayer และ AVPlayer ใช้ อัลกอริทึมแบบผสม ที่รวมการประมาณปริมาณงานและสถานะบัฟเฟอร์ ExoPlayer ใช้อัลกอริทึม ABR เริ่มต้น DefaultTrackSelector ซึ่งพิจารณาพารามิเตอร์ทั้งสอง

ในปี 2024–2025 อัลกอริทึมแบบใช้ ML กำลังถูกนำใช้อย่างแข็งขัน โดยทำนายการเปลี่ยนแปลงเครือข่ายในอนาคตจากข้อมูลในอดีต Netflix, YouTube และ Twitch ใช้โมเดลการเรียนรู้ของเครื่องของตัวเองเพื่อปรับการเลือกบิตเรตให้เหมาะสม ซึ่งลดจำนวนการสลับลง 30–40%

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

แอปพลิเคชันมือถือ กำหนดความต้องการพิเศษแก่ ABR เนื่องจากความไม่เสถียรของเครือข่ายเซลลูลาร์ (4G/LTE, 5G) และพลังการประมวลผลที่จำกัดของอุปกรณ์ เครื่องเล่นต้องปรับตัวอย่างรวดเร็วต่อการเปลี่ยนแปลงเครือข่ายในขณะที่ลดการใช้พลังงานและการใช้ข้อมูลให้น้อยที่สุด

ตามข้อมูลของ OpenSignal (2025) ความเร็ว 4G เฉลี่ยในเขตเมืองอยู่ระหว่าง 5 ถึง 50 Mbps และขณะเคลื่อนที่อาจลดลงเหลือ 1 Mbps อัลกอริทึม ABR ต้อง สลับระหว่างบิตเรต ภายใน 1–2 ส่วนเพื่อหลีกเลี่ยงการบัฟเฟอร์เมื่อเข้าสู่อุโมงค์หรือลิฟต์

การกำหนดค่า ABR ใน ExoPlayer (Android)

val trackSelector = DefaultTrackSelector(context).apply {
    setParameters(buildUponParameters {
        setMaxVideoSizeSd()
        setAllowVideoMixedMimeTypeAdaptiveness(true)
        setPreferredVideoRoleFlags(
            roleFlags(C.ROLE_FLAG_DESCRIBES_VIDEO_AND_AUDIO)
        )
    })
}

val adaptiveTrackSelectionFactory =
    AdaptiveTrackSelection.Factory()
val player = ExoPlayer.Builder(context)
    .setTrackSelector(trackSelector)
    .setMediaSourceFactory(
        DashMediaSource.Factory(dataSourceFactory)
    )
    .build()

การปรับ ABR ให้เหมาะสมสำหรับอุปกรณ์มือถือ

สำหรับแอปพลิเคชันมือถือ การโหลดเริ่มต้นที่รวดเร็ว (เวลาถึงเฟรมแรกน้อยกว่า 2 วินาที) เป็นสิ่งสำคัญ ขอแนะนำให้เริ่มเล่นที่บิตเรตต่ำสุดที่มีแล้วค่อยเพิ่มคุณภาพเมื่อบัฟเฟอร์เต็ม — กลยุทธ์ start-low-and-rise

การใช้พลังงาน ก็สำคัญเช่นกัน: การถอดรหัสแบบเร่งด้วยฮาร์ดแวร์ควรใช้สำหรับทุกระดับบิตเรต การถอดรหัสด้วยซอฟต์แวร์สำหรับบิตเรตสูง (1080p ขึ้นไป) บนอุปกรณ์เก่าอาจทำให้เกิดความร้อนสูงเกินไปและการควบคุมประสิทธิภาพ

ABR และการวิเคราะห์ประสิทธิภาพ

เมตริกคุณภาพ ABR ที่สำคัญ: จำนวนการสลับบิตเรต เวลาถึงเฟรมแรก (TTFF) และอัตราส่วนการสลับต่อเวลาการรับชมทั้งหมด ดัชนี QoE (คุณภาพประสบการณ์) คำนวณเป็นผลรวมถ่วงน้ำหนักของบิตเรต ค่าปรับการสลับ และค่าปรับการบัฟเฟอร์

สำหรับการตรวจสอบ ABR ขอแนะนำให้เก็บวิเคราะห์จากเครื่องเล่น: บิตเรตปัจจุบัน ขนาดบัฟเฟอร์ แบนด์วิดท์ จำนวนและประเภทของการสลับ ข้อมูลนี้ช่วยให้ผู้ให้บริการเนื้อหาปรับชุดบิตเรตที่มีอยู่ให้เหมาะสมและ กำหนดค่าการแบ่งส่วน สำหรับกลุ่มผู้ชมเฉพาะของตน