Media Communication #

Apa yang saya dapatkan dari komunikasi media WebRTC? #

WebRTC memungkinkan Anda mengirim dan menerima jumlah stream audio dan video yang tidak terbatas. Anda dapat menambah dan menghapus stream ini kapan saja selama panggilan. Stream ini semuanya bisa independen, atau bisa digabungkan bersama! Anda dapat mengirim feed video desktop Anda, dan kemudian menyertakan audio dan video dari webcam Anda.

Protokol WebRTC adalah codec agnostic. Transpor yang mendasarinya mendukung semuanya, bahkan hal-hal yang belum ada! Namun, Agent WebRTC yang berkomunikasi dengan Anda mungkin tidak memiliki alat yang diperlukan untuk menerimanya.

WebRTC juga dirancang untuk menangani kondisi jaringan yang dinamis. Selama panggilan bandwidth Anda mungkin meningkat, atau menurun. Mungkin Anda tiba-tiba mengalami banyak packet loss. Protokol ini dirancang untuk menangani semua ini. WebRTC merespons kondisi jaringan dan mencoba memberi Anda pengalaman terbaik yang mungkin dengan sumber daya yang tersedia.

Bagaimana cara kerjanya? #

WebRTC menggunakan dua protokol yang sudah ada sebelumnya RTP dan RTCP, keduanya didefinisikan dalam RFC 1889.

RTP (Real-time Transport Protocol) adalah protokol yang membawa media. Ini dirancang untuk memungkinkan pengiriman video real-time. Ini tidak menetapkan aturan apa pun mengenai latensi atau keandalan, tetapi memberi Anda alat untuk mengimplementasikannya. RTP memberi Anda stream, sehingga Anda dapat menjalankan beberapa feed media melalui satu koneksi. Ini juga memberi Anda informasi timing dan pengurutan yang Anda butuhkan untuk memberi makan pipeline media.

RTCP (RTP Control Protocol) adalah protokol yang mengomunikasikan metadata tentang panggilan. Formatnya sangat fleksibel dan memungkinkan Anda menambahkan metadata apa pun yang Anda inginkan. Ini digunakan untuk mengomunikasikan statistik tentang panggilan. Ini juga digunakan untuk menangani packet loss dan untuk mengimplementasikan congestion control. Ini memberi Anda komunikasi dua arah yang diperlukan untuk merespons kondisi jaringan yang berubah.

Latensi vs Kualitas #

Media real-time adalah tentang membuat trade-off antara latensi dan kualitas. Semakin banyak latensi yang bersedia Anda toleransi, semakin tinggi kualitas video yang dapat Anda harapkan.

Keterbatasan Dunia Nyata #

Batasan ini semua disebabkan oleh keterbatasan dunia nyata. Ini semua adalah karakteristik jaringan Anda yang perlu Anda atasi.

Video itu Kompleks #

Mengangkut video tidaklah mudah. Untuk menyimpan 30 menit video 720 8-bit yang tidak dikompresi, Anda memerlukan sekitar 110 GB. Dengan angka-angka itu, panggilan konferensi 4 orang tidak akan terjadi. Kita memerlukan cara untuk membuatnya lebih kecil, dan jawabannya adalah kompresi video. Itu tidak datang tanpa kekurangan.

Video 101 #

Kami tidak akan membahas kompresi video secara mendalam, tetapi cukup untuk memahami mengapa RTP dirancang seperti itu. Kompresi video mengenkode video ke dalam format baru yang memerlukan lebih sedikit bit untuk merepresentasikan video yang sama.

Kompresi Lossy dan Lossless #

Anda dapat mengenkode video menjadi lossless (tidak ada informasi yang hilang) atau lossy (informasi mungkin hilang). Karena pengkodean lossless memerlukan lebih banyak data yang dikirim ke peer, membuat stream latensi lebih tinggi dan lebih banyak paket yang dijatuhkan, RTP biasanya menggunakan kompresi lossy meskipun kualitas videonya tidak akan sebaik itu.

Kompresi Intra dan Inter frame #

