Menurut beberapa laporan, saat ini ada ratusan juta Kamera IP untuk pengawasan video. Namun, penundaan dalam pemutaran video tidak penting bagi semuanya. Pengawasan video biasanya terjadi "secara statis" - aliran direkam dalam penyimpanan dan dapat dianalisis pergerakannya. Ada banyak solusi perangkat lunak dan perangkat keras yang dikembangkan untuk pengawasan video yang berfungsi dengan baik.

Pada artikel ini kita akan melihat aplikasi yang sedikit berbeda kamera IP, yaitu penerapan dalam siaran online jika diperlukan latensi komunikasi rendah.

Pertama-tama, mari kita perjelas kemungkinan kesalahpahaman dalam terminologi tentang webcam dan kamera IP.

Kamera web adalah perangkat perekam video yang tidak memiliki prosesor dan antarmuka jaringan sendiri. Webcam memerlukan koneksi ke komputer, ponsel cerdas, atau perangkat lain yang memiliki kartu jaringan dan prosesor.

kamera IP adalah perangkat yang berdiri sendiri yang memiliki kartu jaringan dan prosesor sendiri untuk mengompresi video yang diambil dan mengirimkannya ke jaringan. Jadi, kamera IP adalah komputer mini otonom yang terhubung sepenuhnya ke jaringan dan tidak memerlukan koneksi ke perangkat lain, dan dapat langsung menyiarkan ke jaringan.

Latensi rendah(latensi rendah) merupakan persyaratan yang cukup langka untuk kamera IP dan siaran online. Kebutuhan untuk bekerja dengan latensi rendah muncul, misalnya, jika sumber aliran video berinteraksi secara aktif dengan pemirsa aliran tersebut.

Seringkali, latensi rendah diperlukan dalam kasus penggunaan game. Contohnya meliputi: lelang video waktu nyata, kasino video dengan dealer langsung, acara TV online interaktif dengan pembawa acara, kendali jarak jauh quadcopter, dll.

Dealer kasino online langsung di tempat kerja.

Kamera IP RTSP biasa biasanya mengalirkan video H.264 codec dan dapat beroperasi dalam dua mode transportasi data: disisipkan Dan tidak disisipkan.

Mode disisipkan yang paling populer dan nyaman, karena Dalam mode ini, data video dikirimkan melalui TCP dalam koneksi jaringan ke kamera. Untuk mendistribusikan dari kamera IP ke interleaved, Anda hanya perlu membuka/meneruskan satu port RTSP kamera (misalnya 554) ke luar. Pemain hanya dapat terhubung ke kamera melalui TCP dan mengambil aliran dalam koneksi ini.

Mode pengoperasian kamera kedua adalah tidak disisipkan. Dalam hal ini, koneksi dibuat menggunakan protokol RTSP/TCP, dan lalu lintas berjalan secara terpisah, sesuai dengan protokol RTP/UDP di luar saluran TCP yang dibuat.

Mode tidak disisipkan lebih disukai untuk menyiarkan video dengan latensi minimal, karena menggunakan RTP/UDP, tetapi pada saat yang sama akan lebih bermasalah jika pemain berada di belakang NAT.

Saat menghubungkan ke kamera IP pemutar yang berada di belakang NAT, pemutar harus mengetahui alamat IP eksternal dan port mana yang dapat digunakan untuk menerima lalu lintas audio dan video. Port ini ditentukan dalam teks konfigurasi SDP, yang dikirim ke kamera saat sambungan RTSP dibuat. Jika NAT dibuka dengan benar dan alamat IP serta port yang benar ditentukan, maka semuanya akan berfungsi.

Jadi, untuk mengambil video dari kamera dengan penundaan minimal, Anda perlu menggunakan non-interleave mode dan menerima lalu lintas video melalui UDP.

Browser tidak mendukung tumpukan protokol RTSP/UDP secara langsung, namun mendukung tumpukan protokol teknologi bawaan WebRTC.

Teknologi browser dan kamera pada khususnya sangat mirip SRTP itu dienkripsi RTP. Namun untuk distribusi yang benar ke browser, kamera IP memerlukan dukungan parsial untuk tumpukan WebRTC.

Untuk menghilangkan ketidakcocokan ini, diperlukan server relai perantara, yang akan bertindak sebagai jembatan antara protokol kamera IP dan protokol browser.

Server mengambil alih aliran dari kamera IP melalui RTP/UDP dan mengirimkannya ke browser yang terhubung melalui WebRTC.

Teknologi WebRTC bekerja sesuai dengan protokol UDP dan dengan demikian memberikan penundaan arah yang rendah Server > Peramban. Kamera IP juga berfungsi menggunakan protokol RTP/UDP dan memberikan penundaan arah yang rendah Kamera > Server.

Kamera dapat menghasilkan aliran dalam jumlah terbatas karena sumber daya dan bandwidth yang terbatas. Menggunakan server perantara memungkinkan Anda menskalakan siaran dari kamera IP ke sejumlah besar pemirsa.

Di sisi lain, saat menggunakan server, dua jalur komunikasi diaktifkan:
1) Antara pemirsa dan server
2) Antara server dan kamera
Topologi ini memiliki sejumlah “fitur” atau “perangkap”. Kami mencantumkannya di bawah.

Kesalahan #1 – Codec

