RTSP adalah protokol pensinyalan sederhana yang tidak dapat mereka gantikan dengan apa pun selama bertahun-tahun, dan harus diakui bahwa mereka tidak berusaha sangat keras.
Misalnya, kami memiliki kamera IP yang mendukung RTSP. Siapa pun yang pernah menguji lalu lintas dengan kabel Sharkwire akan memberi tahu Anda bahwa pertama-tama ada DESCRIBE, lalu MAIN, lalu lalu lintas mulai dituangkan langsung melalui RTP atau dibungkus dalam saluran TCP misalnya.
Skema khas membangun koneksi RTSP terlihat seperti ini:
Dapat dibayangkan bahwa dukungan protokol RTSP tidak diperlukan untuk browser dan sebanyak penggunaan roda kelima, oleh karena itu browser tidak terburu-buru untuk mengimplementasikannya dalam skala besar, dan itu hampir tidak akan pernah terjadi. Di sisi lain, browser dapat membuat koneksi TCP langsung, dan itu akan menyelesaikan tugas, tetapi sekarang ia menghadapi masalah keamanan: apakah Anda pernah melihat browser yang akan memungkinkan skrip untuk menggunakan protokol transport secara langsung?
Tetapi orang-orang menuntut streaming tersedia di "browser apa pun tanpa menginstal perangkat lunak tambahan", dan para pemula pemula menulis di situs web mereka, "Anda tidak perlu menginstal apa pun, itu akan berfungsi di semua browser di luar kotak", ketika mereka ingin menunjukkan aliran dari kamera IP.
Pada artikel ini kita akan mengeksplorasi bagaimana ini bisa dicapai. Dan karena tahun yang akan datang berisi angka bulat, mari kita tambahkan beberapa topik ke artikel kami dan menempelkan label dengan 2020 untuk itu, terutama karena itu benar-benar begitu.
Jadi, teknologi tampilan video mana yang harus dilupakan pada tahun 2020? Itu Flash di browser. Itu sudah mati. Itu tidak ada lagi, hapus dari daftar.
Tiga metode yang bermanfaat
Alat yang memungkinkan Anda menonton streaming video di peramban hari ini adalah:
- WebRTC
- Hl
- Websocket + MSE
Apa yang salah dengan WebRTC
Dalam dua kata: ini intensif sumber daya dan rumit.
Anda akan melambaikannya, "Apa yang Anda maksud dengan sumber daya intensif?", Karena CPU saat ini kuat, memori murah, jadi apa masalahnya? Yah, pertama-tama, ini adalah enkripsi wajib semua lalu lintas walaupun Anda tidak membutuhkannya. Kedua, WebRTC adalah koneksi dua arah yang rumit dan pertukaran umpan balik peer-to-peer tentang kualitas saluran (peer-to-server, dalam hal ini): pada setiap saat waktu ada bitrate dihitung, packet loss terdeteksi, keputusan tentang pengalihan mereka diambil, dan sinkronisasi audio-ke-video dihitung sehubungan dengan semua itu, yang disebut lipsync, yang membuat bibir pembicara bertepatan dengan kata-kata mereka. Semua perhitungan ini, serta lalu lintas masuk di server, mengalokasikan dan membebaskan gigabytes RAM secara real time, dan jika ada yang salah, server 256-gigabyte dengan CPU 48-core akan berputar dengan mudah meskipun semua gigaherz, nanometer, dan DDR 10 di papan.
Jadi, ini semacam berburu tupai dengan rudal Iskander. Yang perlu kita singkirkan hanyalah aliran RTSP, lalu tampilkan, dan yang dikatakan WebRTC adalah, "Ya, ayolah, tetapi Anda harus membayarnya."
Mengapa WebRTC bagus
Latensi. Sangat rendah. Jika Anda siap mengorbankan kinerja dan kompleksitas untuk latensi rendah, WebRTC adalah varian yang paling cocok untuk Anda.
Mengapa HLS itu baik
Dengan dua kata: itu bisa bekerja di mana saja
HLS adalah off-roader lambat di dunia menampilkan konten langsung. Ini dapat bekerja di mana saja karena dua hal: transportasi HTTP dan perlindungan Apple. Memang, protokol HTTP ada di mana-mana, saya bisa merasakan keberadaannya bahkan ketika saya sedang menulis baris-baris ini. Jadi, di mana pun Anda berada dan tablet kuno apa yang Anda gunakan untuk menjelajahi internet, HLS (HTTP Live Streaming) akan mendatangi Anda dan mengirimkan video ke layar Anda dengan cukup pasti.
Semuanya cukup baik, tapi ...
Mengapa HLS itu buruk
Latensi. Ada, misalnya, proyek pengawasan video situs konstruksi. Sebuah fasilitas sedang dibangun selama bertahun-tahun, dan selama waktu itu kamera yang buruk merekam video dari lokasi konstruksi siang dan malam, 24/7. Ini adalah contoh situasi di mana latensi rendah tidak diperlukan.
Contoh lain adalah babi hutan. Babi hutan nyata. Petani Ohio menderita dari serangan babi hutan yang memakan tanaman dan menginjak-injaknya seperti belalang, karena itu menimbulkan ancaman bagi kesejahteraan keuangan pertanian. Para startupper yang giat telah meluncurkan sistem pengawasan video dari kamera RTSP yang memantau lapangan secara real time dan memicu jebakan ketika para penyusup menyerang. Dalam hal ini latensi rendah sangat penting, dan jika HLS digunakan (dengan latensi 15 detik), babi hutan akan lari sebelum perangkap diaktifkan.
Berikut ini satu contoh lagi: presentasi video di mana seseorang mendemonstrasikan suatu produk kepada Anda dan mengharapkan respons yang cepat. Dalam hal latensi tinggi, mereka akan menunjukkan produk kepada Anda di kamera, kemudian bertanya, "Jadi, bagaimana Anda menyukainya?", Dan itu akan mencapai Anda hanya dalam 15 detik. Dalam 15 detik, sinyal dapat melakukan perjalanan ke Bulan dan kembali 12 kali. Tidak, kami tidak ingin latensi seperti itu. Ini lebih seperti video pra-rekam daripada Live. Tetapi video yang sudah direkam sebelumnya, karena beginilah cara HLS bekerja: ia merekam sebagian video pada disk atau ke memori server, dan pemain mengunduh bagian yang direkam. Ini adalah cara kerja HTTP Live yang bukan Live sama sekali.
Mengapa itu terjadi? Kehadiran global protokol HTTP dan kesederhanaannya menghasilkan kelesuan karena HTTP pada awalnya tidak dimaksudkan untuk mengunduh dan menampilkan ribuan fragmen video besar (segmen HLS) dengan cepat. Mereka tentu saja diunduh dan dimainkan dengan kualitas tinggi, tetapi sangat lambat: dibutuhkan 15 detik atau lebih bagi mereka untuk diunduh, disangga, dan diterjemahkan.
Harus dicatat di sini bahwa Apple mengumumkan HLS Low Latency pada musim gugur 2019, tetapi itu sudah cerita yang berbeda. Mari kita lihat hasil mereka lebih rinci nanti. Dan sekarang kami juga memiliki MSE dalam stok.
Mengapa MSE itu baik?
Media Source Extension adalah dukungan asli untuk memutar video paket di browser. Ini bisa disebut pemain asli untuk H.264 dan AAC, yang Anda dapat memberi makan segmen video, dan yang tidak terikat dengan protokol transport, tidak seperti HLS. Untuk alasan ini, Anda dapat memilih transportasi melalui protokol Websockets. Dengan kata lain, segmen tidak akan diunduh menggunakan teknologi Request-Response (HTTP) kuno lagi tetapi mengalir dengan cepat melalui koneksi Websockets yang hampir merupakan saluran TCP langsung. Ini sangat membantu dalam hal mengurangi penundaan yang dapat menjadi serendah 3-5 detik. Latensi seperti itu tidak fantastis tetapi cocok untuk sebagian besar proyek yang tidak memerlukan waktu nyata yang sulit. Kompleksitas dan intensitas sumber daya juga relatif rendah karena saluran TCP dibuka, dan segmen HLS yang hampir sama menuangkannya, yang dikumpulkan oleh pemain dan dikirim untuk dimainkan.
Mengapa MSE itu buruk
Itu tidak bisa bekerja di mana-mana. Sama seperti dengan WebRTC, penetrasi ke browser lebih rendah. iPhone (iOS) memiliki sejarah kegagalan yang luar biasa untuk memainkan MSE, yang membuat MSE hampir tidak cocok sebagai satu-satunya solusi untuk startup.
Ini sepenuhnya tersedia di browser berikut: Edge, Firefox, Chrome, Safari, Browser Android, Opera Mobile, Chrome untuk Android, Firefox untuk Android, UC Browser untuk Android.
Dukungan terbatas untuk MSE muncul di iOS Safari beberapa waktu yang lalu, dimulai dengan iOS 13.
Kaki RTSP
Kami telah membahas pengiriman di server video> arah browser. Selain itu, Anda juga membutuhkan dua hal ini:
1) Untuk mengirimkan video Anda dari kamera IP ke server.
2) Untuk mengkonversi video menjadi salah satu format / protokol yang dijelaskan di atas.
Di sinilah sisi server masuk.
Ta-dah ... Bertemu Web Call Server 5 (atau sekadar WCS untuk teman). Seseorang harus menerima lalu lintas RTSP, meng-de-paketkan video dengan benar, mengubahnya menjadi WebRTC, HLS atau MSE, lebih disukai tanpa terlalu dikompresi oleh transcoder, dan mengirimkannya ke browser dalam bentuk yang rapi, tidak rusak dengan artefak dan membeku.
Tugasnya tidak rumit pada pandangan pertama, tetapi mungkin ada begitu banyak jebakan tersembunyi, kamera Cina, dan nuansa konversi yang ada di belakangnya sehingga benar-benar mengerikan. Sebenarnya tidak mungkin tanpa peretasan, tetapi ini berfungsi, dan berfungsi dengan baik. Dalam produksi.
Skema pengiriman
Sebagai hasilnya, skema lengkap pengiriman konten RTSP dengan konversi pada server perantara mulai terbentuk.
Salah satu pertanyaan yang paling sering diajukan dari rekan-rekan India kami adalah, “Apakah mungkin? Secara langsung, tanpa server? ". Tidak, tidak; Anda akan memerlukan sisi server yang akan melakukan pekerjaan. Di cloud, di perangkat keras, di corei7 di balkon Anda, tetapi Anda tidak bisa melakukannya tanpanya.
Mari kita kembali ke tahun 2020 kita
Jadi, inilah resep untuk memasak RTSP di browser Anda:
- Ambil WCS baru (Server Panggilan Web) .
- Tambahkan WebRTC, HLS atau MSE secukupnya.
Sajikan di halaman web.
Nikmati makananmu!
Tidak, ini belum semuanya.
Neuron yang bertanya pasti ingin menanyakan pertanyaan ini, "Bagaimana? Sungguh, bagaimana ini bisa dilakukan ? Seperti apa nantinya di browser? ”
Kami ingin menyampaikan kepada Anda pemutar WebRTC minimalis yang dirakit sebagai upaya meja dapur.
1) Hubungkan skrip API utama flashphoner.js dan skrip my_player.js, yang akan kita buat sedikit kemudian, ke halaman web.
<script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script>
2) Inisialisasi API di badan halaman web
<body onload="init_api()">
3) Tambahkan div, yang akan berfungsi sebagai wadah untuk video, ke halaman. Tetapkan ukuran dan batas untuk itu.
<div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div>
4) Tambahkan tombol Play, klik yang akan menginisialisasi koneksi ke server dan mulai memutar video
<input type="button" onclick="connect()" value="PLAY"/>
5) Sekarang mari kita buat skrip my_player.js yang akan berisi kode utama pemain kami. Jelaskan konstanta dan variabel
var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS; var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS; var session;
6) Inisialisasi API ketika halaman HTML dimuat
function init_api() { console.log("init api"); Flashphoner.init({ }); }
7) Hubungkan ke server WCS melalui WebSocket. Agar semuanya berfungsi dengan benar, ganti "wss: //demo.flashphoner.com" dengan alamat WCS Anda
function connect() { session = Flashphoner.createSession({urlServer: "wss://demo.flashphoner.com"}).on(SESSION_STATUS.ESTABLISHED, function(session){ console.log("connection established"); playStream(session); }); }
8) Setelah itu, kirimkan dua parameter berikut, "nama" dan "tampilan", di mana "nama" adalah URL RTSP dari aliran yang sedang diputar, dan "tampilan" adalah elemen dari myVideo di mana pemain kami akan dipasang. Tetapkan URL aliran Anda di sini juga, bukan milik kami.
function playStream() { var options = {name:"rtsp://b1.dnsdojo.com:1935/live/sys2.stream",display:document.getElementById("myVideo")}; var stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) { console.log("playing"); }); stream.play(); }
Simpan file dan coba luncurkan pemain. Apakah streaming RTSP Anda diputar?
Ketika kami mengujinya , yang ini dimainkan: rtsp: //b1.dnsdojo.com: 1935 / live / sys2.stream.
Dan seperti inilah tampilannya:
Pemain sebelum tombol Play diklik
Pemain dengan video diluncurkan
Tidak ada banyak kode sama sekali:
HTML
<!DOCTYPE html> <html lang="en"> <head> <script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script> </head> <body onload="init_api()"> <div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div> <br/><input type="button" onclick="connect()" value="PLAY"/> </body> </html>
Javascript
demo.flashphoner.com digunakan sebagai sisi server. Kode lengkap dari contoh tersedia di bawah ini, di bagian bawah halaman yang berisi tautan.
Selamat menikmati streaming!
Tautan
Kode pemain di github
Integrasi pemain RTSP ke halaman web atau aplikasi seluler