Pada bagian pertama kami telah menggunakan CDN dinamis sederhana untuk menyiarkan aliran WebRTC ke dua benua dan telah membuktikan pada contoh penghitung waktu mundur bahwa latensi pada CDN jenis ini sebenarnya rendah.
Namun, selain latensi rendah, penting untuk memberikan kualitas siaran yang baik kepada pengguna. Lagipula, inilah yang mereka bayar. Dalam kehidupan nyata saluran antara server Edge dan pengguna dapat berbeda dalam kapasitas dan kualitas bandwidth. Misalnya, kami menerbitkan aliran 720p pada 2 Mbps, pengguna memutarnya di ponsel Android menggunakan koneksi 3G di area penerimaan sinyal yang tidak stabil dan resolusi maksimum 360p yang memberikan gambar halus pada 400 Mbps adalah 360p.
Perangkat dan browser yang digunakan pemirsa mungkin sangat berbeda. Misalnya, kami menerbitkan aliran WebRTC menggunakan codec VP8 di 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, mengkode video dalam H264 dan suara di AAC, dan klien menggunakan browser berbasis Chromium yang hanya mendukung VP8 atau VP9 untuk video dan Opus untuk suara.
Kami mungkin juga perlu meningkatkan kualitas penerbitan awal. Sebagai contoh, kami berbagi aliran dari kamera IP di taman alami, sebagian besar waktu gambar statis, dan kamera mengirimkannya pada 1 frame per detik. Namun, kami ingin memberikan kepada pemirsa 24 frame per detik. Apa yang harus dilakukan, jika tidak ada kemungkinan untuk mengganti kamera atau mengubah pengaturannya?
Dalam semua kasus ini, kita perlu transcode stream pada server, yaitu mendekode setiap frame yang diterima dan kemudian mengkodekannya dengan parameter baru. Selain itu, parameter yang akan dimodifikasi sering hanya diketahui di sisi klien. Mari kita lihat bagaimana mencapai transcoding di CDN sambil menjaga keseimbangan antara kualitas siaran dan beban server.
Transcoding: bagaimana, di mana dan mengapa?
Asumsikan kita mengetahui parameter aliran yang ingin diterima klien. Misalnya, pemirsa telah mulai memainkan streaming, dan jumlah kerugian bingkai dalam statistik WebRTC memberi tahu kami bahwa resolusi dan bitrate perlu dikurangi sebelum klien beralih ke acara lain . Dalam hal ini. stream akan ditranskode secara default di server Edge yang terhubung dengan pemirsa.
Jika klien tidak mendukung codec yang digunakan selama penerbitan stream, transcoding dapat dikenakan baik pada server Edge dan Origin.
Kedua metode ini hanya berfungsi sebagai solusi sementara dengan ketentuan bahwa konfigurasi server Origin dan / atau Edge ditetapkan dengan margin. Trascoding selalu dilakukan bingkai demi bingkai, oleh karena itu sangat menuntut sumber daya CPU. Dengan demikian, satu inti CPU dapat mentranskode hanya sejumlah kecil stream:
Bahkan jika kita akan menjalankan proses transcoding tunggal untuk semua pengguna yang membutuhkan parameter aliran media yang sama, sangat mungkin bahwa beberapa pemirsa dengan parameter yang berbeda akan menghabiskan seluruh sumber daya server.
Dengan cara ini, keputusan yang tepat adalah untuk menetapkan server khusus dalam CDN untuk melakukan tugas transcoding dan memilih konfigurasi server mengingat tugas ini.
Menambahkan node Transcoder ke CDN
Sekarang, kami akan menggunakan dua server Transcoder di CDN kami: satu di pusat data Eropa dan satu di Amerika.
Pengaturan 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 melalui profil khusus dalam file cdn_profiles.yml . Sebagai contoh, lihat tiga profil yang digunakan secara default:
- transcoding ke resolusi 640x360, 30 frame per detik, keyframe akan dikirim 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, keyframe akan dikirim setiap 90 frame, bitrate 2Mbps, H264 video codec menggunakan OpenH264 encoder, tanpa transcoding audio.
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Mari kita terbitkan aliran test 720p pada server o-eu1 dan mainkan aliran pada e-eu1 menentukan profil dalam nama aliran, misalnya, test-640x360
Aliran sedang ditranskodekan!
Sekarang kita dapat menggambarkan sejumlah profil pada server Edge, misalnya, -240p, -360p, -480p dan, jika sejumlah besar frame yang hilang didiagnosis pada sisi klien berdasarkan statistik WebRTC, kami dapat secara otomatis mengulangi permintaan untuk aliran resolusi yang lebih rendah.
Pengelompokan node CDN per benua
Saat ini kami memiliki peer Transcoder server. Tetapi bagaimana jika kita ingin transcode stream berdasarkan penyebaran geografis: untuk pemirsa Amerika di Amerika, untuk pemirsa Eropa di Eropa? By the way, ini akan memungkinkan untuk mengurangi beban pada saluran transatlantik, karena server Origin EU akan mentransmisikan ke Amerika dan menerima kembali hanya aliran asli daripada semua varian yang ditranskode.
Dalam hal ini, perlu untuk menentukan grup CDN yang diperlukan dalam pengaturan simpul 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_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
Mari kita restart node dengan pengaturan baru. Kemudian, mari kita terbitkan aliran test 720p pada server o-eu1 dan mainkan aliran ini pada e-eu1 dengan transcoding.
Untuk memastikan bahwa aliran sedang ditranskode pada t-eu , kita harus membuka halaman statistik di http://t-eu1.flashphoner.com:8081/?action=stat , dan kita akan melihat encoder dan dekoder di bagian sumber daya asli.
Selain itu, tidak ada encoders video di t-us1 dalam statistik.
Lebih banyak transcoder: menyeimbangkan beban
Asumsikan jumlah pemirsa terus meningkat dan kapasitas satu server Transcoder per benua tidak cukup lagi. Hebat, mari kita tambahkan satu server lagi untuk setiap benua.
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, kami mengalami masalah menyeimbangkan beban antara dua transcoder. Untuk menghindari mentransmisikan semua stream melalui satu server, kita akan menetapkan ambang batas untuk rata-rata beban CPU maksimum yang diijinkan pada node Transcoder.
cdn_node_load_average_threshold=0.95
Ketika rata-rata beban CPU dibagi dengan jumlah core yang tersedia akan mencapai ambang ini, server akan berhenti menerima permintaan untuk transcoding stream baru.
Kami juga dapat menetapkan batas ke jumlah maksimum yang diijinkan untuk menjalankan enkode video secara bersamaan.
cdn_transcoder_video_encoders_threshold=10000
Ketika nomor ini tercapai, server juga akan berhenti menerima permintaan untuk transcoding aliran, bahkan jika beban CPU masih memungkinkan.
Bagaimanapun, server Transcoder akan terus membagikan aliran yang sedang ditranskode ke server Edge.
Disimpulkan
Singkatnya, kami telah menyebar di server khusus CDN kami untuk mentranskrip stream media dan, dengan demikian, dapat memberikan kualitas siaran yang baik kepada pemirsa kami tergantung pada kemampuan perangkat mereka dan kualitas saluran. Namun, kami belum menyentuh subjek pembatasan akses streaming. Kita akan melihat ini di bagian terakhir.
CDN untuk streaming WebRTC latensi rendah - jaringan pengiriman konten berbasis Server Web.