Jawapan ringkas: gunakan RTMP apabila pengekod perlu menghantar ke titik akhir input, WebRTC apabila interaksi penonton dan laluan masa nyata memerlukannya, dan HLS apabila penyampaian berasaskan HTTP dipilih. Sesuatu perkhidmatan langsung sering menggunakan lebih daripada satu protokol; nama protokol tersebut merujuk kepada sempadan yang berbeza.
Pilih bermula daripada penonton, kemudian kembali ke sumber
| Soalan | WebRTC | HLS | RTMP |
|---|---|---|---|
| Penerima utama | Pelayar atau aplikasi interaktif, atau perkhidmatan media | Pemain dan laluan penyampaian yang menyokong HTTP | Pelayan input atau titik akhir platform |
| Model pengangkutan dan penyampaian | Sesi media masa nyata yang dirundingkan antara rakan sambungan | Senarai main dan segmen media yang diambil melalui HTTP | Sesi penghantaran TCP yang berterusan |
| Peranan pelayar | Direka untuk API media masa nyata dalam pelayar | Disampaikan melalui pemain; sokongan berbeza mengikut platform | Bukan main balik asli pelayar moden |
| Semakan codec | Sahkan sokongan pelayar, perkhidmatan dan rundingan sesi | Sahkan keserasian pemain, pembungkusan dan versi media | Sahkan keserasian pengekod dan titik akhir input |
| Semakan rangkaian | Pengisyaratan, ICE/STUN/TURN dan keadaan tembok api | Pelayan asal, cache atau CDN dan tingkah laku permintaan pemain | Kebolehcapaian hos dan port input yang diperuntukkan |
| Sesuai apabila | Interaksi ialah sebahagian daripada keperluan produk | Tugasnya ialah penyampaian kepada penonton | Pengekod perlu menyerahkan suapan kepada penerima input |
Perkara yang perlu diuji dahulu
| Pilihan aliran kerja | Titik akhir untuk diuji | Semakan penerimaan pertama |
|---|---|---|
| Sumbangan atau penonton interaktif: WebRTC | Titik akhir penonton atau sesi WebRTC yang telah dikonfigurasi | Pengisyaratan dan sambungan ICE/TURN, kemudian audio dan video rancangan |
| Main balik pelayar untuk penonton umum: HLS | https://example.invalid/live/master.m3u8 | Pengambilan manifes dan versi media yang dimaksudkan dalam pemain |
| Input pengekod atau platform: RTMP | rtmp://example.invalid/app bersama kunci yang diperuntukkan | Status penghantar, kemudian output HLS atau WebRTC yang dipilih secara khusus |
Ini ialah bentuk titik akhir, bukan alamat yang disediakan oleh Callaba. Untuk model penyampaian asas, lihat WebRTC W3C, HLS IETF dan spesifikasi RTMP.
Keputusan ringkas: pilih protokol mengikut tugas
Untuk sumbangan interaktif atau penyertaan penonton, uji pengisyaratan WebRTC dan ICE/TURN sebelum memilihnya. Untuk main balik pelayar bagi penonton umum, uji manifes HLS dan pemain. Untuk input daripada pengekod ke platform, uji RTMP ke titik akhir yang diberikan, kemudian pilih dan uji output HLS atau WebRTC seterusnya.
Jika persoalannya ialah cara penonton menerima rancangan dalam pelayar, mulakan dengan WebRTC atau HLS serta keperluan pemain, akses dan penyampaiannya. Jika persoalannya ialah cara pengekod ini menghantar ke platform, mulakan dengan keperluan input RTMP platform tersebut. RTMP boleh membekalkan media kepada peringkat HLS atau WebRTC selepasnya, tetapi tidak mewujudkan peringkat itu dengan sendirinya.
Perbandingan yang sering mengelirukan
WebRTC berbanding HLS
Ini keputusan tentang penyampaian. WebRTC memerlukan laluan sesi masa nyata; HLS memerlukan penyampaian senarai main dan segmen serta pemain yang serasi. Uji titik akhir penonton sebenar dan model aksesnya, bukan suapan sumber sahaja.
RTMP berbanding WebRTC
Kedua-duanya lazimnya berada pada hujung aliran kerja yang berbeza: RTMP untuk input pengekod, WebRTC untuk penyampaian interaktif. Jambatan antara kedua-duanya ialah fungsi pelayan atau perkhidmatan media yang perlu dikonfigurasi dengan codec, pengisyaratan dan operasinya sendiri, bukan sifat yang terkandung dalam mana-mana URL.
HLS berbanding RTMP
HLS membungkus media untuk penyampaian HTTP; RTMP menghantar media kepada penerima input. Penonton yang tidak dapat membuka URL RTMP memerlukan laluan output HLS atau WebRTC yang dipilih, bukan pelayar lain.
Aliran kerja campuran
Pengekod rancangan boleh menghantar RTMP kepada sumber input yang dikawal aksesnya. Pengendali mengesahkan aktiviti sumber, kemudian mengkonfigurasi output berasingan untuk penonton: HLS bagi aliran kerja pemain HTTP, atau WebRTC bagi laluan interaksi. Sahkan setiap sempadan mengikut urutan: pengekod ke input, pemprosesan dan penciptaan output, kemudian URL penonton yang sebenar.
Senarai semak protokol sebelum produksi
- Catat codec sumber, kadar bingkai, audio dan kekangan penerima sasaran.
- Tetapkan pihak yang bertanggungjawab terhadap kelayakan penghantaran, pengisyaratan dan akses serta ujian pemain.
- Gunakan kumpulan penonton tertutup untuk latihan dan uji pemulihan selepas sumber dihentikan.
- Kaitkan dakwaan main balik terus dalam pelayar dengan output yang dikonfigurasi, bukan URL sumber RTMP.
Pilih langkah seterusnya
Untuk input pengekod serta akses penghantar dan penerima, lihat RTMP Server. URL penghantaran RTMP boleh menggunakan aplikasi dan nama strim yang sama seperti URL penerima, tetapi penghantar dan penerima tetap mempunyai peranan berbeza. Untuk output pelayar, mulakan dengan panduan Web Player; untuk pembungkusan, lihat RTMP kepada HLS. Jika aliran kerja menggunakan sumbangan SRT dan bukannya penghantaran RTMP, SRT Server ialah halaman yang sesuai.
