Pilih arsitektur media langsung

Pertanyaan

Kapan cukup menyajikan rekaman, kapan perlu siaran langsung, dan kapan perlu interaksi dua arah, dan apa konsekuensi tiap pilihan buat latensi, biaya, dan kontrol akses?

Setelah baca ini, kamu bisa memilih arsitektur dari kebutuhan latensi dan jumlah penonton, serta menyebut apa yang berubah dari sisi infrastruktur dan keamanan.

Prasyarat dan contoh

Kamu sudah paham video adaptif dan segmen (M15.04), kapasitas dan bandwidth (M01), serta cache dan CDN (M06).

Tiga produk berbeda sering dikira sama: kelas rekaman yang ditonton kapan saja, webinar yang disiarkan ke 5.000 peserta dengan jeda beberapa detik yang bisa diterima, dan konsultasi dokter dua arah di mana jeda lebih dari sekitar 400 ms sudah terasa mengganggu percakapan. Ketiganya video, tapi kendala utamanya berbeda.

Mekanisme

Tiga titik di spektrum latensi.

| Pola | Latensi khas | Penonton | Cara kirim | | ------------------------------ | ----------------- | ------------- | ------------------------------------------- | | Rekaman (VOD) | tidak relevan | sangat banyak | segmen di CDN, disiapkan sebelumnya | | Siaran langsung | 3 sampai 30 detik | ribuan | segmen dibuat terus-menerus, lewat CDN | | Interaksi dua arah (WebRTC) | di bawah 500 ms | puluhan | koneksi langsung atau lewat server media |

Angka latensi adalah rentang khas, bukan janji. Siaran berbasis segmen bisa ditekan ke beberapa detik dengan segmen pendek atau varian latensi rendah, dengan harga lebih banyak request dan buffer lebih tipis.

Siaran langsung. Sumber mengirim aliran ke titik masuk (ingest). Server mengenkode ulang ke ladder rendition dan memotongnya menjadi segmen saat itu juga, lalu CDN mendistribusikannya seperti VOD (M15.04). Latensi kira-kira jumlah panjang segmen x jumlah segmen yang di-buffer pemutar, ditambah waktu encode. Segmen 4 detik x 3 segmen = sekitar 12 detik sebelum tambahan lain. Skalanya bagus: 5.000 penonton hanya menambah beban CDN, bukan beban sumber. Tapi ingest dan encoder adalah titik tunggal yang perlu cadangan.

WebRTC. Latensi rendah dicapai dengan mengirim paket (UDP) tanpa menunggu pengiriman ulang yang sempurna, dan menyesuaikan bitrate terus-menerus. Dua peserta bisa terhubung langsung (peer to peer), tetapi di jaringan nyata sebagian koneksi butuh relay (TURN) karena NAT dan firewall. Untuk lebih dari beberapa peserta, dipakai server media (SFU) yang menerima satu aliran dari tiap peserta dan meneruskannya ke yang lain tanpa mengenkode ulang. Biayanya: 10 peserta, tiap peserta mengunggah 1 aliran dan mengunduh 9. Beban server tumbuh sekitar n x (n-1) aliran keluar, jadi ruang besar butuh pembatasan (hanya pembicara aktif, kualitas bertingkat).

Kontrol akses berbeda di tiap pola.

• VOD: signed URL atau cookie bertanda tangan per segmen/manifest, berlaku pendek. Segmen sudah di CDN, jadi tanda tangan harus diverifikasi di tepi (M15.02).
• Siaran langsung: token pada manifest dan segmen yang diperbarui berkala. Hati-hati, siapa pun yang punya token valid bisa menyalin aliran. Kontrol akses di sini membatasi siapa mulai menonton, bukan apa yang dilakukan penonton dengan video itu.
• WebRTC: sinyal (siapa boleh masuk ruang) lewat server aplikasi dengan token berumur pendek yang terikat ke ruang dan peran. Setelah tersambung, server media harus membatasi siapa boleh mengirim.

Rekaman dari siaran. Segmen siaran langsung bisa disimpan lalu dijadikan VOD setelah selesai, dengan manifest akhir dan rendition rapi (alur M15.03). Rekaman WebRTC perlu mekanisme tambahan: server media atau perekam yang bergabung sebagai peserta.

