Komunikasi video ialah cara komunikasi utama antara guru dan pelajar di platform Vimbox. Kami melepaskan Skype lama dahulu, mencuba beberapa penyelesaian pihak ketiga dan akhirnya menyelesaikan pada gabungan WebRTC - Janus-gerbang. Untuk beberapa lama kami gembira dengan segala-galanya, tetapi masih beberapa aspek negatif terus muncul. Akibatnya, arah video yang berasingan telah dibuat.
Saya meminta Kirill Rogovoy, ketua arah baharu, untuk bercakap tentang evolusi komunikasi video di Skyeng, masalah yang ditemui, penyelesaian dan tongkat yang akhirnya kami gunakan. Kami berharap artikel itu berguna untuk syarikat yang juga membuat video sendiri melalui aplikasi web.
Sedikit sejarah
Pada musim panas 2017, ketua pembangunan Skyeng, Sergey Safonov, bercakap di Backend Conf dengan cerita tentang bagaimana kami "meninggalkan Skype dan melaksanakan WebRTC." Mereka yang berminat boleh menonton rakaman ucapan di (~45 min), dan di sini saya akan menggariskan secara ringkas intipatinya.
Bagi Sekolah Skyeng, komunikasi video sentiasa menjadi cara keutamaan komunikasi guru-murid. Pada mulanya, Skype telah digunakan, tetapi ia tidak memuaskan kerana beberapa sebab, terutamanya disebabkan oleh kekurangan log dan ketidakmungkinan penyepaduan terus ke dalam aplikasi web. Oleh itu, kami menjalankan pelbagai jenis eksperimen.
Sebenarnya, keperluan kami untuk komunikasi video adalah lebih kurang seperti berikut:
- kestabilan;
- harga rendah setiap pelajaran;
- rakaman pelajaran;
β menjejaki siapa yang bercakap (ia adalah penting bagi kami bahawa pelajar bercakap lebih banyak daripada guru semasa pelajaran);
- penskalaan linear;
- keupayaan untuk menggunakan kedua-dua UDP dan TCP.
Yang pertama mencuba ialah melaksanakan Tokbox pada tahun 2013. Semuanya baik, tetapi ternyata sangat mahal - 113 rubel setiap pelajaran - dan memakan keuntungan.
Kemudian pada tahun 2015, Voximplant telah disepadukan. Berikut ialah fungsi yang kami perlukan untuk menjejaki siapa yang bercakap, dan pada masa yang sama penyelesaiannya jauh lebih murah: jika hanya audio dirakam, ia berharga 20 rubel setiap pelajaran. Walau bagaimanapun, ia hanya berfungsi melalui UDP dan tidak boleh bertukar kepada TCP. Walau bagaimanapun, kira-kira 40% pelajar akhirnya menggunakannya.
Setahun kemudian, kami mula mempunyai pelanggan korporat dengan keperluan khusus mereka sendiri. Sebagai contoh, segala-galanya harus berfungsi melalui pelayar, syarikat hanya membuka http dan https; iaitu tiada Skype atau UDP. Pelanggan korporat = wang, jadi mereka kembali ke Tokbox, tetapi masalah harga tidak hilang.
Penyelesaian - WebRTC dan Janus
Memutuskan untuk menggunakan . Ia bertanggungjawab untuk mewujudkan sambungan, pengekodan dan penyahkodan aliran, menyegerakkan trek dan kawalan kualiti dengan pengendalian gangguan rangkaian. Bagi pihak kami, kami mesti memastikan aliran membaca daripada kamera dan mikrofon, melukis video, mengurus sambungan, mewujudkan sambungan WebRTC dan menghantar aliran kepadanya, serta menghantar mesej isyarat antara pelanggan untuk mewujudkan sambungan (WebRTC sendiri menerangkan hanya format data, tetapi bukan pemindahan mekanismenya). Jika pelanggan berada di belakang NAT, WebRTC menghubungkan pelayan STUN; jika ini tidak membantu, TURN pelayan.
Sambungan p2p biasa tidak mencukupi untuk kami, kerana kami ingin merakam pelajaran untuk analisis lanjut sekiranya terdapat aduan. Oleh itu kami menghantar aliran WebRTC melalui geganti . Akibatnya, pelanggan tidak mengetahui alamat masing-masing, hanya melihat alamat pelayan Janus; ia juga melaksanakan fungsi pelayan isyarat. Janus mempunyai banyak ciri yang kami perlukan: bertukar secara automatik kepada TCP jika pelanggan telah disekat UDP; boleh merakam kedua-dua aliran UDP dan TCP; berskala; Malah terdapat pemalam terbina dalam untuk ujian gema. Jika perlu, pelayan STUN dan TURN dari Twilio disambungkan secara automatik.
Pada musim panas 2017, kami menjalankan dua pelayan Janus, ditambah dengan pelayan tambahan untuk memproses fail audio dan video mentah yang dirakam, supaya tidak menduduki pemproses yang utama. Semasa menyambung, pelayan Janus dipilih secara ganjil-genap (nombor sambungan). Pada masa itu, ini sudah cukup, mengikut perasaan kami, ia memberikan kira-kira empat kali ganda margin keselamatan, peratusan pelaksanaan adalah kira-kira 80. Pada masa yang sama, harga dikurangkan kepada ~2 rubel setiap pelajaran, ditambah pembangunan dan sokongan.
Berbalik kepada topik komunikasi video
Kami sentiasa memantau maklum balas daripada pelajar dan guru untuk mengenal pasti dan membetulkan masalah tepat pada masanya. Menjelang musim panas 2018, kualiti panggilan berada di tempat pertama di kalangan aduan. Di satu pihak, ini bermakna kami telah berjaya mengatasi kelemahan lain. Sebaliknya, adalah perlu untuk melakukan sesuatu dengan segera: jika pelajaran itu terganggu, kita berisiko kehilangan nilainya, kadangkala bersama-sama dengan kos pembelian pakej seterusnya, dan jika pelajaran pengenalan terganggu, kita berisiko kehilangan bakal pelanggan. kesemuanya.
Pada masa itu, komunikasi video kami masih dalam mod MVP. Ringkasnya, mereka melancarkannya, ia berjaya, mereka skala sekali, mereka faham cara melakukannya - baik, hebat. Jika ia berfungsi, jangan betulkan. Tiada siapa yang sengaja menangani isu kualiti komunikasi. Menjelang Ogos, menjadi jelas bahawa ini tidak dapat diteruskan, dan kami melancarkan arah yang berasingan untuk mengetahui apa yang salah dengan WebRTC dan Janus.
Pada input, arahan ini menerima: penyelesaian MVP, tiada metrik, tiada matlamat, tiada proses untuk penambahbaikan, manakala 7% guru mengadu tentang kualiti komunikasi (tiada data tentang pelajar juga).
Hala tuju baharu sedang dijalankan
Perintah kelihatan seperti ini:
- Ketua jabatan, yang juga pemaju utama.
- QA membantu menguji perubahan, mencari cara baharu untuk mewujudkan keadaan komunikasi yang tidak stabil dan melaporkan masalah daripada barisan hadapan.
- Penganalisis sentiasa mencari pelbagai korelasi dalam data teknikal, menambah baik analisis maklum balas pengguna dan menyemak keputusan eksperimen.
- Pengurus produk membantu dengan hala tuju keseluruhan dan peruntukan sumber untuk eksperimen.
- Pembangun kedua sering membantu dengan pengaturcaraan dan tugasan yang berkaitan.
Sebagai permulaan, kami menyediakan metrik yang boleh dipercayai yang menjejaki perubahan dalam penilaian kualiti komunikasi (purata sepanjang hari, minggu, bulan). Pada masa itu, ini adalah gred daripada guru; gred kemudian daripada pelajar telah ditambah kepada mereka. Kemudian mereka mula membina hipotesis tentang perkara yang salah, membetulkannya, dan melihat perubahan dalam dinamik. Kami memilih buah yang tergantung rendah: sebagai contoh, kami menggantikan codec vp8 dengan vp9, prestasi bertambah baik. Kami cuba bermain dengan tetapan Janus dan menjalankan eksperimen lain - dalam kebanyakan kes mereka tidak membawa kepada apa-apa.
Pada peringkat kedua, hipotesis muncul: WebRTC ialah penyelesaian peer-to-peer, dan kami menggunakan pelayan di tengah. Mungkin masalahnya terletak di sini? Kami mula menggali dan mendapati peningkatan paling ketara setakat ini.
Pada masa itu, pelayan dari kumpulan telah dipilih menggunakan algoritma yang agak bodoh: masing-masing mempunyai "berat" sendiri, bergantung pada saluran dan kuasa, dan kami cuba menghantar pengguna kepada yang mempunyai "berat" terbesar, tanpa memberi perhatian kepada lokasi pengguna secara geografi. Akibatnya, seorang guru dari St. Petersburg boleh berkomunikasi dengan seorang pelajar dari Siberia melalui Moscow, dan bukan melalui pelayan Janus kami di St. Petersburg.
Algoritma telah dibuat semula: kini, apabila pengguna membuka platform kami, kami mengumpul ping daripadanya ke semua pelayan menggunakan Ajax. Apabila membuat sambungan, kami memilih sepasang ping (pelayan guru dan pelayan pelajar) dengan jumlah terkecil. Kurang ping bermakna kurang jarak rangkaian ke pelayan; jarak yang lebih pendek bermakna kebarangkalian yang lebih rendah untuk kehilangan paket; Kehilangan paket adalah faktor negatif terbesar dalam komunikasi video. Bahagian negatif jatuh separuh dalam tiga bulan (untuk bersikap adil, percubaan lain telah dijalankan pada masa ini, tetapi yang ini hampir pasti mempunyai kesan yang paling besar).
Kami baru-baru ini menemui satu lagi perkara yang tidak jelas, tetapi nampaknya penting: daripada satu pelayan Janus yang berkuasa pada saluran yang tebal, lebih baik untuk mempunyai dua yang lebih mudah dengan lebar jalur yang lebih nipis. Ini menjadi jelas selepas kami membeli mesin berkuasa dengan harapan dapat menjejalkan seberapa banyak bilik (sesi komunikasi) ke dalamnya pada masa yang sama. Pelayan mempunyai had lebar jalur, yang boleh kami terjemahkan dengan tepat ke dalam bilangan bilik - kami tahu berapa banyak yang boleh dibuka, contohnya, pada 300 Mbit/s. Sebaik sahaja terdapat terlalu banyak bilik dibuka pada pelayan, kami berhenti memilihnya untuk aktiviti baharu sehingga beban berkurangan. Ideanya ialah, setelah membeli mesin yang berkuasa, kami akan memuatkan saluran itu ke maksimum, supaya pada akhirnya ia akan dihadkan oleh pemproses dan memori, dan bukan oleh jalur lebar. Tetapi ternyata selepas beberapa bilik terbuka (420), walaupun pada hakikatnya beban pada pemproses, memori dan cakera masih sangat jauh dari had, negativiti mula tiba di sokongan teknikal. Nampaknya, ada sesuatu yang semakin teruk di dalam Janus, mungkin terdapat beberapa sekatan di sana juga. Kami mula bereksperimen, menurunkan had lebar jalur daripada 300 kepada 200 Mbit/s, dan masalah telah hilang. Kini kami membeli tiga pelayan baharu serentak dengan had dan ciri yang rendah, kami berpendapat bahawa ini akan membawa kepada peningkatan yang stabil dalam kualiti komunikasi. Sudah tentu, kami tidak cuba memikirkan apa yang berlaku di sana; tongkat kami adalah segala-galanya. Dalam pembelaan kita, katakan pada masa itu adalah perlu untuk menyelesaikan masalah yang mendesak secepat mungkin, dan tidak melakukannya dengan indah; selain itu, Janus bagi kami adalah kotak hitam yang ditulis dalam C, ia sangat mahal untuk bermain-main dengannya.
Nah, dalam proses itu kami:
- mengemas kini semua kebergantungan yang boleh dikemas kini, baik pada pelayan dan pada klien (ini juga percubaan, kami memantau hasilnya);
- membetulkan semua pepijat yang dikenal pasti berkaitan dengan kes tertentu, contohnya, apabila sambungan terputus dan tidak dipulihkan secara automatik;
- Kami mengadakan banyak mesyuarat dengan syarikat yang bekerja dalam bidang komunikasi video dan biasa dengan masalah kami: permainan penstriman, penganjuran webinar; kami mencuba segala yang kelihatan berguna kepada kami;
- Menjalankan semakan teknikal ke atas perkakasan dan kualiti komunikasi guru, yang paling banyak aduan datang.
Eksperimen dan perubahan seterusnya memungkinkan untuk mengurangkan rasa tidak puas hati terhadap komunikasi dalam kalangan guru daripada 7,1% pada Januari 2018 kepada 2,5% pada Januari 2019.
Apa yang Seterusnya
Menstabilkan platform Vimbox kami adalah salah satu projek utama syarikat untuk 2019. Kami mempunyai harapan yang tinggi bahawa kami akan dapat mengekalkan momentum dan tidak lagi melihat komunikasi video dalam aduan teratas. Kami faham bahawa sebahagian besar aduan ini berkaitan dengan ketinggalan dalam komputer pengguna dan Internet, tetapi kami mesti menentukan bahagian ini dan menyelesaikan selebihnya. Segala-galanya adalah masalah teknikal, nampaknya kita sepatutnya dapat mengatasinya.
Kesukaran utama ialah kita tidak tahu ke tahap mana sebenarnya boleh meningkatkan kualiti. Mengetahui siling ini adalah tugas utama. Oleh itu, dua eksperimen telah dirancang:
- bandingkan video melalui Janus dengan p2p biasa dalam keadaan pertempuran. Eksperimen ini telah pun dijalankan, tiada perbezaan ketara secara statistik ditemui antara penyelesaian kami dan p2p;
- Mari bekalkan perkhidmatan (mahal) daripada syarikat yang menjana wang secara eksklusif untuk penyelesaian komunikasi video, dan bandingkan jumlah negatif daripada mereka dengan yang sedia ada.
Kedua-dua eksperimen ini akan membolehkan kita mengenal pasti matlamat yang boleh dicapai dan memfokuskannya.
Di samping itu, terdapat beberapa tugas yang boleh diselesaikan secara rutin:
- Kami mencipta metrik teknikal kualiti komunikasi dan bukannya ulasan subjektif;
- Kami membuat log sesi yang lebih terperinci untuk menganalisis dengan lebih tepat kegagalan yang berlaku, memahami bila dan di mana tepatnya ia berlaku, dan peristiwa yang kelihatan tidak berkaitan berlaku pada masa itu;
- Kami menyediakan ujian kualiti sambungan automatik sebelum pelajaran, dan juga memberi peluang kepada pelanggan untuk menguji sambungan secara manual untuk mengurangkan jumlah negatif yang disebabkan oleh perkakasan dan salurannya;
- kami akan membangunkan dan menjalankan lebih banyak ujian beban komunikasi video dalam keadaan yang teruk, dengan kehilangan paket berubah-ubah, dsb.;
- kami menukar tingkah laku pelayan sekiranya berlaku masalah untuk meningkatkan toleransi kesalahan;
- Kami akan memberi amaran kepada pengguna jika terdapat sesuatu yang salah dengan sambungannya sama sekali, seperti yang dilakukan oleh Skype, supaya dia memahami bahawa masalah itu ada di pihaknya.
Sejak April, hala tuju komunikasi video telah menjadi projek berasingan sepenuhnya dalam Skyeng, berurusan dengan produknya sendiri, bukan hanya sebahagian daripada Vimbox. Ini bermakna kita mula mencari orang . Baiklah, seperti biasa .
Dan, sudah tentu, kami terus berkomunikasi secara aktif dengan orang dan syarikat yang bekerja dengan komunikasi video. Jika anda ingin bertukar pengalaman dengan kami, kami akan gembira! Komen, hubungi - kami akan menjawab semua orang.
Sumber: www.habr.com