Kompresi video hadir dalam dua jenis. Yang pertama adalah intra-frame. Kompresi intra-frame mengurangi bit yang digunakan untuk mendeskripsikan satu frame video. Teknik yang sama digunakan untuk mengompresi gambar diam, seperti metode kompresi JPEG.

Jenis kedua adalah kompresi inter-frame. Karena video terdiri dari banyak gambar, kita mencari cara untuk tidak mengirim informasi yang sama dua kali.

Jenis Inter-frame #

Anda kemudian memiliki tiga jenis frame:

• I-Frame - Gambar lengkap, dapat didekode tanpa apa pun.
• P-Frame - Gambar parsial, hanya berisi perubahan dari gambar sebelumnya.
• B-Frame - Gambar parsial, adalah modifikasi dari gambar sebelumnya dan masa depan.

Berikut adalah visualisasi dari tiga jenis frame.

Video itu rapuh #

Kompresi video sangat stateful, membuatnya sulit untuk ditransfer melalui internet. Apa yang terjadi jika Anda kehilangan bagian dari I-Frame? Bagaimana P-Frame tahu apa yang harus dimodifikasi? Seiring kompresi video menjadi lebih kompleks, ini menjadi masalah yang lebih besar. Untungnya RTP dan RTCP memiliki solusinya.

RTP #

Format Paket #

Setiap paket RTP memiliki struktur berikut:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            Contributing Source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (V) #

Version selalu 2

Padding (P) #

Padding adalah bool yang mengontrol apakah payload memiliki padding.

Byte terakhir dari payload berisi hitungan berapa banyak byte padding yang ditambahkan.

Extension (X) #

Jika disetel, header RTP akan memiliki ekstensi. Ini dijelaskan lebih detail di bawah ini.

CSRC count (CC) #

Jumlah pengidentifikasi CSRC yang mengikuti setelah SSRC, dan sebelum payload.

Marker (M) #

Marker bit tidak memiliki arti yang telah ditetapkan, dan dapat digunakan sesuai keinginan pengguna.

Dalam beberapa kasus, ini disetel ketika pengguna sedang berbicara. Ini juga biasanya digunakan untuk menandai keyframe.

Payload Type (PT) #

Payload Type adalah pengidentifikasi unik untuk codec apa yang dibawa oleh paket ini.

Untuk WebRTC, Payload Type adalah dinamis. VP8 dalam satu panggilan mungkin berbeda dari yang lain. Offerer dalam panggilan menentukan pemetaan Payload Types ke codec dalam Session Description.

Sequence Number #

Sequence Number digunakan untuk mengurutkan paket dalam stream. Setiap kali paket dikirim, Sequence Number ditambah satu.

RTP dirancang agar berguna melalui jaringan yang lossy. Ini memberi penerima cara untuk mendeteksi kapan paket telah hilang.

Timestamp #

Momen pengambilan sampel untuk paket ini. Ini bukan jam global, tetapi berapa banyak waktu yang telah berlalu dalam stream media. Beberapa paket RTP dapat memiliki timestamp yang sama jika mereka misalnya semua bagian dari frame video yang sama.

Synchronization Source (SSRC) #

SSRC adalah pengidentifikasi unik untuk stream ini. Ini memungkinkan Anda menjalankan beberapa stream media melalui satu stream RTP.

Contributing Source (CSRC) #

Daftar yang mengomunikasikan SSRC mana yang berkontribusi pada paket ini.

Ini biasanya digunakan untuk indikator berbicara. Katakanlah server side Anda menggabungkan beberapa feed audio menjadi satu stream RTP. Anda kemudian dapat menggunakan bidang ini untuk mengatakan “Input stream A dan C sedang berbicara pada saat ini”.

Payload #

Data payload yang sebenarnya. Mungkin diakhiri dengan hitungan berapa banyak byte padding yang ditambahkan, jika flag padding disetel.

Extensions #

RTCP #

Format Paket #

Setiap paket RTCP memiliki struktur berikut:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |       PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (V) #

Version selalu 2.

Padding (P) #

Padding adalah bool yang mengontrol apakah payload memiliki padding.

Byte terakhir dari payload berisi hitungan berapa banyak byte padding yang ditambahkan.

Reception Report Count (RC) #

Jumlah laporan dalam paket ini. Satu paket RTCP dapat berisi beberapa event.

