Sekarang, sepertinya tidak mungkin menemukan messenger tanpa fitur panggilan. Ini nyaman bagi pengguna, karena semua komunikasi dapat dilakukan dalam satu aplikasi. Jika kita menggabungkan semua statistik yang tersedia di media, ternyata orang-orang berbicara melalui internet selama lebih dari satu miliar menit sehari. Dan dengan perkembangan teknologi, pangsa komunikasi video tumbuh, karena video lebih baik menyampaikan emosi lawan bicara dan memungkinkan Anda untuk menciptakan efek kehadiran.

Tantangan baru untuk layanan panggilan video adalah untuk mengumpulkan sekaligus seluruh keluarga atau sekelompok teman yang berlokasi di berbagai belahan dunia, atau kolega yang bekerja jarak jauh pada proyek yang sama, untuk perencanaan.

Kepala pengembangan platform Video dan Tape, Alexander Tobol ( alatobol ), akan menunjukkan bahwa di bawah tenda ada layanan panggilan video, teknologi dan peretasan mana yang digunakan untuk membuat server konferensi Anda, dan cara mentransfer video dengan benar. Ayo turun dan pelajari cara mentransfer layanan panggilan satu-ke-satu ke panggilan grup untuk 100 orang dan mengapa Anda memerlukan dukungan untuk begitu banyak peserta.


Artikel ini didasarkan pada laporan tentang HighLoad ++ Siberia , di mana Alexander Tobol mencoba memberikan gambaran yang lengkap. Jika Anda sudah terbiasa dengan materi lain pada topik (misalnya, tentang fitur transmisi video dan protokol jaringan ), maka Anda dapat melewati bagian teoretis dan langsung menuju solusi .

Garis besar artikel:

• Riwayat dan panggilan perangkat.
• Transisi dari panggilan satu-ke-satu ke panggilan grup.
• Layanan panggilan grup DIY.
• Server Konferensi: Jelajahi Pesaing dan Lakukan Lebih Baik.

Riwayat panggilan

Aplikasi terkenal pertama untuk panggilan, dan dengan videonya, adalah Skype, muncul pada 2006. Di Odnoklassniki, kami meluncurkan panggilan berdasarkan solusi dari Adobe pada 2010-2012 ... Beberapa tahun yang lalu kami benar-benar mengubahnya di WebRTC (lebih lanjut tentang peluncuran ini di sini ), tahun lalu kami menambahkan panggilan grup. Transisi ini akan dibahas dalam artikel.

Mengapa saya pikir saya bisa memberi tahu Anda bagaimana melakukan ini? Karena pemirsa bulanan kami menggunakan panggilan melebihi 10 juta orang, dan kami memiliki lebih dari 2 juta panggilan per hari . Selain itu, lebih dari setengahnya terjadi melalui platform seluler.

Panggilan grup adalah layanan yang paling cepat berkembang, dan tujuan kami adalah 100 peserta konferensi secara bersamaan. Kenapa begitu banyak? Pertama, kadang-kadang Anda ingin berbagi bidikan indah dengan teman dan teman sekelas atau mengadakan seminar. Kedua, bahkan jika Anda berpikir bahwa layanan Anda tidak memerlukan sesuatu, semuanya dapat berubah.

Sekarang sepertinya konferensi video untuk 100 peserta tidak diperlukan, dan lima tahun yang lalu mereka bertanya kepada saya mengapa kami meluncurkan video dalam 4K. Sekarang TV 4K adalah hal biasa, dan kami siap kembali pada tahun 2014.

Intinya tidak lebih dulu. Jika Anda ingin membuat layanan yang baik, tingkatkan persyaratan Anda lebih tinggi.

Jika Anda dapat membuat panggilan berfungsi dengan baik untuk 50-100 orang, maka untuk 6-10 pengguna semuanya akan berfungsi dengan baik.

Setiap layanan panggilan memiliki 4 komponen yang relatif independen:

• Pemberian sinyal Tugasnya adalah memanggil pelanggan, bertukar data awal, menginformasikan apa yang dapat dilakukan oleh setiap pelanggan, dan kemudian membuat saluran melalui mana data video dapat ditransmisikan.
• Video / audio. Data video dan audio dikompres menggunakan codec.
• Jaringan Hal ini diperlukan untuk memastikan bekerja di jaringan yang buruk, mengimplementasikan pemulihan paket, koneksi P2P, dll.
• Topologi - ditambahkan jika ada panggilan grup.

