Menerapkan WebRTC di server media - praktik dan kebijakan

1. Streaming ke browser secara real time - tidak ada solusi. Atau disana?

Selama sekitar 20 tahun sekarang, bandwidth jaringan dan kemampuan komputasi komputer telah memungkinkan kompresi dan penyiaran suara dan video melalui protokol IP dalam mode real-time dekat. Selama waktu ini, organisasi standardisasi pusat seperti W3C dan IETF, serta banyak perusahaan besar dan kecil, telah mengembangkan ratusan standar dan protokol untuk mengompresi, mengepak, meneruskan, menyinkronkan secara efisien dan memutar konten audio-video pada komputer dan perangkat seluler. Pengambilan video, kompresi, dan penyiaran real-time melalui IP diberi perhatian khusus, karena, pertama, IP adalah yang termurah dan paling mudah diakses di semua tingkatan, dan kedua, teknologi konferensi video dan pengawasan video sangat penting dan sangat diminati.

Tampaknya bertahun-tahun telah berlalu dan begitu banyak pekerjaan yang telah dilakukan. Apa prestasi luar biasa di bidang ini yang dapat kita amati setelah 20 tahun? Mari kita lepaskan tutup kotak (tentu saja, ini bukan kotak Pandora dan bukan "kaleng cacing") dan lihat teknologi dan kemampuan hebat apa yang telah tersedia setelah bertahun-tahun bekerja oleh puluhan ribu insinyur perangkat lunak berbakat. Seorang programmer dari tahun 1998, yang pertama kali mengirim suara melalui jaringan, seorang dokter yang menginginkan solusi telemedicine sederhana, murah dan dapat diandalkan, seorang guru yang perlu melakukan pelajaran jarak jauh - sekarang mereka membuka penutup ini, penuh harapan cerah, dan apa yang mereka lihat? Dalam panci mendidih ofensif yang penuh dengan pemasaran yang mengejutkan, kapitalisme sinis dan upaya putus asa oleh para penggemar untuk meningkatkan hal-hal, semua jenis codec, protokol, format dan aplikasi mengambang.Inilah yang ditawarkan “komunitas” IT kepada konsumen secara real time. Tangkap diri Anda yang wangi, coba, tes, beli. Tidak ada solusi yang sederhana dan efektif. Tidak seperti streaming, yang tidak memerlukan waktu nyata: masih ada selama 5 tahun telah ada standar HLS yang bekerja pada semua browser dan perangkat di mana penyedia solusi dapat dengan mudah menginstal segmenter HLS di server Anda dan tidur nyenyak.

Berikut ini adalah RTSP - banyak konsol dan peralatan profesional memainkannya, tetapi browser tidak bermain. Inilah RTMP - Safari tidak ingin memainkannya di iOS dan tidak semua Android memainkannya. Chrome melarangnya sebagai tidak dapat dipercaya. Ini MPEG2-TS - browser juga tidak memainkannya. HTML5 Media Source Extensions (MSE) - bagus untuk segmen video dengan durasi 5-10 detik (mis. Untuk HLS / Dash), tetapi untuk segmen pendek kurang dari satu detik - tidak selalu stabil, berfungsi berbeda di browser yang berbeda dan lagi tidak didukung di iOS.

Bagaimana, orang bertanya-tanya, apakah TK mengirim video dari kamera yang dipasang dalam kelompok kepada orang tua yang ingin membuka browser kapan saja di perangkat apa pun, dan tanpa memasang plug-in untuk menonton anak-anak mereka secara langsung? Mengapa semua taman kanak-kanak tidak menawarkan layanan seperti itu? Ya, karena menyediakan layanan seperti itu sangat mahal. Kita perlu mengembangkan Aplikasi untuk perangkat seluler, tempat video akan diputar - karena browser tidak dapat diputar. Perlu lebih banyak.

