Architekturdiagramm für Video-Streaming: Upload, Transcoding, Packaging, Auslieferung

Ein Architekturdiagramm für Video-Streaming vom Upload bis zur Wiedergabe: Multipart-Uploads, Transcoding-Queues, ABR-Leitern, HLS und DASH, DRM und CDNs.

· Gründer & Entwickler

Veröffentlicht am

Architekturdiagramm für Video-Streaming: Upload, Transcoding, Packaging, Auslieferung

„Entwirf YouTube“ ist eine beliebte System-Design-Frage, weil die interessanten Teile nicht dort liegen, wo man sie erwartet. Die Webserver sind gewöhnlich. Die eigentliche Arbeit ist, Gigabytes zuverlässig vom Handy in den Speicher zu bringen, aus einem Upload ein Dutzend Versionen zu machen, die auf jedem Gerät und jeder Verbindung laufen, und diese Bytes aus einem CDN auszuliefern, sodass deine eigenen Server sie kaum sehen.

Dieser Beitrag geht die Pipeline der Reihe nach durch: Upload, Transcoding, Packaging, Auslieferung. Am Ende stehen ein Architekturdiagramm, das du anpassen kannst, und die Entscheidungen, die du daraufschreiben solltest.

Zwei Systeme, nicht eins

Eine Videoplattform besteht aus zwei Systemen, die sich eine Datenbank teilen:

  • Ingest: Creator laden hoch; die Plattform transkodiert und paketiert. Die Latenz wird in Minuten gemessen, und das stört niemanden.
  • Wiedergabe: Zuschauer drücken auf Play; das erste Bild muss innerhalb weniger Sekunden erscheinen und darf nicht hängen.

Zeichne sie als zwei Spuren. Sie skalieren nach unterschiedlichen Signalen (Uploads pro Stunde gegenüber gleichzeitigen Zuschauern) und fallen unterschiedlich aus.

Upload: nie über deine API-Server

Videodateien sind groß, und mobile Verbindungen brechen ab. Daraus folgen zwei Regeln:

  1. Direkt in den Objektspeicher hochladen. Die Upload-API authentifiziert den Creator, legt einen Videodatensatz an und gibt vorab signierte URLs zurück. Der Client schickt die Bytes direkt in den Bucket. Deine API leitet nie Gigabytes weiter.
  2. Fortsetzbar machen. Nutze Multipart-Uploads, damit eine abgebrochene Verbindung nur den fehlgeschlagenen Teil wiederholt. Amazon S3 Multipart Upload lädt Teile zum Beispiel unabhängig hoch und setzt sie zusammen, wenn der Client den Upload abschließt.

Wenn der Upload abgeschlossen ist, legt das Speicher-Event (oder der Abschlussaufruf des Clients) einen Transcoding-Job in eine Queue.

Transcoding: ein Upload, eine adaptive Bitratenleiter

Player wechseln die Qualität je nach Bandbreite, also kodierst du jedes Video mehrmals: eine adaptive Bitratenleiter (ABR). Eine typische Leiter reicht von etwa 240p oder 360p bis 1080p oder 4K, jede Stufe mit eigener Bitrate.

Transcoding ist CPU-intensiv und lässt sich fast beliebig parallelisieren:

  • Die Quelle an Keyframes in Stücke von wenigen Sekunden teilen.
  • Jedes Stück und jede Rendition als unabhängigen Job auf einer Worker-Flotte kodieren, meist mit FFmpeg.
  • Die Ergebnisse zusammenfügen oder als Segmente behalten.

Ein zweistündiger Film ist dann in Minuten statt Stunden transkodiert, und ein fehlgeschlagener Job wiederholt nur ein Stück. Mach Jobs idempotent, indem du sie nach Video, Rendition und Stück schlüsselst, damit ein Retry überschreibt statt zu duplizieren.

Eine Leiter für alle Inhalte verschwendet Bits: Eine statische Folienpräsentation braucht viel weniger Bitrate als ein Fußballspiel. Netflix hat Per-Title-Encoding bekannt gemacht, das die Leiter pro Video nach seiner Komplexität wählt. Du kannst mit einer festen Leiter starten und später auf Per-Title umsteigen.