Saat rancangan ini gagal

• Memakai WebRTC untuk 5.000 penonton. Biaya server media dan bandwidth melonjak, padahal penonton tidak berinteraksi. Siaran berbasis segmen lewat CDN jauh lebih murah.
• Memakai siaran berbasis segmen untuk konsultasi. Jeda 10 detik membuat percakapan dua arah tidak mungkin.
• Ingest tunggal. Encoder mati, siaran putus. Siapkan jalur ingest cadangan dan prosedur pindah yang sudah dilatih.
• Token bocor. Tautan siaran berbayar dibagikan ke grup. Token berumur pendek, terikat sesi atau perangkat, dan batas koneksi serentak per akun mengecilkan masalah, tapi nggak mencegah perekaman layar.
• Peserta di jaringan ketat. Tanpa relay TURN, sebagian peserta (jaringan kantor) tidak bisa tersambung sama sekali. Siapkan relay dan hitung bandwidth-nya, karena semua aliran peserta tersebut lewat relay.
• Lonjakan ruang. Ruang WebRTC yang tiba-tiba diisi 200 orang melebihi kapasitas SFU. Pasang batas ukuran ruang dan jalur alih ke siaran.

Latihan

Platform pendidikan menawarkan tiga fitur: (a) rekaman kelas untuk 50.000 siswa, (b) kelas langsung dengan satu guru dan 3.000 siswa yang hanya mengetik di obrolan, (c) sesi tutor satu lawan satu dengan murid. Pilih pola tiap fitur dan sebutkan satu kontrol akses per fitur.

Lihat pembahasan+

(a) Rekaman: VOD dengan HLS/DASH lewat CDN. Latensi tidak relevan, dan cache efisien karena banyak siswa meminta segmen yang sama. Akses: manifest dan segmen ditandatangani dengan umur pendek (misalnya 2 jam), diberikan setelah aplikasi memeriksa siswa terdaftar di kelas itu.

(b) Kelas langsung: siaran berbasis segmen. Guru mengirim satu aliran ke ingest, server mengenkode ke 3 sampai 4 rendition, CDN melayani 3.000 penonton. Jeda sekitar 8 sampai 15 detik bisa diterima karena siswa hanya mengetik, dan pertanyaan di obrolan toh sudah tertunda. Dengan 3.000 penonton x 1,8 Mbps rata-rata = sekitar 5,4 Gbps di CDN, bukan di server sendiri. Akses: token penonton pada manifest yang diperbarui berkala, plus batas satu sesi aktif per akun. Setelah selesai, segmen disimpan dan diolah jadi rekaman untuk (a).

(c) Satu lawan satu: WebRTC. Dua peserta, latensi di bawah 500 ms diperlukan untuk percakapan. Pakai koneksi langsung bila bisa, dengan relay TURN sebagai cadangan. Akses: token ruang berumur pendek yang terikat ke dua pengguna dan sesi yang dijadwalkan, diterbitkan server aplikasi dan diverifikasi saat bergabung.

Jawaban bagus mengaitkan pola dengan jumlah penonton dan kebutuhan interaksi, bukan dengan mana yang paling canggih.

Terkait

• Sebelumnya: Distribusikan video adaptif (M15.04) menjelaskan segmen, ladder, dan hitungan egress yang dipakai ulang untuk siaran.
• Sinkronkan berkas (M15.05) dan Proses video secara asinkron (M15.03) menjadi jalur rekaman setelah siaran selesai.
• Antrean dan backpressure di M10 relevan saat ingest dan encoding tertinggal.
• Lab L15, rancangan D19, dan studi kasus C05 belum tersedia.

Catatan

• Asumsi: penyedia ingest dan CDN yang mendukung siaran berbasis segmen, serta SFU untuk WebRTC. Angka latensi adalah rentang khas.
• Yang nggak dibahas: protokol ingest tertentu secara detail, DRM, moderasi konten langsung, dan perekaman multi-sumber.
• Kontrol akses di sini membatasi pemulai tontonan. Menghentikan penyalinan oleh penonton sah adalah masalah yang tidak terselesaikan secara teknis semata.
• Terakhir ditinjau: 26 Oktober 2026.