Streaming- und VOD-Architektur # So bewerten Sie APIs für Live- und On-Demand-Video Bewerten Sie Live- und On-Demand-Video-APIs nach Ingest, Latenz, Wiedergabe, Verarbeitung, Speicher, Observability und Verantwortung. Veröffentlicht am 11. August 2026 ## Wichtigste Erkenntnisse * Klären Sie, ob das Produkt Live-Ingest, VOD-Verarbeitung, gehostete Wiedergabe, Speicher, Analytics oder alle fünf benötigt. * Vergleichen Sie die Wiederherstellung nach Fehlern und die Observability, nicht nur die API im Idealfall. * Messen Sie, wie leicht Originale und Derivate in eigenem Speicher verbleiben oder dorthin zurückkehren können. Eine „Video-API“ kann Live-Transport, gehostete Wiedergabe, Transkodierung, Asset-Management, Analytics oder einen programmierbaren Workflow bedeuten. Der Anbietervergleich beginnt damit, diese Verantwortlichkeiten zu trennen. ## In diesem Leitfaden 1. [Festlegen, wofür die API verantwortlich sein muss](#video-streaming-api-evaluation-section-1) 2. [Protokolle im Kontext bewerten](#video-streaming-api-evaluation-section-2) 3. [VOD-Verarbeitung und Ausgabequalität prüfen](#video-streaming-api-evaluation-section-3) 4. [Festlegen, wer Speicher, Auslieferung und Wiedergabe kontrolliert](#video-streaming-api-evaluation-section-4) 5. [Sicherheit, Datenschutz und Zugriffskontrolle prüfen](#video-streaming-api-evaluation-section-5) 6. [Asynchronen Status als Produktfunktion behandeln](#video-streaming-api-evaluation-section-6) 7. [Fehlerorientierte Integrationstests durchführen](#video-streaming-api-evaluation-section-7) 8. [Gesamtkosten und vertragliche Grenzen modellieren](#video-streaming-api-evaluation-section-8) 9. [Transloadit an der VOD-Verarbeitungsgrenze einsetzen](#video-streaming-api-evaluation-section-9) ## Worauf es besonders ankommt * Modellieren Sie die Kosten anhand von Quellminuten, Ausgabevarianten, Speicher, Auslieferung und wiederholter Verarbeitung. * Testen Sie einen echten Workflow anhand der aktuellen Dokumentation des Anbieters, bevor Sie eine engere Auswahl treffen. ## Festlegen, wofür die API verantwortlich sein muss Der Begriff Video-API umfasst mehrere unterschiedliche Verantwortlichkeiten: Live-Zuspielung, Echtzeit-Transkodierung, Aufzeichnung, On-Demand-Encoding, adaptive Paketierung, Speicherung, Auslieferung, Wiedergabe, Zugriffskontrolle, Analytics und Asset-Management. Ein Anbieter kann eine schmale Verarbeitungs-API oder eine vollständige gehostete Plattform bereitstellen. Beginnen Sie mit einer Verantwortungsmatrix, die für jede Funktion die Komponente und das zuständige Team benennt. So werden Lücken sichtbar, die eine reine Feature-Checkliste verbergen kann. Trennen Sie erforderliche Fähigkeiten von praktischer Bündelung. Ein Produkt, das nur hochgeladene Lektionen veröffentlicht, benötigt möglicherweise zuverlässige VOD-Verarbeitung und Speicherung, aber keine Live-Zuspielung. Eine interaktive Veranstaltung benötigt dagegen einen spezialisierten Live-Transport, einen Player, Moderation und Aufzeichnungsgarantien, bevor die VOD-Verarbeitung überhaupt beginnt. Entscheiden Sie, welche Daten und Medien portabel bleiben müssen. Eine modulare Architektur bedeutet mehr Integrationsaufwand, kann aber verhindern, dass Verarbeitung, Speicherung, Auslieferung und Darstellung zu einer einzigen untrennbaren Abhängigkeit verschmelzen. ### Lifecycle-Zustände zuerst festlegen Definieren Sie die Zustände hochgeladen, wird eingespielt, live, in Aufzeichnung, wird verarbeitet, in Prüfung, veröffentlicht, gesperrt und gelöscht, bevor Sie API-Antworten vergleichen. ### Verantwortungsgrenzen benennen Jede Aufnahme-, Speicher-, Auslieferungs-, Sicherheits-, Analytics- und Support-Verantwortung sollte einen ausdrücklich benannten Verantwortlichen haben. ## Protokolle im Kontext bewerten Die Protokollunterstützung sollte einem konkreten Abschnitt des Systems zugeordnet werden. RTMP und SRT kommen üblicherweise für die Zuspielung von einem Encoder infrage, WebRTC für interaktive Kommunikation und HLS oder MPEG-DASH für HTTP-basierte Wiedergabe. Ein Protokollname allein sagt nichts über tatsächliche Latenz, Zuverlässigkeit, Skalierung oder Gerätekompatibilität aus. Implementierungsdetails wie Encoder-Einstellungen, Segmentverhalten, CDN-Unterstützung und Player-Puffer bestimmen das resultierende Erlebnis. Wählen Sie die Latenz je nach Interaktion. Eine Keynote ohne Rückkanal verträgt mehr Verzögerung als ein Remote-Interview, eine Auktion oder ein Live-Klassenzimmer. Eine niedrigere Latenz verringert die Toleranz des Systems gegenüber Jitter und kann eine komplexere Auslieferung und Überwachung erfordern. Testen Sie auf repräsentativen Mobilgeräten, Browsern, Unternehmensnetzwerken und schlechten Verbindungen. Erfassen Sie die Glass-to-Glass-Latenz bei aussagekräftigen Perzentilen, statt einen Best-Case-Wert zu akzeptieren, der nur innerhalb einer Komponente eines Anbieters gemessen wurde. ### Zuspielung und Wiedergabe getrennt prüfen Ein Anbieter akzeptiert von Sendern möglicherweise einen anderen Satz von Protokollen, als er an Zuschauer ausliefert. ### Fallback-Verhalten bestätigen Bestimmen Sie, was der Player tut, wenn ein bevorzugter Codec, ein Protokoll, eine Variante oder ein Low-Latency-Modus nicht verfügbar ist. ## VOD-Verarbeitung und Ausgabequalität prüfen Eine VOD-Verarbeitungs-API sollte Quellanalyse, Codec- und Container-Auswahl, Größenänderung, Handhabung der Bildrate, Audiokonfiguration, Trimmen, Thumbnails, Untertitel-Workflows und, falls erforderlich, adaptive Paketierung bereitstellen. Testen Sie mit repräsentativen Quellen, darunter Smartphone-Videos, Bildschirmaufzeichnungen, bewegungsreiches Material, ungewöhnliche Seitenverhältnisse, variable Bildraten, mehrere Audiospuren und fehlerhafte Dateien. Eine saubere Vorführdatei sagt wenig über Produktionsmedien aus. Adaptives Bitraten-Streaming verwendet mehrere Varianten, damit der Player die Qualität an Netzwerk- und Gerätebedingungen anpassen kann. Die Bitratenleiter sollte Quellauflösung, Bewegung, Zielgeräte und erwartete Bandbreite widerspiegeln. Mehr Varianten sind nicht automatisch besser. Jede Ausgabe erhöht Encoding-Zeit, Speicherbedarf, Qualitätssicherungsaufwand und Auslieferungsobjekte. Lehnen Sie Upscaling ab, das lediglich Pixel ohne zusätzliche Quelldetails hinzufügt, und vergleichen Sie die sichtbare Qualität bei vergleichbaren Bitraten, statt sich nur auf die Namen der Voreinstellungen zu verlassen. ### Einen einheitlichen Testkorpus verwenden Führen Sie dieselben Dateien durch jeden Kandidaten, damit Zeitverhalten, Fehler, Metadaten und Ausgabequalität vergleichbar sind. ### Synchronisiertes Umschalten prüfen Adaptive Varianten benötigen kompatibles Timing und ausgerichtete Segmentgrenzen für zuverlässige Übergänge. ## Festlegen, wer Speicher, Auslieferung und Wiedergabe kontrolliert Manche APIs liefern verarbeitete Dateien in einen von Ihnen kontrollierten Speicher zurück, während andere erwarten, dass Assets innerhalb eines gehosteten Mediensystems verbleiben. Prüfen Sie, ob Originale, Varianten, Manifeste, Segmente, Thumbnails, Untertitel und Metadaten exportiert werden können, ohne dass Beziehungen verloren gehen. Bestätigen Sie Aufbewahrungsregeln, Löschverhalten, regionale Platzierung, Backup-Erwartungen und die Zeit, die zur Wiederherstellung einer großen Bibliothek nötig ist. Portabilität zählt vor allem dann, wenn sie getestet wird, bevor eine Migration dringend wird. Auslieferung und Wiedergabe sind vom Encoding getrennte Aspekte. Prüfen Sie CDN-Verhalten, Cache-Keys, Range-Requests, CORS, Content-Types, Invalidierung, signierten Zugriff und Player-Kompatibilität. Adaptive Pakete enthalten relative Referenzen, die beim Verschieben in den Speicher intakt bleiben müssen. Ein Player benötigt außerdem Untertitel, Spurauswahl, Fehlerberichte, Tastatursteuerung und Analytics. Wenn diese Funktionen von unterschiedlichen Anbietern stammen, definieren Sie einen stabilen Asset-Datensatz, der sie verbindet, ohne anbieterspezifische Details in der gesamten Anwendung offenzulegen. ### Einen Export frühzeitig testen Rufen Sie ein vollständiges Asset-Paket ab und spielen Sie es außerhalb der Standardumgebung des Anbieters ab. ### Temporäre Ergebnis-URLs vermeiden Veröffentlichen Sie aus dauerhaftem Speicher und einer bewusst gestalteten Auslieferungsschicht, statt Verarbeitungs-URLs mit unsicherer Aufbewahrung zu nutzen. ## Sicherheit, Datenschutz und Zugriffskontrolle prüfen Die Bewertung sollte API-Authentifizierung, Rotation von Secrets, Zugangsdaten mit begrenzten Rechten, signierte Anfragen, Audit-Logs, Verschlüsselung, regionale Verarbeitung, Aufbewahrung und Löschung abdecken. Browser-Clients sollten keine langlebigen Zugangsdaten für Verarbeitung oder Speicherung erhalten. Verwenden Sie serverseitig generierte, zeitlich begrenzte Autorisierung, wenn ein direkter Upload erforderlich ist. Behandeln Sie hochgeladene Medien als nicht vertrauenswürdige Eingabe, setzen Sie Richtlinien für akzeptierte Dateien und Größen durch und geben Sie keine rohen Anbieterfehler oder sensiblen Metadaten an Betrachter zurück. Die Wiedergabeautorisierung kann signierte URLs, Session-Tokens, Cookies, Domainbeschränkungen oder Berechtigungen auf Anwendungsebene verwenden. Jede Option wirkt sich unterschiedlich auf Widerruf und Caching aus. Kurzlebige URLs verringern die Zeit für Replay-Angriffe, können aber die Cache-Wiederverwendung senken oder bei langen Sitzungen fehlschlagen. Domainbeschränkungen allein belegen keine Zuschaueridentität. Testen Sie die Autorisierung auf der Manifest-, Segment-, Untertitel-, Thumbnail- und Download-Ebene, damit ein scheinbar geschützter Player nicht auf öffentlich zugängliche unterstützende Assets verweist. ### Datenstandorte erfassen Dokumentieren Sie, wo Quelldateien, Derivate, Protokolle, Backups und Analytics-Ereignisse verarbeitet oder aufbewahrt werden. ### Löschung durchgängig verifizieren Das Entfernen eines Anwendungsdatensatzes sollte definiertes Lösch- oder Aufbewahrungsverhalten in Verarbeitungs-, Speicher-, Auslieferungs- und Backup-Systemen auslösen. ## Asynchronen Status als Produktfunktion behandeln Videoverarbeitung erfolgt meist asynchron. Eine nützliche API unterscheidet Upload, Ingest, Verarbeitung, Abschluss der Aufzeichnung, Export und Wiedergabebereitschaft, statt einen einzigen mehrdeutigen Schwebezustand offenzulegen. Statusantworten sollten stabile Kennungen, strukturierte Fehler und ausreichend Ausgabemetadaten enthalten, um ein Problem zu diagnostizieren. Anwendungen benötigen begrenztes Polling oder Abschlussbenachrichtigungen sowie einen Abgleich für Vorgänge, deren erwartetes Ereignis nie eintrifft. Webhook-Konsumenten sollten Signaturen prüfen, wenn der Anbieter dies unterstützt, schnell antworten und längere Arbeit in eine Queue verschieben. Gestalten Sie Handler so, dass sie Duplikate, Wiederholungen und Ereignisse tolerieren, die nach einem neueren Anwendungszustand eintreffen. Speichern Sie den Ereignis- oder Auftragsidentifikator des Anbieters und machen Sie Zustandsänderungen idempotent. Ein geplanter Abgleichsprozess sollte nicht abgeschlossene lokale Datensätze mit dem Status beim Anbieter vergleichen, damit eine verpasste Benachrichtigung ein Asset nicht dauerhaft blockiert. ### Fertig von veröffentlicht trennen Der technische Abschluss der Verarbeitung sollte redaktionelle Prüfungen, die Rechteprüfung sowie Prüfungen zu Barrierefreiheit und Sicherheit nicht umgehen. ### Nützliche Diagnosedaten bewahren Erfassen Sie bereinigte Vorgangskennungen, Phase, Fehlerkategorie, Quelleigenschaften und Wiederholungsverlauf, ohne Zugangsdaten oder private Medien-URLs offenzulegen. ## Fehlerorientierte Integrationstests durchführen Ein Proof of Concept sollte einen realen Workflow abbilden, nicht einen vereinfachten Upload. Testen Sie Encoder-Verbindungsabbrüche, Paketverlust, unvollständige Aufzeichnungen, nicht unterstützte Codecs, fehlerhafte Zeitstempel, doppelte Benachrichtigungen, abgelaufene Download-URLs, nicht verfügbaren Speicher und regionale Serviceeinschränkungen. Beobachten Sie, ob Wiederholungsversuche automatisch, steuerbar, kostspielig oder anfällig für doppelte Ausgaben sind. Bestätigen Sie, wie das Support-Team einen fehlgeschlagenen Vorgang identifizieren und erneut ausführen kann. Messen Sie Upload-Zeit, Verarbeitungsdauer, Zeit bis zur ersten abspielbaren Ausgabe, Ausgabequalität, Speicherübertragung und Wiederherstellungszeit. Wiederholen Sie Tests bei realistischer Nebenläufigkeit, da sich Kontingente und Warteschlangenverhalten oft erst unter Last zeigen. Beziehen Sie Barrierefreiheitsprüfungen für Untertitel und Player-Bedienelemente sowie Sicherheitsprüfungen für Autorisierung und Webhook-Verifizierung ein. Legen Sie Abnahmeschwellenwerte vor dem Testen fest, damit ein poliertes Dashboard fehlende betriebliche Anforderungen nicht überdeckt. ### Deterministische Ausgabenamen verwenden Wiederholungen sollten das beabsichtigte Asset ersetzen oder versionieren, statt unvorhersehbare Duplikate zu erzeugen. ### Support-Nachweise testen Stellen Sie sicher, dass die Ihrem Team verfügbaren Logs und Identifikatoren ausreichen, damit ein Anbieter einen Vorfall untersuchen kann. ## Gesamtkosten und vertragliche Grenzen modellieren Berechnen Sie die Kosten anhand des tatsächlichen Workflows: Quellminuten oder -bytes, jede codierte Variante, KI- oder Untertitelverarbeitung, Aufzeichnung, Speicherung, Anfragen, Egress, CDN-Auslieferung, Analytics und wiederholte Arbeit nach Fehlern oder Bearbeitungen. Modellieren Sie ruhige Phasen und Spitzenereignisse getrennt. Ein niedriger Stückpreis für eine Stufe kann durch verpflichtende Speicherung, Auslieferung, Mindestabnahmen oder eine überdimensionierte adaptive Bitratenleiter aufgewogen werden. Betriebliche Einschränkungen gehören neben die Preisgestaltung. Prüfen Sie Nebenläufigkeitsgrenzen, maximale Dauer und Größe, regionale Verfügbarkeit, Ratenbegrenzungen, Support-Reaktionszeiten, Wartungskommunikation, Serviceziele, Aufbewahrung und Datenexport. Schätzen Sie den Ingenieurs- und Support-Aufwand für Integration, Migrationen, Vorfallreaktion und manuelle Prüfung ein. Halten Sie eine kleine Gruppe repräsentativer Aufgaben regelmäßig am Laufen, damit Preisänderungen, Änderungen an Voreinstellungen oder API-Regressionen vor einem großen Launch entdeckt werden. ### Wiederholungen und Überarbeitungen bepreisen Reale Bibliotheken werden nach fehlgeschlagenen Aufgaben, redaktionellen Änderungen, Untertitelkorrekturen und neuen Ausgabeanforderungen erneut verarbeitet. ### Kosten pro veröffentlichtem Asset erfassen Das kombiniert Verarbeitung, Speicher, Auslieferung und fehlgeschlagene Arbeit sinnvoller als ein einzelner beworbener API-Tarif. ## Transloadit an der VOD-Verarbeitungsgrenze einsetzen Transloadit passt, wenn die Eingabe als Upload, Import oder abgeschlossene Live-Aufzeichnung eintrifft. Es bietet weder Live-Ingest noch einen vollständigen Videoplayer. In einer modularen Architektur kann der Live-Anbieter den Übertragungstransport und die Finalisierung der Aufzeichnung übernehmen, während die Anwendung die finalisierte Datei zur wiederholbaren On-Demand-Verarbeitung an eine Transloadit-Assembly übergibt. Ein Template kann für Varianten Steps für /video/encode definieren, für Posterbilder Steps für /video/thumbs, für Text-, SRT- oder WebVTT-Ausgaben Steps für /speech/transcribe und, wenn Untertitel angehängt oder ins Video eingebrannt werden müssen, Steps für /video/subtitle. Fertige Varianten lassen sich in /video/adaptive bündeln, um HLS-, MPEG-DASH- oder CMAF-Pakete zu erzeugen. Wenn es die Nachfrage nicht rechtfertigt, eine vollständige Bitratenleiter vorab zu codieren, kann der Robot /video/ondemand, derzeit in der Betaphase, HLS-Playlists und -Segmente bei Bedarf für die Auslieferung über das Smart CDN von Transloadit generieren. Speicher-Robots können Ergebnisse exportieren, und der Assembly-Status oder eine signierte Benachrichtigung kann den Abschluss-Workflow der Anwendung steuern. Speicher, Auslieferungsrichtlinie, Player-Auswahl, redaktionelle Prüfung und Live-Betrieb bleiben getrennte Zuständigkeiten. ### Schnittstellen zu Anbietern schmal halten Übersetzen Sie Antworten des Anbieters in ein anwendungseigenes Asset- und Auftragsmodell, damit sich Komponenten unabhängig voneinander ändern lassen. ### Paketpfade validieren Bewahren Sie beim Export adaptiver Ausgaben den relativen Pfad jedes Ergebnisses, damit Manifeste ihre Segmente weiterhin auflösen können. ## Wissenswerte technische Details * Die Ingest-Unterstützung kann RTMP, SRT oder neuere WebRTC-basierte Protokolle umfassen, während die Wiedergabe HLS, DASH oder WebRTC nutzen kann. Protokollnamen allein sagen nichts über Latenz oder Zuverlässigkeit aus. * Eine Bitratenleiter sollte die Quellqualität, die Endgeräte des Publikums und die Netzverteilung widerspiegeln. Mehr Varianten erhöhen die Encoding- und Speicherkosten, ohne die Wiedergabe immer zu verbessern. * Die Zustellung von Webhooks muss als „mindestens einmal“ behandelt werden: Konsumenten benötigen Signaturprüfung, Idempotenz, Toleranz gegenüber der Ereignisreihenfolge und eine Möglichkeit, fehlende Statusänderungen abzugleichen. * Die Wiedergabeautorisierung kann signierte URLs, Tokens, Domain-Beschränkungen oder Anwendungsberechtigungen nutzen, jeweils mit unterschiedlichen Auswirkungen auf Widerruf und Caching. * Status-APIs sollten Eingabe-, Verarbeitungs-, Aufzeichnungs- und Auslieferungszustände getrennt ausweisen, damit eine Anwendung eine funktionierende Übertragung von einer abspielbaren Aufzeichnung unterscheiden kann. * Testen Sie eine API unter Paketverlust, Encoder-Abbruch, doppelten Webhooks, fehlerhaften Eingaben und regionalen Ausfällen, statt sie nur anhand der reibungslos verlaufenden Demo zu bewerten. ## Ein praxisnaher Ansatz 1. 1\ Erstellen Sie eine Verantwortungsmatrix für Aufnahme, Verarbeitung, Speicherung, Wiedergabe, Auslieferung und Analytics. 2. 2\ Führen Sie dieselbe repräsentative Quelle durch jede zu vergleichende Architektur. 3. 3\ Vergleichen Sie Bearbeitungszeit, Ausgabequalität, Wiederherstellung, Integrationsaufwand und variable Gesamtkosten. 4. 4\ Halten Sie Schnittstellen zwischen Anbietern explizit, damit sich eine Komponente ändern lässt, ohne alles neu zu schreiben. Ein vierstufiger Medienworkflow ## Wann Transloadit hilfreich ist Transloadit passt als Verarbeitungsschicht, wenn Dateien über Uploads, Importe oder abgeschlossene Live-Aufzeichnungen eintreffen. Es kann adaptive VOD-Assets, Thumbnails, Untertitel und Exporte erstellen, während Speicher und Auslieferung unter Ihrer Kontrolle bleiben. ## Architekturgrenze Transloadit unterstützt On-Demand-Medienverarbeitung und adaptive Paketierung, jedoch keinen Live-Ingest und keinen vollständigen Videoplayer. Ein Live-Produkt benötigt neben Transloadit einen dedizierten Anbieter für Live-Video. ## Häufig gestellte Fragen ### Brauche ich sowohl eine Live-Video-API als auch eine VOD-Verarbeitungs-API? Ja, wenn das Produkt sowohl in Echtzeit überträgt als auch dauerhafte Aufzeichnungen erstellt, es sei denn, ein Anbieter deckt beide Lebenszyklen ausdrücklich ab. Halten Sie die Zustände auch dann getrennt, wenn ein Anbieter beides liefert, denn ein funktionierender Livestream garantiert nicht, dass seine Aufzeichnung finalisiert oder veröffentlichungsbereit ist. ### Sollte ich HLS oder MPEG-DASH wählen? Treffen Sie die Wahl anhand von Zielplayern, Geräten, Auslieferungsinfrastruktur, Codec-Anforderungen und betrieblicher Erfahrung. Viele Dienste unterstützen beides. Testen Sie das genaue Paket im vorgesehenen Player und CDN, denn Protokollunterstützung allein garantiert keine kompatiblen Manifeste, Untertitel, Autorisierung oder niedrige Latenz. ### Wie kann ich die Ausgabequalität fair vergleichen? Verwenden Sie denselben Quellkorpus, dieselben Zielabmessungen, Codecs und ungefähren Bitraten. Prüfen Sie Bewegung, Verläufe, Text, Gesichter, Audiosynchronisation und den Wechsel zwischen Varianten auf repräsentativen Geräten. Vergleichen Sie außerdem Verarbeitungszeit, Dateigröße, Fehler und die Genauigkeit der Metadaten. ### Wie sollte eine Streaming-API abgesichert werden? Bewahren Sie langlebige Zugangsdaten auf vertrauenswürdigen Servern auf, schränken Sie deren Berechtigungsumfang ein, rotieren Sie sie, verifizieren Sie signierte Benachrichtigungen und validieren Sie jede Eingabe. Schützen Sie Manifeste, Segmente, Untertitel, Thumbnails und Downloads einheitlich. Dokumentieren Sie Aufbewahrung und Löschung über Verarbeitung, Speicher, Auslieferung, Protokolle und Backups hinweg. ### Bietet Transloadit Live-Streaming und einen Videoplayer an? Nein. Transloadit unterstützt dateibasierte Medienverarbeitung und adaptive VOD-Paketierung, und der Robot /video/ondemand, derzeit in der Betaphase, kann HLS-Playlists und -Segmente bei Bedarf für die Auslieferung über das Smart CDN generieren. Ein Live-Produkt benötigt weiterhin einen dedizierten Anbieter für Live-Video, und die Wiedergabe erfordert weiterhin einen geeigneten Player. ## Erstellen Sie den Workflow Entwickeln Sie das Konzept mithilfe der Robot-Dokumentation und funktionsfähiger Demos zu einer getesteten Assembly weiter. * [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 * [Video-CDN-Architektur: Transkodierung, HLS/DASH, Speicher und Caching](/de/guides/video-cdn-architecture.md)\ Entwerfen Sie einen Video-CDN-Pfad über Transkodierung; HLS-, MPEG-DASH- oder CMAF-Paketierung; eigenen Speicher; Caching; Wiedergabe; Observability und Kosten. * [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.