Packet Type (PT) #

Pengidentifikasi Unik untuk jenis paket RTCP apa ini. Agent WebRTC tidak perlu mendukung semua jenis ini, dan dukungan antar Agent dapat berbeda. Ini adalah yang mungkin sering Anda lihat:

• 192 - Full INTRA-frame Request (FIR)
• 193 - Negative ACKnowledgements (NACK)
• 200 - Sender Report
• 201 - Receiver Report
• 205 - Generic RTP Feedback
• 206 - Payload Specific Feedback

Signifikansi jenis paket ini akan dijelaskan lebih detail di bawah ini.

Full INTRA-frame Request (FIR) dan Picture Loss Indication (PLI) #

Pesan FIR dan PLI melayani tujuan yang serupa. Pesan-pesan ini meminta key frame penuh dari pengirim. PLI digunakan ketika frame parsial diberikan ke decoder, tetapi tidak dapat mendekodenya. Ini bisa terjadi karena Anda memiliki banyak packet loss, atau mungkin decoder crash.

Menurut RFC 5104, FIR tidak boleh digunakan ketika paket atau frame hilang. Itu adalah tugas PLI. FIR meminta key frame untuk alasan selain packet loss - misalnya ketika anggota baru memasuki konferensi video. Mereka memerlukan key frame penuh untuk mulai mendekode stream video, decoder akan membuang frame sampai key frame tiba.

Ini adalah ide yang baik bagi penerima untuk meminta key frame penuh segera setelah terhubung, ini meminimalkan penundaan antara koneksi, dan gambar yang muncul di layar pengguna.

Paket PLI adalah bagian dari pesan Payload Specific Feedback.

Dalam praktiknya, perangkat lunak yang dapat menangani paket PLI dan FIR akan bertindak dengan cara yang sama dalam kedua kasus. Ini akan mengirim sinyal ke encoder untuk menghasilkan key frame penuh yang baru.

Negative Acknowledgment #

NACK meminta pengirim mengirim ulang satu paket RTP. Ini biasanya disebabkan oleh paket RTP yang hilang, tetapi juga bisa terjadi karena terlambat.

NACK jauh lebih efisien bandwidth daripada meminta seluruh frame dikirim lagi. Karena RTP memecah paket menjadi potongan yang sangat kecil, Anda benar-benar hanya meminta satu bagian kecil yang hilang. Penerima membuat pesan RTCP dengan SSRC dan Sequence Number. Jika pengirim tidak memiliki paket RTP ini tersedia untuk dikirim ulang, ia hanya mengabaikan pesan tersebut.

Sender dan Receiver Reports #

Laporan ini digunakan untuk mengirim statistik antar agent. Ini mengomunikasikan jumlah paket yang benar-benar diterima dan jitter.

Laporan dapat digunakan untuk diagnostik dan congestion control.

Bagaimana RTP/RTCP menyelesaikan masalah bersama-sama #

RTP dan RTCP kemudian bekerja sama untuk menyelesaikan semua masalah yang disebabkan oleh jaringan. Teknik-teknik ini masih terus berubah!

Forward Error Correction #

Juga dikenal sebagai FEC. Metode lain untuk menangani packet loss. FEC adalah ketika Anda mengirim data yang sama beberapa kali, tanpa diminta. Ini dilakukan pada level RTP, atau bahkan lebih rendah dengan codec.

Jika packet loss untuk panggilan stabil maka FEC adalah solusi latensi yang jauh lebih rendah daripada NACK. Round trip time untuk meminta, dan kemudian mengirim ulang paket yang hilang bisa signifikan untuk NACK.

Adaptive Bitrate dan Bandwidth Estimation #

Seperti yang dibahas dalam bab Real-time networking, jaringan tidak dapat diprediksi dan tidak dapat diandalkan. Ketersediaan bandwidth dapat berubah beberapa kali sepanjang sesi. Tidak jarang melihat bandwidth yang tersedia berubah secara dramatis (beberapa kali lipat) dalam satu detik.