Mari kita mendefinisikan konsep "dekat dengan waktu nyata". Ini kurang dari 5 detik keterlambatan untuk pengawasan video dan kurang dari 1 detik untuk konferensi video. Penundaan rata-rata protokol HLS adalah 20-30 detik. Mungkin entah bagaimana cocok untuk taman kanak-kanak, tetapi untuk pengawasan video keamanan, konferensi video dan webinar, teknologi lain diperlukan.

Jadi, sampai sekarang, lebih tepatnya hingga musim panas 2017, tidak ada standar atau protokol tunggal untuk menyiarkan audio-video ke browser apa pun di perangkat apa pun secara real time. Alasan untuk situasi ini, kami akan pertimbangkan dalam artikel ini nanti. Alasan-alasan ini bukan bersifat teknis. Sementara itu, mari kita lihat apa yang terjadi di musim panas 2017, yang paling tidak, tetapi masih menyediakan teknologi yang memungkinkan kita untuk menyelesaikan masalah di atas. Teknologi ini adalah WebRTC, banyak yang telah ditulis tentang hal ini baik pada sumber ini maupun pada jaringan secara umum. Itu tidak lagi bisa disebut sepenuhnya baru, dan pada saat penulisan ini, W3C menganggap WebRTC 1.0 sebagai proyek yang selesai. Kami tidak akan berbicara di sini tentang apa itu WebRTC; jika pembaca tidak terbiasa dengan teknologi ini, maka kami sarankan untuk melakukan pencarian di hub atau di google dan berkenalan,apa yang digunakan untuk dan bagaimana cara kerjanya secara umum. Di sini kami hanya mengatakan bahwa teknologi ini dikembangkan untuk komunikasi peer-to-peer di browser, dengan itu Anda dapat menerapkan aplikasi obrolan video dan suara tanpa server apa pun - browser berkomunikasi langsung dengan browser. WebRTC didukung oleh semua browser di semua perangkat, dan pada musim panas 2017, Apple akhirnya mendatangi kami dan menambahkannya ke Safari-nya di iOS. Acara inilah yang menjadikan WebRTC teknologi paling fleksibel dan diterima secara umum untuk streaming real-time ke browser sejak matahari terbenam RTMP, yang dimulai pada 2015.WebRTC didukung oleh semua browser di semua perangkat, dan pada musim panas 2017, Apple akhirnya mendatangi kami dan menambahkannya ke Safari-nya di iOS. Acara inilah yang menjadikan WebRTC teknologi paling fleksibel dan diterima secara umum untuk streaming real-time ke browser sejak matahari terbenam RTMP, yang dimulai pada 2015.WebRTC didukung oleh semua browser di semua perangkat, dan pada musim panas 2017, Apple akhirnya mendatangi kami dan menambahkannya ke Safari-nya di iOS. Acara inilah yang menjadikan WebRTC teknologi paling fleksibel dan diterima secara umum untuk streaming real-time ke browser sejak matahari terbenam RTMP, yang dimulai pada 2015.

Namun, apa hubungannya streaming dengan browser dari kamera? Tetapi kenyataannya adalah bahwa WebRTC sangat fleksibel dalam fungsinya, dan memungkinkan Anda untuk mengirim audio-video hanya ke salah satu dari dua peserta (rekan-rekan), dan yang lainnya hanya untuk menerima. Oleh karena itu, lahirlah ide untuk mengadaptasi WebRTC di server media. Server media dapat menerima video dari kamera, menjalin komunikasi dengan browser, dan setuju bahwa hanya video yang akan dikirim dan browser akan menerima. Dengan demikian, Server Media dapat secara bersamaan mengirim video dari kamera ke banyak browser / pemirsa. Sebaliknya, server media dapat menerima aliran dari browser, dan meneruskannya ke, katakanlah, banyak browser lain, mewujudkan fungsi "satu-ke-banyak" yang sangat diinginkan.

