Publikasikan dan Mainkan
Ada dua fitur WebRTC sisi-server utama dalam streaming video: penerbitan dan pemutaran. Dalam hal publikasi, aliran video diambil dari webcam dan berpindah dari browser ke server. Dalam hal pemutaran, aliran bergerak ke arah yang berlawanan - dari server ke browser, diterjemahkan dan diputar ulang dalam elemen browser <video> HTML5 pada layar perangkat.
UDP dan TCP
Video dapat berpindah dari dua protokol transport: TCP atau UDP. Dalam kasus UDP, umpan balik RTCP NACK bekerja secara aktif, yang membawa informasi tentang paket yang hilang, dan oleh karena itu, menentukan penurunan saluran UDP adalah tugas yang cukup sederhana dan mengurangi penghitungan NACK (ACK Negatif) untuk menentukan kualitas. Semakin banyak umpan balik NACK dan PLI (Indikator Kehilangan Gambar), semakin banyak kerugian nyata dan semakin buruk kualitas saluran
TCP tanpa NACK
Pada artikel ini, kita akan lebih tertarik pada protokol TCP. Saat menggunakan WebRTC melalui TCP, umpan balik NACK RTCP tidak dikirim, dan jika dikirim, mereka tidak mencerminkan gambaran sebenarnya dari kerugian, dan tidak mungkin untuk menentukan kualitas saluran dari umpan balik. Seperti yang Anda ketahui, TCP adalah protokol transport dengan pengiriman yang terjamin. Untuk alasan ini, jika terjadi degradasi saluran, paket pada jaringan akan dikirim pada tingkat protokol transport. Cepat atau lambat mereka akan dikirimkan, tetapi NACK tidak akan dihasilkan untuk kerugian ini, karena sebenarnya tidak ada kerugian. Paket akhirnya akan tiba terlambat. Paket yang terlambat tidak akan dikumpulkan dalam bingkai video dan akan dibuang oleh depacketizer, sebagai akibatnya pengguna akan melihat sesuatu seperti ini penuh dengan artefak:
Pada umpan balik, semuanya akan baik-baik saja, tetapi akan ada artefak dalam gambar. Di bawah ini adalah tangkapan layar dari lalu lintas Wireshark, yang menggambarkan perilaku aliran yang dipublikasikan pada saluran TCP dan UDP yang terjepit, serta tangkapan layar dari statistik Google Chrome. Tangkapan layar menunjukkan bahwa dalam kasus TCP, metrik NACK tidak tumbuh, berbeda dengan UDP, terlepas dari kenyataan bahwa semuanya sangat buruk dengan saluran.
TCP
UDP
Dan mengapa Anda perlu melakukan streaming melalui TCP jika ada UDP
Pertanyaan yang masuk akal Jawab: untuk mendorong resolusi besar melalui saluran. Misalnya, saat streaming VR (Virtual Reality), izin dapat dimulai pada 4k. Tidak mungkin untuk mendorong aliran resolusi ini dan bit rate sekitar 10 Mbps ke saluran biasa tanpa kehilangan, server mengeluarkan paket UDP dan mereka mulai tersesat dalam paket dalam jaringan, kemudian dikirim, dll. Kesedihan besar dari paket video merusak video, dan pada akhirnya, kualitasnya menjadi buruk. Untuk alasan ini, untuk jaringan tujuan umum dan resolusi tinggi Full HD, 4k, WebRTC melalui TCP digunakan untuk pengiriman video untuk menghilangkan kehilangan paket jaringan dengan mengorbankan beberapa peningkatan keterlambatan komunikasi.
RTT untuk menentukan kualitas saluran
Dengan demikian, tidak ada metrik yang dijamin untuk mengatakan bahwa semuanya buruk dengan saluran. Beberapa pengembang mencoba mengandalkan metrik RTT, tetapi tidak berfungsi di semua browser dan tidak memberikan hasil yang akurat.
Di bawah ini adalah ilustrasi ketergantungan kualitas saluran pada RTT sesuai dengan versi proyek callstat
Solusi REMB
Kami memutuskan untuk mendekati masalah ini dari perspektif yang sedikit berbeda. REMB bekerja di sisi server , yang menghitung bitrate masuk untuk semua stream yang masuk, menghitung deviasinya dari rata-rata dan dalam kasus penyebaran besar, menawarkan browser untuk menurunkan bitrate dengan mengirim perintah REMB khusus melalui protokol RTCP. Browser menerima pesan seperti itu dan mengurangi bit rate encoder video untuk nilai yang disarankan - ini adalah cara perlindungan terhadap kelebihan saluran dan degradasi aliran input bekerja. Dengan demikian, di sisi server, mekanisme untuk menghitung bitrate telah diterapkan. Penentuan rata-rata dan sebaran diterapkan melalui filter Kalman. Ini memungkinkan Anda untuk menghapus bitrate saat ini kapan saja dengan akurasi tinggi dan memfilter penyimpangan yang kuat.
Pembaca mungkin akan memiliki pertanyaan - "Apa yang akan pengetahuan tentang laju bit yang dilihat server pada aliran masuk memberikannya?". Ini akan memberikan pemahaman tentang apa yang dimasukkan oleh video dengan bitrate di server, yang nilainya ditentukan. Untuk mengevaluasi kualitas saluran, diperlukan satu komponen lagi.
Bitrate keluar dan mengapa itu penting
Statistik aliran WebRTC penerbitan menunjukkan dengan bitrate aliran video yang keluar dari browser. Seperti dalam lelucon berjanggut: Admin, memeriksa mesin: “Dari sisiku peluru keluar. Masalah ada di pihak Anda .. ". Gagasan untuk memeriksa kualitas saluran adalah untuk membandingkan dua bit rate: 1) bit rate yang dikirimkan browser 2) bit rate yang sebenarnya diterima server.
Admin menembakkan peluru dan menghitung kecepatan keberangkatan mereka di rumah. Server menghitung kecepatan penerimaan mereka di rumah. Ada peserta lain dalam acara ini, TCP adalah superhero yang terletak di tengah-tengah antara admin dan server dan dapat memperlambat peluru secara acak. Misalnya, ia dapat mengerem 10 peluru acak dari seratus selama 2 detik, dan kemudian membiarkannya terbang lagi. Berikut ini adalah Matrix.
Di sisi browser, kami mengambil bitrate saat ini dari statistik WebRTC, kemudian kami menghaluskan grafik dengan filter Kalman dalam implementasi JavaScript dan pada output kami mendapatkan versi bitrate dari browser bitrate klien. Sekarang kami memiliki hampir semua yang kami butuhkan: bitrate klien memberi tahu kami bagaimana lalu lintas meninggalkan browser, dan bitrate server memberi tahu bagaimana server melihat lalu lintas ini dan bitrate apa yang diterimanya. Jelas, jika bitrate klien tetap tinggi, dan bitrate server mulai melorot sehubungan dengan klien, ini berarti bahwa tidak semua "peluru telah terbang" dan server tidak benar-benar melihat bagian dari lalu lintas yang dikirim ke sana. Berdasarkan ini, kami menyimpulkan bahwa ada sesuatu yang salah dengan saluran dan sekarang saatnya untuk mengganti indikator menjadi merah.
Lebih banyak yang akan datang
Grafik berkorelasi, tetapi sedikit bergeser dalam waktu relatif satu sama lain. Untuk korelasi penuh, perlu menggabungkan grafik waktu untuk membandingkan bitrate klien dan server pada titik waktu yang sama pada data historis. Desync terlihat seperti ini:
Dan sepertinya bagan yang disinkronkan waktu.
Pengujian
Kasingnya kecil, masih harus diuji. Kami menerbitkan aliran video, membuka dan menonton jadwal bitrate yang diterbitkan: di sisi browser dan di sisi server. Menurut grafik, kami melihat kecocokan yang hampir sempurna. Indikator ini disebut PERFECT.
Selanjutnya, kita mulai merusak saluran. Untuk melakukan ini, Anda dapat menggunakan alat " winShaper " gratis di Windows atau " Network Link Conditioner " di MacOS. Mereka memungkinkan Anda untuk mencubit saluran ke nilai yang ditetapkan. Misalnya, jika kita tahu bahwa aliran 640x480 dapat berakselerasi ke 1Mbps, jepit hingga 300 kbs. Pada saat yang sama, kami ingat bahwa kami bekerja dengan TCP. Kami memeriksa hasil tes - grafik menunjukkan korelasi terbalik dan indikator jatuh ke BAD. Memang, browser terus mengirim data dan bahkan meningkatkan bitrate, mencoba mendorong bagian lalu lintas baru ke jaringan. Data ini mengendap di jaringan dalam bentuk transmisi ulang dan tidak mencapai server, sebagai akibatnya, server menunjukkan gambar yang berlawanan dan mengatakan bahwa bitrate yang dilihatnya telah jatuh. Sangat buruk.
Kami melakukan banyak tes yang menunjukkan operasi indikator yang benar . Hasilnya adalah fitur yang memungkinkan Anda untuk memberi tahu pengguna secara kualitatif dan efisien tentang masalah dengan saluran untuk mempublikasikan aliran dan untuk pemutaran (ini bekerja dengan prinsip yang sama). Ya, demi bola lampu PERFECT-BAD hijau-merah ini, kami memagari seluruh taman ini. Tetapi praktik menunjukkan bahwa indikator ini sangat penting dan tidak adanya dan kesalahpahaman tentang status saat ini dapat sangat merusak kehidupan pengguna biasa layanan streaming video melalui WebRTC.
Referensi
WCS 5.2 - server media untuk mengembangkan aplikasi video web dan seluler
Dokumentasi kontrol kualitas saluran WebRTC untuk penerbitan dan pemutaran
REMB - manajemen bitrate sisi server
NACK - kontrol paket yang hilang dari sisi server