Ide utamanya adalah menyesuaikan bitrate pengkodean berdasarkan bandwidth jaringan yang tersedia yang diprediksi, saat ini, dan masa depan. Ini memastikan bahwa sinyal video dan audio dengan kualitas terbaik yang mungkin ditransmisikan, dan koneksi tidak terputus karena kemacetan jaringan. Heuristik yang memodelkan perilaku jaringan dan mencoba memprediksinya dikenal sebagai Bandwidth estimation.

Ada banyak nuansa untuk ini, jadi mari kita jelajahi lebih detail.

Mengidentifikasi dan Mengomunikasikan Status Jaringan #

RTP/RTCP berjalan di atas semua jenis jaringan yang berbeda, dan sebagai hasilnya, adalah umum untuk beberapa komunikasi dijatuhkan dalam perjalanan dari pengirim ke penerima. Dibangun di atas UDP, tidak ada mekanisme bawaan untuk retransmisi paket, apalagi menangani congestion control.

Untuk memberikan pengalaman terbaik kepada pengguna, WebRTC harus memperkirakan kualitas tentang jalur jaringan, dan beradaptasi dengan bagaimana kualitas tersebut berubah dari waktu ke waktu. Sifat kunci untuk dipantau meliputi: bandwidth yang tersedia (di setiap arah, karena mungkin tidak simetris), round trip time, dan jitter (fluktuasi dalam round trip time). Ini perlu memperhitungkan packet loss, dan mengomunikasikan perubahan dalam properti ini seiring kondisi jaringan berkembang.

Ada dua tujuan utama untuk protokol ini:

1. Memperkirakan bandwidth yang tersedia (di setiap arah) yang didukung oleh jaringan.
2. Mengomunikasikan karakteristik jaringan antara pengirim dan penerima.

RTP/RTCP memiliki tiga pendekatan berbeda untuk mengatasi masalah ini. Semuanya memiliki pro dan kontra, dan umumnya setiap generasi telah meningkat dari pendahulunya. Implementasi mana yang Anda gunakan akan bergantung terutama pada stack perangkat lunak yang tersedia untuk klien Anda dan library yang tersedia untuk membangun aplikasi Anda.

Receiver Reports / Sender Reports #

Implementasi pertama adalah pasangan Receiver Reports dan komplemennya, Sender Reports. Ini pesan RTCP didefinisikan dalam RFC 3550, dan bertanggung jawab untuk mengomunikasikan status jaringan antar endpoint. Receiver Reports berfokus pada mengomunikasikan kualitas tentang jaringan (termasuk packet loss, round-trip time, dan jitter), dan berpasangan dengan algoritma lain yang kemudian bertanggung jawab untuk memperkirakan bandwidth yang tersedia berdasarkan laporan ini.

Sender dan Receiver report (SR dan RR) bersama-sama melukiskan gambaran kualitas jaringan. Mereka dikirim sesuai jadwal untuk setiap SSRC, dan mereka adalah input yang digunakan saat memperkirakan bandwidth yang tersedia. Perkiraan tersebut dibuat oleh pengirim setelah menerima data RR, yang berisi bidang-bidang berikut:

• Fraction Lost - Berapa persentase paket yang hilang sejak Receiver Report terakhir.
• Cumulative Number of Packets Lost - Berapa banyak paket yang hilang selama seluruh panggilan.
• Extended Highest Sequence Number Received - Apa Sequence Number terakhir yang diterima, dan berapa kali telah berputar.
• Interarrival Jitter - Jitter bergulir untuk seluruh panggilan.
• Last Sender Report Timestamp - Waktu terakhir yang diketahui pada pengirim, digunakan untuk perhitungan round-trip time.

SR dan RR bekerja bersama untuk menghitung round-trip time.

Pengirim menyertakan waktu lokalnya, sendertime1 dalam SR. Ketika penerima mendapat paket SR, ia mengirim kembali RR. Di antara hal-hal lain, RR menyertakan sendertime1 yang baru saja diterima dari pengirim. Akan ada penundaan antara menerima SR dan mengirim RR. Karena itu, RR juga menyertakan waktu “delay since last sender report” - DLSR. DLSR digunakan untuk menyesuaikan perkiraan round-trip time nanti dalam proses. Setelah pengirim menerima RR, ia mengurangi sendertime1 dan DLSR dari waktu saat ini sendertime2. Delta waktu ini disebut round-trip propagation delay atau round-trip time.