Jadi, akhirnya semuanya terbentuk? Akuna Matata, dan taman kanak-kanak akan dapat menginstal server media semacam itu di suatu tempat di hosting atau di AWS, mengirim satu aliran dari setiap kamera di sana, dan dari sana itu akan didistribusikan ke browser orang tua, semua dengan penundaan tidak lebih dari satu detik. Secara umum - ya, hidup semakin baik. Tapi ada masalah. Dan masalah-masalah ini terkait dengan fakta bahwa WebRTC, seolah-olah, dibuat-buat untuk tugas-tugas seperti itu, itu tidak dirancang untuk mereka dan tidak cukup cocok untuk mereka. Masalah, selain kompatibilitas codec, ada terutama dengan skalabilitas server media tersebut. Artinya, pada saat yang sama 100 orangtua dapat dilayani dari satu komputer server, dan 500 sudah sulit. Meskipun jaringan memungkinkan. Dan lihat beban prosesor di server dengan 100 koneksi - sudah mendekati 90%. Bagaimana? Lagi pula, cukup kirim video suara.

Dengan aliran yang sama, jika dikirim melalui protokol RTMP ke Flash player, maka Anda dapat dengan mudah mendukung 2000 koneksi simultan dari satu server. Apakah WebRTC hanya 100?
Mengapa? Ada dua alasan: pertama, protokol WebRTC jauh lebih mahal secara komputasi - di sana, misalnya, semua data dienkripsi, dan membutuhkan banyak waktu prosesor. Dan alasan kedua, yang akan kita bahas secara lebih rinci, adalah implementasi protokol yang sangat tidak efisien oleh pembuatnya - Google, yang menyediakan kode sumber c ++ untuk implementasi ini untuk adaptasi di server, gateway dan aplikasi lain yang ingin mendukung WebRTC: webrtc.org/native-code

2 API Native WebRTC Google dan Kompatibilitas Server Media

Ingatlah bahwa WebRTC dibuat untuk mentransfer audio-video dari browser ke browser dan tidak ada tugas untuk mendukung banyak koneksi simultan. Oleh karena itu, dan bukan hanya karena itu, penerapan WebRTC di browser sepenuhnya tidak peduli tentang prinsip dasar desain dan arsitektur sistem teknis - keanggunan (tidak lebih), efisiensi, kinerja tinggi. Penekanannya ditempatkan pada keandalan dan pengelolaan dengan kesalahan dan situasi ekstrim dalam jaringan - hilangnya paket, koneksi, dll. Yang tentu saja bagus. Namun, setelah diteliti lebih lanjut, ternyata ini adalah satu-satunya hal yang baik dalam penerapan Google WebRTC.

Mari kita lihat poin utama karena penggunaan implementasi Google WebRTC untuk server media sangat bermasalah.

2.a Kode ini 10 kali lebih banyak dari yang seharusnya dan ini sangat tidak efisien.

Ini adalah angka yang terbukti. Untuk memulai, Anda mengunduh sekitar 5 gigabyte kode, yang mana hanya 500 megabita yang relevan dengan WebRTC. Kemudian Anda mencoba untuk menyingkirkan kode yang tidak perlu. Lagi pula, untuk kebutuhan server media Anda tidak perlu encoding / decoding; server hanya menerima konten dan meneruskannya ke semua orang. Saat Anda menghapus semua hal yang tidak perlu (dan Anda bisa menghapus lebih sedikit dari yang Anda inginkan), Anda masih memiliki 100 megabita kode. Ini adalah sosok yang mengerikan. Dialah yang 10 kali lebih besar dari yang seharusnya.

Ngomong-ngomong, pada titik ini, banyak yang akan mengatakan - bagaimana cara encoding / decoding tidak diperlukan? Bagaimana dengan transcoding dari AAC ke Opus dan sebaliknya? Bagaimana dengan transcoding VP9-> H264? Jika Anda akan melakukan transcoding seperti itu di server, maka Anda tidak dapat menarik 5 koneksi secara bersamaan. Jika benar-benar diperlukan, transcoding tidak boleh dilakukan oleh server media, tetapi oleh program lain.

