Pada bagian pertama, kami menggunakan CDN dinamis sederhana untuk menyiarkan aliran WebRTC ke dua benua dan memastikan bahwa keterlambatan dalam CDN seperti itu benar-benar rendah, menggunakan penghitung waktu mundur sebagai contoh.
Namun, selain latensi rendah, penting untuk menyediakan pemirsa dengan kualitas siaran yang baik, karena mereka membayarnya. Dalam kehidupan nyata, saluran antara server Edge dan pelanggan dapat berbeda dalam hal bandwidth dan kualitas. Misalnya, kami menerbitkan aliran dengan resolusi 720p dengan bitrate 2 Mbps, dan pengguna memainkannya di smartphone Android menggunakan koneksi 3G di area penerimaan sinyal yang tidak aman, dan resolusi maksimum di mana gambar akan mulus, hanya 360p dengan bitrate 400 Mbps .
Perangkat dan browser yang digunakan oleh pemirsa sangat berbeda. Misalnya, kami menerbitkan aliran WebRTC menggunakan codec VP8 dari browser Chrome di PC, dan pemirsa memutar stream di Safari di iPhone, yang hanya mendukung codec H264. Atau sebaliknya, kami menerbitkan aliran RTMP dari OBS Studio, menyandikan video dalam H264, dan audio dalam AAC, dan klien menggunakan browser berbasis Chromium, yang hanya mendukung VP8 atau VP9 untuk video dan opus untuk suara.
Anda mungkin juga perlu meningkatkan kualitas publikasi asli. Sebagai contoh, kami mendistribusikan aliran dari kamera IP dalam cadangan tertentu, sebagian besar waktu gambar statis, kamera memberikannya pada frekuensi 1 frame per detik. Pada saat yang sama, kami ingin pemirsa memutar 24 frame per detik. Bagaimana jika tidak mungkin mengganti kamera atau mengubah pengaturannya?
Dalam semua kasus ini, transcoding aliran pada server akan diperlukan, yaitu, decoding dari setiap frame yang diterima dan pengkodean selanjutnya dengan parameter baru. Selain itu, parameter yang harus diubah sering hanya diketahui di sisi klien. Mari kita lihat bagaimana mungkin untuk menyediakan transkode dalam CDN, menyeimbangkan antara kualitas siaran dan beban server.
Transcoding: bagaimana, di mana dan mengapa?
Misalkan kita tahu parameter aliran yang ingin diterima klien. Misalnya, pemirsa mulai memainkan streaming, dan jumlah kerugian bingkai dalam statistik WebRTC memberi tahu kami bahwa resolusi dan bit rate harus dikurangi sampai klien berpindah saluran . Dalam hal ini, secara default, aliran akan ditranskode pada server Edge yang terhubung dengan pemirsa.
Jika klien tidak mendukung codec yang digunakan saat menerbitkan aliran, Anda dapat menetapkan transcoding ke server Edge dan Origin.
Baik itu, dan yang lain hanya bisa menjadi solusi sementara, asalkan konfigurasi server Origin dan / atau Edge dipilih dengan margin. Transcoding selalu dilakukan bingkai demi bingkai, sehingga sangat menuntut sumber daya prosesor. Jadi, satu inti prosesor dapat melakukan transkode sejumlah kecil utas:
Bahkan jika kita memulai satu proses transkoding untuk semua pelanggan yang membutuhkan parameter aliran media yang sama, kemungkinan beberapa pemirsa dengan parameter berbeda akan memilih semua sumber daya server.
Dengan demikian, solusi yang tepat adalah dengan memilih server khusus di CDN untuk tugas transcoding, dan memilih konfigurasi server berdasarkan tugas-tugas ini.
Tambahkan node Transcoder ke CDN
Jadi, kami akan menggunakan satu server di CDN kami dengan peran Transcoder di pusat data Eropa dan Amerika
Mengkonfigurasi Server Transcoder:
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
Parameter transcoding aliran harus dijelaskan pada server Edge sebagai profil khusus dalam file cdn_profiles.yml . Sebagai contoh, perhatikan tiga profil default:
- transcoding ke resolusi 640x360, 30 frame per detik, frame kunci ditransmisikan untuk setiap 90 frame, H264 video codec menggunakan OpenH264 encoder, audio codec Opus 48 kHz
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- transcoding ke resolusi 1280x720, H264 video codec menggunakan OpenH264 encoder, tanpa transcoding audio
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- transcoding ke resolusi 1280x720, 30 frame per detik, frame kunci ditransmisikan untuk setiap 90 frame, bitrate 2 Mbit / s, H264 video codec menggunakan encoder OpenH264, tanpa transcoding audio
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Kami menerbitkan aliran test dengan resolusi 720p pada o-eu1 dan memainkan aliran ini pada e-eu1 , menentukan profil dalam nama aliran, misalnya, test-640x360
Aliran ditranskodekan!
Sekarang kita dapat menggambarkan sejumlah profil pada server Edge, misalnya -240p, -360p, -480p, dan jika di sisi klien, menurut statistik WebRTC, sejumlah besar frame yang hilang didiagnosis, secara otomatis meminta kembali aliran dengan resolusi yang lebih rendah.
Kelompokkan node CDN berdasarkan benua
Sekarang server Transcoder kami sama. Tetapi bagaimana jika kita ingin transcode stream oleh geografi: untuk pemirsa Amerika di Amerika, untuk pemirsa Eropa di Eropa? Omong-omong, ini akan mengurangi beban pada saluran transatlantik, karena dalam hal ini hanya aliran asli akan pergi dari server Origin EU ke Amerika dan sebaliknya, dan tidak semua versi yang ditranskode.
Dalam hal ini, dalam pengaturan node Transcoder, Anda harus menentukan grup
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
Juga, grup harus ditambahkan ke pengaturan server Edge.
cdn_groups=EU
cdn_groups=US
Mulai ulang node dengan pengaturan baru. Kami menerbitkan aliran test dengan resolusi 720p pada o-eu1 , kami memainkan aliran ini pada e-eu1 dengan transcoding
Pastikan bahwa aliran ditranskode ke t-eu , untuk ini kami membuka halaman statistik http://t-eu1.flashphoner.com:8081/?action=stat dan melihat encoder video dan decoder di bagian Native resources
Pada saat yang sama, tidak ada encoders video di t-us1 dalam statistik
Lebih banyak transcoder: penyeimbangan muatan
Katakanlah jumlah pemirsa terus bertambah, dan kapasitas satu server Transcoder di benua itu sudah tidak cukup. Oke, tambahkan satu server lagi
cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
Namun, sekarang kita dihadapkan dengan masalah load balancing di dua transcoder. Agar tidak mengizinkan semua utas melalui satu server, kami akan membatasi beban prosesor rata-rata maksimum yang diijinkan pada node Transcoder
cdn_node_load_average_threshold=0.95
Ketika rata-rata beban prosesor, dibagi dengan jumlah inti yang tersedia, mencapai nilai ini, server akan berhenti menerima permintaan untuk mentranskode utas baru.
Anda juga dapat membatasi jumlah maksimum penyandi video yang menjalankan secara bersamaan
cdn_transcoder_video_encoders_threshold=10000
Ketika jumlah ini tercapai, server juga akan berhenti menerima permintaan untuk transcoding stream, bahkan jika memuat prosesor masih memungkinkannya.
Bagaimanapun, server Transcoder akan terus mendistribusikan ke server Edge stream-stream yang sudah ditranskode di atasnya.
Berakhir berikut ini
Jadi, kami telah mengerahkan server khusus untuk transcoding stream media di CDN kami dan, dengan demikian, kami dapat memberikan pemirsa kami kualitas siaran tergantung pada kemampuan peralatan mereka dan kualitas saluran. Namun, kami masih tidak membahas masalah membatasi akses ke utas. Kami akan mempertimbangkannya di bagian akhir.
Referensi
CDN streaming WebRTC latensi rendah adalah jaringan pengiriman konten berbasis Web Call Server.