Untuk menonton stream SRT, periksa koneksi dan media
Gunakan pemutar native saat Anda perlu melihat feed kontribusi itu sendiri. Gunakan pemutaran browser hanya setelah feed dibuat menjadi output yang kompatibel dengan browser. Dalam kedua kasus, koneksi SRT yang berhasil dan gambar yang dapat diputar adalah hasil terpisah: mode, host, port UDP, latensi, Stream ID, dan passphrase membuka sesi; container, track, timestamp, dan codec menentukan apakah stream dapat didekode.
Jika tugasnya membuat, melindungi, atau mengoperasikan endpoint penerima, buka Callaba SRT Server. Panduan ini dimulai dari receiver.
Demo pemutar SRT langsung
Uji koneksi pemutar SRT
Buat koneksi sementara selama satu jam. Kirim stream SRT ke alamat penerbit dalam mode Caller, membiarkan ID Stream kosong. Setelah penerbit terhubung, tonton di Multiview di bawah atau hubungkan pemutar native ke alamat penerima dalam mode Caller.
Pilih pemutar yang sesuai dengan tugas
ffplay adalah pemeriksaan cepat melalui command line jika build FFmpeg yang terpasang menyertakan SRT. OBS Media Source berguna saat Anda ingin pratinjau grafis dan dapat menetapkan detail input SRT-nya. VLC mungkin berguna untuk tampilan lokal jika versi terpasang mendukung mode SRT yang diperlukan; periksa dokumentasi aplikasi terkini dan uji build yang tepat. Tidak satu pun pilihan tersebut membuat payload yang tidak diketahui menjadi dapat didekode.
Demo di atas membuat pasangan SRT Callaba selama satu jam. Setelah publisher masuk terhubung, demo membuat pratinjau Multiview. Gunakan nilai yang diberikan untuk menguji pasangan dan memeriksa gambar serta audio yang dihasilkan. Ini adalah jalur Callaba sementara yang nyata, bukan pemutar untuk URL SRT eksternal arbitrer.
Coba ffplay terlebih dahulu
Untuk receiver yang memanggil listener yang diketahui, ganti placeholder dengan endpoint yang diizinkan untuk Anda gunakan:
ffplay "srt://LISTENER_HOST:PORT?mode=caller"Untuk receiver yang menunggu Caller:
ffplay "srt://0.0.0.0:PORT?mode=listener"Jangan tempel passphrase ke tiket, chat, atau riwayat shell yang tidak Anda kendalikan. FFmpeg mendokumentasikan opsi URL SRT-nya; OBS mendokumentasikan alur kerja input SRT-nya.
Selaraskan Caller dan Listener sebelum mengubah pengaturan pemutar
Susunan yang umum sederhana: Listener menunggu pada port UDP dan Caller terhubung ke alamatnya yang dapat dijangkau. Catat kedua peran, verifikasi host dan port dari jaringan pengirim, lalu mulai pemutar. Dua Listener hanya menunggu; Caller yang diarahkan ke alamat tidak terjangkau tidak akan diperbaiki oleh pengaturan codec. Rendezvous adalah konfigurasi terpisah yang harus didukung oleh kedua endpoint.
Saat enkripsi diaktifkan, gunakan passphrase yang sama dan pengaturan kunci yang kompatibel pada kedua ujung. Jika layanan menggunakan Stream ID untuk memilih stream, pertahankan sintaks dan escaping-nya. Perlakukan keduanya sebagai data koneksi: jauhkan rahasia dari tangkapan layar dan laporan, lalu bandingkan sesi yang ditolak dengan log endpoint yang tersedia.
Tetapkan latensi untuk pemulihan, bukan tampilan
Latensi SRT memberi paket terlambat dan transmisi ulang waktu untuk tiba. Ini bukan keseluruhan jeda glass-to-glass; encoding, buffer decoder, packaging, dan buffer penonton menambah jeda masing-masing. Mulailah dengan rute yang diukur, lalu bandingkan kondisi bersih dan terganggu sambil mengamati kehilangan paket, transmisi ulang, drop, dan kontinuitas hasil dekode.
Dalam URL SRT bergaya FFmpeg, latency=200000 berarti 200 ms karena nilainya dalam mikrodetik. Itu hanya contoh. Catat nilai efektif di kedua endpoint dan sesuaikan untuk jalur kontribusi sebenarnya.
Periksa payload saat terhubung tetapi tidak dapat diputar
SRT membawa paket, bukan jaminan tentang codec video, codec audio, atau container. MPEG-TS umum untuk kontribusi, tetapi tetap memerlukan informasi program, timestamp, dan stream yang valid yang dapat didekode pemutar pilihan. Probe endpoint yang sama sebelum mengubah latensi lagi:
ffprobe -v error -show_format -show_streams "srt://LISTENER_HOST:PORT?mode=caller"Perhatikan container, codec video dan audio, profil, track, serta timestamp. Bandingkan fakta tersebut dengan dukungan yang didokumentasikan pemutar.
Jika bitrate ada tetapi layar tetap hitam
| Yang terlihat | Periksa selanjutnya |
|---|---|
| Tidak ada koneksi | Peran, host yang dapat dijangkau, port UDP, firewall, dan data akses. |
| Terhubung, tanpa gambar atau audio | Jalankan probe; periksa informasi program, codec, track, dan timestamp. |
| Gambar putus-putus saat ada kehilangan paket | Bandingkan pengukuran rute dan latensi pemulihan sebelum mengubah pemutar. |
Pemisahan ini mencegah masalah payload berubah menjadi rangkaian perubahan koneksi yang tak berakhir.
Gunakan SRT native untuk kontribusi; gunakan output browser untuk penonton
Elemen media browser standar tidak membuka URL srt:// secara native. Terima kontribusi terlebih dahulu, lalu publikasikan output yang kompatibel dengan browser dan uji pada perangkat serta jaringan yang akan menontonnya. Gunakan Multiview untuk tampilan kepercayaan bersama operator dan Web Player untuk pengiriman browser.
Simpan pemeriksaan receiver yang singkat
- Catat peran endpoint, host, port, latensi, kebijakan Stream ID, dan status enkripsi.
- Pastikan jaringan pengirim sebenarnya dapat menjangkau receiver.
- Periksa transport selama interval bersih dan kondisi terganggu yang penting untuk acara.
- Konfirmasikan gambar hasil dekode dan audio program pada pemutar yang dituju.
- Mulai ulang satu sisi dalam pengujian terencana dan periksa kembali permukaan operator atau penonton akhir.
Untuk detail protokol, lihat dokumentasi SRT live-transmit dan panduan protokol SRT Callaba.
FAQ SRT Player
Dapatkah browser memutar URL SRT secara langsung?
Tidak melalui elemen media HTML standar. Terima SRT terlebih dahulu dan publikasikan output yang kompatibel dengan browser.
Mengapa koneksi SRT dapat menunjukkan bitrate tanpa video?
Sesi mungkin berfungsi sementara pemutar tidak dapat mendekode container, track, timestamp, atau profil codec.
Haruskah pemutar menggunakan mode Caller atau Listener?
Gunakan peran yang melengkapi peer yang disepakati dan keterjangkauan jaringannya.
Apakah menambah latensi SRT selalu mengatasi kehilangan paket?
Tidak. Latensi memberi transmisi ulang lebih banyak waktu, tetapi tidak dapat membuka UDP yang diblokir, memperbaiki kekurangan kapasitas berkelanjutan, atau mendekode payload yang tidak didukung.
