Saya memiliki kesempatan untuk mengerjakan banyak proyek yang sangat baik. Setiap proyek dilengkapi dengan tantangan unik mereka. Salah satu proyek itu adalah aplikasi panggilan video. Itu adalah pengalaman belajar yang hebat, banyak kesenangan dan pencapaian yang luar biasa.
Saya memiliki beberapa tantangan dengan proyek ini, yang pertama adalah biaya, produk yang saya kerjakan memiliki margin yang sangat ramping. Saya harus memastikan apa pun yang saya buat hemat biaya. Itu harus bekerja dengan konektivitas internet minimum, dan percakapan harus direkam. Kisah hari ini adalah tentang bagian rekaman.
Jika Anda ingin merekam panggilan WebRTC, ada banyak opsi. Tetapi umumnya bermuara pada dua jenis solusi:
- Catat aliran dari sisi server
- Rekam dari sisi klien
Perekaman sisi server banyak digunakan, mudah diatur jika Anda memiliki server media. Seringkali sangat dapat diandalkan dan dapat diformat dengan cara yang diinginkan. Namun, harganya mahal. Terlepas dari ruang penyimpanan yang dibutuhkan, ini membutuhkan server media tambahan, panggilan tidak ada peer untuk mengintip lagi, dan semua panggilan menggunakan bandwidth server. Semua ini juga menambah latensi kecil ke aliran video “waktu nyata”, terlihat jika Anda memiliki konektivitas yang buruk.
Rekaman sisi klien adalah area abu -abu. Anda dapat merekam menggunakan aplikasi pihak ketiga atau menggunakan API Recorder Stream Media baru. Tapi seringkali rumit untuk diatur, sangat tergantung pada kemampuan klien dan dapat membunuh browser jika tidak dilakukan dengan benar.
Saya harus memilih perekaman sisi klien setelah banyak percobaan dan perhitungan. Bahkan saya tahu bahwa aplikasi yang saya buat akan menjadi sistem panggilan video satu-ke-satu dan salah satu pihak akan duduk di pusat panggilan dengan konektivitas internet yang baik dan perangkat keras yang dapat saya kendalikan. Saya harus merancang solusi saya di sekitar fakta -fakta itu.
Saya harus mengurus dua aliran dari satu sisi. Partai yang duduk di pusat panggilan akan merekam kedua aliran, mengunggah ke server karena saya tidak memiliki kendali atas perangkat keras atau koneksi internet dari pihak lain.
Upaya pertama adalah kegagalan yang mengerikan. Saya menggunakan dua perekam aliran media untuk merekam aliran lokal dan jarak jauh dan kemudian seluruh rekaman akan diunggah setelah panggilan akan berakhir. Lima menit setelah panggilan, dan browser macet. Saya benar -benar lupa fakta bahwa rekaman tersebut disimpan dalam ingatan dan dengan cepat memakan semua kenangan yang dialokasikan dengan data video mentah.
Saya memodifikasi kode dan merekam video sebagai 10 detik. Itu sebagian besar bekerja dengan baik tetapi segera saya menyadari bahwa dua aliran 10 -an mengunggah sekaligus setiap 10 detik memberi tekanan pada bandwidth klien dan mengurangi kualitas video dari panggilan langsung. Saya harus mengurangi unggahan sekaligus.
Jadi saya memasak mekanisme antrian kecil. Aliran video mentah dikumpulkan dalam antrian dan kemudian diunggah satu per satu. Ini memecahkan masalah tekanan bandwidth. Tetapi akhirnya mulai membangun antrian dan kemudian mengisi memori.
Jadi saya harus menemukan mekanisme yang cerdas untuk mengacak panjang untuk menghindari tumpang tindih aliran, ini dikombinasikan dengan mekanisme antrian memecahkan masalah unggahan saya. Tapi rekaman hanya bagus jika bisa diputar kembali. Saya harus mencari cara untuk memainkannya kembali.
Klip disimpan di Amazon AWS S3 dengan URL yang ditandatangani satu kali. Saya pikir saya bisa menggunakan transcoder elastis Amazon AWS untuk menjahit klip dan membuat rekaman lengkap. Saya membuat fungsi AWS Lambda untuk memohon transcoder elastis pada file yang tepat dan output ke ember S3 lain. Setelah panggilan selesai, sistem akan memohon fungsi lambda dan transcoding akan dimulai.
Saya hampir siap untuk merayakan keberhasilan ketika saya melihat banyak pekerjaan transcoding gagal karena klip dari panggilan yang sama memiliki resolusi video dan bitrate yang berbeda. Khususnya pada aliran jarak jauh. Ini masuk akal karena WEBRTC menyesuaikan parameter ini berdasarkan konektivitas internet secara real time. Transcoder tidak dapat menjahit klip video itu dan gagal.
Jadi .. saya membuat pemain. Dari awal. Video -video tersebut dapat diakses hanya menggunakan URL yang ditandatangani satu kali, saya harus membuat pemain yang memainkan aliran lokal dan jarak jauh berdampingan, pastikan mereka sinkron, dan mengunduh dan menyiapkan potongan berikutnya di latar belakang untuk pengalaman pemutaran yang tidak terputus. Dengan sedikit kerja keras dan banyak matematika, pemain itu fungsional.
Dan dengan begitu saya mungkin membuat solusi perekaman WebRTC yang paling efektif saya dapat pencitraan.
Merekam video WebRTC. Metode yang saya coba, pelajaran yang saya pelajari.