Anda dapat membicarakan bagian-bagian ini secara terpisah. Tapi saya ingin memberikan gambaran besar tentang bagaimana panggilan bekerja, jadi saya akan mencoba memasukkan semuanya ke dalam satu cerita.

Sebelum Anda mulai bekerja pada layanan ini, Anda perlu mengidentifikasi persyaratan :

• Buat koneksi dengan cepat sehingga koneksi dibuat segera setelah teman bicara mengangkat telepon.
• Kualitas panggilan tinggi sehingga video tidak hancur dan tidak membeku.
• Jumlah peserta dalam panggilan , sehingga Anda dapat memanggil dalam obrolan, di mana hingga 100 peserta.
• Latensi rendah di antara penelepon. Latensi 1,3 detik karena Polycom tidak cocok untuk kita sama sekali.

Berikut adalah makna spesifik yang menyatakan persyaratan untuk panggilan grup ini: mulai dari panggilan tidak lebih dari 1 detik; sebuah jaringan di mana video 300 Kbps bekerja secara stabil; latensi dari penelepon ke pendengar tidak lebih dari 0,5 detik; 100 pengguna dalam satu panggilan.

Apa yang menghalangi?

Seperti yang Anda ketahui, data dalam jaringan ditransmisikan dalam paket: ada soket, Anda mengirim aliran data di sana, semuanya terbang menjauh, seolah-olah dalam kotak hitam, ia dirakit dan berfungsi.

Tetapi jaringannya berbeda. Setengah dari panggilan dilakukan melalui jaringan seluler, dan mereka tidak selalu terlihat seperti jalan bebas hambatan.

Jaringan dapat kelebihan beban, maka data akan hilang dan harus dipulihkan, selanjutnya memuat jaringan. Ada jaringan dengan mana semuanya tampak beres, tetapi paket masih menghilang - misalnya, karena fakta bahwa router Wi-Fi terletak di belakang dinding beton bertulang.

Fitur Jaringan

Kami akan menganalisis karakteristik utama yang menggambarkan kualitas jaringan.

RTT

Waktu pulang-pergi - waktu antara server mengirim data ke klien dan menerima pemberitahuan kembali.

Ingat, kami ingin membuat koneksi dalam 1 detik. Jika waktu pulang pergi adalah 200 ms, maka dengan koneksi yang dibuat, misalnya, melalui TCP, ditambah beberapa TLS, Anda dapat kehilangan 500 ms hanya pada koneksi . Hanya 500 ms yang akan tersisa, mis. beberapa permintaan lagi, setelah itu koneksi harus dibuat. Karena itu, dengan permintaan tambahan dengan RTT Anda harus bekerja dengan sangat hati-hati.

Contoh:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

Dengan RTT = 220ms, menerima respons melalui https membutuhkan waktu hingga 800 ms. Karena itu, jika Anda memiliki koneksi aman soket web, maka dengan ping seperti itu seluruh detik akan hilang.

Tabel menunjukkan penundaan jabat tangan yang diukur dalam jaringan seluler (dalam laporan ini , detail lebih lanjut tentang pengoperasian aplikasi dalam jaringan seluler).

Throughput

Anda dapat mengirim paket ke jaringan sesuka Anda: dalam batch atau segera memalu semua yang ada di buffer, mereka akan tetap sampai ke klien secara merata. Jumlah paket atau data per detik adalah bandwidth atau bandwidth.

Masalahnya adalah bandwidth di jaringan seluler terus berubah . Jika jatuh tajam, dan data ditransmisikan dengan bitrate yang sama, mereka jelas akan mengalami kerugian, dan panggilan pengguna akan "hang". Ini juga harus diperjuangkan.

Paket hilang

Saat mentransfer data, paket mungkin hilang. Dalam hal ini, ada pilihan: lewati sebagian paket dan dapatkan distorsi, atau coba kirim ulang paket dan dapatkan bingkai beku.

Jitter

