Im ersten Teil haben wir ein einfaches dynamisches CDN für die Übertragung von WebRTC-Streams auf zwei Kontinente bereitgestellt und anhand des Countdown-Timers sichergestellt, dass die Verzögerungen in einem solchen CDN wirklich gering sind.
Neben einer geringen Latenz ist es jedoch wichtig, den Zuschauern eine gute Sendequalität zu bieten, da sie dafür bezahlen. In der Praxis können sich die Kanäle zwischen Edgeservern und Abonnenten in Bandbreite und Qualität unterscheiden. Zum Beispiel veröffentlichen wir einen Stream mit einer Auflösung von 720p mit einer Bitrate von 2 Mbit / s und der Benutzer spielt ihn auf einem Android-Smartphone über eine 3G-Verbindung im Bereich des unsicheren Empfangs des Signals ab. Die maximale Auflösung, bei der das Bild flüssig wird, beträgt nur 360p mit einer Bitrate von 400 Mbit / s .
Die von den Zuschauern verwendeten Geräte und Browser sind sehr unterschiedlich. Beispielsweise veröffentlichen wir einen WebRTC-Stream mit dem VP8-Codec aus dem Chrome-Browser auf einem PC, und der Viewer gibt den Stream in Safari auf dem iPhone wieder, das nur den H264-Codec unterstützt. Oder umgekehrt veröffentlichen wir den RTMP-Stream von OBS Studio, kodieren Video in H264 und Audio in AAC, und der Client verwendet einen Chromium-basierten Browser, der nur VP8 oder VP9 für Video und Opus für Sound unterstützt.
Möglicherweise müssen Sie auch die Qualität der Originalveröffentlichung verbessern. Zum Beispiel verteilen wir den Stream von der IP-Kamera in einer gewissen Reserve. Meistens ist das Bild statisch, die Kamera gibt es mit einer Frequenz von 1 Frame pro Sekunde. Gleichzeitig soll der Betrachter 24 Bilder pro Sekunde abspielen. Was ist, wenn es nicht möglich ist, die Kamera auszutauschen oder ihre Einstellungen zu ändern?
In all diesen Fällen ist eine Umcodierung des Streams auf dem Server erforderlich, d. H. Eine Decodierung jedes empfangenen Frames und eine anschließende Codierung mit neuen Parametern. Darüber hinaus sind die zu ändernden Parameter häufig nur auf der Client-Seite bekannt. Lassen Sie uns sehen, wie es möglich ist, Transcodierung in CDN bereitzustellen, wobei ein Gleichgewicht zwischen Broadcast-Qualität und Server-Auslastung hergestellt wird.
Transcodierung: wie, wo und warum?
Angenommen, wir kennen die Flussparameter, die der Client erhalten möchte. Der Betrachter hat beispielsweise mit der Wiedergabe eines Streams begonnen, und die Anzahl der Frame-Verluste in der WebRTC-Statistik gibt an, dass Auflösung und Bitrate reduziert werden müssen bis der Client die Kanäle gewechselt hat . In diesem Fall wird der Stream standardmäßig auf dem Edgeserver transcodiert, mit dem der Viewer verbunden ist.
Wenn der Client den beim Veröffentlichen des Streams verwendeten Codec nicht unterstützt, können Sie die Transcodierung sowohl dem Edge-Server als auch dem Origin-Server zuweisen.
Beides und ein anderes kann nur eine vorübergehende Lösung sein, vorausgesetzt, die Konfiguration von Origin- und / oder Edgeservern wurde mit einem Spielraum ausgewählt. Die Transcodierung wird immer Frame für Frame ausgeführt, wodurch die Prozessorressourcen stark beansprucht werden. Ein Prozessorkern kann also eine sehr kleine Anzahl von Threads umcodieren:
Selbst wenn wir einen Transcodierungsvorgang für alle Abonnenten starten, die dieselben Media Stream-Parameter benötigen, werden wahrscheinlich mehrere Zuschauer mit unterschiedlichen Parametern alle Ressourcen des Servers auswählen.
Daher besteht die richtige Lösung darin, spezielle Server im CDN für Transcodierungsaufgaben auszuwählen und die Serverkonfiguration basierend auf diesen Aufgaben auszuwählen.
Fügen Sie dem CDN Transcoder-Knoten hinzu
Wir werden also einen Server in unserem CDN mit der Transcoder-Rolle in den europäischen und amerikanischen Rechenzentren bereitstellen
Transcoder-Server konfigurieren:
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
Stream-Transcodierungsparameter müssen auf cdn_profiles.yml als spezielle Profile in der Datei cdn_profiles.yml werden. Betrachten Sie als Beispiel drei Standardprofile:
- Transcodierung auf 640x360 Auflösung, 30 Bilder pro Sekunde, alle 90 Bilder wird ein Schlüsselbild übertragen, H264-Videocodec mit OpenH264-Encoder, Opus-Audiocodec 48 kHz
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- Transcodierung auf Auflösung 1280x720, H264-Videocodec mit OpenH264-Encoder, ohne Audio-Transcodierung
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- Transcodierung mit einer Auflösung von 1280 x 720, 30 Bilder pro Sekunde, Übertragung eines Schlüsselbildes für jeweils 90 Bilder, Bitrate 2 Mbit / s, H264-Videocodec mit OpenH264-Encoder, ohne Audio-Transcodierung
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Wir veröffentlichen den test mit einer Auflösung von 720p auf dem o-eu1 und geben diesen Stream auf e-eu1 , wobei test-640x360 das Profil im test-640x360 , z. B. test-640x360
Der Stream wird transkodiert!
Nun können wir eine Reihe von Profilen auf Edgeservern beschreiben, z. B. -240p, -360p, -480p. Wenn laut WebRTC-Statistiken auf der Clientseite eine große Anzahl verlorener Frames diagnostiziert wird, wird der Stream automatisch mit einer niedrigeren Auflösung erneut angefordert.
Gruppieren Sie CDN-Knoten nach Kontinent
Jetzt sind unsere Transcoder-Server gleich. Was aber, wenn wir Streams nach Geografie transkodieren wollen: für amerikanische Zuschauer in Amerika, für europäische Zuschauer in Europa? Dies wird im Übrigen die Belastung der transatlantischen Kanäle verringern, da in diesem Fall nur die Originaldatenströme von Origin EU-Servern nach Amerika und umgekehrt übertragen werden und nicht alle transkodierten Versionen.
In diesem Fall müssen Sie in den Einstellungen der Transcoder-Knoten die Gruppe angeben
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
Außerdem muss die Gruppe zu den Einstellungen von Edgeservern hinzugefügt werden.
cdn_groups=EU
cdn_groups=US
Starten Sie die Knoten mit den neuen Einstellungen neu. Wir veröffentlichen den test mit einer Auflösung von 720p auf dem o-eu1 , wir spielen diesen Stream auf e-eu1 mit Transcodierung ab
Stellen Sie sicher, dass der Stream in t-eu transkodiert ist. Dazu öffnen wir die Statistikseite http://t-eu1.flashphoner.com:8081/?action=stat und sehen den Video-Encoder und -Decoder im Abschnitt Native resources
Gleichzeitig gibt es auf t-us1 in der Statistik keine Video-Encoder
Mehr Transcoder: Lastenausgleich
Nehmen wir an, die Anzahl der Zuschauer wächst weiter und die Kapazitäten eines Transcoder-Servers auf dem Kontinent reichen bereits nicht aus. Ok, füge einen weiteren Server hinzu
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
Jetzt stehen wir jedoch vor dem Problem des Lastausgleichs zwischen zwei Transcodern. Um nicht alle Threads über einen Server zuzulassen, begrenzen wir die maximal zulässige durchschnittliche Prozessorlast auf Transcoder-Knoten
cdn_node_load_average_threshold=0.95
Wenn die durchschnittliche Prozessorauslastung, dividiert durch die Anzahl der verfügbaren Kerne, diesen Wert erreicht, akzeptiert der Server keine Anforderungen zum Transcodieren neuer Threads mehr.
Sie können auch die maximale Anzahl gleichzeitig laufender Video-Encoder begrenzen
cdn_transcoder_video_encoders_threshold=10000
Wenn dieser Wert erreicht ist, akzeptiert der Server auch keine Anforderungen zum Umcodieren von Streams mehr, selbst wenn das Laden des Prozessors dies noch zulässt.
In jedem Fall verteilt der Transcoder-Server weiterhin die Streams, die bereits transcodiert wurden, an die Edgeserver.
Das Ende folgt
Aus diesem Grund haben wir dedizierte Server zum Umcodieren von Medienströmen in unserem CDN bereitgestellt. Auf diese Weise können wir unseren Zuschauern eine Sendequalität bieten, die von den Funktionen ihrer Geräte und der Qualität der Kanäle abhängt. Das Problem der Einschränkung des Zugriffs auf Threads wurde jedoch immer noch nicht angesprochen. Wir werden es im letzten Teil betrachten.
Referenzen
WebRTC-Streaming mit geringer Latenz CDN ist ein auf Web Call Server basierendes Netzwerk für die Bereitstellung von Inhalten.