cdn

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
cdn [2020/11/28 19:52] – [Loadbalancer] ischluffcdn [2022/07/11 12:09] andi
Line 1: Line 1:
 = CDN = CDN
-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 [[software:voctoweb]] beschrieben. 
  
-== Architektur+<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> 
 + 
 + 
 + 
 +== The Future of Streaming 
 + 
 +Um die Redundanz zu erhöhen und das Management zu vereinfachen werden die Streams auf dem CDN über ein verteiltes System verwaltet welches auf Consul aufbaut. 
 + 
 +Damit ist 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 zu v1 
 +==== 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. 
 + 
 + 
 +== Ursprüngliche Architektur v1
 Die CDN-Kaskade hat 5 Stufen: Master-Encoder, Transcoder, Fanout, Transport-/Master-Relays und schließlich Edge-Relays. Die CDN-Kaskade hat 5 Stufen: Master-Encoder, Transcoder, Fanout, Transport-/Master-Relays und schließlich Edge-Relays.
  
Line 136: Line 172:
 Die endgültigen Stream-URLs für einen Beispielstream sX sind dann wie folgt: Die endgültigen Stream-URLs für einen Beispielstream sX sind dann wie folgt:
  
-MPEG-DASH (Multi-Qualität + Multi-Lang)+MPEG-DASH (VPx Multi-Qualität + Multi-Lang)
 * http://cdn.c3voc.de/dash/sX/manifest.mpd * http://cdn.c3voc.de/dash/sX/manifest.mpd
  
-HLS (Multi-Qualität + Multi-Lang) +HLS (h.264 Multi-Qualität + Multi-Lang) 
-* http://cdn.c3voc.de/sX_native_hd.m3u8 +* http://cdn.c3voc.de/hls/sX/native_hd.m3u8
-* http://cdn.c3voc.de/sX_native_sd.m3u8 (nur SD, aber Multi-Lang)+
  
-VPx-HD:+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_native_hd.webm
 * http://cdn.c3voc.de/sX_translated_hd.webm * http://cdn.c3voc.de/sX_translated_hd.webm
 * http://cdn.c3voc.de/sX_translated-2_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_native_sd.webm
 * http://cdn.c3voc.de/sX_translated_sd.webm * http://cdn.c3voc.de/sX_translated_sd.webm
 * http://cdn.c3voc.de/sX_translated-2_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_native_slides.webm
 * http://cdn.c3voc.de/sX_translated_slides.webm * http://cdn.c3voc.de/sX_translated_slides.webm
 * http://cdn.c3voc.de/sX_translated-2_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 
  
 Audio-MP3: Audio-MP3:
Line 182: Line 209:
 * http://cdn.c3voc.de/sX_translated.opus * http://cdn.c3voc.de/sX_translated.opus
 * http://cdn.c3voc.de/sX_translated-2.opus * http://cdn.c3voc.de/sX_translated-2.opus
- 
  
 == Loadbalancer == Loadbalancer
Line 212: Line 238:
 Die RTMP-Url für den endpunkt ''stream/qtest23'' mit auth token lautet z.B.: ''%%rtmp://ingest.c3voc.de/stream/qtest23?auth=token%%'' 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 etcd 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 
-{{::stream-automation-v2.png?1200|}} 
- 
-=== Ä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. 
  
  • cdn.txt
  • Last modified: 2024/01/29 10:45
  • by ischluff