Dua pertanyaan tersembunyi di dalam “apakah semua ini akan bekerja bersama”. Yang pertama adalah apakah perekam akan menerima kamera itu sama sekali — penemuan, stream, gambar di layar. Yang kedua, yang menentukan apakah sistemnya menyenangkan untuk dimiliki, adalah apakah semua yang dilakukan kamera bertahan dalam perjalanan: peristiwa, kendali PTZ, sub-stream yang dipakai grid, jadwal perekaman. Standar terbuka menjawab pertanyaan pertama dengan andal dan pertanyaan kedua hanya sebagian, dan mengetahui mana yang mana itulah yang mencegah sistem campuran menjadi masalah pemeliharaan.
Alasan untuk mencampur itu biasa, bukan eksotis. Gedung diperluas dan sayap barunya mendapat kamera modern; perekam mencapai akhir masa pakainya tetapi kamera di dinding baru berusia tiga tahun dan masih bekerja; klien ingin berganti merek tanpa menarik ulang kabel di lima lantai. Dalam setiap kasus pertanyaannya sama: berapa banyak dari sistem yang ada yang tetap, dan apa yang harus diterima sebagai berbeda.
Apa itu ONVIF, dan apa yang tidak dijaminnya?
ONVIF adalah standar interoperabilitas: ia mendefinisikan bagaimana sebuah perangkat menggambarkan dirinya di jaringan dan bagaimana perangkat lain memintanya sebuah stream, menggerakkan kepala PTZ, atau berlangganan peristiwa. Perangkat yang membawa tanda kesesuaian telah lulus uji untuk profil yang diklaimnya. Itu jaminan yang bermakna — artinya dua perangkat dari pabrikan berbeda berbagi bahasa dan seperangkat perintah yang sama.
Yang tidak dijaminnya adalah kesetaraan fitur. Standar mendefinisikan antarmuka, bukan implementasi: sebuah kamera dapat mengekspos PTZ melalui ONVIF dan sebuah perekam dapat menerimanya, sementara analitik di kamera atau fitur berbasis aplikasi milik pabrikan tidak pernah muncul sama sekali di perekam pihak ketiga. Kesesuaian adalah soal percakapan, bukan soal setiap kalimat yang dapat diucapkan kedua pihak.
Profil ONVIF mana yang penting pada sistem gedung?
| Profil | Apa yang dicakupnya | Di mana Anda menjumpainya |
|---|---|---|
| Profile S | Streaming: konfigurasi, penemuan, video langsung, dan audio | Titik acuan agar kamera muncul di perekam merek lain |
| Profile T | Streaming lanjutan: H.265, multi-stream, dan metadata | Kamera modern yang menawarkan stream utama dan sub-stream ke perekam pihak ketiga |
| Profile G | Kendali perekaman dan penyimpanan di sisi perangkat | Tempat rekaman dan pengambilannya dikelola di kamera atau penyimpanannya sendiri |
Untuk sistem gedung, asumsi kerjanya sederhana: asumsikan Profile S, periksa T jika Anda berniat merekam codec modern melalui perekam pihak ketiga, dan perlakukan G sebagai pertanyaan tentang penyimpanan tepi alih-alih tentang perekam di kabinet.
Mengapa RTSP adalah pintu yang biasanya terbuka?
Jika ONVIF adalah bahasa, RTSP sering menjadi jalur langsung: URL yang meminta stream kepada kamera, dalam bentuk alamat, port, dan jalur. Port-nya secara konvensional 554; jalurnya spesifik untuk firmware setiap pabrikan dan diterbitkan dalam dokumentasi kamera itu sendiri. Dua hal mengikutinya untuk sistem campuran. Pertama, RTSP bekerja di tempat integrasi yang lebih kaya tidak bekerja, yang menjadikannya jalur cadangan yang menjaga sistem campuran tetap hidup. Kedua, karena jalurnya spesifik per pabrikan, ia didokumentasikan per kamera alih-alih diasumsikan.
Kamera seperti yang kami bangun mengekspos stream utama dan sub-stream melalui antarmuka itu. Stream utama adalah yang layak direkam pada 5 MP; sub-stream adalah yang seharusnya dipakai grid tampilan langsung dan klien seluler, karena dinding berisi puluhan jendela mungil tidak membutuhkan resolusi penuh dan tidak seharusnya membayarnya dalam bandwidth. Sistem campuran yang sub-stream-nya dibiarkan mati adalah sistem campuran yang terasa lambat karena alasan yang tidak ada hubungannya dengan merek.
Apa yang bertahan di sistem campuran, dan apa yang tidak?
| Kemampuan | Melalui antarmuka terbuka | Catatan jujurnya |
|---|---|---|
| Tampilan langsung dan perekaman | Ya | Kasus yang umum, dan yang menjadi alasan standar ini ditulis |
| Kendali PTZ | Ya, di tempat kamera mengeksposnya | Preset dan tur dapat berperilaku berbeda antar klien |
| Peristiwa gerakan | Gerakan dasar, biasanya | Lintas garis, intrusi, dan analitik serupa sering tetap di dalam klien milik pabrikan |
| Audio dua arah | Kadang-kadang | Bergantung pada kedua ujung yang mendukung jalur audio yang sama |
| Aplikasi seluler dan klien | Tidak | Aplikasi setiap pabrikan hanya melihat perangkat kerasnya sendiri; sistem campuran biasanya berarti dua aplikasi, atau satu perekam yang menerbitkan satu aplikasi |
| Firmware dan pembaruan | Tidak | Selalu terpisah, selalu per merek |
Apa saja tiga cara menjalankan sistem campuran?
- Pertahankan kameranya, ganti perekamnya. Migrasi yang paling umum, dan yang paling murah direncanakan: perekam di rangkaian kami berbicara ONVIF, RTSP, GB28181, dan P2P, sehingga kamera yang ada yang mengekspos salah satu antarmuka itu dapat didaftarkan dan direkam. Ganti perekamnya, pertahankan jadwal kameranya, dan pengkabelannya tidak berubah.
- Pertahankan perekamnya, ganti kameranya. Daftarkan kamera baru ke perekam yang ada melalui ONVIF atau RTSP, satu kanal setiap kali. Kamera lama tetap berjalan sampai setiap posisi siap, yang berarti gedung tidak pernah buta selama perubahan.
- Jalankan keduanya selama serah terima. Perekam lama dan perekam baru di jaringan yang sama untuk suatu periode, sehingga tidak ada yang hilang selama perubahannya diverifikasi. Ini membutuhkan pengalamatan cadangan dan seseorang yang memahami sistem mana yang merekam apa — sepadan di tempat yang klaimnya bisa diajukan pada jendela peralihan itu.
Di mana sistem campuran gagal dalam praktik?
Kegagalannya jarang soal merek dan hampir selalu soal konfigurasi. Sub-stream yang dibiarkan mati, sehingga perekam menarik stream utama untuk setiap kanal dan batas bandwidth tiba lebih awal — pada perekam kami yang lebih besar, bandwidth masuknya 64 Mbps, yang nyaman untuk sebuah gedung dan sesuatu yang Anda jumpai di sekitar kanal 5 MP ketiga puluh jika semuanya direkam pada laju penuh. Ketidakcocokan codec, ketika satu ujung menawarkan H.265 dan ujung lain mengharapkan H.264. Pengalamatan ganda, ketika dua server DHCP berbagi satu jaringan selama migrasi dan sebuah kamera menjawab alamat yang diklaim orang lain. Pergeseran jam, yang diam-diam membuat timeline tidak dapat diandalkan sampai seseorang mengaktifkan NTP di semua perangkat. Kredensial dan batas sesi, ketika perekam meminta lebih banyak stream simultan kepada kamera daripada yang diizinkan firmware-nya.
Apa saja yang masuk daftar periksa migrasi?
- Daftar apa yang tetap dan apa yang berubah, dan tuliskan mata rantai mana dari kelima rantai — kamera, switch, kabel, perekam, klien — yang disentuh perubahan itu.
- Konfirmasikan antarmuka di kedua ujung: profil ONVIF, ketersediaan RTSP, dan codec yang direkam masing-masing pihak.
- Periksa bandwidth masuk perekam terhadap jumlah kanal dan resolusi yang direkam, bukan terhadap jumlah kamera saja.
- Setel NTP di setiap perangkat sebelum commissioning, agar timeline-nya dapat dipercaya sejak hari pertama.
- Pindahkan satu kanal lebih dulu, dan pantau sepanjang malam, sebelum menyerahkan sisanya.
- Biarkan akses ke sistem lama tetap tersedia sampai uji serah terima ditandatangani.
Kompatibilitas bukan sifat ya-atau-tidak dari sebuah merek; ia adalah daftar antarmuka dan pengaturan yang entah sejalan atau tidak. Kerjakan kanal per kanal dan sistem campuran menjadi biasa saja — itulah intinya.