Sementara pengadopsi awal pertama mencoba konferensi video baru kami (hingga 100 orang!) Dalam proyek mereka, kami terus berbicara tentang hal-hal menarik dari dunia transmisi suara dan video dengan browser. Kami juga akan berbicara tentang konferensi video, tetapi nanti - ketika massa kritis pengguna menumpuk dan statistik menarik dikumpulkan. Dan sekarang saya telah menerjemahkan dan mengadaptasi untuk kita kisah Dr. Alex tentang tempat protokol yang berbeda saat mentransmisikan video dengan latensi rendah. Cerita ini pada dasarnya adalah tanggapan terhadap artikel lain, dan penulis, bersama dengan cerita tersebut, menunjukkan kesalahan dan ketidakakuratan yang dibuat oleh rekan-rekannya di bengkel tersebut.
Data jaringan: alarm secara terpisah, video secara terpisah
Dalam sistem modern, jika Anda melihat video di browser, maka aliran video dan alarm kemungkinan besar akan diproses oleh server yang berbeda. Jika semuanya jelas dengan video, maka "server alarm" menyediakan dua hal: "penemuan" dan "jabat tangan". Yang pertama, "penemuan", adalah pilihan metode transfer data: alamat IP, server perantara (jika perlu). "Jabat Tangan" - tentang negosiasi antara peserta dalam transmisi video dan suara: codec, resolusi, kecepatan bingkai, kualitas. Menariknya, dalam Flash kuno, pensinyalan dan transmisi media tidak dipisahkan seperti di VoxIP atau WebRTC dan disediakan oleh satu protokol: RTMP.
Perbedaan antara protokol pensinyalan dan transport pensinyalan
Protokol pensinyalan mendefinisikan bahasa yang dengannya browser dan peserta lain dalam transmisi video akan menyetujui penemuan dan jabat tangan. Itu bisa SIP untuk penemuan di VoIP atau WebRTC, dan itu adalah dengan penawaran / jawaban untuk jabat tangan. Dahulu kala, Flash menggunakan
RTMP / AMF . Dan jika diinginkan, untuk WebRTC, Anda dapat menggunakan bukan SIP, tetapi JSEP yang tidak biasa.
Protokol pensinyalan pensinyalan dari tumpukan yang sama, tetapi lebih rendah: ini adalah bagaimana paket protokol pensinyalan akan ditransmisikan secara fisik. Secara tradisional, untuk Flash + SIP, TCP atau UDP digunakan, tetapi sekarang dalam bundel WebRTC + SIP, WebSockets semakin banyak ditemukan. Protokol transport WebSockets menempati ceruk TCP di browser tempat Anda tidak dapat menggunakan soket "murni" TCP dan UDP.
Tumpukan pensinyalan penuh sekarang populer diuraikan dengan frasa seperti "SIP di atas soket web", "JSEP di atas soket web", usang "SIP di atas TCP / UDP" atau "bagian RTMP" kuno.
Programmer Anglicism: Media Codec
Sebagian besar protokol streaming video terikat pada satu atau lebih codec. Video yang diterima dari kamera diproses bingkai demi bingkai. Dan masalah jaringan, seperti berkurangnya bandwidth, hilangnya paket, atau penundaan di antara keduanya, diselesaikan dengan pengaturan codec untuk setiap frame. Untuk mempelajari masalah jaringan tepat waktu, kami menggunakan mekanisme protokol transportasi (RTP / RTCP) dan mekanisme estimasi bandwidth (REMB, Transport-CC, TIMBR). Salah satu masalah mendasar dengan video Flash adalah RTMP tidak dapat melakukan keduanya, sehingga video berhenti diputar saat bandwidth saluran turun.
Anglicism lain: Protokol Streaming Media
Menentukan bagaimana membagi aliran video ke dalam paket-paket kecil yang dikirim melalui jaringan oleh protokol transport. Biasanya, protokol streaming masih menyediakan mekanisme untuk menangani masalah jaringan: kehilangan dan penundaan paket. Buffer Jitter, transmisi ulang (RTC), redundansi (RED) dan Forward Error Correction (FEC).
Protokol Transfer Media
Setelah video yang diterima dari kamera dibagi menjadi beberapa paket kecil, mereka harus ditransmisikan melalui jaringan. Protokol transport yang digunakan untuk ini mirip dengan yang signaling, tetapi karena “payload” sangat berbeda, beberapa protokol lebih baik daripada yang lain. Sebagai contoh, TCP menyediakan jangkauan paket, tetapi itu tidak menambah nilai ke stack, karena mekanisme yang serupa (RTX / RED / FEC) sudah ada dalam protokol streaming. Tetapi keterlambatan pengiriman kembali ke TCP adalah cacat yang jelas tidak dimiliki UDP. Tetapi ada praktik memblokir UDP sebagai "protokol untuk torrent."
Pilihan port protokol dan jaringan sebelumnya diputuskan oleh "hardcoding", tetapi sekarang kami menggunakan protokol seperti ICE di WebRTC, yang memungkinkan kami untuk menyetujui port dan mengangkut di setiap koneksi tertentu. Dalam waktu dekat, dimungkinkan untuk menggunakan protokol QUIC (kompatibel dengan UDP), yang secara aktif dibahas oleh IETF dan memiliki keunggulan dibandingkan TCP dan UDP dalam kecepatan dan keandalan. Terakhir, kita dapat menyebutkan protokol streaming media seperti MPEG-DASH dan HLS, yang menggunakan HTTP sebagai transportasi dan akan mendapat manfaat dari pengenalan HTTP / 2.0.
Keamanan Transmisi Media
Beberapa mesin melindungi data selama transmisi melalui jaringan: baik media itu sendiri, atau paket-paket lapisan transport. Proses ini termasuk transfer kunci enkripsi, yang digunakan protokol terpisah: SDES dalam VoIP dan DTLS di WebRTC. Yang terakhir ini memiliki keunggulan, karena selain data, ia juga melindungi pengiriman kunci enkripsi.
Apa yang menggangguku tentang semua ini
Beberapa pengembang, seperti penulis
artikel ini , menempatkan protokol WebSocket dan QUIC murni pada tingkat yang sama dengan WebRTC, Flash, atau HLS. Bagi saya, pengelompokan seperti itu terlihat aneh, karena tiga protokol terakhir adalah cerita tentang streaming media. Pengkodean dan pengemasan dilakukan sebelum menggunakan WebSocket atau QUIC. Referensi Google implementasi WebRTC (libwebrtc / chrome) dan Microsoft ORTC menggunakan QUIC sebagai protokol transport.
Yang sama mengejutkannya adalah kurangnya penyebutan HTTP / 2.0 sebagai optimisasi untuk protokol berbasis HTTP seperti HLS dan MPEG-DASH. Dan CMAF yang disebutkan tidak lebih dari format file untuk HLS dan MPEG-DASH, tetapi bukan pengganti mereka sama sekali.
Akhirnya, SRT hanyalah protokol transportasi. Dia, tentu saja, menambahkan sejumlah chip dibandingkan dengan yang berbasis pada file HLS dan MPEG-DASH, tetapi semua chip ini sudah pada tingkat tumpukan yang berbeda dan diimplementasikan dalam RTMP atau WebRTC. SRT juga berbagi penyandian aliran media dan statistik, yang tidak memungkinkan codec untuk menyimpan informasi ini sedekat mungkin satu sama lain. Keputusan seperti itu dapat mempengaruhi kemampuan untuk mengadaptasi video yang ditransfer ke bandwidth jaringan yang berubah.
Protokol berbasis file, seperti HLS, mengkodekan beberapa stream dan memilih yang diperlukan untuk beradaptasi dengan lebar saluran. WebRTC memungkinkan Anda untuk menyesuaikan penyandian setiap frame secara real time: itu jauh lebih cepat daripada memilih aliran lain di HLS, yang membutuhkan penghitungan hingga 10 detik dari data yang sudah dikirim.