Tapi mari kita kembali ke masalah kode kembung dan menggambarkannya. Menurut Anda apa kedalaman tumpukan panggilan fungsi saat mengirim bingkai video yang sudah dikompresi? Satu panggilan ke winsock (pada Windows) dari fungsi kirim atau kirim ke (WSASend / WSASendTo)? Tidak, tentu saja, masih banyak pekerjaan yang harus dilakukan. Dalam kasus WebRTC, Anda perlu mengemas frame melalui protokol RTP dan mengenkripsi, yang secara total memberi kita protokol SRTP. Penting untuk menyimpan frame jika terjadi kehilangan paket untuk mengirimkannya kembali nanti. Berapa banyak objek dan utas c ++ yang harus terlibat dalam ini?

Begini cara WebRTC 61



melakukannya : Seperti yang dapat Anda lihat dari tangkapan layar ini, mulai dari saat kami mengumpankan bingkai terkompresi ke WebRTC hingga antrian objek Paced_Sender, kedalaman tumpukan panggilan adalah 8 (!) Dan 7 objek terlibat!

Kemudian utas terpisah (utas) PacedSender menarik bingkai kami dari antrian dan mengirimkannya lebih lanjut untuk diproses:



Dan akhirnya, kami sampai pada langkah 4, di mana bingkai yang sudah dikemas dan terenkripsi RTP bergantung pada antrian untuk dikirim ke jaringan, yang bergerak dalam utas lainnya. Pada titik ini, kedalaman tumpukan panggilan (pada utas PacedSender) adalah 7, dan 3 objek baru lainnya terlibat. Utas yang sibuk mengirim akan memanggil WSASend akhir / WSASendTo juga setelah 3-4 fungsi panggilan bersarang dan akan melibatkan 3-4 objek baru.

Jadi, kami melihat 3 utas, yang masing-masing bekerja dengan baik. Setiap orang yang memprogram sistem semacam itu memiliki gagasan tentang bagaimana hal-hal seperti itu dilakukan, dan apa yang benar-benar perlu dilakukan. Menurut perkiraan kami, setidaknya 90% dari objek dan kode di sini berlebihan dan melanggar prinsip-prinsip pemrograman berorientasi objek.

2.b 4-5 utas dialokasikan per koneksi

Tidak diragukan lagi, dengan jumlah utas dalam contoh ini, semuanya teratur. Penting untuk menyediakan pemrosesan asinkron, bukan untuk memblokir siapa pun, dan ketiga utas diperlukan. Secara umum, satu WebRTC PeerConnection mengalokasikan 4-5 utas. Yah, itu mungkin untuk tetap di dalam 3. Tapi tidak kurang. Masalahnya adalah ini untuk setiap koneksi! Di server, misalnya, Anda dapat menyimpan 3 utas, tetapi mereka akan melayani semua koneksi secara bersamaan, dan tidak mengalokasikan 3 utas untuk setiap koneksi. Kumpulan utas adalah solusi server yang tidak diragukan untuk tugas-tugas seperti itu.

2.c Soket asinkron yang bekerja melalui pesan windows

Kode Google WebRTC di Windows menggunakan soket asinkron melalui WSAAsyncSelect. Pemrogram server tahu bahwa menggunakan fungsi pilih pada server adalah bunuh diri, dan WSAAsyncSelect, meskipun itu memperbaiki situasi, tetapi tidak dengan urutan besarnya. Jika Anda ingin mendukung ratusan dan ribuan koneksi, ada solusi yang lebih baik pada Windows daripada soket asinkron. Soket yang tumpang tindih dan Port Penyelesaian IO harus diaktifkan, mengirim pemberitahuan ke kumpulan utas yang sedang melakukan pekerjaan.

2.d Kesimpulan

Jadi, kita dapat menyimpulkan: menerapkan kode Google WebRTC, tanpa perubahan besar, ke server media dimungkinkan, tetapi server tidak akan dapat menarik ratusan koneksi simultan. Mungkin ada dua solusi:

Untuk membuat perubahan serius pada kode Google, tanpa berlebihan, hampir mustahil - setelah semua, semua objek ini sangat cocok satu sama lain, jangan merangkum fungsionalitas, bukan blok independen yang melakukan pekerjaan tertentu, sebagaimana mestinya. Melibatkan mereka tidak berubah dalam skenario lain adalah tidak mungkin.

