Differences

This shows you the differences between two versions of the page.

--- cdn [2019/08/20 22:04] – andi
+++ cdn [2022/04/27 21:58] – [Repo Links] andi
@@ Line 1: / Line 1: @@
 = CDN
-Diese Doku beschreibt unser Live-Streaming CDN, wie es seit dem 34C3 gilt.
+<bootnote>
+Diese Doku beschreibt unser Live-Streaming CDN, wie es seit dem 34C3 existiert.  Anfang 2020 wurde das Verteilen der Transcoder-Prozesse automatisiert, und die Doku entsprechend angepasst.
+Das File-CDN wird dagegen auf der Seite [[software:voctoweb]] beschrieben.
+</bootnote>
 == Architektur
-Die CDN-Kaskade hat 5 Stufen: Master-Encoder, Transcoder, Fanout, Transport-/Master-Nodes und schließlich Edge-Nodes.
+Die CDN-Kaskade hat 5 Stufen: Master-Encoder, Transcoder, Fanout, Transport-/Master-Relays und schließlich Edge-Relays.
-{{::docs_voc-cdn-2018-skizze.png?600|}}
+{{:cdn_overview.png?1200|}}
 === 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 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 in AAC (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.
+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 dem Master-Relay (z.B. ''live.ber.c3voc.de'') pullt diesen und bietet ihn seinerseits auf http://live.ber.c3voc.de:7999/sX an.
+==== Debugging
-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)
-http://195.54.164.164:7999
 ```
 voc@live.ber:/etc/icecast2$ systemctl status icedist                                           2019-08-20 21:52:20
@@ Line 28: / Line 35: @@
 sudo tail -f /var/log/icedist/error.log
 ```
+=== 1.5 Exkurs Stream-API
+Die "Stream-API" ist aktuell ein statisches JSON-File mit Pfaden und Transcoder-Zuordnungen für aktuelle Streams.
+Aktuelles Beispiel siehe https://live.ber.c3voc.de/stream_info.json (Zugang im Keepass unter stream-api).
+Das JSON wird periodisch auf dem Master Relay von einem Skript durch die Abfrage von Icedist/Icecast-Instanzen (lokal, ingest, etc.) erstellt. Damit enthält es alle Streams die aktuell oder kürzlich (bis zum timeout) auf dem icedist/icecast ankamen. Weiterhin wird anhand einer Config automatisiert ein (nicht-voller) Transcoder zum Stream zugeordnet. Jeder Transcoder hat in der Config eine "Kapazität" d.h. eine Maximalzahl von möglichen Streams anhand derer die Verteilung gewählt wird.
 === 2. Transcoder
