Streaming- und VOD-Architektur # Video-CDN-Architektur: Transkodierung, HLS/DASH, Speicher und Caching Entwerfen Sie einen Video-CDN-Pfad über Transkodierung; HLS-, MPEG-DASH- oder CMAF-Paketierung; eigenen Speicher; Caching; Wiedergabe; Observability und Kosten. Veröffentlicht am 1. September 2026 ## Wichtigste Erkenntnisse * Trennen Sie Ingest, Verarbeitung, Speicher, Auslieferung und Wiedergabe, bevor Sie Produkte auswählen, und wenden Sie Autorisierung dann über den gesamten Anfragepfad hinweg an. * Bauen Sie Bitratenleitern aus der Quellqualität und gemessenen Bedingungen beim Publikum auf, statt aus einer festen Liste von Auflösungen. * Verpacken Sie abgestimmte Varianten als HLS, MPEG-DASH oder CMAF und bewahren Sie beim Export jeden relativen Manifest- und Segmentpfad. Ein Video-CDN ist keine einzelne Blackbox. Zuverlässige On-Demand-Wiedergabe entsteht aus einer Kette, deren Schichten für Ingest, Verarbeitung, Speicher, Auslieferung und Wiedergabe jeweils eine klare Verantwortung haben, wobei Autorisierung als übergreifende Policy angewendet wird. Das Design scheitert, wenn ein gecachtes Manifest auf ersetzte oder noch nicht veröffentlichte Segmente verweist, Varianten-Pfade beim Export brechen oder eine Live-Streaming-Anforderung mit dateibasierter VOD-Verarbeitung verwechselt wird. ## In diesem Leitfaden 1. [Jeder Schicht eine klare Verantwortung zuweisen](#video-cdn-architecture-section-1) 2. [Eine Bitratenleiter erstellen, die ihre Kosten rechtfertigt](#video-cdn-architecture-section-2) 3. [Adaptive Ausgaben als einen zusammenhängenden Baum verpacken](#video-cdn-architecture-section-3) 4. [Speicher- und Cache-Verhalten deploymentsicher gestalten](#video-cdn-architecture-section-4) 5. [Wiedergabe schützen, ohne den Cache zu zerstören](#video-cdn-architecture-section-5) 6. [Den gesamten Pfad beobachten und Fehlerszenarien üben](#video-cdn-architecture-section-6) 7. [Kosten pro veröffentlichtem und angesehenem Asset modellieren](#video-cdn-architecture-section-7) ## Worauf es besonders ankommt * Verwenden Sie versionierte Asset-Pfade, bewusste Cache-Policys und ein einheitliches Autorisierungsmodell für Manifeste, Segmente, Untertitel und Posterbilder. * Messen Sie Startverzögerung, Rebuffering, Wiedergabefehler, Cache-Hit-Rate, Origin-Traffic, Verarbeitungsfehler und Kosten pro veröffentlichtem Asset. ## Jeder Schicht eine klare Verantwortung zuweisen Beginnen Sie beim Zuschauer und verfolgen Sie den Weg rückwärts. Der Player interpretiert das Manifest, wählt eine Variante aus, rendert Untertitel, meldet Wiedergabe-Ereignisse und wendet Produktsteuerungen an. Das CDN terminiert die Anfragen der Zuschauer, setzt die gewählte Auslieferungsrichtlinie durch, cacht Antworten und holt Cache-Misses von einem Origin. Für freigegebene Manifeste, Segmente, Untertitel, Posterbilder und einen etwaigen Archiv-Master ist der dauerhafte Objektspeicher verantwortlich. Ein Verarbeitungsdienst erzeugt diese Ausgaben aus einer vollständigen Quelle. Upload- oder Live-Ingest-Infrastruktur bringt die Quelle über diese Verarbeitungsgrenze. Autorisierung ist eine übergreifende Policy, die konsistent auf den Auslieferungs- und Wiedergabe-Anfragepfad angewendet wird, und keine sechste Verarbeitungsschicht für Medien. Der Begriff „Video-CDN“ verdeckt oft diese Aufteilung. Ein CDN repariert keine beschädigten Zeitstempel und erstellt keine adaptive Bitratenleiter, und ein Transcoder liefert nicht automatisch Autorisierung fürs Publikum, globales Caching, einen Player oder Quality-of-Experience-Analytics. Halten Sie stabile, anwendungseigene Asset- und Versions-Identifikatoren über alle Schichten hinweg konsistent, damit sich ein Verarbeitungsauftrag, ein exportiertes Paket, eine Auslieferungsanfrage und ein Player-Fehler zuordnen lassen, ohne einen Dateinamen als Datenbank zu missbrauchen. ### Ingest-Schicht Nimmt einen vollständigen Upload oder Import entgegen oder schließt eine Live-Aufzeichnung ab, bevor eine dauerhafte Quelle an die Verarbeitung übergeben wird. ### Verarbeitungsschicht Erstellt technisch gültige Varianten und Pakete aus der von der Ingest-Schicht übergebenen dauerhaften Quelle. ### Speicherschicht Verwaltet freigegebene Dateien und stellt einen kontrollierten Origin-Pfad bereit; sie ist nicht der Asset-Katalog der Anwendung. ### Auslieferungsschicht Schützt und cacht Zuschaueranfragen, ruft bei einem Cache-Miss vom Origin ab und wendet die gewählte Auslieferungsrichtlinie an. ### Wiedergabeschicht Interpretiert das Manifest, wählt Varianten aus, rendert Untertitel und bestimmt das Wiedergabeerlebnis. ## Eine Bitratenleiter erstellen, die ihre Kosten rechtfertigt Prüfen Sie die Quelle, bevor Sie Ausgaben wählen. Auflösung, Bildrate, Codec, Bittiefe, Audio-Layout, Dauer und visuelle Komplexität bestimmen, was sinnvoll ist. Eine 720p-Quelle kann durch ein 1080p-Encoding keine echten zusätzlichen Details gewinnen. Ein bewegungsarmer Vortrag und eine schnelle Aufzeichnung eines Sportereignisses benötigen bei gleichen Abmessungen unter Umständen unterschiedliche Bitraten. Bewahren Sie eine hochwertige Archivquelle auf, wenn eine spätere erneute Verarbeitung wichtig ist, senden Sie diesen Master jedoch nicht über den öffentlichen Wiedergabepfad. Codieren Sie eine kleine Anzahl an Varianten, deren Bitrate und Abmessungen sinnvolle Umschaltstufen bieten. Verwenden Sie im gesamten Satz dieselbe Segmentdauer, ausgerichtete Keyframes und kompatible Zeitachsen. Prüfen Sie die visuelle Qualität anhand repräsentativer Inhalte, statt sich auf Auflösungsbezeichnungen zu verlassen. Mehr Varianten erhöhen Encoding-Minuten, gespeicherte Bytes, Paketobjekte und Prüfzeit und können zu mehr Cache-Misses führen. Fügen Sie daher nur dann eine weitere hinzu, wenn die Player-Telemetrie eine Abdeckungslücke zeigt. ### Quellobergrenze respektieren Erfinden Sie niemals zusätzliche Bilddetails durch Hochskalieren einer Quelle, nur um eine übliche Bitratenleiter zu füllen. ### Repräsentativen Korpus verwenden Vergleichen Sie Bewegung, Farbverläufe, Text, Gesichter, dunkle Szenen und Audiosynchronisation bei den Zielbitraten. ### Messkreislauf schließen Optimieren Sie die Bitratenleiter anhand von Daten zu Startzeit, Pufferunterbrechungen und ausgelieferter Bitrate statt allein nach Intuition. ## Adaptive Ausgaben als einen zusammenhängenden Baum verpacken HLS- und MPEG-DASH-Pakete sind Referenzgraphen und keine unabhängigen Dateien. Ein übergeordnetes Manifest identifiziert Varianten, Medien-Playlists oder Repräsentationen identifizieren Medien, und die Medieneinträge lösen Segmente auf. Untertitel, alternative Audiospuren, Verschlüsselungsmetadaten und Initialisierungssegmente können weitere Beziehungen hinzufügen. Prüfen Sie das gesamte Paket nach dem Export über seine öffentliche URL; wenn nur geprüft wird, ob das übergeordnete Manifest 200 zurückgibt, werden defekte untergeordnete Ressourcen, MIME-Typen, CORS-Regeln und Autorisierungsfehler übersehen. Das Beispiel erstellt zwei HLS-fertige Varianten in separaten Steps für `/video/encode` und bündelt sie anschließend mit `/video/adaptive`. Der adaptive Step definiert eine `segment_duration` für das Paket; stellen Sie sicher, dass die Zeitachsen der Varianten und die Keyframe-Einstellungen kompatibel bleiben, insbesondere bevor Sie Dateien kombinieren, die außerhalb eines kontrollierten Workflows vorbereitet wurden. Anschließend exportiert `/s3/store` die resultierenden Dateien. Die adaptiven Ergebnisse enthalten Metadaten unter `relative_path`. Das Ziel kombiniert die paketweite `${assembly.id}` mit `${file.meta.relative_path}` und `${file.name}`, sodass jedes Ergebnis unter einem Präfix bleibt und die von den Playlists referenzierte Verzeichnisstruktur erhalten bleibt. Verwenden Sie in der Produktion ein gespeichertes Template und Template-Zugangsdaten mit minimalen Berechtigungen. Ersetzen Sie die Beispiel-Bitratenleiter, den Namen `my_s3_credentials`, den in diesen Template-Zugangsdaten konfigurierten Bucket und die Region sowie das Pfadpräfix `vod` durch Werte, die für den Quellkorpus, die Zielplayer und den Bucket getestet wurden. Das Beispiel setzt `acl` bewusst auf `private`, da `/s3/store` andernfalls standardmäßig `public-read` verwendet; konfigurieren Sie den privaten Origin-Zugriff des CDN separat. Zwei vorbereitete Varianten paketieren und ihre relativen Pfade in S3 erhalten ``` { "steps": { ":original": { "robot": "/upload/handle" }, "hls_480p": { "use": ":original", "robot": "/video/encode", "result": false, "ffmpeg_stack": "v6", "preset": "hls/480p" }, "hls_720p": { "use": ":original", "robot": "/video/encode", "result": false, "ffmpeg_stack": "v6", "preset": "hls/720p" }, "vod_package": { "use": { "steps": ["hls_480p", "hls_720p"], "bundle_steps": true }, "robot": "/video/adaptive", "result": true, "technique": "hls", "playlist_name": "master.m3u8" }, "exported": { "use": "vod_package", "robot": "/s3/store", "credentials": "my_s3_credentials", "acl": "private", "path": "vod/${assembly.id}/${file.meta.relative_path}/${file.name}" } } } ``` ## Speicher- und Cache-Verhalten deploymentsicher gestalten Veröffentlichen Sie jedes freigegebene Paket unter einem unveränderlichen Versionspfad, etwa einer Asset-ID mit Version oder Inhaltsprüfsumme. Laden Sie jedes Objekt hoch, prüfen Sie das Paket, und ändern Sie erst danach den Anwendungsdatensatz, um das neue übergeordnete Manifest bereitzustellen. Dadurch wird die Veröffentlichung aus Sicht des Zuschauers atomar und es wird vermieden, dass ein neues Manifest auf Segmente verweist, die den Origin noch nicht erreicht haben. Behalten oder löschen Sie alte Versionen gemäß einer expliziten Rollback- und Aufbewahrungsrichtlinie. Segmente unter unveränderlichen Pfaden können in der Regel lange Cache-Lebensdauern erhalten, da sich ihre Bytes nie ändern. Ein Manifest, das an Ort und Stelle geändert wird, benötigt eine kürzere oder aktiv invalidierte Richtlinie; das Versionieren des vollständigen VOD-Pakets lässt sich jedoch einfacher nachvollziehen. Konfigurieren Sie korrekte Content-Types, bei Bedarf Byte-Range-Verhalten, CORS für die tatsächlichen Player-Ursprünge und einheitliche Kompressionsregeln. Testen Sie generische HTML-Caching-Annahmen für Manifeste und Segmente stets mit dem gewählten Player und CDN, bevor Sie sie anwenden. ### Atomar veröffentlichen Ein Paket wird erst sichtbar, nachdem alle referenzierten Objekte exportiert und geprüft wurden. ### Unveränderliche Versionen verwenden Dieselbe URL liefert immer dieselben Bytes, sodass zwischengespeicherte Medien nicht unbemerkt verschiedene Versionen mischen können. ## Wiedergabe schützen, ohne den Cache zu zerstören Legen Sie fest, ob ein Video öffentlich, zeitlich begrenzt oder an eine Anwendungsberechtigung gebunden ist. Wenden Sie die daraus resultierende Richtlinie auf das übergeordnete Manifest, untergeordnete Manifeste, Segmente, Untertitel, Posterbilder und Downloads an. Nur die erste Anfrage zu schützen, reicht nicht aus, wenn ein Zuschauer die Segment-URLs direkt wiederverwenden kann. Bewahren Sie private Speicher-Zugangsdaten und Transloadit-Signierschlüssel auf vertrauenswürdigen Servern auf. Jeder variierende Abfrageparameter, jedes Cookie und jeder Anfrage-Header kann die Cache-Wiederverwendung beeinflussen, wenn er in den Cache-Key einfließt. Umgekehrt kann das Entfernen eines sicherheitsrelevanten Werts aus dem Cache-Key dazu führen, dass eine autorisierte Antwort im falschen Kontext ausgeliefert wird. Bevorzugen Sie eine kleine, dokumentierte Menge an Auslieferungsparametern, normalisieren Sie diese bei Bedarf am Edge, und testen Sie Ablauf, Widerruf, Sprung im Zeitstrahl und gleichzeitige Segmentanfragen. Halten Sie Geheimnisse und personenbezogene Daten aus Manifest- und Segment-URLs heraus, da diese URLs in Protokollen, Analytics, Browserverlauf und Support-Traces erscheinen können. ## Den gesamten Pfad beobachten und Fehlerszenarien üben Verarbeitungstelemetrie sollte akzeptierte Eingaben, jede Variante, die Paketerstellung, den Abschluss des Exports, die Dauer und strukturierte Fehler offenlegen. Speicher- und CDN-Telemetrie sollte fehlende Objekte, die Antwortzeit des Origin-Servers, die Cache-Hit-Rate, übertragene Bytes und den Antwortstatus nach Objektklasse offenlegen. Player-Telemetrie sollte Startverzögerung, Rebuffering, fatale Fehler, die gewählte Bitrate, fehlgeschlagene Sprünge in der Wiedergabe und Fehler bei der Untertitelwiedergabe offenlegen. Verknüpfen Sie diese Beobachtungen über stabile Asset- und Versions-Identifikatoren, während Sie Zuschauerdaten angemessen minimieren. Testen Sie beschädigte und nicht unterstützte Quellen, unterbrochene Uploads, ein nicht erreichbares Exportziel, unvollständige Pakete, doppelte Abschlussbenachrichtigungen, ein veraltetes Manifest, einen Ausfall des Origin-Servers, abgelaufene Auslieferungsberechtigungen, fehlende CORS-Header und einen nicht unterstützten Codec. Gleichen Sie nicht abgeschlossene Verarbeitungsaufträge mit dem maßgeblichen Status ab, damit eine verpasste Benachrichtigung ein Asset nicht dauerhaft in der Schwebe hält. Halten Sie „verarbeitet“, „exportiert“, „abspielbar“, „geprüft“ und „veröffentlicht“ als getrennte Zustände auseinander. ### Für Wiederholung auslegen Wiederholungssichere Pfade und idempotente Handler verhindern, dass doppelte Benachrichtigungen doppelte Veröffentlichungen erzeugen. ### Fehlende Ereignisse abgleichen Eine geplante Statusprüfung stellt den Zustand wieder her, wenn eine Benachrichtigung verzögert ist oder die Anwendung nie erreicht. ## Kosten pro veröffentlichtem und angesehenem Asset modellieren Zählen Sie den Quell-Upload oder -Import, jede codierte Ausgabe, das Packaging, Untertitel, Thumbnails, den Export, aufbewahrte Originale, gespeicherte Segmente, CDN-Anfragen, Origin-Anfragen und den Egress. Addieren Sie dann Fehler, Wiederholungen, Bearbeitungen und neu benötigte Formate. Eine größere Bitratenleiter kostet mehr, bevor überhaupt ein Zuschauer eintrifft, während ein Design mit sehr kleinen Segmenten das Anfragevolumen und den Manifest-Overhead erhöhen kann. Cache-Fragmentierung verlagert Arbeit und Traffic zurück zum Origin-Server. Vergleichen Sie Architekturen anhand repräsentativer Quellen und Zuschauerverteilungen. Die Kosten pro Eingabeminute sind für die Verarbeitung nützlich, doch die Kosten pro veröffentlichtem Asset zeigen fehlgeschlagene und abgebrochene Arbeit, und die Kosten pro angesehener Stunde erfassen das Auslieferungsverhalten. Berücksichtigen Sie den Entwicklungsaufwand für Player-Kompatibilität, Cache-Regeln, Autorisierung, Observability, Incident Response und Migration. Die günstigste beworbene Einheit ist nicht zwangsläufig das kostengünstigste zuverlässige System. ## Wissenswerte technische Details * HLS und MPEG-DASH beschreiben adaptive Auslieferungspakete; keines der beiden Protokolle bietet für sich genommen Live-Ingest, Speicher, ein CDN, einen Player, Analytics oder Berechtigungsprüfungen. * Adaptives Umschalten setzt voraus, dass Varianten kompatible Zeitachsen und ausgerichtete Segmentgrenzen haben. Unabhängig codierte Dateien lassen sich nicht automatisch gefahrlos zu einer Bitratenleiter kombinieren. * Ein Master-Manifest verweist auf Media-Playlists oder Repräsentationen, die wiederum auf Segmente verweisen. Wenn Dateien verschoben werden, ohne diese relativen Pfade zu erhalten, wird die Wiedergabe unterbrochen, selbst wenn jedes Objekt vorhanden ist. * Manifeste und Mediensegmente haben unterschiedliche Änderungsmuster. Versionierte VOD-Segmente können langlebig unveränderlich gecacht werden, während veränderliche Manifeste eine Richtlinie benötigen, die zum Veröffentlichungs- und Ersetzungsverhalten passt. * CDN-Cache-Keys und Autorisierung müssen gemeinsam entworfen werden. Query-Strings, Cookies oder Header, die unnötig variieren, können den Cache fragmentieren, während fehlende Autorisierungsangaben geschützte Medien offenlegen können. * Die Segmentdauer und damit die ungefähre Segmentgröße bei einer bestimmten Bitrate wirken sich auf die Startlatenz aus und darauf, wie schnell ein Player zwischen Varianten wechseln kann. * Byte-Range-Adressierung ermöglicht es, mehrere Segmente in einer fMP4- oder CMAF-Ressource unterzubringen, die Player über HTTP-Range-Anfragen abrufen, wodurch sich die Anzahl der Objekte und Cache-Keys verringert. Sie verringert nicht die insgesamt bei linearer Wiedergabe ausgelieferten Bytes und ergänzt die segmentierte Auslieferung, statt sie zu ersetzen. * Der Transloadit-Robot /video/adaptive verpackt vorbereitete Varianten als HLS, MPEG-DASH oder CMAF. Speicher-Exporte müssen die relative\_path-Metadaten jedes Ergebnisses erhalten, damit das Paket verbunden bleibt. * Die Anwendung sollte ein Video nicht allein deshalb als veröffentlichbar markieren, weil das Encoding abgeschlossen ist. Sie muss zusätzlich die Vollständigkeit des Exports, die Gültigkeit des Manifests, den Auslieferungszugriff, Untertitel, Posterbilder und die Wiedergabe auf den Zielgeräten prüfen. ## Ein praxisnaher Ansatz 1. 1\ Zeichnen Sie den Anfrage- und Datenpfad vom Quell-Ingest bis zum Zuschauer auf und legen Sie fest, wer für jeden Übergang verantwortlich ist. 2. 2\ Codieren Sie eine kleine Bitratenleiter aus repräsentativen Quellen und validieren Sie das Umschalten auf Zielgeräten und realistischen Netzwerken. 3. 3\ Exportieren Sie das vollständige adaptive Paket in versionierte Speicherpfade und testen Sie es über die produktiven CDN-Regeln. 4. 4\ Führen Sie Fehlerübungen für unvollständige Exporte, veraltete Manifeste, nicht erreichbare Origins, abgelaufene Autorisierung und fehlende Abschlussereignisse durch. Ein vierstufiger Medienworkflow ## Wann Transloadit hilfreich ist Verwenden Sie ein gespeichertes Template, um hochgeladene, importierte oder finalisierte Aufzeichnungen mit /video/encode in eine Bitratenleiter zu verwandeln, die auf gemessene Bedingungen zugeschnitten ist, verpacken Sie diese Varianten mit /video/adaptive und exportieren Sie den kompletten Verzeichnisbaum in Ihren eigenen Speicher. Versehen Sie die resultierenden VOD-Assets entsprechend Ihren Auslieferungsanforderungen mit einem CDN und einem Player. ## Architekturgrenze Transloadit verarbeitet fertige Videodateien und kann adaptive Video-on-Demand-Ausgaben (VOD) paketieren, betreibt aber weder Live-Ingest noch ein Allzweck-CDN oder einen Videoplayer. Live-Broadcasting und die Wiedergabe für Zuschauer erfordern dedizierte Komponenten. ## Häufig gestellte Fragen ### Sollte jeder Dienst sowohl HLS als auch MPEG-DASH veröffentlichen? Nicht unbedingt. HLS wird in Apple-Umgebungen breit nativ unterstützt, während MPEG-DASH in anderen Player-Stacks verbreitet ist. Manche Produkte veröffentlichen beides aus gemeinsamem CMAF-Material, doch das erhöht den Validierungs- und Betriebsaufwand. Wählen Sie anhand der tatsächlichen Geräte- und Player-Anforderungen und testen Sie die konkreten Manifeste, Codecs, Untertitel und den Autorisierungspfad. ### Gibt es eine Standard-Bitratenleiter für adaptives Streaming? Nein. Eine sinnvolle Bitratenleiter orientiert sich an der Quellauflösung, der Bildrate, der visuellen Komplexität, den Zieldisplays und der gemessenen Bandbreite der Zuschauer. Skalieren Sie nicht über die Quelle hinaus hoch und fügen Sie keine benachbarten Varianten hinzu, die das Umschalten nicht verbessern. Beginnen Sie mit einer kleinen Bitratenleiter und passen Sie diese anhand von Wiedergabedaten an. ### Wie sollte ich ein bereits zwischengespeichertes Video ersetzen? Verwenden Sie für jedes freigegebene Paket einen versionierten, unveränderlichen Pfad und ändern Sie den Asset-Zeiger der Anwendung, sobald ein Ersatz bereit ist. So verhindern Sie, dass ein neues Manifest auf alte oder teilweise ersetzte Segmente verweist, und das langlebige Segment-Caching bleibt sicher. ### Kann Transloadit den Live-Teil eines Video-CDN übernehmen? Es kann dateibasierte Video-on-Demand-Assets vorbereiten, nachdem eine vollständige Datei hochgeladen, importiert oder von einem Live-Anbieter finalisiert wurde. Es akzeptiert keinen kontinuierlichen Live-Eingangsstream, manchmal Contribution Feed genannt, und betreibt auch nicht die Live-Übertragung. Ein Live-Workflow benötigt daher einen spezialisierten Dienst für Ingest und Distribution. ### Was sollte ich zuerst überwachen? Erfassen Sie Startzeit beim Zuschauer, Rebuffer-Quote, fatale Wiedergabefehler, durchschnittliche ausgelieferte Bitrate, CDN-Cache-Hit-Rate, Origin-Bytes, fehlgeschlagene Manifest- und Segmentantworten, Verarbeitungsdauer, Vollständigkeit der Exporte und Kosten pro veröffentlichtem Asset. Halten Sie Player-, CDN-, Speicher- und Verarbeitungs-Identifikatoren verknüpfbar, ohne private Daten in URLs abzulegen. ## Erstellen Sie den Workflow Entwickeln Sie das Konzept mithilfe der Robot-Dokumentation und funktionsfähiger Demos zu einer getesteten Assembly weiter. ### Relevante Robots * [/video/encode](/de/docs/robots/video-encode.md) * [/video/adaptive](/de/docs/robots/video-adaptive.md) * [Video-Varianten mit /video/encode erstellen](/de/docs/robots/video-encode.md) * [Adaptives Video mit /video/adaptive verpacken](/de/docs/robots/video-adaptive.md) * [Pakete mit /s3/store exportieren](/de/docs/robots/s3-store.md) * [Speicher-Zugangsdaten schützen](/de/docs/topics/template-credentials.md) * [Die HTTP-Live-Streaming-Spezifikation lesen⁠](https://www.rfc-editor.org/rfc/rfc8216.html) * [Lesen Sie die API-Dokumentation](/de/docs.md) * [Entdecken Sie funktionsfähige Demos EN (English)](/demos.md) * [Kostenlosen Workspace erstellen](/c/signup/) Streaming- und VOD-Architektur ## Mit verwandten Leitfäden fortfahren * [So bewerten Sie APIs für Live- und On-Demand-Video](/de/guides/video-streaming-api-evaluation.md)\ Bewerten Sie Live- und On-Demand-Video-APIs nach Ingest, Latenz, Wiedergabe, Verarbeitung, Speicher, Observability und Verantwortung. * [Nach dem Livestream: Aufzeichnung On-Demand bereitstellen](/de/guides/turn-live-video-into-vod.md)\ Verwandeln Sie abgeschlossene Live-Aufzeichnungen in verlässliche On-Demand-Assets, ohne den VOD-Lebenszyklus an den Live-Anbieter zu koppeln. * [Die besten Video-APIs für Produktions-Workloads](/de/guides/best-video-apis-2026.md)\ Vergleichen Sie führende Video-APIs 2026 nach Lebenszyklusverantwortung: Ingest, Verarbeitung, Speicherung, Auslieferung, Wiedergabe, Bearbeitung und Analytics.