Packaging: HLS, DASH und CMAF

Player laden keine große Datei herunter. Sie lesen ein Manifest, das Renditions und Segmente auflistet, und holen dann Segmente von wenigen Sekunden über normales HTTP.

Format Definiert durch Typische Player
HLS RFC 8216 Apple-Geräte, die meisten Browser über Player wie hls.js
MPEG-DASH ISO/IEC 23009-1 Android, Smart-TVs, Browser über dash.js und Shaka Player
CMAF ISO/IEC 23000-19 Ein Satz fragmentierter MP4-Segmente für HLS- und DASH-Manifeste

CMAF ist der Grund, warum der Packager zählt: Damit speicherst du einen Satz Segmente und schreibst zwei Manifeste statt zwei Kopien jedes Videos. Kurze Segmente starten schneller und wechseln früher die Qualität; längere Segmente kosten weniger Anfragen. Apples HLS Authoring Specification nennt konkrete Empfehlungen für Segmentdauer, Keyframes und Leitern.

Bezahlinhalte bringen DRM ins Spiel. Der Packager verschlüsselt Segmente einmal mit Common Encryption (CENC), und das DRM-System jeder Plattform (Widevine, FairPlay, PlayReady) stellt Playern über einen Lizenzserver Lizenzen aus.

Auslieferung: Das CDN macht die Arbeit

Segmente sind statische Dateien, und genau darum geht es: Ein CDN cacht sie nahe bei den Zuschauern, und ein beliebtes Video wird fast vollständig aus Edge-Caches ausgeliefert. Der Origin ist der Renditions-Bucket, oft hinter einem Origin Shield, sodass ein Cache-Miss an 50 Edge-Standorten zu einer einzigen Anfrage an den Speicher wird.

Die Wiedergabe-API bleibt klein: prüfen, ob der Zuschauer das Video sehen darf, eine Manifest-URL zurückgeben (signiert, wenn der Inhalt privat ist) und Wiedergabe-Events für Analytics erfassen.

Live-Streaming ist eine andere Pipeline

Live-Video nutzt Packaging und CDN weiter, ersetzt aber den Ingest. Ein Encoder schickt einen Stream über ein Protokoll wie RTMP oder SRT an einen Ingest-Server, der die Leiter in Echtzeit transkodiert und alle paar Sekunden neue Segmente schreibt. Die Latenz ergibt sich aus Segmentlänge plus Puffer des Players; die Low-Latency-Modi von HLS und DASH liefern Teile eines Segments aus, bevor es fertig ist, um näher an wenige Sekunden heranzukommen. Halte Live und On-Demand als getrennte Pipelines, die sich CDN, Player und Metadaten teilen.

Das Architekturdiagramm

Ein Creator holt eine Upload-URL und lädt Teile in einen Raw-Bucket, der Transcoding-Jobs einreiht. Worker kodieren Renditions; ein Packager schreibt Segmente in einen zweiten Bucket und markiert das Video als bereit. Zuschauer holen ein Manifest, streamen vom CDN, holen eine DRM-Lizenz.

13 Komponenten · 12 Verbindungen

In Archboard öffnen
Diagramminhalt
  • Creator
  • Upload API
  • Raw uploads
  • Transcode jobs
  • Transcode workers
  • Packager
  • Renditions
  • Video metadata
  • Viewer
  • Playback API
  • CDN
  • DRM license server
  • 1. upload URL
  • 2. multipart
  • 3. done
  • ladder
  • segments
  • ready
  • manifest URL
  • cache miss
  • license
Eine Videoplattform, aufgeteilt in Ingest-Pipeline und Wiedergabepfad. Uploads gehen direkt in den Speicher, eine Queue steuert das Transcoding in eine adaptive Bitratenleiter, ein Packager schreibt HLS- und DASH-Segmente, und Zuschauer streamen sie von einem CDN.