Faktanya adalah bahwa paket-paket tidak tiba secara merata satu per satu, tetapi dalam paket paket pada suatu interval tertentu.


Jitter mudah diukur:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

Pinganuli highload.ru beberapa kali (ping adalah nilai yang tidak stabil, perlu untuk rata-rata), kami mendapat jitter rata-rata: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .

Misalkan kita mengirimkan video, dan satu frame adalah paket jaringan. Beberapa frame dimainkan tanpa henti, tetapi burung ketiga tertunda karena jitter - kami mendapatkan bingkai beku. Jadi, Anda perlu mengakumulasi paket di suatu tempat dan menyamakan efek ini.

Artinya, untuk mengkarakterisasi jaringan nirkabel, cukup mengetahui nilai-nilai berikut: RTT (waktu pulang-pergi); bandwidth BW (bandwidth); persentase kehilangan paket; jitter.

Seperti apa rupa pengguna?

Sebelum Anda mulai mengoptimalkan pekerjaan dengan jaringan, Anda perlu mencari tahu jenis Internet yang dimiliki pengguna - mungkin setiap orang memiliki jaringan yang sempurna, solusi apa pun akan berhasil.

Dalam 80% kasus, pengguna akhir menggunakan koneksi nirkabel: itu adalah jaringan seluler atau Wi-Fi.



Di Rusia, di luar wilayah barat dan kota-kota besar, karakteristik jaringan rata-rata adalah: RTT - 200 ms, bandwidth - 1,1 Mbps, packet loss - 0,6%, jitter - 5ms.

Kami membagi nilai-nilai ini berdasarkan jenis jaringan dan menyadari bahwa belajar untuk mengerjakan ini diperlukan.

Fitur Pengembangan Panggilan

Banyak orang lupa, tetapi LTE dan 3G adalah saluran komunikasi asimetris: downlink selalu lebih dari sekadar uplink. Bergantung pada jenis protokol, rasio ini dapat bervariasi dari 15/85 hingga 30/70. Saat merancang panggilan, ini penting.

Bagaimana cara memeriksa saluran yang dimiliki pelanggan Anda?



Anda dapat melihat speedtest, berapa rasio kecepatan di dunia antara mobile dan internet tetap. Ternyata di seluruh dunia Internet tetap juga asimetris. Di Rusia, untungnya, ternyata simetris: rasio uplink / downlink pada Internet tetap melalui Wi-Fi di Rusia adalah 50/50. Kami akan fokus pada nilai-nilai tersebut.



Intinya: Jaringan nirkabel populer dan tidak stabil.

• Lebih dari 80% pelanggan menggunakan internet nirkabel.
• Pengaturan nirkabel berubah secara dinamis.
• Jaringan nirkabel memiliki tingkat packet loss, jitter, reordering yang tinggi.
• Saluran uplink / downlink asimetris dalam rasio 30/70.

Panggilan

Dengan penyimpanan pengetahuan ini, mari kita kembali ke implementasi panggilan grup. Pertimbangkan algoritme untuk panggilan grup sederhana, yang kemudian kami perbaiki.

Langkah 1. Alice ingin memanggil Boris dan mengirimkannya tawaran, di mana ia melaporkan semua yang ia bisa, yang mendukung protokol, pengaturan, dll.

Langkah 2. Boris menjawab Alice, setelah itu koneksi transportasi dibuat.

Langkah 3. Setelah itu, pertukaran data audio / video dimulai.

Arsitektur panggilan apa pun terlihat seperti diagram di bawah ini.

Selalu ada server bersama, tetapi ketika koneksi dibuat, pengguna sudah dapat mentransfer data p2p atau melalui server pihak ketiga.

Data ditangkap oleh kamera yang mengkodekannya pada perangkat dan mengirimkannya ke koneksi soket. Mereka melewati jaringan, diputar di sisi lain oleh codec, dan ditampilkan di layar.

Pertimbangkan semua langkah algoritma secara terperinci dan cobalah untuk beralih dari panggilan 1-ke-1 ke panggilan grup.

Pemberian sinyal

Tugas: melaporkan panggilan dan membuat koneksi data.

Semuanya cukup sederhana:

