**This is an old revision of the document!**
CDN
Diese Doku beschreibt unser Live-Streaming CDN, wie es seit dem 34C3 gilt.
Architektur
Die CDN-Kaskade hat 5 Stufen: Master-Encoder, Transcoder, Fanout, Transport-/Master-Nodes und schließlich Edge-Nodes.
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.
Das Master-Encoding wird von einem Script erzeugt, welches vom ansible aus folgendem Template erzeugt wird: https://github.com/voc/cm/blob/master/ansible/roles/encoder/templates/voctomix-scripts/streaming-sink-mkvonly.sh.j2
Das Master-Encoding wird auf den lokalen (= auf dem encoder-cube laufenden) Icedist (= Icecast zur internen Distribution) auf Port 7999 gepusht (http://encoderX.lan.c3voc.de:7999/sX). Der Icedist auf live.ber.c3voc.de pullt diesen und bietet ihn seinerseits auf http://live.ber.c3voc.de:7999/sX an.
Debugging
http://195.54.164.164:7999 (oder http://live.ber.c3voc.de:7999 im Inkognito-Modus damit einen der Browser nicht zu HTTPS zwingen will)
voc@live.ber:/etc/icecast2$ systemctl status icedist 2019-08-20 21:52:20
● icedist.service - distribution Icecast
Loaded: loaded (/etc/systemd/system/icedist.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-07-30 19:50:07 CEST; 3 weeks 0 days ago
Main PID: 794 (icecast2)
Tasks: 25 (limit: 4915)
CGroup: /system.slice/icedist.service
└─794 /usr/bin/icecast2 -c /etc/icecast2/icedist.xml
sudo tail -f /var/log/icedist/error.log
2. Transcoder
Das Transcoding läuft auf Speedy & Tweety im RZ “alb”. Dabei sind die Räume wie folgt verteilt:
- speedy:
s1,s2,s3,q1(Freie Push-Quelle),sX(Teststream) - tweety:
s4,s5,s6,q2(Freie Push-Quelle),s23(Encoder CCCB),s80(Encoder MUC)
Important: Es ist unwarscheinlich dass speedy & tweety all diese Streams gleichzeitig mit allen Features (HD, SD und Slides) transcoden können.
Diese Verteilung wird über Host-Attribute im cm geregelt: https://github.com/voc/cm/blob/master/ansible/event#L48-L49.
Die Transcoding-Scripte holen sich die Master-Streams von http://live.ber.c3voc.de:7999 und erzeugen die fehlenden Formate: vpx-hd/sd/slides, vorbis-audio (für webm), h264-sd sowie mp3/opus-audio.
Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt: https://github.com/voc/cm/tree/master/ansible/roles/transcoder/templates/transcoder
Die drei Scripte (h264, vpx, audio) erzeugen aus dem Master-Stream drei Format-Streams: (sXh264, , sXwebmsX_audio), welche wieder gegen live.ber.c3voc.de:7999 gepusht werden. Diese Format-Streams sind dann unter folgenden URLs verfügbar:
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://github.com/voc/cm/blob/master/ansible/group_vars/transcoders
Verwaltung
Je nach Event und Situation möchte man ggf. die Verteilugn der Streams zwischen Speedy und Tweety anders einstellen. Dazu existieren auf beiden Rechnern systemd-Targets für jeden Raum. Um einen Überblick über die derzeit aktivierten Transcodings zu erhalten kann folgender Befehl verwendet werden:
voc@tweety.int:~$ systemctl list-units 'trans*' 2018-01-23 0:22:42 UNIT LOAD ACTIVE SUB DESCRIPTION transcode_s1_audio.service loaded active running Transcoder audio Stream s1 transcode_s1_h264.service loaded active running Transcoder h264 Stream s1 transcode_s1_vpx.service loaded active running Transcoder vpx Stream s1 transcode_s2_audio.service loaded active running Transcoder audio Stream s2 … transcode_s1.target loaded active active All Transcoders of Stream s1 transcode_s2.target loaded active active All Transcoders of Stream s2 …
Zum auflisten aller verfügbaren Transcoder kann folgender Befehl benutzt werden:
voc@tweety.int:~$ systemctl list-unit-files 'trans*' 2018-01-23 0:35:36 UNIT FILE STATE transcode_s1_audio.service enabled transcode_s1_h264.service enabled transcode_s1_vpx.service enabled transcode_s2_audio.service enabled … transcode_s1.target disabled transcode_s2.target disabled transcode_s3.target disabled transcode_s4.target enabled transcode_s5.target enabled transcode_s6.target enabled
Einzelne Räume können über die Targets aktiviert bzw. Deaktiviert werden:
sudo systemctl start transcode_s5.target sudo systemctl stop transcode_s1.target
Important: Unbedingt darauf achten, dass Streams nicht auf beiden Hosts transcodet werden, da dies zu Stream-Abbrüchen führen kann.
3. Fanout
Diese 3 Format-Streams je Raum werden von der nächsten Stufe auf live.ber.c3voc.de in die finalen Streams in allen für Endnutzer angebotenen Kombinationen auseinander gemuxt (=“fanout”).
Dabei entstehen alle Kombinationen aus sX[hd|sd|slides][native|translated|translated-2] in webm, hls und dash sowie sX_[native|translated|translated-2].[mp3|opus] erzeugt. Die WebM- und die Audio-Streams werden gegen den Icecast auf http://live.ber.c3voc.de:8000/ gepusht, die HLS- und DASH-Streams werden vom nginx unter http://live.ber.c3voc.de/hls/ bzw. http://live.ber.c3voc.de/dash/ angeboten.
Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt werden: https://github.com/voc/cm/tree/master/ansible/roles/relay/files/fanout.
Um einen Überblick über die deployten Fanout Skripte zu erhalten kann folgender Befehl verwendet werden:
voc@live.ber:~$ systemctl list-units 'fanout*'
Die Pull-Quelle und das Push-Ziel sowie der Pfad unter dem die HLS/DASH-Schnipsel und Playlisten abgelegt werden ist über Group-Vars konfigurierbar: https://github.com/voc/cm/blob/master/ansible/group_vars/relays#L5
Zu den Aufgaben der fanout-Scripte gehört auch das übermitteln des h264-Videostroms zu Youtube. Die Stream-Keys dazu kommen aus dem KeePass, die Scripte aus dem oben verlinkten Git-Repo.
- Youtube ist derzeit deaktiviert und wird üblicherweise nur für den Congress aktiviert.
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 Audiomapping in Voctomix zu Details wie Translations de/aktiviert werden können.
4. Transport- und Master-Nodes
Im Non-Congress Setup ist live.ber.c3voc.de die einzige (Non-Public) Transport-Node. Die (Public) Edge-Nodes ziehen ihre Daten von dort.
5. Edge-Nodes
Die ganzjährigen Edge-Nodes lauten:
live.bn.c3voc.delive.alb.c3voc.delive.dus.c3voc.delive.self.c3voc.delive.fem.c3voc.de
Diese pullen alle Icecast-Streams (Port :8000) – nicht die Icedist-Streams – von live.ber.c3voc.de. 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://live.x.c3voc.de/sX_native_hd.webm) agiert der nginx als Proxy zu seinem eigenen Icecast. Er übernimmt in dieser Rolle das Aggregieren auf die Ports 80/443 sowie das SSL-Handling (für 443).
- Für Anfragen nach HLS oder DASH-Schnipseln, -Playlisten und -Manifests (z.B. http://live.x.c3voc.de/hls/sX_native_hd.m3u8) agiert der nginx als Proxy zur Master-Node
live.ber.c3voc.de, von welcher er die angefragten Datein abholt und für einen genau festgelegten Zeitraum zwischenspeichert. Dieser Zeitraum muss dabei mit der Segmentlänge der Playlists abgestimmt sein, um eine Fehlerfreie Wiedergabe zu ermöglichen.
Teststream
Für den Teststream vornach dem Congress (Codename sXnativehd & co.) wurde speedy.lan.c3voc.de als Transcoder für den Stream sX konfiguriert; live.ber.c3voc.de übernimmt das fanout. Der Teststream wird von einem script in einem screen des voc-Benutzers auf live.ber.c3voc.de zugeliefert.
Alle bereitgestellten Test-URLs lauten
VPx-HD:
VPx-SD:
VPx-Slides:
h264-HD:
h264-SD:
h264-Slides:
WebM Multi-Qualität + Multi-Lang
Audio-MP3:
Audio-Opus:
Vollständiges deaktivieren des Teststreams
auf speedy.lan.c3voc.de:
sudo systemctl stop transcode_sX.target sudo systemctl disable transcode_sX.target
auf live.ber.c3voc.de:
sudo systemctl stop fanout_sX.target sudo systemctl disable fanout_sX.target screen -rd source-for-teststream :quit
Loadbalancer
Neben den Transport- und Edge-Relays gibt es noch zwei Loadbalancer:
lb.dus.c3voc.delb.alb.c3voc.de
Diese sind sowohl für die Domains streaming.media.ccc.de als auch für cdn.c3voc.de zuständig. Im DNS sind für beide Domains beide Server angegeben, so dass Clients per statistischem Round-Robin auf einen der beiden Server verteilt werden.
streaming.media.ccc.de
Unter dieser Domain liefern beide LBs unabhängig von einander die Streaming-Webseite aus. Die LBs sind dabei komplett unabhängig voneinander und haben auch je eine eigene Konfiguration. Es ist aufgabe des Website-Deployments die Konfiguration synchron zu halten. Durch dieses Setup kann bei Bedarf der jeweilige LB einfach aus der DNS-Rotation herausgenommen werden.
cdn.c3voc.de
Die Domain cdn.c3voc.de wird auf beiden LBs von einem HAProxy bedient. Dieser sortiert eventuell zwischen DTAG und Lokalen Klienten und wählt auf dieser Basis einen des obenstehenden Relays aus. Im unterjährigen Betrieb gibt es keine Unterscheidung: Alle Anfragen werden unter den genannten Relays verteilt.
Der HAProxy verteilt dabei ausschließlich per Redirect, er proxied (entgegen seines Namens) nicht.
RTMP Ingest
Für Spezialanwendungen (z.B. Cam-Only Streaming im Fritz-Studio) existieren die RTMP-Endpunkte q1 und q2 auf live.ber.c3voc.de. Die Push-Targets lauten rtmp://live.ber.c3voc.de/stream/q1 bzw. q2. Eine Systemd-Unit setzt diese dann auf Icedist-Ströme gleichen Namens um, von wo Transcoding und Fanout wie oben beschrieben seinen Weg nehmen.
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.