Im ersten Teil haben wir ein einfaches dynamisches CDN für die Übertragung von WebRTC-Streams auf zwei Kontinente bereitgestellt und am Beispiel eines Countdown-Timers bewiesen, dass die Latenz bei dieser Art von CDN tatsächlich gering ist.
Neben einer geringen Latenz ist es jedoch wichtig, den Benutzern eine gute Sendequalität zu bieten. Schließlich bezahlen sie dafür. In der Praxis können sich die Kanäle zwischen Edgeservern und Benutzern in Bezug auf Bandbreite und Qualität unterscheiden. Zum Beispiel veröffentlichen wir einen 720p-Stream mit 2 Mbit / s, der Benutzer spielt ihn auf einem Android-Telefon mit 3G-Verbindung in einem instabilen Signalempfangsbereich ab und die maximale Auflösung von 360p, die ein flüssiges Bild mit 400 Mbit / s liefert, beträgt 360p.
Die von den Zuschauern verwendeten Geräte und Browser können sehr unterschiedlich sein. Zum Beispiel veröffentlichen wir einen WebRTC-Stream mit VP8-Codec in Chrome auf dem PC und der Betrachter spielt den Stream in Safari auf einem iPhone ab, das nur den H264-Codec unterstützt. Oder umgekehrt veröffentlichen wir einen RTMP-Stream von OBS Studio, der das Video in H264 und den Sound in AAC codiert. Der Client verwendet einen Chromium-basierten Browser, der nur VP8 oder VP9 für das Video und Opus für den Sound unterstützt.
Möglicherweise müssen wir auch die Qualität der Erstveröffentlichung verbessern. Zum Beispiel teilen wir einen Stream von einer IP-Kamera in einem Naturpark, die meiste Zeit ist das Bild statisch und die Kamera liefert es mit 1 Bild pro Sekunde. Wir möchten den Zuschauern jedoch 24 Bilder pro Sekunde zur Verfügung stellen. Was ist zu tun, wenn keine Möglichkeit besteht, die Kamera auszutauschen oder ihre Einstellungen zu ändern?
In all diesen Fällen müssen wir den Stream auf dem Server umcodieren, dh jeden empfangenen Frame decodieren und dann mit neuen Parametern codieren. Außerdem sind die zu ändernden Parameter oft nur auf Kundenseite bekannt. Lassen Sie uns einen Blick darauf werfen, wie Sie eine Transcodierung in CDN erreichen und dabei ein Gleichgewicht zwischen Broadcast-Qualität und Server-Auslastung herstellen.
Transcodierung: wie, wo und warum?
Angenommen, wir kennen die Stream-Parameter, die der Client erhalten möchte. Der Betrachter hat beispielsweise mit der Wiedergabe des Streams begonnen, und die Anzahl der Frame-Verluste in der WebRTC-Statistik weist darauf hin, dass Auflösung und Bitrate reduziert werden müssen bevor der Client zu einer anderen Show wechselt . In diesem Fall. Der Stream wird standardmäßig auf dem Edgeserver transkodiert, mit dem der Viewer verbunden ist.
Wenn der Client den beim Veröffentlichen von Streams verwendeten Codec nicht unterstützt, kann die Transcodierung sowohl auf Edge- als auch auf Origin-Servern angewendet werden.
Diese beiden Methoden funktionieren nur als vorübergehende Lösung, vorausgesetzt, die Origin- und / oder Edgeserverkonfigurationen sind mit einem Rand versehen. Das Trascoding wird immer Frame für Frame ausgeführt, daher sind die CPU-Ressourcen sehr stark beansprucht. Somit kann ein einzelner CPU-Kern nur eine kleine Anzahl von Streams transkodieren:
Selbst wenn wir einen einzigen Transcodierungsprozess für alle Benutzer ausführen, die gleiche Media Stream-Parameter benötigen, ist es sehr wahrscheinlich, dass einige Zuschauer mit unterschiedlichen Parametern die Serverressourcen vollständig verbrauchen.
Auf diese Weise besteht die richtige Entscheidung darin, dedizierte Server im CDN zu trennen, um die Transcodierungsaufgabe auszuführen, und die Serverkonfiguration unter Berücksichtigung dieser Aufgabe auszuwählen.
Hinzufügen von Transcoder-Knoten zum CDN
Jetzt werden wir zwei Transcoder-Server in unserem CDN bereitstellen: einen im europäischen Rechenzentrum und einen im amerikanischen.
Einrichtung von Transcoder-Servern:
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 sollten auf cdn_profiles.yml mithilfe spezieller Profile in der Datei cdn_profiles.yml werden. Schauen Sie sich als Beispiel die drei Profile an, die standardmäßig verwendet werden:
- Transcodierung auf 640x360 Auflösung, 30 Bilder pro Sekunde, der Keyframe wird alle 90 Bilder gesendet, H264-Videocodec mit OpenH264-Encoder, Opus-48-kHz-Audiocodec.
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- Transcodierung mit einer Auflösung von 1280 x 720, H264-Videocodec mit OpenH264-Encoder, ohne Audio-Transcodierung.
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- Beim Transcodieren mit einer Auflösung von 1280 x 720 (30 Bilder pro Sekunde) wird der Keyframe alle 90 Bilder mit einer Bitrate von 2 Mbit / s und einem H264-Videocodec mit OpenH264-Encoder ohne Audio-Transcodierung gesendet.
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Veröffentlichen Sie den 720p- test auf dem o-eu1 Server und geben Sie den Stream auf e-eu1 wobei Sie 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 eine große Anzahl verlorener Frames auf der Client-Seite diagnostiziert wird, können wir die Anforderung für automatisch wiederholen ein Stream mit niedrigerer Auflösung.
Gruppieren von CDN-Knoten nach Kontinenten
Derzeit haben wir Peer-Transcoder-Server. Was aber, wenn wir die Streams anhand der geografischen Verbreitung umcodieren wollen: für die amerikanischen Zuschauer in Amerika, für die europäischen Zuschauer in Europa? Übrigens wird dies eine Verringerung der Belastung der transatlantischen Kanäle ermöglichen, da der Origin EU-Server nach Amerika sendet und nur die ursprünglichen Streams und nicht alle Varianten der transkodierten Streams zurück empfängt.
In diesem Fall muss die erforderliche CDN-Gruppe in den Transcoder-Knoteneinstellungen angegeben werden
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 Edgeservereinstellungen hinzugefügt werden.
cdn_groups=EU
cdn_groups=US
Lassen Sie uns die Knoten mit neuen Einstellungen neu starten. Dann veröffentlichen wir den 720p- test auf dem o-eu1 Server und spielen diesen Stream mit Transcodierung auf e-eu1 .
Um sicherzustellen, dass der Stream unter t-eu transkodiert wird, müssen Sie die Statistikseite unter http://t-eu1.flashphoner.com:8081/?action=stat öffnen. Der Encoder und werden angezeigt Der Decoder im Abschnitt "Native Resources".
Darüber hinaus gibt es in der Statistik keine Video-Encoder für t-us1 .
Mehr Transcoder: Lastenausgleich
Angenommen, die Anzahl der Zuschauer steigt ständig und die Kapazität eines Transcoder-Servers pro Kontinent reicht nicht mehr aus. Gut, fügen wir einen weiteren Server für jeden Kontinent 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 haben wir jedoch das Problem, die Last zwischen zwei Transcodern auszugleichen. Um zu vermeiden, dass alle Streams über einen Server übertragen werden, legen wir den Schwellenwert für die maximal zulässige durchschnittliche CPU-Auslastung auf Transcoder-Knoten fest.
cdn_node_load_average_threshold=0.95
Wenn der durch die Anzahl der verfügbaren Kerne dividierte CPU-Auslastungsdurchschnitt diesen Schwellenwert erreicht, akzeptiert der Server keine Anforderungen zum Umcodieren neuer Streams mehr.
Wir können auch ein Limit für die maximal zulässige Anzahl gleichzeitig laufender Video-Encoder festlegen.
cdn_transcoder_video_encoders_threshold=10000
Wenn diese Anzahl erreicht ist, akzeptiert der Server auch keine Anfragen zur Stream-Transcodierung mehr, selbst wenn die CPU-Auslastung dies noch zulässt.
Auf jeden Fall teilt der Transcoder-Server die Streams, die auf ihm transcodiert werden, weiterhin mit den Edgeservern.
Abgeschlossen werden
Zusammenfassend lässt sich sagen, dass wir in unseren CDN-dedizierten Servern Medienströme zum Umcodieren bereitgestellt haben und unseren Zuschauern daher eine gute Sendequalität bieten können, die von den Fähigkeiten ihrer Geräte und der Qualität der Kanäle abhängt. Wir haben uns jedoch noch nicht mit der Einschränkung des Stream-Zugriffs befasst. Wir werden uns das im letzten Teil ansehen.
CDN für WebRTC-Streaming mit geringer Latenz - Web Call Server-basiertes Netzwerk für die Bereitstellung von Inhalten.