• Panggilan Alice, pemberitahuan dikirim ke Boris di perangkat seluler atau browser.
• Soket web atau koneksi lain dibuat.
• Setelah ini, negosiasi terjadi - Alice dan Boris setuju.
• Ketika handset diambil pada satu perangkat, panggilan berakhir secara otomatis di perangkat lainnya.

Platform panggilan di Odnoklassniki mendukung berbagai klien dan transportasi. Mereka semua dekat dengan beberapa jenis server, yang bergerak dalam melayani panggilan dan meneruskan pesan.

Dalam hal server crash atau instalasi pembaruan, ada penyimpanan yang tetap di mana semua pesan direkam. Jika server hilang, Anda dapat dengan mudah beralih ke yang lain. Inilah yang dilakukan ZooKeeper.

Satu-satunya kesulitan adalah tepat sekali . Kami tidak ingin menerapkan beberapa pesan dua kali. Masalah ini diselesaikan dengan sederhana: semua pesan memiliki nomor seri - dua kali satu pesan tidak akan sampai.

Selain itu, Anda perlu berhati-hati saat membuat panggilan. Seseorang dapat membuat panggilan, menutup telepon dan membuat panggilan lain. Atau mungkin tidak menggantung, tetapi masih membuat yang lain. Semua panggilan ini tidak unik - tidak jelas apakah ini relay atau pengguna mengklik dua kali tombol panggilan. Itu mudah diperbaiki: ID unik dihasilkan pada klien, dan deduplikasi dilakukan padanya. Pada prinsipnya, tidak ada kesulitan dalam pensinyalan .

pensinyalan p2p ke grup selesai dengan mudah.

Penawaran dan jawaban yang sama yang Alice kirimkan tidak hanya ke Boris, tetapi juga ke Dima. Mereka menerimanya, setuju, saluran pertukaran data muncul di antara mereka.

Audio / Video

Untuk mengatasi panggilan grup dan memahami teknologi apa yang dibutuhkan, kita harus berbicara sedikit tentang apa itu video.

Video adalah 24 atau 60 frame per detik. Untuk mengompresnya, codec digunakan. Inti utama dari codec adalah bahwa setiap beberapa frame ada bingkai referensi (seperti JPEG), dan frame menengah ditentukan melalui perubahan.

Pada gambar di atas, frame pertama dengan mesin adalah yang referensi, dan di frame berikutnya, hanya perubahan (pergerakan mesin) yang dikodekan, dan waktu berikutnya hanya perubahan yang dikodekan.

Ini disebut kelompok gambar - satu set independen dari frame yang saling berhubungan yang dapat diterjemahkan. Codec adalah algoritma transformasi antar frame. Semakin curam codec, semakin baik kompres data, dan semakin banyak sumber daya yang dibutuhkan.
Tentang rasio bitrate codec ada aturan umum (lihat tautan ).

Codec paling populer yang digunakan untuk panggilan adalah H.264 dan VP8 . H.264 bagus karena di mana-mana bekerja keras dan tidak memakan baterai. Namun biasanya pada ponsel satu encoder (encoder) dan 4 decoder. Untuk yang lainnya, Anda memerlukan perangkat lunak VP8, yang menghabiskan baterai yang baik. Sebaiknya ubah prioritas menjadi H.264 untuk panggilan grup (lihat tautan tentang cara melakukan ini).

Codec dapat dikodekan dengan variabel (Variable bitrate) atau bitrate konstan (Constant bitrate). Banyak codec pada perangkat tidak mendukung laju bit konstan, jadi Anda harus hidup dengan gambar di sebelah kiri.

Codec audio

Ada berbagai codec lawas untuk audio, seperti G711. Opus codec sangat populer - ini memecahkan masalah pengkodean baik pada bitrate rendah dan pada tinggi, karena di dalamnya mengandung SUTRA dari Skype dan codec CELT untuk musik.

Patut dikatakan bahwa Opus memiliki algoritme koreksi kesalahan proaktif Teruskan Koreksi (FEC). Untuk audio, algoritma ini berfungsi seperti ini: di setiap paket ada data dalam kualitas tinggi dan data dari frame sebelumnya untuk beberapa waktu dalam kualitas rendah. Dengan demikian, jika paket sebelumnya hilang, Anda bisa mendapatkan data dari paket sebelumnya dalam kualitas rendah dan entah bagaimana kehilangan. Rata-rata, hasilnya lumayan bagus.