-Das Transcoding läuft auf Speedy & Tweety im RZ "alb". Dabei sind die Räume wie folgt verteilt:
+Das Transcoding läuft auf verschiedenen Transcodern. Aktuelle Zuordnung siehe ''event''-Inventory im ansible https://github.com/voc/cm/blob/master/ansible/event#L49 "alb".
-  * **speedy**: ''s1'', ''s2'', ''s3'', ''q1'' (Freie Push-Quelle), ''sX'' (Teststream)
-  * **tweety**: ''s4'', ''s5'', ''s6'', ''q2'' (Freie Push-Quelle), ''s23'' (Encoder CCCB), ''s80'' (Encoder MUC)
-<bootnote important>Es ist unwarscheinlich dass speedy & tweety all diese Streams gleichzeitig mit allen Features (HD, SD und Slides) transcoden können.</bootnote>
+Jeder Transcoder pollt regelmäßig die Stream-Api und startet/stoppt entsprechende Systemd-Units der Form "transcode@sX.target".
+Abhängig von der Hardware starten diese entweder einzelne "transcode_h264@sX.service", "transcode_vpx@sX.service", etc. Units oder einen einzelnen "transcode_vaapi@sX.service".
-Diese Verteilung wird über Host-Attribute im cm geregelt: https://github.com/voc/cm/blob/master/ansible/event#L48-L49.
+Die Pull/Push-Konfiguration jedes Streams wird aus der Stream-API entnommen und in ein File entsprechend "/opt/transcoder/config/sloop". Die Transcoding-Services verwenden dann diese Datei als EnvironmentFile.
-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 Quelle eines transkodierten Streams ist immer eine Icecast-URL der Form http://host:port/sX und das Ziel ist immer eine Icecast-URL der Form http://host2:port2/sX_format.
+(Beispiel: http://live.ber.c3voc.de:7999/s1 -> http://live.ber.c3voc.de:7999/s1_h264)
-Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt: https://github.com/voc/cm/tree/master/ansible/roles/transcoder/templates/transcoder
+Die transkodierten Formate sind dabei: h264, vpx (VP9), audio (MP3, Opus) und thumbnail (MJPEG mit 0.1Hz).
+Dementsprechend z.B.:
+  * http://live.lan.c3voc.de:7999/sX_h264
+  * http://live.lan.c3voc.de:7999/sX_vpx
+  * http://live.lan.c3voc.de:7999/sX_audio
+  * http://live.lan.c3voc.de:7999/sX_thumbnail
-Die drei Scripte (h264, vpx, audio) erzeugen aus dem Master-Stream drei Format-Streams: (''sX_h264'', ''sX_webm'', ''sX_audio''), welche wieder gegen ''live.ber.c3voc.de:7999'' gepusht werden. Diese Format-Streams sind dann unter folgenden URLs verfügbar:
- * http://live.lan.c3voc.de:7999/sX_h264
+Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt: https://github.com/voc/cm/tree/master/ansible/roles/transcoder/templates/transcoder
- * http://live.lan.c3voc.de:7999/sX_vpx und
- * http://live.lan.c3voc.de:7999/sX_audio
+Da jeder Format-Stream aus einem einzelnen ffmpeg-Prozess stammt und in einem Container landet sind die darin enthaltenen Videoströme Zeitsynchron zueinander.
-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:
+Die Verteilung der Transcodings wird wie oben erwähnt über die Stream-API realisiert. Dadurch werden die Streams immer gleichmäßig verteilt und es gibt keine doppelten Zuweisungen.
+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:
 <code>
@@ Line 67: / Line 86: @@
 </code>
-Zum auflisten aller verfügbaren Transcoder kann folgender Befehl benutzt werden:
+Der Zustand des API-Clients ist gelegentlich sinnvoll abzufragen
 <code>
-voc@tweety.int:~$ systemctl list-unit-files 'trans*'                                                                                                                                            2018-01-23 0:35:36
+sudo journalctl -afu update_transcoding
-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
-</code>
-Einzelne Räume können über die Targets aktiviert bzw. Deaktiviert werden:
-<code>
-sudo systemctl start transcode_s5.target
-sudo systemctl stop transcode_s1.target
 </code>
-<bootnote important>Unbedingt darauf achten, dass Streams nicht auf beiden Hosts transcodet werden, da dies zu Stream-Abbrüchen führen kann.</bootnote>
 === 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").
+Die Format-Streams je Raum werden von der nächsten Stufe auf dem Master-Relay (''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.
+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]'' und die Thumbnails.
+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.
+Segmente im File-System:
+  * /srv/nginx/dash/sX/[manifest.mpd|init_\d.webm|segment_\d_\d+.webm]
+  * /srv/nginx/hls/[sX_native_[hd|sd|slides].m3u8]
+  * /srv/nginx/hls/sX/[chunks_\d.m3u8|\d+-\d+_\d.ts]
+  * /srv/nginx/thumbnail/sX/[poster.jpeg|thumb.jpeg]
 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:
+Um einen Überblick über die laufenden Fanout Skripte zu erhalten kann folgender Befehl verwendet werden:
 <code>
 voc@live.ber:~$ systemctl list-units 'fanout*'
 </code>
@@ Line 115: / Line 120: @@
 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:audiomapping|]] zu Details wie Translations de/aktiviert werden können.
