Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
cdn [2020/02/04 00:25] – CDN-Bild ischluff | cdn [2024/01/29 10:45] (current) – ischluff | ||
---|---|---|---|
Line 1: | Line 1: | ||
= CDN | = CDN | ||
- | Diese Doku beschreibt unser Live-Streaming CDN, wie es seit dem 34C3 gilt. | ||
- | == Architektur | + | < |
- | Die CDN-Kaskade hat 5 Stufen: | + | This documentation describes our Livestreaming CDN as of 2024. |
+ | |||
+ | The File-CDN for media.ccc.de is described on [[software: | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | == The Future of Streaming | ||
+ | |||
+ | For redundancy and ease of use the CDN is managed by a distributed system built on consul. | ||
+ | |||
+ | Damit ist es möglich redundante | ||
+ | |||
+ | Ein weiterer Vorteil des angedachten Setups sind deutlich geringere Latenz durch den fehlenden Fanout, sowie deutlich schnellere Stream-Restarts durch aktive Benachrichtigung der Transcoder. | ||
+ | |||
+ | === Übersicht | ||
+ | {{drawio> | ||
+ | |||
+ | ==== Repo Links | ||
+ | * Stream-api, Upload-Proxy, Upload-Server: https:// | ||
+ | * rtmp-auth daemon: https:// | ||
+ | * Transcoding-Script: | ||
+ | |||
+ | == Architecture | ||
+ | The CDN-Cascade has 5 stages: | ||
{{: | {{: | ||
=== 1. Master-Encoder | === 1. Master-Encoder | ||
- | Das Master-Encoding entsteht auf dem encoder-cube im Saal aus dem Ausgabesignal des Voctomix. Das Master-Encoding enthält den Mix als 1080p25 in h264 sowie die Slides als 1080p5 in h264 sowie aac von bis zu drei Audiospuren (Native, Translated, Translated-2). Wahlweise können die Übersetzerspuren sowie die Slide-Spur weggelassen werden. Alle Spuren werden in einem Matroska-Container verpackt. | + | The master stream encoding is created near the stage on the encoder PC running voctomix or on with other videoencoder for third party streams. |
+ | The master encoding contains a 1080p25 video signal. | ||
+ | Das Master-Encoding entsteht auf dem encoder-cube im Saal aus dem Ausgabesignal des Voctomix. Das Master-Encoding enthält den Mix als 1080p25 in h264 sowie die Slides als 1080p5 in h264 mit bis zu drei Audiospuren | ||
Das Master-Encoding wird von einem Script erzeugt, welches vom ansible aus folgendem Template erzeugt wird: https:// | Das Master-Encoding wird von einem Script erzeugt, welches vom ansible aus folgendem Template erzeugt wird: https:// | ||
- | Das Master-Encoding wird auf den lokalen (= auf dem encoder-cube laufenden) Icedist (= Icecast zur internen Distribution) auf Port 7999 gepusht (http:// | + | Das Master-Encoding wird auf den lokalen (= auf dem encoder-cube laufenden) Icedist (= Icecast zur internen Distribution) auf Port 7999 gepusht (http:// |
Line 31: | Line 56: | ||
``` | ``` | ||
- | === 2. Transcoder | + | === 1.5 Exkurs Stream-API |
- | Das Transcoding läuft auf Speedy & Tweety im RZ "alb" | + | Die "Stream-API" |
- | * **speedy**: '' | + | Aktuelles Beispiel siehe https:// |
- | * **tweety**: '' | + | |
- | < | + | Das JSON wird periodisch auf dem Master Relay von einem Skript durch die Abfrage von Icedist/ |
- | Diese Verteilung wird über Host-Attribute | + | === 2. Transcoder |
+ | Das Transcoding läuft auf verschiedenen Transcodern. Aktuelle Zuordnung siehe '' | ||
- | Die Transcoding-Scripte holen sich die Master-Streams von http://live.ber.c3voc.de:7999 und erzeugen die fehlenden Formate: vpx-hd/ | + | Jeder Transcoder pollt regelmäßig |
+ | Abhängig von der Hardware starten diese entweder einzelne " | ||
- | Die Scripte dazu werden vom ansible | + | Die Pull/ |
- | Die drei Scripte (h264, vpx, audio) erzeugen aus dem Master-Stream drei Format-Streams: ('' | + | Die Quelle eines transkodierten Streams ist immer eine Icecast-URL der Form http:// |
+ | (Beispiel: http://live.ber.c3voc.de: | ||
- | * http:// | + | Die transkodierten Formate sind dabei: h264, vpx (VP9), audio (MP3, Opus) und thumbnail (MJPEG mit 0.1Hz). |
- | * http:// | + | Dementsprechend z.B.: |
- | * http:// | + | * http:// |
+ | * http:// | ||
+ | * http:// | ||
+ | * http:// | ||
- | Da jeder Format-Stream aus einem einzelnen ffmpeg-Prozess stammt und in einem Container landet sind die darin enthaltenen Videoströme Zeitsynchron zueinander. Die Trennung nach Formaten soll ermöglichem einzelne Format-Transport-Chains bei Problemen neustarten zu können, ohne die andere zu stören. | ||
- | Die Pull-Quelle und das Push-Ziel ist über Group-Vars konfigurierbar: https:// | + | Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt: https:// |
+ | |||
+ | Da jeder Format-Stream aus einem einzelnen ffmpeg-Prozess stammt und in einem Container landet sind die darin enthaltenen Videoströme Zeitsynchron zueinander. | ||
==== Verwaltung | ==== Verwaltung | ||
- | Je nach Event und Situation möchte man ggf. die Verteilugn der Streams | + | Die Verteilung der Transcodings wird wie oben erwähnt über die Stream-API realisiert. Dadurch werden |
+ | |||
+ | Die Maximalzahl der Streams pro Transcoder und eventuelle Stream-Bindungen an bestimmte Transcoder können über Variablen im ansible gesteuert werden. | ||
+ | |||
+ | Um einen Überblick über die derzeit aktivierten Transcodings zu erhalten kann folgender Befehl verwendet werden: | ||
< | < | ||
Line 71: | Line 106: | ||
</ | </ | ||
- | Zum auflisten aller verfügbaren Transcoder kann folgender Befehl benutzt werden: | + | Der Zustand des API-Clients ist gelegentlich sinnvoll abzufragen |
< | < | ||
- | voc@tweety.int: | + | sudo journalctl |
- | UNIT FILE | + | |
- | transcode_s1_audio.service | + | |
- | transcode_s1_h264.service | + | |
- | transcode_s1_vpx.service | + | |
- | transcode_s2_audio.service | + | |
- | … | + | |
- | transcode_s1.target | + | |
- | transcode_s2.target | + | |
- | transcode_s3.target | + | |
- | transcode_s4.target | + | |
- | transcode_s5.target | + | |
- | transcode_s6.target | + | |
</ | </ | ||
- | Einzelne Räume können über die Targets aktiviert bzw. Deaktiviert | + | === 3. Fanout |
- | < | + | Die Format-Streams je Raum werden |
- | sudo systemctl start transcode_s5.target | + | |
- | sudo systemctl stop transcode_s1.target | + | |
- | </ | + | |
- | < | + | Dabei entstehen alle Kombinationen aus '' |
- | === 3. Fanout | + | Die WebM- und die Audio-Streams werden gegen den Icecast auf http:// |
- | Diese 3 Format-Streams je Raum werden von der nächsten Stufe auf '' | + | Segmente im File-System: |
- | + | * / | |
- | Dabei entstehen alle Kombinationen aus '' | + | * / |
+ | * / | ||
+ | * / | ||
Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt werden: https:// | Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt werden: https:// | ||
- | Um einen Überblick über die deployten | + | Um einen Überblick über die laufenden |
< | < | ||
voc@live.ber: | voc@live.ber: | ||
- | |||
</ | </ | ||
Line 119: | Line 140: | ||
Das Transcoding und Fanout reagiert dynamisch auf die Konfiguration des Streams der vom encoder-cube gesendet wird. Fehlt die Slides-Spur oder die Translation-Spuren wird diese nicht in den Master-Playlists und Dash-Manifestd für Adaptives streaming angeboten. Dadurch kann von Event zu Event entschieden werden, ob der Einsatz der Slide-Spur bzw. von Translations sinn ergibt. Siehe dazu [[voctomix: | Das Transcoding und Fanout reagiert dynamisch auf die Konfiguration des Streams der vom encoder-cube gesendet wird. Fehlt die Slides-Spur oder die Translation-Spuren wird diese nicht in den Master-Playlists und Dash-Manifestd für Adaptives streaming angeboten. Dadurch kann von Event zu Event entschieden werden, ob der Einsatz der Slide-Spur bzw. von Translations sinn ergibt. Siehe dazu [[voctomix: | ||
- | === 4. Transport- und Master-Nodes | + | === 4. Transport- und Master-Relays |
- | Im Non-Congress Setup ist '' | + | Im Non-Congress Setup ist '' |
- | === 5. Edge-Nodes | + | === 5. Edge-Relays |
- | Die ganzjährigen Edge-Nodes lauten: | + | Die ganzjährigen Edge-Relay lauten: |
* '' | * '' | ||
* '' | * '' | ||
+ | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
Line 133: | Line 155: | ||
Für die schlussendliche Auslieferung kommt ein nginx zum Einsatz, der abhängig von der URL Daten von einem der unterschiedlichen Backend proxied: | Für die schlussendliche Auslieferung kommt ein nginx zum Einsatz, der abhängig von der URL Daten von einem der unterschiedlichen Backend proxied: | ||
* Für Anfragen zu einem WebM, MP3 oder Opus-Stream (z.B: http:// | * Für Anfragen zu einem WebM, MP3 oder Opus-Stream (z.B: http:// | ||
- | * Für Anfragen nach HLS oder DASH-Schnipseln, | + | * Für Anfragen nach HLS oder DASH-Schnipseln, |
- | == Teststream | + | == Stream-URLs |
- | Für den Teststream < | + | |
- | Alle bereitgestellten Test-URLs lauten | + | Die endgültigen Stream-URLs für einen Beispielstream sX sind dann wie folgt: |
- | VPx-HD: | + | MPEG-DASH (VPx Multi-Qualität + Multi-Lang) |
+ | * http:// | ||
+ | |||
+ | HLS (h.264 Multi-Qualität + Multi-Lang) | ||
+ | * http:// | ||
+ | |||
+ | Moar HLS | ||
+ | * http:// | ||
+ | * http:// | ||
+ | * http:// | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | Legacy | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
- | VPx-SD: | + | Legacy |
* http:// | * http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
- | VPx-Slides: | + | Legacy |
* http:// | * http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
- | |||
- | h264-HD: | ||
- | * http:// | ||
- | * http:// | ||
- | * http:// | ||
- | |||
- | h264-SD: | ||
- | * http:// | ||
- | * http:// | ||
- | * http:// | ||
- | |||
- | h264-Slides: | ||
- | * http:// | ||
- | * http:// | ||
- | * http:// | ||
- | |||
- | WebM Multi-Qualität + Multi-Lang | ||
- | * http:// | ||
Audio-MP3: | Audio-MP3: | ||
Line 182: | Line 198: | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
- | |||
- | === Vollständiges deaktivieren des Teststreams | ||
- | auf '' | ||
- | < | ||
- | sudo systemctl stop transcode_sX.target | ||
- | sudo systemctl disable transcode_sX.target | ||
- | </ | ||
- | |||
- | auf '' | ||
- | < | ||
- | sudo systemctl stop fanout_sX.target | ||
- | sudo systemctl disable fanout_sX.target | ||
- | |||
- | screen -rd source-for-teststream | ||
- | :quit | ||
- | </ | ||
- | |||
== Loadbalancer | == Loadbalancer | ||
- | Neben den Transport- und Edge-Relays gibt es noch zwei Loadbalancer: | + | Neben den Transport- und Edge-Relays gibt es noch drei Loadbalancer: |
* '' | * '' | ||
* '' | * '' | ||
+ | * '' | ||
- | Diese sind sowohl für die Domains '' | + | Diese sind sowohl für die Domains '' |
=== streaming.media.ccc.de | === streaming.media.ccc.de | ||
Line 217: | Line 217: | ||
== RTMP Ingest | == RTMP Ingest | ||
- | Für Spezialanwendungen (z.B. Cam-Only Streaming im Fritz-Studio) existieren die RTMP-Endpunkte '' | + | Für Spezialanwendungen (z.B. Cam-Only Streaming im Fritz-Studio) existieren die RTMP-Endpunkte '' |
- | Die Push-Targets lauten '' | + | Die Push-Targets lauten '' |
Achtung: Aufgrund der langen rtmp-Timeouts in ffmpeg kann es bis zu 40 Sekunden dauern, bis die Streams auftauchen und weitere 30 Sekunden, bis alle Formate zur Verfügung stehen. Keine Ungeduld. | Achtung: Aufgrund der langen rtmp-Timeouts in ffmpeg kann es bis zu 40 Sekunden dauern, bis die Streams auftauchen und weitere 30 Sekunden, bis alle Formate zur Verfügung stehen. Keine Ungeduld. | ||
+ | |||
+ | === Dynamische endpunkte mit rtmp-auth | ||
+ | RTMP Endpunkte können unter https:// | ||
+ | |||
+ | Die RTMP-Url für den endpunkt '' | ||
+ | |||
+ |