Saat bekerja dengan codec audio, menarik untuk melihat grafik, yang menunjukkan rasio kualitas sinyal input dan bitrate.

Dapat dilihat bahwa Opus memecahkan hampir semua masalah. Sangat menarik untuk memperhatikan AAC, yang digunakan saat encoding video di berbagai layanan hosting, dan pada codec Speex lama, yang digunakan khusus untuk audio dan bekerja hingga 32 Kbps.

Data patologi media

Untuk memahami cara kerja topologi, fitur apa yang dimilikinya, Anda perlu memahami bagaimana codec video menangani kerugian.

Dalam kasus pertama, tidak ada yang hilang, dan kami melihat gambar yang bagus. Di baris kedua, satu frame acak hilang - ada artefak kecil dalam gambar. Dalam kasus ketiga, kerangka referensi menghilang, oleh karena itu, hingga kerangka referensi berikutnya, perubahan yang tumpang tindih satu sama lain akan ditampilkan.

Jelas, membuat kerangka acuan seringkali mahal karena laju bit tumbuh. Karena itu, hampir semua layanan panggilan entah bagaimana mendukung kemampuan untuk meminta kerangka referensi jika terjadi kerugian. Di WebRTC, ini disebut INTRA-frame penuh.

Topologi paling sederhana adalah mengirim semua video Anda ke semua peserta konferensi lainnya.

Kami mulai satu codec dan mulai mentransfer video. Alice menyalakan kamera, codec, mengirimkan videonya ke Boris dan Dima. Tetapi jika Dima memiliki Internet yang buruk, Boris menderita, karena Anda perlu menurunkan kualitas seluruh video. Dan jika Dima kehilangan kesempatan dan meminta yang mendukung, Boris akan mendapatkannya juga, meskipun dia tidak membutuhkannya.

Di sisi lain, Anda dapat merekatkan semua video dalam satu aliran. Ini akan membutuhkan peralatan khusus dan, mungkin, akan ada penundaan tambahan, tetapi solusi seperti itu juga ada.

Transportasi atau kirim video dan audio dengan penundaan minimal

Kami memiliki pilihan protokol TCP atau UDP.
Mungkin semua orang ingat bahwa TCP adalah protokol yang andal, yang dalam kasus packet loss mengirimnya lagi. Itulah sebabnya urutan bingkai ini dimungkinkan, seperti pada gambar di bawah ini.

Jika suatu paket tidak ada dalam paket, Anda dapat dengan bebas melewati salah satu dari 24 frame ini pada video, tetapi TCP tidak akan mengizinkan Anda untuk menerima yang berikut sampai Anda mengirim yang hilang. Mengirim video melalui TCP sangat tidak efisien. UDP direkomendasikan untuk tugas-tugas seperti itu, dan semua layanan panggilan menggunakannya.

Artikel ini menyediakan semua fitur dari kedua protokol dan menjelaskan mengapa semua streaming berfungsi pada UDP. Sebagai bagian dari topik hari ini, cukup bagi kita untuk mengetahui bahwa UDP tidak tersedia di mana-mana, itu tidak berfungsi di 3% dari jaringan.

Secara umum, pengguna dapat membuat koneksi P2P di antara mereka.

Ini adalah yang paling menguntungkan, karena jika kita saling memanggil di Novosibirsk, jauh lebih baik untuk berkomunikasi secara langsung dan tidak menggunakan server tambahan yang akan memberikan pengaruh.

Tetapi NAT ada, dan lebih dari 97% pengguna sekarang berada di belakangnya - beberapa memiliki IP eksternal. Di satu sisi, masalah ini cepat atau lambat akan diselesaikan oleh IPv6. Ngomong-ngomong, di Rusia, MTS adalah yang pertama meluncurkannya. Sekarang mereka sepenuhnya mendukung IPv6, dan semua klien mereka memiliki IP putih.

NAT mungkin menerobos, mungkin tidak menerobos, dan kemudian Anda harus menggunakan mundur melalui server. Ada juga artikel tentang cara menerobos NAT.

Jitter buffer antara transport dan frame