rtt = sendertime2 - sendertime1 - DLSR

Round-trip time dalam bahasa Inggris sederhana:

• Saya mengirim Anda pesan dengan pembacaan jam saya saat ini, katakanlah jam 4:20 sore, 42 detik dan 420 milidetik.
• Anda mengirim saya timestamp yang sama ini kembali.
• Anda juga menyertakan waktu yang berlalu dari membaca pesan saya hingga mengirim pesan kembali, katakanlah 5 milidetik.
• Setelah saya menerima waktu kembali, saya melihat jam lagi.
• Sekarang jam saya mengatakan jam 4:20 sore, 42 detik 690 milidetik.
• Itu berarti dibutuhkan 265 milidetik (690 - 420 - 5) untuk mencapai Anda dan kembali ke saya.
• Oleh karena itu, round-trip time adalah 265 milidetik.

TMMBR, TMMBN, REMB dan TWCC, dipasangkan dengan GCC #

Google Congestion Control (GCC) #

Algoritma Google Congestion Control (GCC) (dijelaskan dalam draft-ietf-rmcat-gcc-02) mengatasi tantangan estimasi bandwidth. Ini berpasangan dengan berbagai protokol lain untuk memfasilitasi persyaratan komunikasi terkait. Akibatnya, ini sangat cocok untuk berjalan baik di sisi penerima (ketika dijalankan dengan TMMBR/TMMBN atau REMB) atau di sisi pengirim (ketika dijalankan dengan TWCC).

Untuk mencapai perkiraan untuk bandwidth yang tersedia, GCC berfokus pada packet loss dan fluktuasi dalam waktu kedatangan frame sebagai dua metrik utamanya. Ini menjalankan metrik ini melalui dua controller yang terhubung: controller berbasis kehilangan dan controller berbasis penundaan.

Komponen pertama GCC, loss-based controller, sederhana:

• Jika packet loss di atas 10%, perkiraan bandwidth dikurangi.
• Jika packet loss antara 2-10%, perkiraan bandwidth tetap sama.
• Jika packet loss di bawah 2%, perkiraan bandwidth ditingkatkan.

Pengukuran packet loss dilakukan dengan sering. Tergantung pada protokol komunikasi berpasangan, packet loss dapat dikomunikasikan secara eksplisit (seperti dengan TWCC) atau disimpulkan (seperti dengan TMMBR/TMMBN dan REMB). Persentase ini dievaluasi melalui jendela waktu sekitar satu detik.

Delay-based controller bekerja sama dengan loss-based controller, dan melihat variasi dalam waktu kedatangan paket. Delay-based controller ini bertujuan untuk mengidentifikasi kapan tautan jaringan menjadi semakin padat, dan dapat mengurangi perkiraan bandwidth bahkan sebelum packet loss terjadi. Teorinya adalah bahwa antarmuka jaringan yang paling sibuk di sepanjang jalur akan terus mengantri paket sampai antarmuka kehabisan kapasitas di dalam buffer-nya. Jika antarmuka itu terus menerima lebih banyak lalu lintas daripada yang dapat dikirimnya, ia akan dipaksa untuk menjatuhkan semua paket yang tidak dapat masuk ke dalam ruang buffer-nya. Jenis packet loss ini sangat mengganggu untuk komunikasi latensi rendah/real-time, tetapi juga dapat menurunkan throughput untuk semua komunikasi melalui tautan itu dan idealnya harus dihindari. Dengan demikian, GCC mencoba mencari tahu apakah tautan jaringan menumbuhkan kedalaman antrian yang semakin besar dan lebih besar sebelum packet loss benar-benar terjadi. Ini akan mengurangi penggunaan bandwidth jika mengamati peningkatan penundaan antrian dari waktu ke waktu.