Codec yang digunakan dapat menjadi penghambat kinerja latensi rendah dan dapat menurunkan kinerja sistem secara keseluruhan.

Misalnya, jika kamera mengeluarkan aliran video 720p dalam H.264, dan browser Chrome di ponsel pintar Android yang hanya mendukung VP8 tersambung.

Saat transcoding diaktifkan, sesi transcoding harus dibuat untuk setiap kamera IP terhubung yang melakukan decode H.264 dan mengkodekannya Wakil Presiden8. Dalam hal ini, server prosesor ganda 16 inti hanya dapat melayani 10-15 kamera IP, dengan perkiraan kecepatan 1 kamera per inti fisik.

Oleh karena itu, jika kapasitas server tidak memungkinkan transcoding jumlah kamera yang direncanakan, maka transcoding harus dihindari. Misalnya, hanya melayani browser yang mendukung H.264, dan menawarkan browser lain untuk menggunakan aplikasi seluler asli untuk iOS atau Android yang mendukung codec H.264.

Sebagai opsi untuk melewati transcoding di browser seluler, Anda dapat menggunakan H.L.S.. Namun streaming HTTP tidak memiliki latensi rendah sama sekali dan saat ini tidak dapat digunakan untuk siaran interaktif.

Kesalahan #2 - Bitrate dan kehilangan kamera

Protokol UDP membantu mengatasi latensi, namun memungkinkan hilangnya paket video. Oleh karena itu, meskipun latensinya rendah, jika terjadi kehilangan jaringan yang besar antara kamera dan server, gambar mungkin rusak.

Untuk menghilangkan kerugian, Anda perlu memastikan bahwa aliran video yang dihasilkan oleh kamera memiliki bitrate yang sesuai dengan bandwidth khusus antara kamera dan server.

Kesalahan #3 - Kecepatan bit dan kerugian pemirsa

Setiap penampil siaran yang terhubung ke server juga memiliki bandwidth tertentu pada Download.

Jika kamera IP mengirimkan aliran yang melebihi kemampuan saluran pemirsa (misalnya, kamera mengirimkan 1Mbps, dan pemirsa hanya dapat menerima 500 Kbps), maka saluran ini akan mengalami kerugian besar dan akibatnya video macet atau artefak kuat.

Dalam hal ini, ada tiga pilihan:

1. Transkode aliran video satu per satu untuk setiap pemirsa pada kecepatan bit yang diperlukan.
2. Transkode streaming bukan untuk setiap orang yang terhubung, tetapi untuk sekelompok pemirsa.
3. Persiapkan streaming dari kamera terlebih dahulu dalam beberapa resolusi dan bitrate.

Pilihan pertama dengan transcoding tidak cocok untuk setiap penampil, karena akan menghabiskan sumber daya CPU bahkan dengan 10-15 penampil yang terhubung. Meskipun perlu dicatat bahwa opsi ini memberikan fleksibilitas maksimum dengan beban CPU maksimum. Itu. Ini adalah opsi yang ideal, misalnya, jika Anda menyiarkan streaming hanya ke 10 orang yang tersebar secara geografis, masing-masing orang menerima bitrate dinamis dan masing-masing memerlukan latensi minimal.

Pilihan kedua adalah mengurangi beban pada CPU server menggunakan grup transcoding. Server membuat beberapa grup berdasarkan bitrate, misalnya dua:

• 200 Kbps
• 1Mbps

Jika pemirsa tidak memiliki bandwidth yang cukup, ia beralih ke grup tempat ia dapat menerima streaming video dengan nyaman. Jadi, jumlah sesi transcoding tidak sama dengan jumlah penonton seperti pada kasus pertama, tetapi merupakan jumlah yang tetap, misalnya 2, jika grup transcoding dua.

Opsi ketiga melibatkan penolakan total terhadap transcoding di sisi server dan penggunaan aliran video yang sudah disiapkan dalam berbagai resolusi dan bitrate. Dalam hal ini, kamera dikonfigurasikan untuk mengeluarkan dua atau tiga aliran dengan resolusi dan kecepatan bit berbeda, dan pemirsa beralih di antara aliran tersebut bergantung pada bandwidthnya.

Dalam hal ini, beban transcoding di server hilang dan dialihkan ke kamera itu sendiri, karena Kamera sekarang dipaksa untuk menyandikan dua aliran atau lebih, bukan hanya satu.

Hasilnya, kami mempertimbangkan tiga opsi untuk menyesuaikan dengan bandwidth pemirsa. Jika kita berasumsi bahwa satu sesi transcoding memakan 1 inti server, maka kita mendapatkan tabel beban CPU berikut:

Tabel tersebut menunjukkan bahwa kita dapat mengalihkan beban transcoding ke kamera atau mentransfer transcoding ke server. Opsi 2 dan 3 sepertinya yang paling optimal.

Menguji RTSP sebagai WebRTC

Waktunya telah tiba untuk melakukan beberapa tes untuk mengidentifikasi gambaran sebenarnya dari apa yang terjadi. Mari kita ambil kamera IP asli dan lakukan pengujian untuk mengukur latensi siaran.

Untuk pengujian, mari kita ambil kamera IP kuno D-link DCS-2103 dengan dukungan tersebut RTSP dan codec H.264 dan G.711.