Kami melanjutkan. Sekarang kita perlu buffer jitter untuk meningkatkan efek jitter

Kami secara proaktif mulai menunjukkan frame dengan beberapa penundaan dan sementara itu kami berbaris frame pada interval yang sama di buffer.

Buffer meningkat secara dinamis.

Jika bingkai hilang, dan gambar membeku, maka penyangga meningkat, dan kemudian kita sudah bekerja dengan penyangga ukuran ini.

Tetapi mungkin ada situasi sebaliknya ketika Anda perlu mengurangi buffer. Misalnya, jaringan telah stabil, dan waktu perlu diperketat. Jika Anda hanya mengurangi buffer, itu akan konyol, orang akan mulai berbicara dengan sangat cepat dengan suara gnome. Oleh karena itu, ada algoritme khusus yang secara tidak terlihat menyesuaikan kecepatan audio: menghilangkan jeda di antara kata-kata atau meruntuhkan suara yang terlalu lama dalam ucapan.

Jika Anda ingin transcode video dan memperbaiki sesuatu, Anda harus terlebih dahulu memiliki buffer jitter, dan latensi-nya tidak kurang dari latensi jitter jaringan ini. Artinya, itu pasti meningkatkan latensi, dan kami ingat bahwa kami benar-benar ingin tetap dalam 0,5 s.

Buang napas - teorinya sudah berakhir!

Panggilan ke OK

Sebelum panggilan grup, kami melakukan panggilan P2P, perpustakaan WebRTC digunakan, klien web dan seluler dikumpulkan, pensinyalan ditulis.

Analisis pesaing

Ketika Anda tidak tahu apa yang harus dilakukan, lihatlah pesaing Anda. Untuk referensi, kami memilih satu set: Skype, WhatsApp, Hangouts, ICQ, Zoom. Kami mengukur jumlah maksimum peserta dalam panggilan grup, latensi, konsumsi baterai, dan kualitas.

Yang paling menarik adalah menentukan keterlambatannya. Kami melakukannya dengan cara ini: hidupkan timer, mulai merekam video, buat panggilan.

100 ms - keterlambatan kamera sejak video mengenai lensa, sebelum ditarik pada matriks ponsel. Setelah itu, video dikirim ke jaringan, dan kami melihat penundaan 310 ms sudah ada dalam panggilan.

Jangan lupa untuk mengukur penggunaan CPU pada perangkat. Dimulai dengan iOS 12, menjadi mungkin untuk melakukan ini secara sistematis, tetapi kami menggunakan pyrometer dengan cara lama.

Mendapat hasil sebagai berikut:

WhatsApp dan ICQ memiliki maksimal 4 peserta panggilan, Skype memiliki 25 (Skype for Business 250), dan Hangouts dan Zoom masing-masing memiliki 100 peserta. Hangouts dulu memiliki sekitar 35 anggota, dan sekarang dia melompat ke bagian 100+.

Zoom memiliki penundaan yang sedikit lebih lama, tetapi Hangouts mengkonsumsi lebih banyak daya baterai. Menurut saya Zoom memiliki kualitas yang lebih baik, tetapi ada artikel yang mengatakan sebaliknya - ini adalah metrik subjektif.

Beberapa layanan menggunakan WebRTC terbuka, yang lain menggunakan protokol milik. Tetapi jelas bahwa jenis transportasi apa yang Anda gunakan di bawah ini tidak mempengaruhi jumlah peserta dalam panggilan tersebut. Ada solusi dengan 100 panggilan dan dengan protokolnya sendiri (Zoom), dan dengan WebRTC (Hangouts).

Skala dari 2 hingga N

Pertimbangkan kasus yang menarik: ada klien dengan saluran asimetris, input 3 Mbit / s, output 1,5 Mbit / s, paket loss 0,6%, jitter 50 ms. Ada video dalam HD (1280x720) dengan bitrate 1,5 Mbps dan video dengan resolusi 640x360 (sebut saja RENDAH) pada 600 Kbps. Kami ingin mengirimkan video keren.

Dalam hal dua orang memanggil p2p, maka semuanya sederhana. Mereka memiliki jaringan input yang cukup, jaringan output cukup erat, karena salurannya asimetris, dan tidak ada masalah dengan codec - semua codec gratis.