Jangan menggunakan kode Google sama sekali, tetapi terapkan semuanya sendiri menggunakan perpustakaan terbuka seperti libsrtp dan sejenisnya. Mungkin ini adalah cara yang benar, tetapi selain fakta bahwa ini juga merupakan pekerjaan besar, Anda mungkin menghadapi kenyataan bahwa implementasi Anda tidak akan sepenuhnya kompatibel dengan Google, dan, karenanya, tidak akan berfungsi, atau tidak akan bekerja dalam semua kasus, untuk misalnya, dengan chrome, yang tidak dapat ditoleransi. Anda kemudian dapat berdebat dengan orang-orang dari Google untuk waktu yang lama, membuktikan bahwa Anda telah mengikuti standar, tetapi mereka tidak melakukannya, dan Anda akan benar seribu kali. Tetapi mereka, paling banter, akan mengatakan - “kita akan memperbaikinya, mungkin entah bagaimana nanti.” Anda perlu menyesuaikan ke chrome sekarang. Dan intinya.

3. Mengapa semuanya begitu menyedihkan

Situasi ini dengan streaming ke browser secara real time adalah ilustrasi yang sangat khas tentang apa yang kadang-kadang mengarah pada "teknologi yang didorong oleh bisnis". Teknologi yang dimotivasi oleh bisnis berkembang ke arah yang diperlukan untuk bisnis dan sejauh itu menyenangkan untuk bisnis ini. Berkat pendekatan bisnis kami sekarang memiliki komputer pribadi dan telepon seluler - tidak ada pemerintah atau kementerian perencanaan pusat yang dapat begitu tertarik dalam mengembangkan dan memperkenalkan semua teknologi konsumen ini kepada massa. Bisnis swasta, dimotivasi oleh keuntungan pribadi pemiliknya, melakukan ini segera setelah peluang teknis muncul.

Sudah lama diketahui, dipahami, dan diterima bahwa barang dan jasa konsumen yang tidak penting, yang tanpanya Anda dapat hidup damai, lebih baik dikembangkan oleh bisnis swasta, maka hal-hal yang sangat diperlukan bagi seseorang - energi, jalan, pendidikan polisi dan sekolah - harus dikembangkan secara terpusat. lembaga yang dikendalikan negara.

Kami, anak-anak Uni Soviet dan mentalitas "mari kita membuat teknologi yang benar dan kuat secara teknis sehingga orang dapat menggunakannya dan semuanya baik," tentu saja dapat mengatakan bahwa dalam sistem Soviet yang direncanakan (jika pemerintah tiba-tiba memutuskan), teknologi streaming IP waktu nyata dapat dikembangkan dan diimplementasikan dalam satu tahun dan akan menjadi urutan yang lebih baik daripada apa yang sekarang diperoleh bisnis dalam 20 tahun. Tetapi kami juga memahami bahwa hal itu tidak akan berkembang, menjadi usang dan, pada akhirnya, dalam jangka panjang, masih kehilangan beberapa teknologi Barat komersial.