Karena kamera berada di lemari untuk waktu yang lama dengan perangkat dan kabel berguna lainnya, saya harus mengirimkannya ke Mengatur ulang dengan menekan dan menahan tombol di bagian belakang kamera selama 10 detik.

Setelah terhubung ke jaringan, lampu hijau pada kamera menyala dan router melihat perangkat lain di jaringan lokal dengan alamat IP 192.168.1.37.

Kami pergi ke antarmuka web kamera dan mengatur codec dan resolusi untuk pengujian:

Selanjutnya, buka pengaturan jaringan dan cari tahu alamat RTSP kamera. Dalam hal ini, alamat RTSP live1.sdp, yaitu. Kamera tersedia di rtsp://192.168.1.37/live1.sdp

Ketersediaan kamera dapat dengan mudah diperiksa menggunakan pemutar VLC. Media - Buka Aliran Jaringan.

Kami memastikan kamera berfungsi dan mentransmisikan video melalui RTSP.

Kami akan menggunakan Web Call Server 5 sebagai server untuk pengujian. Ini adalah server streaming dengan dukungan RTSP dan WebRTC protokol. Ini akan terhubung ke kamera IP melalui RTSP dan mengambil aliran video. Selanjutnya, distribusikan alirannya WebRTC.

Setelah instalasi, Anda perlu mengalihkan server ke mode RTSP tidak disisipkan yang kita bahas di atas. Hal ini dapat dilakukan dengan menambahkan pengaturan

Rtsp_interleaved_mode=salah
Pengaturan ini ditambahkan ke konfigurasi flashphoner.properties dan memerlukan reboot server:

Server panggilan web layanan dimulai ulang
Jadi, kami memiliki server yang beroperasi sesuai dengan skema non-interleaved, menerima paket dari kamera IP melalui UDP, dan kemudian mendistribusikannya melalui WebRTC (UDP).

Server pengujian terletak di server VPS yang terletak di pusat data Frankfurt, memiliki 2 core dan 2 gigabyte RAM.

Kamera terletak di jaringan lokal di 192.168.1.37.

Oleh karena itu, hal pertama yang harus kita lakukan adalah meneruskan port 554 ke alamat 192.168.1.37 untuk masuk TCP/RTSP koneksi sehingga server dapat membuat koneksi ke kamera IP kami. Untuk melakukan ini, tambahkan satu aturan saja di pengaturan router:

Aturan tersebut memberitahu router untuk mengalihkan semua lalu lintas masuk ke port 554 dan alamat IP ke 37.

Jika Anda memiliki NAT yang ramah dan mengetahui alamat IP eksternal, Anda dapat memulai pengujian dengan server.

Pemutar demo standar di browser Google Chrome terlihat seperti ini:

Untuk mulai memutar aliran RTSP, Anda hanya perlu memasukkan alamatnya di kolom Sungai kecil.
Dalam hal ini, alamat alirannya adalah: rtsp://ip-cam/live1.sdp
Di Sini ip-cam ini adalah alamat IP eksternal kamera Anda. Server akan mencoba membuat koneksi ke alamat ini.

Pengujian latensi VLC vs WebRTC

Setelah kami mengkonfigurasi kamera IP dan mengujinya VLC, mengonfigurasi server dan mengujinya RTSP mengalir melalui server dengan distribusi oleh WebRTC, kami akhirnya dapat membandingkan latensi.

Untuk melakukan ini, kita akan menggunakan pengatur waktu yang akan menampilkan sepersekian detik di layar monitor. Nyalakan pengatur waktu dan putar streaming video secara bersamaan VLC secara lokal dan di browser Firefox melalui server jarak jauh.

Ping ke server 100 ms.
Ping secara lokal 1 ms.

Tes pertama menggunakan timer terlihat seperti ini:
Pada latar belakang hitam adalah pengatur waktu asli, yang menunjukkan nol penundaan. Kiri VLC, di sebelah kanan Firefox, menerima WebRTC streaming dari server jarak jauh.

	Nol	VLC	Firefox, WCS
Waktu	50.559	49.791	50.238
Latensi ms	0	768	321

Dalam pengujian ini kami melihat penundaan sebesar VLC dua kali lebih lama dari penundaannya Firefox + Server Panggilan Web, meskipun faktanya video dalam VLC diputar di jaringan lokal, dan video yang ditampilkan di Firefox melewati server di pusat data di Jerman dan kembali lagi. Perbedaan ini mungkin disebabkan oleh fakta bahwa VLC beroperasi melalui TCP (mode interleaved) dan menyertakan beberapa buffer tambahan untuk pemutaran video yang lancar.

Kami mengambil beberapa gambar untuk mencatat nilai latensi.

Pertanyaan yang sering muncul: Bagaimana cara menghubungkan kamera IP ke NVR jika tidak ada dalam daftar kompatibilitas?

Ada dua pilihan ONVIF dan RTSP

Mari kita mulai dengan protokol ONVIF (Forum Antarmuka Video Jaringan Terbuka)

ONVIF adalah protokol yang diterima secara umum untuk pengoperasian bersama kamera IP, NVR, perangkat lunak, jika semua perangkat berasal dari produsen yang berbeda. ONVIF dapat dibandingkan dengan bahasa Inggris untuk komunikasi internasional.

Pastikan perangkat yang terhubung mendukung ONVIF; pada beberapa perangkat ONVIF mungkin dinonaktifkan secara default.
Atau otorisasi ONVIF mungkin dinonaktifkan, yang berarti login/kata sandi akan selalu default
terlepas dari login/kata sandi untuk WEB

