Distribusikan video adaptif

Pertanyaan

Gimana menyajikan video ke penonton dengan jaringan yang berbeda-beda, dan apa yang diubah saat mau menukar waktu mulai dengan kemungkinan buffering ulang?

Setelah baca ini, kamu bisa menghitung beban bandwidth dan origin dari sebuah ladder rendition, dan menjelaskan pengaruh panjang segmen serta ukuran buffer pada pengalaman menonton.

Prasyarat dan contoh

Kamu sudah paham cache dan hit rate (M06), kapasitas dan bandwidth (M01), dan manifest keluaran dari M15.03.

Sebuah kursus daring punya video 20 menit. Satu berkas MP4 1080p sebesar 1,1 GB disajikan apa adanya. Penonton di jaringan seluler 3 Mbps nggak bisa memutarnya tanpa berhenti-henti, karena bitrate 1080p sekitar 7 Mbps. Penonton di 20 Mbps menikmati hasil yang bagus, tapi tetap mengunduh lebih dari yang dipakai kalau menutup video di menit ke-2.

Mekanisme

Rendition dan ladder. Satu video dienkode di beberapa kombinasi resolusi-bitrate. Contoh ladder (angka kira-kira, tergantung codec dan konten):

| Rendition | Bitrate video | | --------- | ------------- | | 1080p | 5 Mbps | | 720p | 2,8 Mbps | | 480p | 1,4 Mbps | | 360p | 0,8 Mbps |

Segmen dan manifest. Tiap rendition dipotong jadi segmen berdurasi tetap (misalnya 4 detik), dan manifest (HLS .m3u8 atau DASH .mpd) mendaftar rendition dan URL segmennya. Segmen adalah berkas biasa, jadi CDN menyimpannya seperti gambar (M15.02). Pemutar mengunduh manifest, memilih rendition, lalu meminta segmen satu per satu.

Adaptasi dilakukan klien. Pemutar mengukur throughput unduhan segmen dan isi buffer, lalu memilih rendition segmen berikutnya. Server nggak perlu tahu. Aturannya kasar: kalau throughput terukur 3 Mbps, pilih rendition di bawahnya dengan margin, misalnya 1,4 sampai 2,8 Mbps. Naik harus hati-hati, turun harus cepat.

Panjang segmen adalah kompromi.

• Segmen pendek (2 detik): pemutar bereaksi cepat pada perubahan jaringan, dan mulai putar cepat. Tapi request lebih banyak (30 per menit per penonton), kompresi sedikit lebih boros karena tiap segmen mulai di keyframe, dan beban manifest/CDN naik.
• Segmen panjang (10 detik): request sedikit dan kompresi efisien, tapi waktu mulai lebih lama (butuh minimal satu segmen), adaptasi lambat, dan satu segmen yang macet bisa menghabiskan buffer.

Buffer dan waktu mulai. Pemutar yang mulai setelah 1 segmen terisi memulai cepat tapi gampang buffering ulang. Yang menunggu 3 segmen (12 detik) lebih tahan, tapi penonton menunggu. Banyak pemutar memulai di rendition rendah lalu naik. Itu menukar kualitas awal demi kelancaran.

Anggaran bandwidth dan origin. Egress = penonton serentak x bitrate rata-rata. 10.000 penonton serentak x 2,8 Mbps = 28 Gbps. Nggak ada origin biasa yang melayani itu langsung. Dengan CDN dan hit rate 98%, origin melayani 2% dari bytes: 0,56 Gbps. Segmen video populer sangat bisa di-cache karena semua penonton meminta segmen yang sama. Video jarang ditonton (long tail) hit rate-nya rendah, jadi origin dan storage menanggung lebih banyak.