Oleh karena itu, karena sangat mungkin untuk bergaul tanpa streaming-shimming, itu benar ditinggalkan pada belas kasihan bisnis swasta. Yang mengembangkannya untuk kepentingan mereka sendiri, dan bukan untuk kepentingan konsumen. Bagaimana itu tidak untuk kepentingan konsumen? Tetapi bagaimana dengan penawaran dan permintaan? Apa yang dibutuhkan konsumen, kemudian bisnis akan menawarkan? Tapi itu tidak menawarkan. Semua konsumen berteriak - Google, mendukung audio AAC di WebRTC, tetapi Google tidak akan pernah melakukannya, meskipun hanya meludah untuk melakukannya. Apple sama sekali tidak peduli dan tidak mengimplementasikan apa pun dari teknologi streaming yang sangat dibutuhkan dalam gadgetnya. Mengapa? Ya, karena tidak selalu bisnis melakukan apa yang dibutuhkan konsumen. Dia tidak melakukan ini ketika dia seorang monopolis dan tidak takut kehilangan konsumen. Kemudian bisnis sibuk memperkuat posisinya. Jadi Google membeli dalam beberapa tahun terakhir banyak produsen codec suara.Dan sekarang ini mendorong audio Opus, dan memaksa seluruh dunia untuk transcode AAC-> Opus agar sesuai dengan WebRTC, karena semua teknologi telah lama beralih ke audio AAC. Google membenarkan dugaan ini dengan fakta bahwa AAC adalah teknologi berbayar, dan Opus gratis. Tetapi pada kenyataannya, ini dilakukan untuk menetapkan teknologinya sebagai standar. Seperti Apple pernah lakukan dengan HLS celaka, yang dibuat untuk kita cintai, atau seperti Adobe lakukan dengan protokol RTMP yang tidak bertanggung jawab bahkan lebih awal. Gadget dan browser masih merupakan hal yang secara teknis cukup sulit untuk dikembangkan, dari sinilah monopolis muncul, dari sini, seperti yang mereka katakan, semuanya ada di sana. Dan W3C dan IETF disponsori oleh perusahaan monopoli yang sama, sehingga mentalitas "mari kita membuat teknologi yang benar dan kuat secara teknis sehingga orang dapat menggunakannya dan semuanya baik-baik saja" tidak ada dan tidak akan pernah ada.Tapi seharusnya begitu.

Apa jalan keluar dari situasi ini? Rupanya, hanya menunggu teknologi yang digerakkan oleh bisnis yang "tepat", hasil dari persaingan dan segala macam hal hebat lainnya, akhirnya, akan muncul dengan sesuatu yang demokratis, cocok untuk dokter pedesaan yang sederhana, sehingga ia dapat menyediakan layanan pengobatan medis jarak jauh dengan Internet normal. Memang, perlu untuk membuat amandemen, bukan untuk dokter pedesaan yang sederhana, tetapi bagi mereka yang dapat membayar banyak, bisnis telah lama menawarkan solusi streaming real-time. Bagus, dapat diandalkan, membutuhkan jaringan khusus dan peralatan khusus. Dalam banyak kasus, dan tidak bekerja pada protokol IP. Yang - dan ini adalah alasan lain untuk situasi yang menyedihkan - tidak diciptakan secara real time, dan tidak selalu menjamin itu. Tidak selalu, tetapi tidak dalam situasi vital, sangat cocok saat ini.Jadi mari kita coba WebRTC. Sejauh ini, dari semua kejahatan, ia adalah yang terkecil dan paling demokratis. Lagipula, Anda harus mengucapkan terima kasih kepada Google.

4. Sedikit tentang server media yang mengimplementasikan WebRTC

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro, Unreal Media Server - ini adalah beberapa server media yang mendukung WebRTC. Mereka menyediakan publikasi video dari browser ke server dan menyiarkan video ke browser melalui WebRTC dari server.

Masalah yang dijelaskan dalam artikel ini, dengan cara yang berbeda dan dengan tingkat keberhasilan yang berbeda-beda, diselesaikan dalam produk perangkat lunak ini. Beberapa dari mereka, misalnya, Kurento dan Wowza, melakukan transcoding audio-video langsung di server, yang lain, misalnya, Unreal Media Server, tidak melakukan transkode sendiri, tetapi menyediakan program lain untuk ini. Beberapa server, seperti Wowza dan Unreal Media Server, mendukung streaming pada semua koneksi melalui satu port TCP dan UDP pusat, karena WebRTC sendiri mengalokasikan port terpisah untuk setiap koneksi, sehingga penyedia harus membuka banyak port di firewall, yang menciptakan masalah keamanan.

Ada banyak poin dan kehalusan yang diterapkan di semua server ini dengan cara yang berbeda. Seberapa cocok ini dengan konsumen, nilai Anda, pengguna yang terhormat.