-=== 4. Transport- und Master-Nodes
+=== 4. Transport- und Master-Relays
-Im Non-Congress Setup ist ''live.ber.c3voc.de'' die einzige (Non-Public) Transport-Node. Die (Public) Edge-Nodes ziehen ihre Daten von dort.
+Im Non-Congress Setup ist ''live.ber.c3voc.de'' das einzige (Non-Public) Transport-Relay. Die (Public) Edge-Relays ziehen ihre Daten von dort.
-=== 5. Edge-Nodes
+=== 5. Edge-Relays
-Die ganzjährigen Edge-Nodes lauten:
+Die ganzjährigen Edge-Relay lauten:
   * ''live.bn.c3voc.de''
   * ''live.alb.c3voc.de''
+  * ''live2.alb.c3voc.de''
   * ''live.dus.c3voc.de''
   * ''live.self.c3voc.de''
@@ Line 129: / Line 135: @@
 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.
+ * Für Anfragen nach HLS oder DASH-Schnipseln, -Playlisten und -Manifests oder Thumbnails (z.B. http://live.x.c3voc.de/hls/sX_native_hd.m3u8) agiert der nginx als Proxy zum Master-Relay ''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
+== Stream-URLs
-Für den Teststream <del>vor</del>nach dem Congress (Codename ''sX_native_hd'' & 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
+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://cdn.c3voc.de/dash/sX/manifest.mpd
+HLS (h.264 Multi-Qualität + Multi-Lang)
+* http://cdn.c3voc.de/hls/sX/native_hd.m3u8
+Moar HLS
+* http://cdn.c3voc.de/hls/sX/translated_hd.m3u8 (auch Multi-Lang, nur anderer Default)
+* http://cdn.c3voc.de/hls/sX/translated-2_hd.m3u8
+* http://cdn.c3voc.de/hls/sX/native_sd.m3u8 (nur SD, aber trotzdem Multi-Lang)
+* http://cdn.c3voc.de/hls/sX/translated_sd.m3u8
+* http://cdn.c3voc.de/hls/sX/translated-2_sd.m3u8
+Legacy VPx-HD:
 * http://cdn.c3voc.de/sX_native_hd.webm
 * http://cdn.c3voc.de/sX_translated_hd.webm
 * http://cdn.c3voc.de/sX_translated-2_hd.webm
-VPx-SD:
+Legacy VPx-SD:
 * http://cdn.c3voc.de/sX_native_sd.webm
 * http://cdn.c3voc.de/sX_translated_sd.webm
 * http://cdn.c3voc.de/sX_translated-2_sd.webm
-VPx-Slides:
+Legacy VPx-Slides:
 * http://cdn.c3voc.de/sX_native_slides.webm
 * http://cdn.c3voc.de/sX_translated_slides.webm
 * http://cdn.c3voc.de/sX_translated-2_slides.webm
-h264-HD:
-* http://cdn.c3voc.de/hls/sX_native_hd.m3u8
-* http://cdn.c3voc.de/hls/sX_translated_hd.m3u8
-* http://cdn.c3voc.de/hls/sX_translated-2_hd.m3u8
-h264-SD:
-* http://cdn.c3voc.de/hls/sX_native_sd.m3u8
-* http://cdn.c3voc.de/hls/sX_translated_sd.m3u8
-* http://cdn.c3voc.de/hls/sX_translated-2_sd.m3u8
-h264-Slides:
-* http://cdn.c3voc.de/hls/sX_native_slides.m3u8
-* http://cdn.c3voc.de/hls/sX_translated_slides.m3u8
-* http://cdn.c3voc.de/hls/sX_translated-2_slides.m3u8
-WebM Multi-Qualität + Multi-Lang
-* http://cdn.c3voc.de/dash/sX/manifest.mpd
 Audio-MP3:
@@ Line 178: / Line 178: @@
 * http://cdn.c3voc.de/sX_translated.opus
 * http://cdn.c3voc.de/sX_translated-2.opus
-=== Vollständiges deaktivieren des Teststreams
-auf ''speedy.lan.c3voc.de'':
-<code>
-sudo systemctl stop transcode_sX.target
-sudo systemctl disable transcode_sX.target
-</code>
-auf ''live.ber.c3voc.de'':
-<code>
-sudo systemctl stop fanout_sX.target
-sudo systemctl disable fanout_sX.target
-screen -rd source-for-teststream
-:quit
-</code>
 == Loadbalancer
-Neben den Transport- und Edge-Relays gibt es noch zwei Loadbalancer:
+Neben den Transport- und Edge-Relays gibt es noch drei Loadbalancer:
   * ''lb.dus.c3voc.de''
   * ''lb.alb.c3voc.de''
+  * ''lb.dort.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.
+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 alle Server angegeben, so dass Clients per statistischem Round-Robin auf die Loadbalancer verteilt werden.
 === streaming.media.ccc.de
@@ Line 213: / Line 197: @@
 == 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''.
+Für Spezialanwendungen (z.B. Cam-Only Streaming im Fritz-Studio) existieren die RTMP-Endpunkte ''q1'' und ''q2'' auf ''ingest.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.
+Die Push-Targets lauten ''%%rtmp://ingest.c3voc.de/stream/q1%%'' bzw. ''q2''. Eine Systemd-Unit setzt diese dann auf Icecast-Ströme gleichen Namens um, von wo Transcoding und Fanout wie oben beschrieben automatisch ihren 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.
+=== Dynamische endpunkte mit rtmp-auth
+RTMP Endpunkte können unter https://ingest.c3voc.de/backend/ (passwort im keepass unter ansible/stream-api/htpasswd) erstellt werden. Nach dem Anlegen kann der Stream auf ingest gepusht werden.
+Die RTMP-Url für den endpunkt ''stream/qtest23'' mit auth token lautet z.B.: ''%%rtmp://ingest.c3voc.de/stream/qtest23?auth=token%%''
+== The Future of Streaming?
+Um die Redundanz zu erhöhen und das Management zu vereinfachen ist geplant die Streams auf dem CDN zukünftig über ein verteiltes System zu managen welches auf consul aufbaut.
+Damit wäre es möglich redundante CDN-Master sowie redundante Ingest-Server zu betreiben und trotzdem ein Web-Backend mit allen relevanten Streaming-Infos bereitzustellen. Weiterhin könnte die Streaming-Webseite intelligent auf das Vorhandensein/Fehlen von Streams im CDN reagieren und zusätzliche Metadaten von Encodern verarbeiten.
+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>diagram1.png}}
+==== Repo Links
+  * Stream-api, Upload-Proxy, Upload-Server: https://github.com/iSchluff/stream-api
+  * rtmp-auth daemon: https://github.com/voc/rtmp-auth
+  * Transcoding-Script: https://github.com/iSchluff/transcoding
+=== Änderungen zum Jetzt-Stand
+==== 1. Kein Fanout auf dem Master-Relay mehr
+Transcoder pushen direkt die fertig gemuxten Client-Streams auf 1-N Master-Relays. Damit brauchen die Transcoder potentiell etwas mehr Bandbreite, dafür wird der Prozess vereinfacht weil der Master Format-unabhängig verteilen kann.
+Weiterhin kann damit die Latenz um mindestens ein Keyframe-Intervall (3s), vermutlich sogar mehr gesenkt werden.
+==== 2. Keine WebM-Icecast Streams mehr
+Um die Zahl der gepushten Streams zu reduzieren (siehe 1) werden die alten Icecast-Streams abgeschaltet. Seit 2 Jahren sind diese nicht mehr default in der Streaming-Webseite. Als Vorbereitung hierzu wurde Frühling 2020 der Legacy-Tab entfernt.
+Audio-Only Streams über Icecast bleiben aber vermutlich erhalten genauso wie das interne Relaying über Icecast.