Biaya penyimpanan. Ladder 4 rendition dengan bitrate total 10 Mbps untuk video 20 menit: 10 Mbps x 1200 detik / 8 = 1,5 GB per video. Mengalikan 100.000 video = 150 TB. Rendition tambahan menambah biaya penyimpanan dan transcoding, dan manfaatnya tergantung audiens: kalau 95% penonton ada di jaringan cepat, rendition 360p jarang dipakai.

Saat rancangan ini gagal

• Ladder nggak cocok dengan audiens. Rendition terendah masih 2,5 Mbps, sementara banyak penonton di 1 Mbps. Mereka buffering terus. Lihat distribusi throughput nyata sebelum menentukan ladder.
• Cold start di CDN. Rilis kursus baru diputar ribuan orang di menit yang sama, segmen belum ada di cache, dan origin menerima ribuan request untuk segmen yang sama. Gabungkan request, atau panaskan segmen awal.
• Manifest yang di-cache terlalu lama. Untuk video biasa (VOD) manifest stabil dan boleh di-cache lama. Salah mengganti manifest tanpa URL berversi membuat pemutar meminta segmen yang sudah nggak ada.
• Lonjakan tak terduga. Satu video viral membuat egress 10x. Biaya CDN naik seiring bytes, bukan seiring jumlah video. Pasang batas biaya dan alert.
• Pemutar salah memilih. Estimasi throughput dari satu segmen kecil menyesatkan. Rata-rata bergerak dan margin keamanan mengurangi osilasi.

Latihan

Platform kursus punya 3.000 penonton serentak di jam puncak. Ladder: 720p 2,8 Mbps, 480p 1,4 Mbps, 360p 0,8 Mbps. Distribusi penonton: 40% di 720p, 40% di 480p, 20% di 360p. Hit rate CDN 97%. Hitung egress puncak dan beban origin, lalu putuskan antara segmen 2 detik dan 6 detik untuk penonton seluler.

Lihat pembahasan+

Bitrate rata-rata: 0,4 x 2,8 + 0,4 x 1,4 + 0,2 x 0,8 = 1,12 + 0,56 + 0,16 = 1,84 Mbps.

Egress puncak: 3.000 x 1,84 = 5.520 Mbps, sekitar 5,5 Gbps. Beban origin dengan hit rate 97%: 3% x 5,5 Gbps = sekitar 166 Mbps, atau 21 MB per detik. Itu terkelola untuk satu storage atau origin shield, tapi perlu dicek saat video baru dirilis dan cache masih kosong. Hit rate 97% sebagai asumsi: untuk katalog dengan long tail, angkanya bisa jauh lebih rendah.

Segmen: untuk seluler yang jaringannya naik-turun, pilih 4 detik sebagai kompromi, atau 2 detik kalau waktu mulai dan reaksi cepat lebih penting dan jumlah request masih tertampung (3.000 penonton x 0,5 request per detik = 1.500 request per detik di CDN). 6 detik masih masuk akal buat desktop stabil. Jawaban yang bagus menyebut kompromi: segmen pendek menambah request dan overhead keyframe, segmen panjang memperlambat mulai dan adaptasi.

Terkait

• Sebelumnya: Proses video secara asinkron (M15.03) menghasilkan rendition dan manifest yang disajikan di sini.
• Sajikan gambar melalui CDN (M15.02) membahas key cache dan invalidasi yang berlaku sama untuk segmen.
• Selanjutnya: Pilih arsitektur media langsung (M15.06) membahas kasus saat segmen tidak bisa disiapkan sebelumnya.
• Lab L15 belum tersedia.

Catatan

• Asumsi: video sesuai permintaan (VOD) dengan HLS atau DASH berbasis HTTP. Bitrate di tabel adalah angka ilustratif, bukan rekomendasi codec.
• Hit rate 97% dan 98% adalah asumsi. Ukur dari log CDN kamu sendiri.
• Yang nggak dibahas: DRM, iklan yang disisipkan, dan pemilihan codec (H.264, HEVC, AV1).
• Terakhir ditinjau: 26 Oktober 2026.