Jawaban singkat: gunakan RTMP ketika encoder diminta publish ke endpoint ingest, WebRTC ketika interaksi penonton dan jalur real-time membenarkannya, dan HLS ketika delivery audiens berbasis HTTP adalah jalur yang dipilih. Layanan live sering memakai lebih dari satu; nama protokol menggambarkan batas yang berbeda.
Pilih dari penonton kembali ke source
| Pertanyaan | WebRTC | HLS | RTMP |
|---|---|---|---|
| Receiver utama | Peer browser/aplikasi interaktif atau layanan media | Player dan jalur delivery berkemampuan HTTP | Server ingest atau endpoint platform |
| Model transport/delivery | Sesi media real-time yang dinegosiasikan untuk peer | Playlist ditambah segmen media yang diambil melalui HTTP | Sesi publishing TCP persisten |
| Peran browser | Dirancang untuk API media real-time browser | Dikirim melalui jalur player; dukungan platform berbeda-beda | Bukan pemutaran browser modern native |
| Pemeriksaan codec | Konfirmasikan dukungan browser, layanan, dan negosiasi | Konfirmasikan kompatibilitas player, packaging, dan rendition | Konfirmasikan kompatibilitas encoder dan endpoint ingest |
| Pemeriksaan jaringan | Kondisi signalling, ICE/STUN/TURN, dan firewall | Perilaku origin, cache/CDN, dan request player | Keterjangkauan host dan port ingest yang diberikan |
| Cocok ketika | Interaksi adalah bagian dari kebutuhan produk | Delivery audiens adalah pekerjaannya | Encoder harus menyerahkan feed ke receiver ingest |
Yang diuji terlebih dahulu
| Pilihan alur | Endpoint untuk diuji | Pemeriksaan penerimaan pertama |
|---|---|---|
| Kontribusi atau audiens interaktif: WebRTC | Endpoint viewer/sesi WebRTC yang dikonfigurasi | Signalling ditambah konektivitas ICE/TURN, lalu audio/video program |
| Pemutaran browser luas: HLS | https://example.invalid/live/master.m3u8 | Pengambilan manifest dan rendition player yang dimaksud |
| Ingest encoder/platform: RTMP | rtmp://example.invalid/app plus assigned key | Status publisher, lalu output HLS atau WebRTC yang dipilih secara eksplisit |
Ini adalah bentuk endpoint, bukan alamat yang disediakan Callaba. Untuk model delivery yang mendasari, lihat W3C WebRTC, IETF HLS, dan spesifikasi RTMP.
Keputusan cepat: pilih protokol berdasarkan pekerjaan
Untuk kontribusi interaktif atau partisipasi audiens, uji signalling WebRTC dan ICE/TURN sebelum memilihnya. Untuk pemutaran browser luas, uji manifest HLS dan player. Untuk ingest encoder-ke-platform, uji RTMP ke endpoint yang diberikan, kemudian pilih dan uji output HLS atau WebRTC lanjutan.
Jika keputusannya adalah “bagaimana penonton menerima program di browser?”, mulai dengan WebRTC atau HLS serta kebutuhan player, akses, dan delivery-nya. Jika pertanyaannya “bagaimana encoder ini publish ke platform?”, mulai dengan kontrak ingest RTMP platform. RTMP dapat memberi makan tahap HLS atau WebRTC berikutnya, tetapi tidak menciptakan tahap itu sendiri.
Perbandingan keliru yang umum
WebRTC vs HLS
Ini adalah keputusan delivery. WebRTC memerlukan jalur sesi real-time; HLS memerlukan delivery playlist/segmen dan player yang kompatibel. Uji endpoint audiens yang tepat beserta model aksesnya, bukan hanya feed source.
RTMP vs WebRTC
Keduanya biasanya berada di ujung alur yang berbeda: RTMP sebagai ingest encoder, WebRTC sebagai delivery interaktif. Bridge adalah fungsi server media atau layanan yang dikonfigurasi dengan codec, signalling, dan operasinya sendiri—bukan properti dari salah satu URL.
HLS vs RTMP
HLS memaketkan media untuk delivery HTTP; RTMP mempublikasikan media ke receiver ingest. Penonton yang tidak dapat membuka URL RTMP memerlukan jalur output HLS atau WebRTC yang dipilih, bukan browser lain.
Alur protokol campuran
Encoder program dapat publish RTMP ke resource ingest terkontrol. Operator mengonfirmasi aktivitas source, lalu mengonfigurasi output terpisah untuk delivery audiens—HLS untuk alur player HTTP atau WebRTC untuk jalur interaksi. Validasikan setiap batas secara berurutan: encoder-ke-ingest, pembuatan pemrosesan/output, lalu URL penonton sebenarnya.
Checklist protokol pra-produksi
- Tuliskan codec source, frame rate, audio, dan batasan receiver target.
- Tetapkan pemilik untuk kredensial publishing, signalling/akses, dan pengujian player.
- Gunakan audiens rehearsal privat dan uji pemulihan setelah menghentikan source.
- Pertahankan klaim pemutaran browser langsung pada output yang dikonfigurasi, bukan URL source RTMP.
Pilih langkah berikutnya
Untuk ingest encoder serta akses publisher/receiver, lihat RTMP Server. URL publish RTMP dapat memakai nama aplikasi dan stream yang sama dengan URL receiver, tetapi publisher dan receiver tetap memiliki peran berbeda. Untuk output browser, mulai dengan panduan Web Player; untuk maksud packaging, lihat RTMP ke HLS. Jika alurnya adalah kontribusi SRT, bukan publishing RTMP, SRT Server adalah pemilik yang tepat.
