Dari hari-hari pertama mengusahakan sistem pengawasan video awan, kami berhadapan dengan masalah, tanpa penyelesaian yang boleh kami tinggalkan di Ivideon - ini adalah Everest kami, pendakian yang mengambil banyak tenaga, tetapi kini kami akhirnya berjaya melekatkan kapak ais ke bahagian atas teka-teki silang platform.
Sistem untuk menghantar audio dan video melalui Internet tidak seharusnya bergantung pada peralatan, pelanggan Web dan piawaian yang mereka sokong, dan juga berfungsi dengan betul dengan kehadiran Penterjemah Alamat Rangkaian dan tembok api. Pengguna pengawasan video awan ingin mengakses perkhidmatan itu, walaupun dia menggunakan kamera analog, dan lebih suka menonton siaran video secara langsung pada peranti paling moden.
Adalah sangat penting bahawa pengguna ingin menonton video dengan kelewatan yang minimum. Hampir satu-satunya cara untuk menunjukkan video dengan kependaman rendah dalam penyemak imbas ialah menggunakan WebRTC (komunikasi masa nyata web). WebRTC ialah satu set teknologi untuk penghantaran video dan audio peer-to-peer dalam penyemak imbas, pada mulanya direka untuk penghantaran dan main balik strim video dengan kependaman rendah. Untuk tujuan ini, antara lain, protokol UDP digunakan.
Sebelum kami memberitahu anda apa yang diberikan oleh enjin baharu kepada pengguna, kami akan mengingatkan anda sebab dan sebab kami menyokong teknologi HLS, dan sebab kami memutuskan untuk meneruskan.
Enjin HLS: kebaikan dan keburukan
()
Teknologi HLS (HTTP Live Streaming) telah dibangunkan oleh Apple, jadi tidak hairanlah ia pertama kali disokong pada peranti Apple. Hari ini, video HLS juga disokong oleh hampir semua kotak set-top dan banyak peranti yang menjalankan OS tersebut. Android.
Enjin HLS menggunakan codec video H264 yang terkenal dalam kombinasi dengan strim audio AAC atau MP3 untuk menstrim data video. Seluruh aliran data audio dan video dibungkus ke dalam bekas pengangkutan MPEG-TS. Untuk penghantaran melalui protokol HTTP, maklumat yang terkandung dalam strim dibahagikan kepada serpihan yang diterangkan dalam senarai main m3u8. Dan hanya kemudian serpihan ini, bersama-sama dengan senarai main, dihantar melalui HTTP. Chunking secara automatik bermaksud kelewatan dalam beberapa saat. Ini adalah ciri bekas MPEG-TS.
Enjin HLS juga menyokong aliran berbilang bit, Langsung/VOD.
Kelebihan utama HLS:
- sokongan terbina dalam semua pelayar utama;
- kemudahan pelaksanaan (berbanding dengan WebRTC);
- Adalah sangat mudah dan cekap untuk mengatur semua jenis siaran kepada khalayak yang besar kerana fakta bahawa segmen boleh dimuat naik ke CDN sekali.
Walaupun kesederhanaan enjin, tidak semuanya lancar seperti yang kelihatan. Masalah utama ialah pembangun pemain pihak ketiga telah beralih daripada cadangan Apple, contohnya dari segi format audio yang disokong. Khususnya, ramai pembangun mula menambah keupayaan untuk bekerja dengan strim audio popular: video mpeg2, audio mpeg2, dll. Akibatnya, mereka terpaksa mencipta format senarai main yang berbeza untuk pemain yang berbeza.
Tetapi salah satu masalah terbesar dengan enjin HLS ialah kependaman yang tinggi dalam pemindahan data.
Asal-usul "brek"
Sebab utama kependaman tinggi HLS terletak pada fakta bahawa pengaturcara mencipta enjin untuk mendapatkan imej berkualiti tinggi. Oleh itu, parameter selang bingkai yang digunakan dan saiz penimbal main balik sememangnya tidak sesuai untuk siaran video secara langsung. Disebabkan ini, terdapat kelewatan yang agak tinggi dalam penghantaran rakaman video, yang boleh menjadi 5-7 saat.
Di satu pihak, ini tidak banyak, sebagai contoh, bagi mereka yang menonton filem dari pelayan pengehosan video. Tetapi untuk sistem pengawasan video, kelewatan dalam menghantar rakaman video boleh menjadi sangat penting.
Jika anda menonton pejabat di mana pekerja melihat dari monitor mereka sekali sejam, maka kelewatan selama 5 saat tidak penting sama sekali. Tetapi orang mula merungut bahawa, sebagai contoh, apabila menyiarkan perlawanan bola sepak, mereka sudah menulis GOOOOL dalam sembang, tetapi ini belum ada dalam video :). Kami sudah mempunyai beberapa kes pengguna di mana Ivideon sepatutnya menggantikan Skype.
Adakah mungkin untuk mengalahkan kependaman dalam HLS? Jawapan kepada soalan ini kedengaran seperti ucapan seorang pembasmi tikus berpengalaman pada kuliah kepada pakar kawalan perosak pemula: "Tikus tidak boleh dibasmi, tetapi bilangannya boleh dikurangkan kepada minimum yang munasabah." Sama dengan kelewatan dalam HLS, ia tidak akan dapat dikurangkan kepada sifar, tetapi terdapat penyelesaian di pasaran yang boleh mengurangkan kelewatan dengan ketara.
Potongan halus
Satu lagi kelemahan enjin ialah penggunaan fail kecil untuk pemindahan data. Nampaknya apa yang salah dengan ini?
Sesiapa yang cuba menyalin sejumlah besar fail kecil dari satu medium ke medium lain mungkin menyedari bahawa kelajuan menulis set sedemikian jauh lebih rendah daripada satu fail besar dengan saiz yang sama. Dan keamatan akses kepada cakera keras meningkat dengan ketara, yang secara amnya menjejaskan prestasi keseluruhan komputer secara negatif. Oleh itu, penghantaran data video dalam ketulan kecil 10 saat juga menyumbang kepada peningkatan kependaman enjin.
Mari kita ringkaskan secara ringkas semua kebaikan dan keburukan teknologi HLS.
Kelebihan HLS:
- Keupayaan untuk bekerja dengan mana-mana peranti. Anda boleh menonton video pada mana-mana peranti moden, sama ada telefon pintar, tablet, komputer riba atau PC desktop. Perkara utama ialah pelayar web adalah terkini dan serasi dengan HTML5 dan Sambungan Sumber Media.
- Kualiti imej yang sangat baik. Fungsi penghantaran data adaptif yang digunakan membolehkan anda menukar kualiti video yang dihantar secara dinamik bergantung pada lebar jalur sambungan Internet, manakala algoritma berusaha untuk mengekalkan kualiti maksimum.
- Tidak ada keperluan untuk konfigurasi kompleks peralatan pengguna.
Kelemahan:
- Sokongan terhad untuk bekerja dengan enjin pada sesetengah peranti.
- Kelewatan tinggi dalam penghantaran imej.
- Peningkatan ketara dalam overhed dan kerumitan pengoptimuman disebabkan penggunaan fail kecil. Disebabkan oleh sifat bekas, kami tidak akan pernah mendapat kependaman yang lebih rendah daripada saiz segmen.
Kelemahan HLS mengatasi kelebihannya untuk kami dan memaksa kami mencari pilihan alternatif.
Apakah itu WebRTC
()
Platform WebRTC telah dibangunkan oleh Google pada tahun 2011 untuk menghantar data penstriman video dan audio antara penyemak imbas dan aplikasi mudah alih dengan kependaman minimum. Untuk ini, protokol UDP standard dan algoritma kawalan aliran khas digunakan. Hari ini ia adalah projek sumber terbuka, ia diselenggara secara aktif oleh Google dan sedang dibangunkan.
WebRTC ialah satu set teknologi untuk penghantaran video dan audio peer-to-peer. Iaitu, sebagai contoh, pelayar pengguna yang menggunakan WebRTC boleh memindahkan data antara satu sama lain secara langsung, tanpa menggunakan pelayan jauh untuk menyimpan dan memproses data. Semua maklumat juga diproses oleh pelayar pengguna akhir dan aplikasi mudah alih.
Kemudahan dan keupayaan meluas teknologi ini telah dihargai oleh pembangun semua pelayar popular. Sokongan WebRTC kini tersedia dalam Mozilla Firefox, Opera, Google Chrome (dan semua pelayar berasaskan Chromium), serta dalam aplikasi mudah alih. Android dan iOS.
Untuk semua kelebihannya yang tidak diragui, WebRTC mempunyai beberapa kelemahan yang ketara.
Kesukaran pilihan
Teknologi WebRTC jauh lebih kompleks dari segi interaksi rangkaian kerana fakta bahawa ia adalah mengenai P2P. Sukar untuk nyahpepijat, menguji dan boleh berkelakuan tidak dapat diramalkan. Pada masa yang sama, kita perlu mengatasi NAT dan firewall, kita perlu memastikan operasi dalam rangkaian di mana UDP disekat.
Pelaksanaan WebRTC Google sangat sukar untuk digunakan. Malah terdapat keseluruhan syarikat yang menyediakan perkhidmatan pemasangan SDK. Selain itu, pelaksanaan Google adalah sangat sukar untuk disepadukan dengan sistem kami tanpa mengekod semula keseluruhan video.
Walau bagaimanapun, kami telah lama ingin memberi pengguna peluang untuk bekerja dengan video "langsung" sepenuhnya dan meminimumkan selang antara imej pada skrin dan acara itu sendiri. Selain itu, kami mempunyai keinginan untuk menggunakan kamera PTZ, di mana kelewatan adalah kritikal, lebih selesa.
Memandangkan pelaksanaan anti-lag lain masih mempunyai kefungsian terhad dan berfungsi dengan ketara lebih teruk, kami memutuskan untuk menggunakan WebRTC.
Apa yang telah kita lakukan
Melaksanakan platform WebRTC dengan betul bukanlah satu tugas yang mudah. Sebarang kesilapan pengiraan atau ketidaktepatan boleh menyebabkan kelewatan dalam penghantaran video bukan sahaja tidak berkurangan berbanding platform lain, malah meningkat.
Untuk WebRTC berfungsi dengan betul, pertama sekali, adalah perlu untuk menjalankan peningkatan teknologi tindanan untuk bekerja dengan video web. Itulah yang kami lakukan.
Mula-mula, kami melaksanakan pelayan protokol isyarat WebRTC melalui Websocket, dan juga menggunakan pelayan rakan sebaya WebRTC dalam awan berdasarkan SDK webrtc.org. Tugasnya adalah untuk mengedarkan strim video kepada rakan WebRTC pelanggan dalam format H.264 + Opus/G.711 tanpa transcoding video.
Kami memilih Websocket sebagai protokol isyarat kerana ia sudah mempunyai sokongan berkualiti tinggi dalam semua pelayar web yang popular. Disebabkan ini, anda boleh mengurangkan dengan ketara bukan sahaja overhed pembangunan, tetapi juga mengelakkan pembaziran masa dan sumber pada jabat tangan TCP dan TLS berulang berbanding AJAX.
Hakikatnya, secara lalai, WebRTC tidak menyediakan protokol isyarat yang diperlukan untuk mengkonfigurasi, menyelenggara dan menamatkan komunikasi video masa nyata antara sumber dan aplikasi klien dengan betul.
Dan untuk melaksanakan teknologi isyarat secara bebas, kami perlu membangunkan pelayan isyarat kami sendiri dengan sokongan untuk beberapa protokol web (Websocet, WebRTC). Dan dengan keupayaan untuk mengurus sesi dan pemberitahuan dengan selamat dalam masa nyata, pengurusan video dan banyak lagi.
Kami mengatasi had P2P dengan mengurangkan kependaman bukan melalui P2P, tetapi melalui UDP dan kawalan aliran untuk mengurangkan kependaman. Ini juga terbina dalam WebRTC, kerana kes penggunaan utama ialah perbualan p2p melalui penyemak imbas.
Dalam klien mudah alih, kami melaksanakan pemain menggunakan SDK webrtc.org, kerana hanya ia melaksanakan kawalan aliran dengan betul, mempunyai semua skim Pembetulan Ralat Hadapan (FEC) yang diketahui dan melaksanakan mekanisme untuk menghantar semula paket untuk semua penyemak imbas dengan betul. Adalah penting juga bahawa SDK webrtc.org sedang dibangunkan secara aktif oleh Google.
Apakah hasil daripada melaksanakan WebRTC?
Untuk melihat video langsung daripada kamera, kami telah menambah pemain baharu yang dioptimumkan berdasarkan WebRTC pada akaun peribadi anda. Ia menyediakan kelajuan memuatkan video yang pantas dan menghapuskan sepenuhnya masalah kependaman terkumpul apabila masa tontonan meningkat.
Selepas memperkenalkan sokongan WebRTC dalam perkhidmatan awan Ivideon, kami boleh mengatakan dengan penuh keyakinan bahawa pelanggan kami kini boleh menonton video langsung sepenuhnya. Kini kelewatan semasa menyiarkan urutan video tidak melebihi satu saat! Sebagai perbandingan, enjin HLS sebelumnya menyediakan penghantaran video dengan kelewatan selama 5-7 saat. Perbezaan dalam kelajuan demonstrasi video adalah sangat ketara, dan pengguna akan menyedarinya serta-merta selepas mula bekerja dengan perkhidmatan video kami.
Seperti yang kami jangkakan, pelaksanaan pemain baharu telah meningkatkan responsif PTZ dan komunikasi suara dengan kamera.
Hanya ada satu perkara halus yang ingin kami tarik perhatian. Pemain WebRTC baharu sedang berfungsi dalam mod ujian. Dan itulah sebabnya kami tidak mendayakannya untuk semua pelanggan kami secara lalai. Tetapi anda boleh mengaktifkannya sendiri dengan mendayakan item yang sepadan dalam tetapan kamera (untuk melakukan ini, pergi ke ).
Ciri-ciri pelaksanaan WebRTC dalam perkhidmatan Ivideon
WebRTC masih merupakan teknologi percubaan pada masa ini. Sokongannya belum dilaksanakan dengan betul dalam semua pelayar dan peranti pengguna, dan juga tidak dalam semua kamera.
Inilah sebabnya kami belum lagi menjadikan pemain WebRTC sebagai lalai untuk semua pengguna.
Buat masa ini, kami mengesyorkan menggunakan WebRTC hanya dalam penyemak imbas Google Chrome. Versi terkini Firefox dan Safari juga menyokong teknologi ini, tetapi, malangnya, ia masih tidak stabil.
Kami belum lagi melaksanakan sokongan WebRTC untuk penyemak imbas pada peranti mudah alih. Pada masa ini, jika anda log masuk dari peranti mudah alih dan mengaktifkan WebRTC, mod ini tidak akan berfungsi. Walau bagaimanapun, WebRTC tersedia dalam aplikasi mudah alih kami untuk и .
Dan menyimpulkan cerita tentang ciri pelaksanaan WebRTC dalam perkhidmatan kami, mari kita perhatikan dua perkara yang lebih halus.
Pertama, teknologi ini tertumpu pada penyiaran video secara langsung dalam masa nyata. Oleh itu, jika saluran anda tidak mempunyai lebar jalur yang mencukupi untuk menghantar video, anda akan melihat kejatuhan bingkai (dengan HLS anda akan melihat video pudar dan peningkatan kependaman, tetapi tidak akan ada kejatuhan bingkai), tetapi video itu masih akan disiarkan secara nyata masa.
Kedua, memandangkan teknologi ini direka untuk berfungsi secara khusus dengan video langsung dalam masa nyata, kami tidak menggunakannya untuk bekerja dengan data video yang diarkibkan.
Perubahan lain pada perkhidmatan
Pada masa ini, Flash tidak lagi terlibat dalam mekanisme pemilihan enjin automatik. Anda masih boleh menggunakan pemain sedemikian, tetapi untuk melakukan ini, anda perlu memilihnya secara manual dalam tetapan akaun atau kamera. Ini bukan penghormatan kepada fesyen, cuma mengikut statistik perkhidmatan kami, hampir tiada pengguna yang masih boleh bekerja dengan Flash. Dan cuba menentukan sama ada penyemak imbas pengguna menyokongnya, kami kehilangan kira-kira 2 saat masa yang berharga.
Berikut ialah gambaran ringkas tentang perubahan yang menanti anda dalam sistem pengawasan video awan dan akaun peribadi kami. Kekal bersama kami dan ikuti berita!
Sumber: www.habr.com