Perlu juga dicatat bahwa beberapa perangkat digunakanport terpisah untuk operasi melalui protokol ONVIF

Dalam beberapa kasus, kata sandi ONVIF mungkin berbeda dari kata sandi akses WEB.

Apa yang tersedia saat terhubung melalui ONVIF?

Penemuan perangkat

Transmisi video

Penerimaan dan transmisi data audio

Kontrol kamera PTZ

Analisis video (misalnya deteksi gerakan)

Parameter ini bergantung pada kompatibilitas versi protokol ONVIF. Dalam beberapa kasus, beberapa parameter tidak tersedia atau tidak berfungsi dengan benar.

K dan menggunakan ONVIF

Pada perekam SNR dan Dahua, protokol ONVIF terletak di tab Perangkat Jarak Jauh, baris Produsen

Pilih saluran yang akan dihubungkan dengan perangkat

Dari tab Produsen, pilih ONVIF

Menentukan alamat IP perangkat

RTSP port tetap default

Penggunaan kamera ONVIF pelabuhan 8080
(sejak tahun 2017, pada model ONVIF baru portnya diubah menjadi 80 untuk seri Alpha dan Mira)
kamera OMNY Basis menggunakan ONVIF pelabuhan 80, di registrar itu ditunjukkan sebagai port HTTP

Nama

Kata sandi sesuai dengan parameter perangkat

Saluran jarak jauh defaultnya adalah 1. Jika perangkat multisaluran, nomor saluran akan ditunjukkan.

Penyangga Dekoder— buffering aliran video yang menunjukkan nilai waktu

Jenis serverdisini ada pilihan TCP,UDP Schedule

TCP- menjalin hubungan antara pengirim dan penerima, memastikan bahwa semua data sampai ke penerima tanpa perubahan dan dalam urutan yang diperlukan, serta mengatur kecepatan transmisi.

Berbeda dengan TCP, UDP tidak membuat sambungan awal, melainkan mulai mengirimkan data. UDP tidak memantau data yang telah diterima, dan tidak menggandakannya jika terjadi kehilangan atau kesalahan.

UDP kurang dapat diandalkan dibandingkan TCP. Namun di sisi lain, ini memberikan transmisi aliran yang lebih cepat karena tidak adanya transmisi ulang paket yang hilang

Jadwal— deteksi tipe otomatis.

Seperti inilah tampilan perangkat yang terhubung di Dahua

Status hijau berarti perekam dan kamera berhasil terhubung

Status merah berarti ada masalah koneksi. Misalnya, port koneksi salah.

Metode koneksi kedua adalah RTSP(Protokol Streaming Waktu Nyata)

RTSPprotokol streaming waktu nyata yang menjelaskan perintah untuk mengontrol aliran video.

Dengan menggunakan perintah ini, aliran video disiarkan dari sumber ke penerima

misalnya dari kamera IP ke DVR atau server.

Apa yang tersedia saat terhubung melalui RTSP?

Transmisi video

Penerimaan dan transmisi data audio

KeuntunganProtokol transfer ini tidak memerlukan kompatibilitas versi.

Saat ini RTSP didukung oleh hampir semua kamera IP dan NVR

Kekurangan Protokolnya adalah selain transmisi data video dan audio, tidak ada hal lain yang tersedia.

Mari kita lihat contoh menghubungkan kamera ke dan menggunakan RTSP

RTSP terletak di tab Perangkat Jarak Jauh, baris Pabrikan, di perekam SNR dan Dahua disajikan sebagaiUmum

Pilih saluran yang akan dihubungkan dengan perangkat

Alamat URL- di sini kita memasukkan string kueri yang dikirimkan kamera dasar Aliran RTSP dengan tinggi resolusi.

URL tambahan - Di Sini masukkan string kueri yang dikirimkan kamera tambahan Aliran RTSP dengan resolusi rendah.

Contoh permintaan:

rtsp://172.16.31.61/1 aliran utama

rtsp://172.16.31.61/2 aliran tambahan

Mengapa Anda memerlukan utas tambahan?

Pada monitor lokal yang tersambung ke perekam multi-gambar, perekam menggunakan thread tambahan untuk menghemat sumber daya. Misalnya, dalam gambar kecil dengan 16 jendela, resolusi Full HD sama sekali tidak perlu di-decode, D1 saja sudah cukup. Nah, jika Anda sudah membuka 1/4/8 windows, dalam hal ini aliran utama di-decode dengan resolusi tinggi.

Namasesuai dengan parameter perangkat

Kata sandi sesuai dengan parameter perangkat

Penyangga Dekoderbuffering aliran video yang menunjukkan nilai waktu

Jenis server- TCP, UDP, Jadwal (mirip dengan protokol ONVIF)

Artikel ini menjawab pertanyaan paling umum, seperti:

Apakah kamera IP kompatibel dengan NVR?

Dan jika kompatibel, bagaimana cara menghubungkannya!?

Memecahkan masalah penyiaran online dari kamera IP, secara umum, tidak memerlukan penggunaan WebRTC. Kamera sendiri merupakan server, memiliki alamat IP dan dapat dihubungkan langsung ke router untuk mendistribusikan konten video. Jadi mengapa menggunakan teknologi WebRTC?