So liest du es:

  • Obere Spur, Ingest: Der Creator holt sich bei der Upload-API eine Upload-URL (1), lädt Teile direkt in den Raw-Upload-Bucket (2), und der abgeschlossene Upload reiht Transcoding-Jobs ein (3). Worker kodieren die Leiter, und der Packager schreibt Segmente in den Renditions-Bucket und markiert das Video im Metadatenspeicher als bereit.
  • Untere Spur, Wiedergabe: Der Zuschauer fragt die Wiedergabe-API nach einer Manifest-URL und streamt dann Segmente vom CDN. Ein Cache-Miss liest aus dem Renditions-Bucket.
  • DRM ist gepunktet, weil nur geschützte Inhalte es brauchen: Der Player holt eine Lizenz vom Lizenzserver.
  • Der Markdown-Block zeigt eine Beispielleiter. Deine Zahlen sollten aus deinen Inhalten und der Bandbreite deiner Zuschauer kommen.

Was ins Diagramm gehört

  • Wohin die Bytes fließen. Zeichne Uploads und Segmente auf dem Weg in den Speicher und ins CDN, nicht durch deine API.
  • Die Job-Einheit. „Ein Job pro Rendition und Stück“ zeigt Reviewern, wie Retries und Parallelität funktionieren.
  • Formate und Schutz. Nenne HLS, DASH oder CMAF und DRM, falls du es nutzt.
  • Das Bereit-Signal. Ein Video ist erst abspielbar, wenn das Packaging fertig ist; zeig, wo dieser Zustand liegt.

Dieselbe Form aus Queue und Workern taucht im Beitrag zur ereignisgesteuerten Architektur auf. Für die Cloud-Seite behandelt das AWS-Architekturdiagramm für mehrere Regionen die Auslieferung aus mehr als einer Region, und das Serverless-Architekturdiagramm zeigt, wie Speicher-Events Funktionen statt einer Worker-Flotte auslösen können.

In Archboard nachbauen

  1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
  2. Füge aus dem C4-Modell-Pack zwei Person-Nodes für Creator und Zuschauer hinzu.
  3. Füge Container-Nodes für Upload-API, Transcoding-Worker, Packager und Wiedergabe-API hinzu und eine Datenbank für die Videometadaten.
  4. Füge aus dem Cloud-Pack zwei Objektspeicher-Nodes und ein CDN hinzu, aus dem Daten-Pack eine Warteschlange für Transcoding-Jobs und ein Externes System für den DRM-Lizenzserver.
  5. Zeichne den Ingest in die obere und die Wiedergabe in die untere Spur, nummeriere die Upload-Schritte an den Kanten und füge einen Markdown-Block aus dem Basis-Pack mit deiner Leiter hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist eine adaptive Bitratenleiter? Die Menge an Renditions, in die ein Video kodiert wird, jede mit eigener Auflösung und Bitrate. Der Player wählt die beste, die die Verbindung des Zuschauers trägt, und wechselt, wenn sich die Bandbreite ändert.

Sollte ich HLS oder DASH nutzen? Oft beides. Paketiere einmal als CMAF-Segmente und schreib ein HLS- und ein DASH-Manifest, dann sind Apple-Geräte und andere Player abgedeckt, ohne zwei Kopien zu speichern.

Warum direkt in den Objektspeicher hochladen? Große Dateien über deine API-Server binden Verbindungen und Speicher, und eine abgebrochene Verbindung startet den Upload neu. Vorab signierte Multipart-Uploads gehen direkt in den Speicher und setzen Teil für Teil fort.

Wie wird Transcoding parallelisiert? Teile die Quelle an Keyframes in Stücke und kodiere jedes Stück und jede Rendition als eigenen Job, dann füge die Ergebnisse zusammen oder paketiere sie.

Brauche ich für Video ein CDN? Für alles jenseits eines kleinen Publikums ja. Segmente sind statische Dateien, und ein CDN beantwortet wiederholte Anfragen aus Caches nahe bei den Zuschauern statt aus deinem Speicher.

Kostenlos starten — ein Seat, keine Kreditkarte.

Ähnliche Beiträge

← Zurück zum Blog

In einer Minute ein Canvas öffnen

Melden Sie sich mit Google oder GitHub an. Kostenlos für einen Sitzplatz. Upgraden Sie, wenn das Team dazukommt.