Untuk mencapai ini, GCC mencoba menyimpulkan peningkatan kedalaman antrian dengan mengukur peningkatan halus dalam round trip time. Ini mencatat “inter-arrival time” frame, t(i) - t(i-1): perbedaan waktu kedatangan dari dua kelompok paket (umumnya, frame video berturut-turut). Kelompok paket ini sering berangkat pada interval waktu yang teratur (misalnya setiap 1/24 detik untuk video 24 fps). Sebagai hasilnya, mengukur inter-arrival time kemudian sesederhana merekam perbedaan waktu antara awal dari kelompok paket pertama (yaitu frame) dan frame pertama dari yang berikutnya.

Dalam diagram di bawah ini, peningkatan penundaan inter-packet median adalah +20 milidetik, indikator yang jelas dari kemacetan jaringan.

Jika inter-arrival time meningkat dari waktu ke waktu, itu dianggap bukti peningkatan kedalaman antrian pada antarmuka jaringan yang menghubungkan dan dianggap kemacetan jaringan. (Catatan: GCC cukup pintar untuk mengontrol pengukuran ini untuk fluktuasi dalam ukuran byte frame.) GCC memperbaiki pengukuran latensinya menggunakan filter Kalman dan mengambil banyak pengukuran round-trip time jaringan (dan variasinya) sebelum menandai kemacetan. Orang dapat menganggap filter Kalman GCC sebagai pengganti regresi linier: membantu membuat prediksi yang akurat bahkan ketika jitter menambahkan kebisingan ke dalam pengukuran timing. Setelah menandai kemacetan, GCC akan mengurangi bitrate yang tersedia. Atau, dalam kondisi jaringan yang stabil, ia dapat perlahan-lahan meningkatkan perkiraan bandwidth-nya untuk menguji nilai beban yang lebih tinggi.

TMMBR, TMMBN, dan REMB #

Untuk TMMBR/TMMBN dan REMB, sisi penerima pertama-tama memperkirakan bandwidth masuk yang tersedia (menggunakan protokol seperti GCC), dan kemudian mengomunikasikan perkiraan bandwidth ini ke pengirim remote. Mereka tidak perlu bertukar detail tentang packet loss atau kualitas lain tentang kemacetan jaringan karena beroperasi di sisi penerima memungkinkan mereka mengukur inter-arrival time dan packet loss secara langsung. Sebaliknya, TMMBR, TMMBN, dan REMB hanya bertukar perkiraan bandwidth itu sendiri:

• Temporary Maximum Media Stream Bit Rate Request - Mantissa/eksponen dari bitrate yang diminta untuk satu SSRC.
• Temporary Maximum Media Stream Bit Rate Notification - Pesan untuk memberi tahu bahwa TMMBR telah diterima.
• Receiver Estimated Maximum Bitrate - Mantissa/eksponen dari bitrate yang diminta untuk seluruh sesi.

TMMBR dan TMMBN datang pertama dan didefinisikan dalam RFC 5104. REMB datang kemudian, ada draft yang diajukan dalam draft-alvestrand-rmcat-remb, tetapi tidak pernah distandarisasi.

Contoh sesi yang menggunakan REMB mungkin berperilaku seperti berikut:

Metode ini bekerja dengan baik di atas kertas. Pengirim menerima estimasi dari penerima, mengatur bitrate encoder ke nilai yang diterima. Tada! Kami telah menyesuaikan dengan kondisi jaringan.

Namun dalam praktiknya, pendekatan REMB memiliki beberapa kekurangan.

Ketidakefisienan encoder adalah yang pertama. Ketika Anda menetapkan bitrate untuk encoder, itu tidak selalu menghasilkan bitrate yang tepat yang Anda minta. Pengkodean dapat menghasilkan lebih banyak atau lebih sedikit bit, tergantung pada pengaturan encoder dan frame yang dikode.

Misalnya, menggunakan encoder x264 dengan tune=zerolatency dapat secara signifikan menyimpang dari target bitrate yang ditentukan. Berikut adalah skenario yang mungkin:

• Katakanlah kita mulai dengan mengatur bitrate ke 1000 kbps.
• Encoder hanya menghasilkan 700 kbps, karena tidak ada cukup fitur frekuensi tinggi untuk dikode. (AKA - “menatap dinding”.)
• Mari kita juga bayangkan bahwa penerima mendapat video 700 kbps dengan nol packet loss. Kemudian ia menerapkan aturan REMB 1 untuk meningkatkan bitrate masuk sebesar 8%.
• Penerima mengirim paket REMB dengan saran 756 kbps (700 kbps * 1.08) ke pengirim.
• Pengirim mengatur bitrate encoder ke 756 kbps.
• Encoder menghasilkan bitrate yang lebih rendah lagi.
• Proses ini terus berulang, menurunkan bitrate ke minimum absolut.