Setidaknya ada dua alasan untuk ini:

1. Ketika jumlah pemirsa siaran Ethernet meningkat, pertama-tama akan dirasakan kurangnya ketebalan saluran, dan kemudian sumber daya kamera itu sendiri.

2. Seperti disebutkan di atas, kamera IP adalah server. Tapi protokol apa yang bisa digunakan untuk mengirim video ke browser desktop? Perangkat seluler? Kemungkinan besar ini adalah streaming HTTP, di mana bingkai video atau gambar JPEG ditransmisikan melalui HTTP. Streaming HTTP, seperti yang Anda tahu, tidak sepenuhnya cocok untuk streaming video real-time, meskipun telah terbukti baik dalam video Sesuai Permintaan, di mana interaktivitas dan latensi streaming tidak terlalu penting. Faktanya, jika Anda sedang menonton film, penundaan beberapa detik tidak akan memperburuk keadaan kecuali Anda menonton film tersebut pada waktu yang sama dengan orang lain. "Oh tidak! Jack membunuhnya! - Alice menulis spoiler di chat ke Bob 10 detik sebelum akhir yang tragis.”

Atau bisa berupa RTSP/RTP dan H.264, dalam hal ini plugin pemutar video seperti VLC atau QuickTime harus diinstal di browser. Plugin semacam itu akan menangkap dan memutar video, sama seperti pemutar itu sendiri. Namun kita membutuhkan streaming berbasis browser yang nyata tanpa memasang kruk/plugin tambahan.

Pertama, mari kita ambil cuplikan kamera IP untuk mengetahui apa sebenarnya yang dikirimkan perangkat ini ke browser. Subjek ujinya adalah kamera D-Link DCS 7010L:

Anda dapat membaca lebih lanjut tentang memasang dan mengonfigurasi kamera di bawah, namun di sini kita hanya akan melihat kegunaannya untuk streaming video. Saat memasuki panel admin kamera melalui antarmuka web, kami melihat sesuatu seperti ini (maaf untuk lanskapnya):

Gambar terbuka di semua browser dan membeku secara merata, sekitar satu detik sekali. Mengingat kamera dan laptop tempat kita menonton streaming terhubung ke router yang sama, semuanya seharusnya lancar dan indah, tetapi kenyataannya tidak demikian. Sepertinya HTTP. Mari kita luncurkan Wireshark untuk mengonfirmasi dugaan kita:

Di sini kita melihat urutan fragmen TCP sepanjang 1514 byte

Dan HTTP 200 OK terakhir dengan panjang JPEG yang diterima:

Kami tidak membutuhkan streaming seperti ini. Tidak lancar, menyentak permintaan HTTP. Berapa banyak permintaan per detik yang dapat ditangani kamera? Ada alasan untuk percaya bahwa pada 10 penonton atau lebih awal, kamera akan menekuk dengan aman atau mulai mengalami gangguan parah dan menghasilkan slide.

Jika Anda melihat halaman HTML panel admin kamera, Anda akan melihat kode menarik ini:

