Publikasikan dan Mainkan
Ada dua fungsi utama operasi WebRTC di sisi server dalam bidang streaming video: penerbitan dan pemutaran. Dalam hal penerbitan, aliran video diambil dari kamera web dan berpindah dari browser ke server. Dalam kasus bermain, aliran bergerak ke arah yang berlawanan, dari server ke browser, diterjemahkan dan diputar dalam elemen HTML5 <video> browser pada layar perangkat.
UDP dan TCP
Video dapat bergerak melalui dua protokol transport: TCP atau UDP. Dalam kasus UDP, umpan balik NACK RTCP bekerja secara aktif, membawa informasi tentang paket yang hilang, karena itu merupakan tugas yang cukup sederhana untuk mendeteksi kerusakan saluran UDP, maka dimatikan untuk menghitung NACK (Negative ACK) untuk menentukan kualitas. Semakin banyak umpan balik NACK dan PLI (Indikator Kehilangan Gambar), semakin banyak kerugian nyata, dan semakin rendah kualitas salurannya.
TCP tanpa NACK
Pada artikel ini, kita akan lebih fokus pada protokol TCP. Ketika WebRTC digunakan melalui TCP, umpan balik NACK RTCP tidak dikirim, dan bahkan jika dikirim, mereka tidak mencerminkan gambaran sebenarnya dari kerugian, dan tampaknya tidak mungkin untuk menentukan kualitas saluran dengan umpan balik. Seperti diketahui, TCP adalah protokol transport dengan pengiriman yang terjamin. Untuk alasan ini, jika kualitas saluran memburuk, sisa paket yang ada dalam jaringan akan dikirim pada tingkat protokol transport. Cepat atau lambat mereka akan dikirimkan, tetapi NACK tidak akan dihasilkan untuk kerugian tersebut karena sebenarnya tidak ada kerugian. Akibatnya, paket akan mencapai tujuan mereka dengan penundaan. Paket yang tertunda tidak akan berkumpul menjadi bingkai video dan akan dibuang oleh depacketizer, sebagai akibatnya pengguna akan melihat gambar seperti ini, penuh dengan artefak:
Umpan balik akan menunjukkan bahwa semuanya baik-baik saja, tetapi gambar akan berisi artefak. Di bawah ini Anda dapat melihat tangkapan layar lalu lintas Wireshark yang menggambarkan perilaku aliran yang diterbitkan pada saluran TCP dan UDP terkompresi, serta tangkapan layar statistik Google Chrome. Di tangkapan layar, Anda dapat melihat bahwa dalam kasus TCP, metrik NACK tidak tumbuh tidak seperti UDP, meskipun kondisi saluran sangat buruk.
TCP
UDP
Mengapa streaming melalui TCP sama sekali jika ada UDP
Ini pertanyaan wajar untuk diajukan. Jawabannya adalah, untuk mendorong resolusi besar melalui saluran. Misalnya, dalam kasus streaming VR (Virtual Reality) resolusi dapat dimulai dari 4k. Tampaknya tidak mungkin untuk mendorong aliran dengan resolusi seperti itu dan dengan bitrate sekitar 10 Mbps ke saluran biasa tanpa kehilangan, server mengeluarkan paket UDP dan mereka mulai hilang dalam jaringan dalam tandan, kemudian sisanya dari mereka mulai dikirim, dan seterusnya. Paket video terbuang dalam jumlah besar merusak video, dan hasilnya adalah kualitasnya menjadi sangat buruk. Ini adalah alasan mengapa WebRTC melalui TCP digunakan untuk mengirimkan video dalam jaringan tujuan umum dan dengan resolusi tinggi, seperti Full HD dan 4k, untuk menyingkirkan hilangnya paket jaringan dengan mengorbankan sedikit peningkatan latensi komunikasi.
RTT untuk menentukan kualitas saluran
Jadi, tidak ada metrik yang memberi tahu Anda dengan pasti bahwa salurannya dalam kondisi yang sangat buruk. Beberapa pengembang mencoba mengandalkan metrik RTT tetapi jauh dari mampu bekerja di semua browser, dan tidak memberikan hasil yang akurat.
Di bawah ini Anda dapat menemukan ilustrasi ketergantungan kualitas saluran pada RTT sesuai dengan proyek callstat
Solusi berbasis REMB
Kami telah memutuskan untuk mengambil pendekatan yang sedikit berbeda untuk masalah ini. Ada REMB yang bekerja di sisi server , yang menghitung bitrate yang masuk untuk semua stream yang masuk, menghitung deviasinya dari nilai tengah, dan menunjukkan bahwa browser menurunkan bitrate dalam kasus dispersi yang signifikan, mengirimkan perintah REMB khusus melalui RTCP protokol. Browser menerima pesan seperti itu dan menurunkan bitrate dari encoder video untuk nilai yang disarankan: ini adalah cara perlindungan terhadap kelebihan saluran dan degradasi aliran yang masuk bekerja. Dengan cara ini, mekanisme perhitungan bitrate telah diterapkan di sisi server. Rata-rata dan menentukan dispersi telah diwujudkan melalui filter Kalman. Ini memungkinkan untuk mendapatkan bitrate saat ini kapan saja dengan akurasi tinggi dan untuk memfilter penyimpangan yang signifikan.
Pembaca pasti akan memiliki pertanyaan ini, "Bagaimana ini membantu saya untuk mengetahui bitrate yang dapat dilihat server untuk aliran yang masuk ke dalamnya?" Ini hanya akan membuat Anda mengerti bahwa ada video yang masuk ke server dengan bitrate nilainya yang memungkinkan untuk ditentukan. Untuk mengevaluasi kualitas saluran, satu komponen lagi akan diperlukan.
Bitrate yang keluar, dan mengapa itu penting
Statistik untuk aliran WebRTC penerbitan menunjukkan dengan bitrate aliran video yang keluar dari browser. Seperti lelucon lama, seorang admin situs mengatakan ketika memeriksa senapan serangannya, “Di sisiku, peluru telah terbang keluar. Masalahnya ada di pihak Anda ... ”Gagasan untuk memeriksa kualitas saluran melibatkan membandingkan dua bitrate: 1) bitrate yang dikirim oleh browser, 2) bitrate yang sebenarnya diterima oleh server.
Admin situs menembakkan peluru dan menghitung kecepatan mereka terbang di sisinya. Server menghitung kecepatan yang diterima pada sisinya. Ada satu lagi peserta acara ini, TCP, ini adalah pahlawan super yang terletak di tengah-tengah antara admin dan server dan dapat menghentikan peluru secara acak. Misalnya, ia dapat menghentikan 10 peluru acak 100 selama 2 detik, dan kemudian membiarkannya terbang lagi. Matriks yang kita lihat di sini.
Di sisi browser, kami mengambil bitrate saat ini dari statistik WebRTC, kemudian menghaluskan grafik dengan filter Kalman dalam implementasi JavaScript, dan mendapatkan versi bitrate dari browser client bitrate di akhir proses. Sekarang kita memiliki hampir semua yang kita butuhkan: bitrate klien memberi tahu kita bagaimana lalu lintas keluar dari browser, dan bitrate server memberitahu kita bagaimana lalu lintas itu dilihat oleh server, dan dengan bitrate apa yang diterima. Jelas bahwa jika bitrate klien tetap tinggi dan bitrate server mulai menyusut sehubungan dengan bitrate klien, itu berarti bahwa tidak semua peluru telah "mencapai target", dan server sebenarnya tidak dapat melihat bagian dari lalu lintas yang dikirim kepadanya. Atas dasar ini, kita dapat menyimpulkan bahwa ada sesuatu yang salah dengan saluran dan saatnya untuk mengubah warna indikator menjadi merah.
Dan masih ada lagi
Grafik berkorelasi tetapi mereka sedikit bergeser waktu dalam kaitannya satu sama lain. Untuk korelasi penuh, perlu mencocokkan waktu grafik untuk membandingkan bitrate klien dan server pada titik waktu yang sama terhadap data historis. Sinkronisasi terlihat kurang lebih seperti ini:
Dan seperti inilah grafik yang disinkronkan waktu.
Mari kita coba
Kami memiliki sedikit yang harus dilakukan, kami hanya perlu mengujinya. Mari publikasikan aliran video, buka, dan lihat grafik bitrate yang diterbitkan: di sisi browser dan di sisi server. Grafik menunjukkan secara praktis pasangan yang sempurna. Dan ini adalah nama indikatornya, PERFECT.
Lalu, mari kita mulai merusak saluran. Untuk melakukan itu, kita dapat menggunakan alat gratis berikut: winShaper untuk Windows atau Network Link Conditioner untuk MacOS. Mereka memungkinkan untuk mengompresi saluran ke nilai preset. Misalnya, jika kita tahu bahwa aliran 640x480 dapat mencapai kecepatan 1 Mbps, mari kita kompres hingga 300 kbs. Ketika melakukan itu kita tidak boleh lupa bahwa kita sedang bekerja dengan TCP. Mari kita periksa hasil pengujian kami: ada korelasi terbalik dalam grafik, dan indikatornya tergelincir ke BAD. Memang, peramban terus mengirim data dan bahkan meningkatkan bitrate yang mencoba mendorong sebagian lalu lintas baru ke jaringan. Data ini terakumulasi dalam jaringan dalam bentuk transmisi ulang dan gagal mencapai server, akibatnya server menunjukkan gambar terbalik dan mengatakan bahwa bitrate yang dilihatnya telah turun. Memang, ini BURUK.
Kami telah melakukan cukup banyak tes yang menunjukkan operasi indikator yang benar . Karenanya, kami memiliki fitur yang memungkinkan untuk secara andal dan segera memberi tahu pengguna tentang masalah dengan saluran baik untuk streaming penerbitan dan bermain (bekerja dengan prinsip yang sama). Ya, semua yang diributkan ini untuk lampu hijau dan merah ini, PERFECT-BAD. Tetapi praktik menunjukkan bahwa indikator ini sangat penting, dan ketidakhadirannya, bersama dengan kegagalan untuk memahami status saat ini, dapat menciptakan masalah besar bagi pengguna biasa layanan streaming video WebRTC.
Tautan
WCS 5.2 adalah server media streaming untuk pengembangan aplikasi web dan seluler
Kontrol kualitas saluran penerbit dan pemain
REMB - Estimasi Penerima Bitrate Maksimum yang digunakan untuk kontrol bandwidth
NACK - Pengakuan Negatif yang digunakan untuk kontrol paket yang hilang dan transmisi ulang