Ketika kami mulai melakukan panggilan grup, kami perlu menghubungkan kembali semua orang. Versi topologi yang paling sederhana adalah Mesh atau "all to all."

Sangat bagus bahwa server perantara tidak diperlukan, tetapi menjadi masalah untuk memberi semua orang video Anda kepada klien dengan karakteristik seperti itu. Dan jika klien tidak dapat mendistribusikan video ke seseorang sendirian, maka Anda perlu menurunkan kualitasnya, karena aliran umum dikodekan untuk semua orang.

Dalam hal ini, untuk 5 peserta, 3 atau 4 Mbps tidak cukup.

Oleh karena itu, di WhatsApp dalam panggilan grup ada maksimum 4 peserta, dan tidak akan lagi selama mereka menggunakan Mesh.

Pilihan lain adalah mengumpulkan seluruh gambar di server . Ini adalah yang paling menguntungkan bagi klien: ia memiliki satu koneksi ke server, server mengumpulkan gambar, klien menerimanya kembali.

Tetapi anggaplah pengguna kami dari Petropavlovsk-Kamchatsky, Komsomolsk-on-Amur dan Novosibirsk ingin mengobrol melalui server Moskow. Secara alami, itu akan menjadi sangat buruk. Kehadiran CDN akan membantu sedikit, tetapi masih mendapatkan sejumlah besar buffer jitter, yang secara total akan membuat tambahan latensi yang layak.

Topologi berikutnya - Pencampuran akhir - menyarankan tidak mengumpulkan gambaran umum pada server untuk menghindari keterlambatan ini, tetapi hanya melempar paket.

Artinya, server dalam topologi ini hanyalah sebuah relay yang mentransfer data.

Semuanya menjadi sedikit lebih baik: pengguna menerima aliran semua peserta lain dalam panggilan dan mengirimkan sendiri hanya sekali. Tetapi sekali lagi ada masalah:

• Kualitas. Semua penerima aliran Anda memiliki jaringan yang berbeda. Jika satu orang terhubung dengan Internet yang buruk, maka video harus dikirim kepadanya dalam resolusi rendah dan, karenanya, gambar akan menjadi buruk untuk semua orang.
• Bingkai referensi badai . Jika seseorang dengan Internet yang buruk terus-menerus meminta kerangka referensi, maka semua orang juga mulai menerima oporniks. Ini adalah penggunaan bitrate yang tidak efisien, kualitasnya menurun lagi.

Jika sistem terpusat digunakan , yaitu, semua video dikumpulkan di server. Ini membutuhkan banyak tahapan pengkodean, yang ditambahkan latensi dan membutuhkan perangkat keras tambahan. Dalam pencampuran Akhir, sebaliknya, semuanya cepat dan mudah.

Topologi kontra:

• Mesh - maksimal 4 anggota.
• Terpusat - masalah dengan transcoding dan jitter.
• Pencampuran akhir - batas kualitas dan kerangka acuan badai.

Hanya ICQ dan Skype yang berfungsi pada topologi Mesh, dan sisanya adalah pencampuran Akhir. Tetapi, seperti yang kita ingat, semua layanan berbeda dalam hal karakteristik - yang berarti bahwa tidak hanya ada pencampuran Akhir, tetapi sesuatu yang lain.

Hangouts melakukan trik dengan mencampur Akhir.

Dua encoders diluncurkan pada setiap klien: H.264 dalam kualitas tinggi, dan VP8 dalam kualitas rendah. Dengan demikian, untuk pengguna dengan Internet yang baik, server mentransmisikan video berkualitas tinggi, bagi mereka yang memiliki Internet buruk, itu lebih buruk, dan kualitas buruk beradaptasi dengan jaringan terburuk. Dua kualitas bagus, tapi ini traffic ekstra dari pelanggan dan konsumsi baterai. Tetapi tidak ada buffer jitter

Tabel tersebut menunjukkan bahwa dengan Hangouts yang menjalankan telepon paling panas, penundaannya minimal, tetapi kualitasnya menurun, karena kualitas rendah masih memakan bitrate tinggi.

, : - , H.264, ( ) End mixing . centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• .
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

Kesimpulan

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .