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 kolaborasi kamera IP, NVR, perangkat lunak, jika semua perangkat berasal dari produsen yang berbeda. ONVIF dapat dibandingkan dengan Bahasa inggris untuk komunikasi internasional antar manusia.

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(PTZ)

Analisis video (seperti 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

Dalam 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 koneksi 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!?

Protokol RTSP

RTSP (Protokol Streaming Waktu Nyata, atau, dalam bahasa Rusia, protokol streaming waktu nyata) adalah protokol aplikasi yang menjelaskan perintah untuk mengontrol aliran video. Dengan menggunakan perintah ini, kita dapat “memerintahkan” kamera atau server, misalnya, untuk mulai menyiarkan streaming video. Contoh permintaan untuk memulai pemutaran terlihat seperti ini: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

Artinya, RTSP hanyalah sekumpulan perintah untuk mengendalikan aliran video. Mari kita melakukan percobaan. Untuk melakukan ini, kita memerlukan kamera IP yang mendukung protokol RTSP dan alamat RTSP-nya. Alamat ini terlihat seperti ini: rtsp:// /mpeg. Anda dapat menemukannya di manual kamera atau di deskripsi API. Untuk kenyamanan, kami akan mencantumkan alamat RTSP untuk sejumlah kamera populer di tabel. Setelah kami mengetahui alamat RTSP kamera, kami membuka pemutar standar yang mendukung RTSP. Ini bisa berupa salah satu program berikut: Windows Media Player, QuickTime, Media Pemain Klasik, VLC pemutar media, Pemain Nyata, Pemain MP. Kami memilih QuickTime. Buka menu “File > Open URL” dan masukkan alamat RTSP kami. QuickTime kemudian akan terhubung ke kamera dan memutar video langsung. Perangkat perekam yang beroperasi dalam sistem pengawasan video IP menerima video dari kamera baik menggunakan protokol HTTP - yaitu, dengan cara yang sama seperti kita mengunduh gambar JPEG dari situs web, atau sebagai streaming melalui RTSP - dengan cara yang sama seperti kita menerimanya menggunakan standar pemain dalam contoh terakhir. Dalam pengaturan kamera IP, opsi streaming untuk transmisi data dapat ditetapkan sebagai RTSP melalui TCP, RTSP melalui UDP, atau hanya RTP. Jadi, RTSP adalah sekumpulan perintah untuk pengendalian aliran. Tapi apa arti singkatan lainnya: TCP, UDP, RTP? TCP, UDP dan RTP adalah mekanisme transport (protokol) yang benar-benar mengirimkan video.

protokol TCP

Katakanlah kita telah memilih metode RSTP melalui TCP dan ingin mulai mentransmisikan aliran video. Apa yang akan terjadi pada tingkat mekanisme transportasi? Pertama, dengan menggunakan beberapa perintah, koneksi akan dibuat antara pengirim dan penerima. Setelah ini, transfer data video akan dimulai. Pada saat yang sama, mekanisme TCP

akan memastikan bahwa semua data sampai ke penerima tanpa perubahan dan dalam urutan yang diperlukan. TCP juga akan mengatur kecepatan transmisi agar pengirim tidak mengirimkan data lebih banyak dari yang dapat diproses oleh penerima, misalnya saja

UDP adalah alternatif transportasi protokol TCP. Tidak seperti TCP, UDP tidak membuat koneksi awal, melainkan mulai mengirimkan data. UDP tidak memastikan bahwa data diterima dan tidak menggandakannya jika ada bagian yang hilang atau tiba dengan kesalahan. UDP lebih sedikit

lebih dapat diandalkan dibandingkan TCP. Namun di sisi lain, ini memberikan transmisi aliran yang lebih cepat karena tidak adanya mekanisme untuk mengirimkan ulang paket yang hilang. Perbedaan protokol TCP dan UTP dapat diilustrasikan pada contoh berikut. Dua teman bertemu. Opsi TCP:

Ivan: “Halo! Bagaimana kalau kita ngobrol? (koneksi terjalin)
Semyon: “Halo! Ayo!" (koneksi terjalin)
Ivan: “Saya berada di toko kemarin. Apakah kamu mengerti? (transfer data)
Semyon: “Ya!” (konfirmasi)
Ivan: “Peralatan baru diturunkan di sana. Apakah kamu mengerti? (transfer data)
Semyon: “Tidak” (konfirmasi)
Ivan: “Peralatan baru diturunkan di sana. Apakah kamu mengerti? (transmisi ulang)
Semyon: “Ya!” (konfirmasi)
Ivan: “Besok saya akan kesana lagi. Apakah kamu mengerti? (transfer data)
Semyon: “Ya!” (konfirmasi)
Opsi UDP
Ivan: “Halo! Saya berada di toko kemarin" (transfer data)
Ivan: “Peralatan baru diturunkan di sana” (transfer data)
Ivan : “Besok saya kesana lagi” (transfer data)
Ivan: “Saya bisa mengetahui harga untuk Anda” (transfer data)
Ivan: “Mereka menjanjikan diskon untuk volume yang bagus” (transfer data)
Ivan: “Jika kamu mau, teleponlah - kita akan pergi bersama” (transfer data)
Semyon: “Ya, saya akan menelepon” (transfer data)

Anda juga dapat melihat perbedaan protokol dengan melakukan percobaan berikut: coba atur kamera ke RTSP melalui mode TCP dan lambaikan tangan Anda di depan lensa - Anda akan melihat penundaan di layar monitor. Sekarang jalankan tes yang sama di RTSP melalui mode UDP. Penundaannya akan lebih sedikit. Latensi dipengaruhi oleh beberapa faktor: format kompresi, daya komputer, protokol transmisi, dan fitur perangkat lunak yang terlibat dalam decoding video.

RTP (Protokol Transportasi Waktu Nyata), atau dalam bahasa Rusia protokol transportasi waktu nyata. Protokol ini dibuat khusus untuk mentransmisikan lalu lintas waktu nyata. Ini memungkinkan Anda untuk memantau sinkronisasi data yang dikirimkan, menyesuaikan urutan pengiriman paket, dan oleh karena itu lebih cocok daripada yang lain untuk mentransmisikan data video dan audio. Secara umum, lebih baik menggunakan RTP atau UDP untuk mengirimkan aliran video. Bekerja melalui TCP dibenarkan hanya jika kita harus bekerja dengan jaringan yang bermasalah, karena protokol TCP akan dapat memperbaiki kesalahan dan kegagalan yang terjadi selama transfer data.

RTSP (Protokol Streaming Waktu Nyata)– protokol streaming waktu nyata yang berisi serangkaian sederhana perintah utama 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.

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 memilikinya 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 yang berdiri sendiri yang terhubung sepenuhnya ke jaringan dan tidak memerlukan koneksi ke perangkat lain, dan dapat menyiarkan langsung 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 real-time, 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 ditransmisikan melalui protokol TCP secara internal 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 untuk menskalakan siaran dari kamera IP ke jumlah besar penonton.

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 streaming video 720p dalam H.264, dan browser Chrome tersambung ke ponsel pintar Android dengan dukungan untuk VP8 saja.

Saat transcoding diaktifkan, sesi transcoding harus dibuat untuk setiap kamera IP terhubung yang melakukan dekode 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 browser asli aplikasi seluler untuk iOS atau Android, yang mendukung codec H.264.

Sebagai opsi untuk melewati transcoding peramban seluler, dapat digunakan 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 kekhasan tersendiri keluaran di Unduh.

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. Siapkan aliran kamera terlebih dahulu dalam beberapa resolusi dan bitrate.

Opsi 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 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 masuk jaringan lokal dengan alamat IP 192.168.1.37.

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

Selanjutnya kita pergi ke 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 menurut 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 sambungan ke alamat ini.

Pengujian latensi VLC vs WebRTC

Setelah kami mengkonfigurasi kamera IP dan mengujinya VLC, mengkonfigurasi server dan menguji 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 seterusnya peramban 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, 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 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.