Jika(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //karena ipv6 tidak mendukung rtsp.var host = g_netip;"; //peringatan(o); DW(o); )

RTSP/RTP adalah apa yang Anda perlukan untuk pemutaran video yang tepat. Tapi apakah ini akan berfungsi di browser? - TIDAK. Namun jika Anda menginstal plugin QuickTime, semuanya akan berfungsi. Namun kami melakukan streaming murni berbasis browser.

Di sini kami juga dapat menyebutkan Flash Player, yang melalui server yang sesuai seperti Wowza, dapat menerima aliran RTMP yang dikonversi dari RTSP, RTP, H.264. Namun Flash Player, seperti yang Anda ketahui, juga merupakan plugin browser, meskipun jauh lebih populer daripada VLC atau QuickTime.

Dalam hal ini, kami akan menguji streaming ulang RTSP/RTP yang sama, tetapi browser yang kompatibel dengan WebRTC akan digunakan sebagai perangkat bermain tanpa plugin browser tambahan atau kruk lainnya. Kami akan menyiapkan server relai yang akan mengambil aliran dari kamera IP dan mengirimkannya ke Internet ke sejumlah pengguna menggunakan browser yang mendukung WebRTC.

Menghubungkan kamera IP

Seperti disebutkan di atas, kamera IP D-Link DCS-7010L sederhana dipilih untuk pengujian. Kriteria pemilihan utama di sini adalah dukungan perangkat terhadap protokol RTSP, karena melalui inilah server kami akan menerima aliran video dari kamera.

Kami menghubungkan kamera ke router menggunakan kabel patch yang disertakan. Setelah menyalakan daya dan menghubungkan ke router, kamera mengambil alamat IP melalui DHCP, dalam kasus kami adalah 192.168.1.34 (Jika Anda masuk ke pengaturan router, Anda akan melihat bahwa perangkat DCS 7010L terhubung - itu saja ). Saatnya menguji kamera.

Buka alamat IP yang ditentukan di browser 192.168.1.34 untuk masuk ke antarmuka web administrator kamera. Secara default tidak ada kata sandi.

Seperti yang Anda lihat, video dari kamera disiarkan dengan benar di panel admin. Pada saat yang sama, guncangan berkala terlihat. Inilah yang akan kami perbaiki menggunakan WebRTC.

Pengaturan kamera

Pertama, kami menonaktifkan otentikasi di pengaturan kamera - sebagai bagian dari pengujian, kami akan memberikan aliran kepada semua orang yang bertanya. Untuk melakukan ini, buka pengaturan di antarmuka web kamera Pengaturan - Jaringan dan atur nilai opsi Otentikasi untuk Menonaktifkan.

Di sana kami juga memeriksa nilai port protokol RTSP; secara default adalah 554. Format video yang dikirimkan ditentukan oleh profil yang digunakan. Anda dapat mengatur hingga tiga di antaranya di kamera, kami akan menggunakan yang pertama, live1.sdp - secara default dikonfigurasi untuk menggunakan H.264 untuk video dan G.711 untuk audio. Anda dapat mengubah pengaturan jika perlu di bagian tersebut Pengaturan – Audio dan Video.

Sekarang Anda dapat memeriksa pengoperasian kamera melalui RTSP. Buka VLC Player (Anda dapat menggunakan pemutar lain yang mendukung RTSP - QuickTime, Windows Media Player, RealPlayer, dll.) dan dalam dialog Buka URL atur alamat RTSP kamera: rtsp://192.168.1.34/live1.sdp

Yah, semuanya berjalan sebagaimana mestinya. Kamera secara teratur memutar aliran video di pemutar melalui protokol RTSP.

Omong-omong, streaming diputar dengan cukup lancar dan tanpa artefak. Kami mengharapkan hal yang sama dari WebRTC.

Instalasi server

Jadi, kamera sudah terpasang, diuji dengan pemutar desktop dan siap disiarkan melalui server. Menggunakan whatismyip.com kami menentukan alamat IP eksternal kamera. Dalam kasus kami adalah 178.51.142.223. Yang tersisa hanyalah memberi tahu router bahwa ketika mengakses melalui RTSP pada port 554, permintaan masuk akan dikirimkan ke kamera IP.

Masukkan pengaturan yang sesuai ke dalam router...

...dan periksa alamat IP eksternal dan port RTSP menggunakan telnet:

Telnet 178.51.142.223 554

Setelah memastikan ada respon pada port ini, kami melanjutkan untuk menginstal server WebRTC.

Server virtual pada Centos 64 bit di Amazon EC2 akan bertanggung jawab untuk hosting.
Untuk menghindari masalah kinerja, kami memilih instans m3.medium dengan satu VCPU:

Iya, ada juga Linode dan DigitalOcean, tapi dalam hal ini saya ingin mencoba Amazon.
Ke depan, saya akan menulis bahwa di panel kontrol Amazon EC2 Anda perlu menambahkan beberapa aturan (port maju), yang tanpanya contoh tidak akan berfungsi. Ini adalah port untuk lalu lintas WebRTC (SRTP, RTCP, ICE) dan port untuk lalu lintas RTSP/RTP. Jika Anda mencobanya, aturan Amazon seharusnya memiliki hal serupa untuk lalu lintas masuk:

Omong-omong, dengan DigitalOcean semuanya akan lebih sederhana, cukup buka port ini di firewall atau matikan yang terakhir. Berdasarkan pengalaman terbaru dalam mengoperasikan instans DO, instans DO masih mengeluarkan alamat IP statis dan tidak mengganggu NAT, yang berarti penerusan porta, seperti dalam kasus Amazon, tidak diperlukan.

Kami akan menggunakan WebRTC Media & Broadcasting Server dari Flashphoner sebagai perangkat lunak server yang meneruskan aliran RTSP/RTP ke WebRTC. Server streaming sangat mirip dengan Wowza, yang dapat mengalirkan aliran RTSP/RTP ke Flash. Satu-satunya perbedaan adalah aliran ini akan dikirim ke WebRTC, bukan ke Flash. Itu. DTLS yang jujur ​​​​akan lewat antara browser dan server, sesi SRTP akan dibuat dan aliran yang dikodekan dalam VP8 akan menuju ke penampil.

Untuk instalasi kita memerlukan akses SSH.

Di bawah spoiler adalah penjelasan rinci tentang perintah yang dijalankan

1. Mengunduh arsip instalasi server:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Diperluas:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Terpasang:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Selama proses instalasi, kami memasukkan alamat IP eksternal server: 54.186.112.111 dan internal 172.31.20.65 (sama dengan IP Pribadi).
4. Memulai server:
$layanan webcallserver dimulai
5. Memeriksa log:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Pastikan server sudah mulai dan siap bekerja:
$ps tambahan | grep Flashphoner
7. Menginstal dan meluncurkan apache:
$yum instal httpd
$layanan httpd mulai
8. Mengunduh file web dan menempatkannya di folder standar Apache /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Masukkan alamat IP server ke dalam konfigurasi flashphoner.xml:
10. Menghentikan firewall.
$layanan iptables berhenti

Secara teori, alih-alih poin 10, yang terbaik adalah menetapkan semua port dan aturan firewall yang diperlukan, tetapi untuk tujuan pengujian kami memutuskan untuk menonaktifkan firewall saja.

Penyetelan Server

Ingatlah bahwa struktur siaran WebRTC kami adalah sebagai berikut:

Kami telah memasang elemen utama diagram ini; yang tersisa hanyalah menetapkan “panah” interaksi.

Koneksi antara browser dan server WebRTC disediakan oleh klien web, yang tersedia di Github :. Satu set file JS, CSS, dan HTML dimasukkan begitu saja /var/www/html pada tahap instalasi (lihat poin 9 di atas di bawah spoiler).

Interaksi antara browser dan server dikonfigurasi dalam file konfigurasi XML flashphoner.xml. Di sana Anda perlu memasukkan alamat IP server agar klien web dapat terhubung ke server WebRTC melalui HTML5 Websockets (poin 9 di atas).

Penyiapan server berakhir di sini, Anda dapat memeriksa pengoperasiannya:

Buka halaman klien web index.html di browser (untuk ini, Apache diinstal pada server Amazon yang sama dengan perintah enak -y instal httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Di Sini webrtc-ipcam.ddns.net adalah domain gratis yang diperoleh melalui server DNS dinamis noip.com, yang tertaut ke alamat IP eksternal kami. Kami menyuruh router untuk mengalihkan permintaan RTSP ke 192.168.1.34 sesuai dengan aturan terjemahan alamat jaringan NAT (lihat juga di atas).
Parameter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp menentukan URL aliran yang akan diputar. Server WebRTC akan meminta streaming dari kamera, memprosesnya, dan mengirimkannya ke browser untuk diputar melalui WebRTC. Mungkin router Anda mendukung DDNS. Jika tidak, maka kamera IP itu sendiri memiliki dukungan berikut:

Dan seperti inilah dukungan DDNS di router itu sendiri:

Sekarang Anda dapat mulai menguji dan mengevaluasi hasilnya.

Pengujian

Setelah membuka tautan di browser, koneksi dibuat ke server WebRTC, yang mengirimkan permintaan ke kamera IP untuk menerima aliran video. Seluruh proses memakan waktu beberapa detik.

Pada saat ini, koneksi dibuat antara browser dan server melalui websockets, kemudian server meminta kamera IP melalui RTSP, menerima aliran H.264 melalui RTP dan mentranskodenya menjadi VP8 / SRTP - yang pada akhirnya memutar browser WebRTC.

Di bagian bawah video, URL aliran video ditampilkan, yang dapat disalin dan dibuka untuk dilihat dari browser atau tab lain.

Kami memastikan bahwa ini benar-benar WebRTC.

Bagaimana jika kita tertipu, dan video dari kamera IP dikirimkan lagi melalui HTTP? Mari kita tidak iseng melihat gambarnya, tapi mari kita periksa lalu lintas seperti apa yang sebenarnya kita terima. Tentu saja, kami meluncurkan Wireshark dan konsol debugging di Chrome lagi. Di konsol browser Chrome kita dapat melihat yang berikut:

Kali ini tidak ada yang berkedip dan tidak ada gambar yang terlihat dikirimkan melalui HTTP. Yang kita lihat kali ini hanyalah frame Websocket dan sebagian besar merupakan tipe ping/pong untuk mempertahankan sesi Websocket. Bingkai yang menarik: sambungkan, siapkanRtspSession, dan onReadyToPlay - ini adalah urutan pembuatan koneksi ke server: pertama koneksi Websocket, dan kemudian permintaan streaming untuk pemutaran.

Inilah yang ditunjukkannya chrome://webrtc-internal

Menurut grafik, kami memiliki bitrate dari kamera IP sebesar 1Mbps. Ada juga lalu lintas keluar, kemungkinan besar adalah paket RTCP dan ICE. RTT ke server Amazon adalah sekitar 300 milidetik.

Sekarang mari kita lihat Wireshark, Anda dapat dengan jelas melihat lalu lintas UDP dari alamat IP server. Pada gambar di bawah, paketnya berukuran 1468 byte. Ini adalah WebRTC. Lebih tepatnya, paket SRTP membawa frame video VP8, yang bisa kita amati di layar browser. Selain itu, permintaan STUN lolos (paket terendah dalam gambar) - ini adalah WebRTC ICE yang memeriksa koneksi dengan cermat.

Perlu juga diperhatikan latensi yang relatif rendah (ping ke pusat data sekitar 250 ms) untuk pemutaran video. WebRTC bekerja melalui SRTP/UDP, dan ini adalah cara tercepat untuk mengirimkan paket, tidak seperti HTTP, RTMP, dan metode streaming mirip TCP lainnya. Itu. Penundaan yang terlihat oleh mata haruslah RTT + waktu buffering, decoding, dan pemutaran oleh browser. Secara visual, inilah yang terjadi - mata hampir tidak melihat penundaan, kurang dari 500 milidetik.

Tes selanjutnya adalah menghubungkan pemirsa lain. Saya berhasil membuka 10 jendela Chrome, dan masing-masing jendela menampilkan gambar. Pada saat yang sama, Chrome sendiri mulai menjadi sedikit membosankan. Saat membuka jendela ke-11 di komputer lain, pemutaran tetap lancar.

Tentang WebRTC di perangkat seluler

Seperti yang Anda ketahui, WebRTC didukung oleh browser Chrome dan Firefox di platform Android.
Mari kita periksa apakah siaran kita akan ditampilkan di sana:

Gambar menunjukkan ponsel HTC; browser Firefox menampilkan video dari kamera. Tidak ada perbedaan kelancaran pemutaran dengan desktop.

Kesimpulan

Hasilnya, kami dapat meluncurkan siaran online WebRTC dari kamera IP ke beberapa browser dengan sedikit usaha. Tidak diperlukan menari dengan rebana atau ilmu roket - hanya pengetahuan dasar tentang Linux dan konsol SSH.

Kualitas siaran berada pada tingkat yang dapat diterima, dan penundaan pemutaran tidak terlihat oleh mata.

Ringkasnya, kita dapat mengatakan bahwa siaran WebRTC berbasis browser berhak untuk ada, karena dalam kasus kami, WebRTC bukan lagi penopang atau plugin, tetapi platform nyata untuk memutar video di browser.

Mengapa kita tidak melihat adopsi WebRTC secara luas?

Kendala utamanya mungkin adalah kurangnya codec. Komunitas dan vendor WebRTC harus berupaya dan memperkenalkan codec H.264 ke WebRTC. Tidak ada yang menentang VP8, tapi mengapa harus melepaskan jutaan perangkat dan perangkat lunak yang kompatibel yang bekerja dengan H.264? Paten, paten semacam itu...

Di tempat kedua adalah tidak adanya dukungan penuh di browser. Dengan IE dan Safari, misalnya, pertanyaannya tetap terbuka dan di sana Anda harus beralih ke jenis streaming lain atau menggunakan plugin seperti webrtc4all.

Jadi di masa mendatang, kami berharap dapat melihat solusi yang lebih menarik yang tidak memerlukan transcoding dan konversi streaming, dan sebagian besar browser dapat memutar streaming dari berbagai perangkat secara langsung.

Kenyamanan menonton siaran video atau dapat dikonfigurasi menggunakan perangkat lunak pemutar multimedia di komputer pribadi Anda. Hari ini kita akan melihat cara mengkonfigurasi aliran RTSP untuk peralatan jaringan Dahua Technology di salah satu pemain paling populer, VLC Media Player.

RTSP (Real Time Streaming Protocol) adalah protokol yang memungkinkan pengguna memutar aliran data multimedia (audio dan video) dari jarak jauh menggunakan hyperlink dan pemutar multimedia (dalam kasus kami, VLC Media Player).

Jika Anda perlu mengonfigurasi streaming video, gunakan langkah-langkah berikut:

1. Pertama-tama, Anda perlu mengunduh dan menginstal VLC Media Player, yang tersedia secara gratis di situs resminya.
2. Klik pada item menu Media – Buka Aliran Jaringan (URL Terbuka).
3. Masukkan alamat jaringan RTSP di baris prompt.
4. Tekan tombol putar ketika gambar video muncul di layar.

Penjelasan tautannya RTSP

Contoh:

rtsp: // :@:/cam/realmonitor?saluran= &subtipe=

Di mana :

: Nama pengguna (login).

: kata sandi.

: Alamat IP kamera video jaringan.

: Port default adalah 554. Nilai ini dapat diabaikan.

: nomor saluran. Penomoran dimulai dari 1.

: jenis aliran. Arti thread utama adalah 0, thread tambahan 1 adalah 1, thread tambahan 2 adalah 2. Misalnya, link untuk thread tambahan nomor 1 adalah sebagai berikut:

rtsp://admin: [dilindungi email]:554/cam/realmonitor?channel=1&subtipe=1

Kamera video IP Teknologi Dahua mendukung protokol transfer data TCP dan UDP. Jika port 554 telah diubah, ubahlah di bidang yang sesuai pada pengaturan kamera video (antarmuka web).

Jika Anda mengalami masalah dalam menyiapkan aliran RTSP, silakan merujuk ke bagian yang sesuai.

RTSP (Protokol Streaming Waktu Nyata)– protokol streaming waktu nyata yang berisi serangkaian perintah dasar sederhana untuk mengontrol aliran video.

Menghubungkan sumber RTSP dan kamera IP dalam konferensi video

Protokol RTSP memungkinkan setiap pengguna TrueConf untuk terhubung ke kamera video IP dan sumber konten media lainnya yang menyiarkan menggunakan protokol ini untuk memantau objek jarak jauh. Pengguna juga dapat terhubung ke kamera tersebut untuk menyiarkan gambar selama konferensi video.

Berkat dukungan protokol RTSP, pengguna TrueConf Server tidak hanya dapat terhubung ke kamera IP, tetapi juga menyiarkan konferensi video ke pemutar RTSP dan server media. Baca lebih lanjut tentang siaran RTSP.

Manfaat menggunakan kamera IP dengan solusi perangkat lunak TrueConf

• Dengan memasang kamera IP di kantor atau bengkel industri dan menghubungkannya kapan saja, Anda akan dapat mengontrol proses produksi perusahaan Anda.
• Anda dapat memonitor objek jarak jauh sepanjang waktu. Misalnya, jika Anda akan berlibur dan tidak ingin meninggalkan apartemen tanpa pengawasan, cukup pasang satu atau lebih kamera IP di sana. Dengan melakukan panggilan ke salah satu kamera ini dari PC Anda dengan aplikasi klien TrueConf terinstal, Anda dapat terhubung ke apartemen Anda kapan saja dan melihat secara real time apa yang terjadi di sana.
• Dalam aplikasi klien TrueConf untuk Windows, Linux dan macOS, semua pengguna memiliki akses ke kemampuan merekam konferensi video, berkat itu selama pengawasan video Anda dapat merekam peristiwa apa pun dan menerima bukti dokumenter tentangnya.