Anda dapat melihat bagaimana ini akan menyebabkan penyetelan parameter encoder yang berat, dan mengejutkan pengguna dengan video yang tidak dapat ditonton bahkan pada koneksi yang bagus.

Transport Wide Congestion Control #

Transport Wide Congestion Control adalah perkembangan terbaru dalam komunikasi status jaringan RTCP. Ini didefinisikan dalam draft-holmer-rmcat-transport-wide-cc-extensions-01, tetapi juga tidak pernah distandarisasi.

TWCC menggunakan prinsip yang cukup sederhana:

Dengan REMB, penerima menginstruksikan sisi pengirim dalam bitrate download yang tersedia. Ini menggunakan pengukuran yang tepat tentang packet loss yang disimpulkan dan data hanya yang dimilikinya tentang waktu kedatangan inter-packet.

TWCC hampir merupakan pendekatan hibrida antara SR/RR dan generasi protokol REMB. Ini membawa perkiraan bandwidth kembali ke sisi pengirim (mirip dengan SR/RR), tetapi teknik estimasi bandwidth-nya lebih mirip dengan generasi REMB.

Dengan TWCC, penerima memberi tahu pengirim waktu kedatangan setiap paket. Ini adalah informasi yang cukup untuk pengirim mengukur variasi penundaan kedatangan inter-packet, serta mengidentifikasi paket mana yang dijatuhkan atau tiba terlambat untuk berkontribusi pada feed audio/video. Dengan data ini yang dipertukarkan dengan sering, pengirim dapat dengan cepat menyesuaikan dengan kondisi jaringan yang berubah dan bervariasi output bandwidth-nya menggunakan algoritma seperti GCC.

Pengirim melacak paket yang dikirim, nomor urutnya, ukuran dan timestamp. Ketika pengirim menerima pesan RTCP dari penerima, ia membandingkan penundaan inter-packet pengiriman dengan penundaan penerimaan. Jika penundaan penerimaan meningkat, ini menandakan kemacetan jaringan, dan pengirim harus mengambil tindakan korektif.

Dengan memberikan pengirim data mentah, TWCC menyediakan pandangan yang sangat baik ke dalam kondisi jaringan real time:

• Perilaku packet loss hampir instan, hingga paket individual yang hilang
• Bitrate pengiriman yang akurat
• Bitrate penerimaan yang akurat
• Pengukuran jitter
• Perbedaan antara penundaan paket pengiriman dan penerimaan
• Deskripsi tentang bagaimana jaringan mentolerir pengiriman bandwidth yang bursty atau stabil

Salah satu kontribusi paling signifikan dari TWCC adalah fleksibilitas yang diberikannya kepada developer WebRTC. Dengan mengkonsolidasikan algoritma congestion control ke sisi pengirim, ini memungkinkan kode klien sederhana yang dapat digunakan secara luas dan memerlukan peningkatan minimal dari waktu ke waktu. Algoritma congestion control yang kompleks kemudian dapat diiterasi lebih cepat pada perangkat keras yang mereka kontrol langsung (seperti Selective Forwarding Unit, dibahas di bagian 8). Dalam kasus peramban dan perangkat seluler, ini berarti klien tersebut dapat mengambil manfaat dari peningkatan algoritma tanpa harus menunggu standardisasi atau pembaruan peramban (yang dapat memakan waktu cukup lama untuk tersedia secara luas).

Alternatif Bandwidth Estimation #

Implementasi yang paling banyak diterapkan adalah “A Google Congestion Control Algorithm for Real-Time Communication” yang didefinisikan dalam draft-alvestrand-rmcat-congestion.

Ada beberapa alternatif untuk GCC, misalnya NADA: A Unified Congestion Control Scheme for Real-Time Media dan SCReAM - Self-Clocked Rate Adaptation for Multimedia.