Live-Streaming-Übertragungen

Mit der Vonage Video API Live-Streaming-Funktion können Sie eine Videositzung über HTTP-Live-Streaming (HLS) oder einen RTMP-Stream an ein großes Publikum übertragen.

Es können mehr Clients gleichzeitig einen HLS-Stream ansehen als einen Interaktive Live-Video-Sitzung. So können Sie beispielsweise einem Kunden einen HLS-Stream zur Verfügung stellen, wenn die Sitzung das Limit von 15.000 Verbindungen für interaktive Live-Übertragungen erreicht hat. HLS-Streams unterstützen eine unbegrenzte Anzahl von Zuschauern. RTMP-Streams sind durch die Anzahl der vom RTMP-Anbieter unterstützten Betrachter begrenzt.

Sie können die RTMP-Streaming-Funktion verwenden, um einen Videostream auf einer Plattform bereitzustellen, die RTMP-Streams unterstützt, z. B. YouTube Live oder Facebook.

Auch Clients, die WebRTC nicht unterstützen, können den HLS- oder RTMP-Stream anzeigen.

Eine Übertragung kann bis zu 16 Videostreams aus der Sitzung (und bis zu 50 Audiostreams) enthalten. Wenn die Sitzung mehr als 16 Videostreams gleichzeitig enthält, werden die zusätzlichen Streams nicht in die Sendung aufgenommen.

Ein HLS wird 15 bis 20 Sekunden hinter den Live-Streams in der Sitzung verzögert. Während der anfänglichen Verzögerung ist der Broadcast-Stream nicht verfügbar. Geben Sie die Broadcast-URL nicht an Clients weiter, bis der HLS- oder RTMP-Stream verfügbar ist.

Bei einem RTMP-Stream führt die Vonage-Plattform eine Latenz von etwa 5 Sekunden ein. Jede RTMP-Übertragungsplattform (z. B. YouTube Live oder Facebook) fügt jedoch eine zusätzliche Latenz hinzu, die auf ihrer Verarbeitung des Videos vor der Veröffentlichung beruht.

Die HLS- und RTMP-Streaming-Funktion ist nur für geroutete Sitzungen verfügbar (Sitzungen, die den Vonage Media Router verwenden). Für weitere Informationen siehe Der Vonage Media Router und die Media-Modi.

Die HLS-Wiedergabe wird nicht von allen Browsern unterstützt. Es gibt jedoch eine Reihe von Plugins, wie z. B. Flowplayerdie browserübergreifende Unterstützung bieten (Verwendung von Flash Player in Browsern, die keine direkte HLS-Unterstützung bieten).

Vonage RTMP-Streams haben die folgenden Spezifikationen:

H.264 Baseline, Stufe 3.1, Video-Codec
640x480-Pixel (SD-Querformat), 480x640-Pixel (SD-Hochformat), 1280x720-Pixel (HD-Querformat), 720x1280-Pixel (HD-Hochformat), 1920x1080-Pixel (FHD-Querformat) oder 1080x1920-Pixel (HD-Hochformat), bei 25 Bildern pro Sekunde
2 Mbps konstante Bitrate (CBR), mit einem Keyframe-Intervall von 2 Sekunden
1-Kanal-AAC-Audio mit 128 Kbps und einer Abtastrate von 48 Khz Streams, die von Safari aus veröffentlicht werden, werden in Live-Streaming-Übertragungen nur als Audio angezeigt.

Siehe die Vonage-Preisseite für Einzelheiten zu den Preisen für HLS- und RTMP-Streaming.

Starten und Beenden von Live-Streaming-Übertragungen

Verwenden Sie die Video REST API um das Live-Streaming einer Sitzung zu starten und zu stoppen und um den Status einer Live-Streaming-Übertragung zu überprüfen.

Die HLS- und RTMP-Streams werden automatisch 60 Sekunden, nachdem der letzte Client die Verbindung zur Sitzung getrennt hat, beendet. Außerdem gibt es eine Standard-Höchstdauer von 4 Stunden (14.400 Sekunden) für jeden HLS- und RTMP-Stream (die Live-Stream-Übertragung wird automatisch beendet, wenn diese Dauer erreicht ist). Sie können die maximale Dauer für die Übertragung ändern, indem Sie die Eigenschaft maxDuration beim Aufruf der Funktion Startsendung REST-Methode. Sie können die maximale Dauer auf 60 Sekunden bis 10 Stunden (36.000 Sekunden) einstellen.

Anmerkung: Live-Streaming-Übertragungen enden während der Serverrotation für die Sitzung. Sie können eine Übertragung als Reaktion auf Benachrichtigungsereignisse zur Serverrotation neu starten. Siehe Server-Rotation und Sitzungsmigration.

Sie können die maximale Bitrate für die Übertragung begrenzen, indem Sie den Wert maxBitrate Eigenschaft beim Aufruf der Startsendung REST-Methode. Sie können die maximale Bitrate auf einen Wert zwischen 100.000 und 6.000.000 Bits pro Sekunde einstellen.

Konfigurieren des Video-Layouts für die Live-Streaming-Übertragungen

Wenn Sie die Live-Streaming-Funktion verwenden, können Sie das Layout der Videos im HLS- oder RTMP-Stream anpassen.

Standardmäßig ordnet die Live-Streaming-Funktion die Videos der Sitzung in einem Kachel-Layout im zusammengestellten HLS- oder RTMP-Video an. Das Layout basiert auf der Anzahl der Videos in der Sitzung. Im Folgenden wird beispielsweise das Layout für 1, 2, 4 oder 5 Streams in einer Sitzung dargestellt:

Dies ist das so genannte "Best Fit"-Layout. Alternativ dazu können Sie aus einer Reihe anderer vordefinierter Layouts wählen. Bei den anderen Layouts weisen Sie jedem Videostream einen Klassennamen zu, um festzulegen, wie er im Layout erscheinen soll. (Siehe Vordefinierte Layout-Typen.)

Sie können auch Ihre eigenen benutzerdefinierten Layouts mit CSS definieren. Siehe Definieren benutzerdefinierter Layouts.

Standardmäßig ist das Sendevideo 640x480 Pixel groß (SD-Querformat, Seitenverhältnis 4:3). Die einzelnen Videos werden in Container-Rechtecken innerhalb des zusammengesetzten Videos angeordnet. Standardmäßig wird das Video mit der CSS-Eigenschaft "object-fit" gezeichnet, die auf "contain" eingestellt ist. Die folgende Abbildung zeigt zum Beispiel ein Best-Fit-Layout mit zwei SD-Querformatvideos (4:3) (1 und 4) und zwei HD-Querformatvideos (16:9) (2 und 3):

Sie können dieses Verhalten ändern, indem Sie benutzerdefinierte Layouts.

Sie können einen Broadcast-Stream auch so einstellen, dass er eine Auflösung von 480x640 (SD-Hochformat, 3:4-Seitenverhältnis), 1280x720 (HD-Querformat, 16:9-Seitenverhältnis), 720x1280 (HD-Hochformat, 9:16-Seitenverhältnis), 1920x1080 (FHD-Querformat, 16:9-Seitenverhältnis), 1080x1920 (FHD-Hochformat, 9:16-Seitenverhältnis) verwendet, wenn Sie den Startsende-Endpunkt des Vonage REST API. Sie können ein Hochformat für Sendungen verwenden, die Videostreams von mobilen Geräten enthalten (die oft das Hochformat verwenden).

Festlegen des anfänglichen Layouttyps

Wenn Sie die Live-Streaming-Übertragung für eine Sitzung starten, verwenden Sie die REST-APIkönnen Sie optional den anfänglichen Layouttyp angeben.

Setzen Sie die Content-Type zu "application/json" und setzen Sie die im Layout-Typ als Eigenschaft der in der POST-Anforderung gesendeten JSON-Daten.

{
  "sessionId": "2_MX44NTQ1MTF--bm1kTGQ0RjVHeGNQZE51VG5scGNzdVl0flB-",
  "layout": {
    "type": "pip"
  }
}

Wenn Sie ein benutzerdefiniertes Layout verwenden (siehe Definieren benutzerdefinierter Layouts), setzen Sie die type Eigenschaft zu "custom" und geben Sie das Stylesheet als zusätzliche Eigenschaft an - stylesheet:

{
  "sessionId": "2_MX44NTQ1MTF--bm1kTGQ0RjVHeGNQZE51VG5scGNzdVl0flB-",
  "layout": {
    "type": "custom",
    "stylesheet": "stream.instructor {position: absolute; width: 100%;  height:50%;}"
  }
}

Sie können auch einen Layouttyp angeben, der verwendet werden soll, wenn ein Screen-Sharing-Stream in der Sitzung vorhanden ist, indem Sie die Eigenschaft screenshareType der Layout-Eigenschaft festlegen (siehe Layouts für die gemeinsame Bildschirmnutzung):

{
  "sessionId": "2_MX44NTQ1MTF--bm1kTGQ0RjVHeGNQZE51VG5scGNzdVl0flB-",
  "layout": {
    "type": "bestFit",
    "screenshareType": "pip"
  },
  "name" : "archive_name",
  "outputMode" : "composed"
}

Wenn Sie einen ungültigen Typ angeben, gibt die Anfrage einen 400-Fehler-Antwortcode zurück.

Wenn Sie keinen anfänglichen Layouttyp angeben, verwendet der HLS- oder RTMP-Stream den am besten geeigneten Layouttyp. Wenn Sie einen anderen Layout-Typ angeben, müssen Sie die entsprechenden Layout-Klassen für Streams in der Sitzung anwenden (siehe Zuweisung von Layoutklassen zu Streams).

Siehe Vordefinierte Layout-Typen.

Dynamische Änderung des Layouttyps

Dynamische Änderung des Layout-Typs während einer Live-Streaming-Übertragung Sie können den Layout-Typ dynamisch ändern, indem Sie die Funktion /broadcast/layout REST-Endpunkt.

Setzen Sie die Content-Type zu "application/json" und fügen Sie den Layouttyp als Eigenschaft der JSON-Daten in die PUT-Anforderung ein:

{
  "type": "pip"
}

Wenn Sie ein benutzerdefiniertes Layout verwenden (siehe Definieren benutzerdefinierter Layouts) setzen die type Eigenschaft zu "custom" und geben Sie das Stylesheet als zusätzliche Eigenschaft an - stylesheet:

{
  "type": "custom",
  "stylesheet": "stream.instructor {position: absolute; width: 100%;  height:50%;}"
}

Sie können auch einen Layouttyp angeben, der verwendet werden soll, wenn ein Screen-Sharing-Stream in der Sitzung vorhanden ist, indem Sie die Eigenschaft screenshareType festlegen (siehe Layouts für die gemeinsame Bildschirmnutzung):

{
  "type": "bestFit",
  "screenshareType": "pip"
}

Wenn Sie einen ungültigen Typ angeben, gibt die Anfrage einen 400-Fehler-Antwortcode zurück.

Wenn Sie einen anderen Layouttyp als den Standard-Layouttyp Best Fit angeben, müssen Sie die entsprechenden Layoutklassen für Streams in der Sitzung anwenden (siehe Zuweisung von Layoutklassen zu Streams).

Auswahl von Streams für eine Live-Streaming-Übertragung

Wenn Sie eine Live-Streaming-Übertragung starten, können Sie mit der Einstellung streamMode zu "manual"können Sie die Streams auswählen, die in die Übertragung einbezogen werden sollen. Sie können während der Übertragung Streams hinzufügen und entfernen. Außerdem können Sie festlegen, ob die Übertragung das Audio oder das Video eines Streams (oder beides) enthalten soll. Siehe die Video REST API.

Aktivieren der DVR-Funktionalität in HLS-Übertragungen

HLS-Sendungen unterstützen die DVR-Funktionalität, mit der Benutzer die Sendungen zurückspulen, anhalten und fortsetzen können (in Playern, die DVR unterstützen). Sie können die dvr Option zu true wenn Sie eine Live-Streaming-Übertragung starten.

Wenn DVR aktiviert ist, enthält die HLS-URL eine ?DVR Abfragezeichenfolge an das Ende angehängt.

Die DVR-Funktion bietet ein zweistündiges Zeitfenster für die Wiedergabe von Sendeinhalten. Während die Sendung läuft, können Sie jeden beliebigen Punkt der Sendung bis zu zwei Stunden vor der aktuellen Zeit wiedergeben (und zurückspulen). Die DVR-Aufnahme ist zwei Stunden nach Beendigung der Sendung nicht mehr verfügbar.

Verwendung von HLS-Zeitstempel-Metadaten zur Synchronisierung von Ereignissen

Das Manifest des HTTP-Livestreams enthält eine EXT-X-PROGRAM-DATE-TIME Header, der auf den Zeitstempel des Echtzeitbeginns der Erfassung des Streaming-Segments gesetzt wird. Dies wird in der Datei Spezifikation für HTTP-Live-Streaming. Diese wird auf einen ISO 8601:2004 Datum/Uhrzeit, in UTC.

Die Kopfzeile sieht dann zum Beispiel so aus:

#EXT-X-PROGRAM-DATE-TIME:2021-09-02T11:45:00.810+00:00

Mit diesen Zeitstempeln können Sie Ereignisse in Client-Anwendungen synchronisieren, um die Verzögerung im HLS-Stream zu berücksichtigen. Wenn Sie beispielsweise einem Client ein Ereignis zur Anzeige eines Emojis zu einem bestimmten Zeitpunkt im Videostream senden möchten, kann der Client den Zeitstempel verwenden, um die Anzeige des Emojis entsprechend der Verzögerung des empfangenen Streams zu verzögern.

HLS-Übertragungen mit niedriger Latenz

Um eine HLS-Übertragung so einzustellen, dass sie den Modus mit niedriger Latenz unterstützt, setzen Sie den low-latency Option zu true wenn Start einer Live-Streaming-Übertragung.

Einige HLS-Player unterstützen den Modus mit niedriger Latenz nicht.

Diese Funktion ist nicht kompatibel mit DVR-HLS-Übertragungen.

Gleichzeitige Sendungen

Um mehrere Live-Streaming-Übertragungen für dieselbe Sitzung gleichzeitig zu starten, setzen Sie den multiBroadcastTag beim Starten jeder Live-Streaming-Übertragung. Sie müssen diese Option auf eine eindeutige Zeichenkette für jede gleichzeitige Übertragung einer laufenden Sitzung einstellen.

Obwohl Sie mehrere RTMP-Streams angeben können, wenn Start einer Live-Streaming-Übertragungverwenden sie alle dieselben Optionen (z. B. die zugewiesenen Streams und das Layout). Wenn Sie jedoch gleichzeitige Übertragungen starten (durch mehrfachen Aufruf der REST-Methode, mit der multiBroadcastTag Option) können Sie verschiedene Layouts verwenden und den einzelnen gleichzeitigen Sendungen unterschiedliche Streams zuweisen.

Reine Audio- und Videoübertragungen

Wenn Sie eine Live-Streaming-Übertragung mit der Funktion OpenTok REST API, können Sie angeben, ob es Audio, Video oder beides enthalten soll. (Siehe die hasAudio und hasVideo Optionen). Standardmäßig wird beides gesendet.

Anmerkung: RTMP-Streams, die nur mit Audio übertragen werden, enthalten Video mit schwarzen 160x120 Frames. Einige Endpunkte, wie YouTube und Facebook, lehnen reine Audio-RTMP-Streams ab.

Informationen über Live-Streaming-Sendungen erhalten

Verwenden Sie die Server-SDKs oder REST-API um Informationen über eine Live-Streaming-Sendung zu erhalten oder um Live-Streaming-Sendungen aufzulisten.

Überwachung von Statusänderungen bei Live-Streaming-Übertragungen

Sie können eine Callback-URL (Webhook) registrieren, um Benachrichtigungen über Statusänderungen für die Live-Streaming-Übertragungen eines Projekts zu erhalten. Live-Streaming-Übertragungen zu erhalten. Der Status einer Live-Streaming-Übertragung wird auf ether gesetzt "started" oder "stopped".

So registrieren Sie einen Broadcast-Callback für ein Projekt:

Melden Sie sich bei Ihrem Vonage Video API Account.
Wählen Sie im linken Menü den gewünschten Account aus (wenn Sie mehrere Accounts haben).
Wählen Sie im linken Menü die Registerkarte Applications und dann das Projekt, für das Sie einen sicheren Rückruf registrieren möchten.
Scrollen Sie nach unten zu Projekt-Einstellungen. Klicken Sie auf die bearbeiten Symbol, schalten Sie die Gesicherter Rückruf Schieberegler, und klicken Sie auf den Speichern Sie Taste.

Derzeit müssen Sie gesicherte Rückrufe aktivieren, um einen Rückruf für die Broadcast-Überwachung festzulegen. Wenn Sie sichere Rückrufe deaktivieren, wird jeder von Ihnen festgelegte Broadcast-Rückruf deaktiviert.

Suchen Sie die Broadcast-Überwachung Abschnitt und klicken Sie auf den Konfigurieren Sie Taste.
Geben Sie die Callback-URL und (optional) ein Signaturgeheimnis an.

Weitere Informationen über sichere Rückrufe finden Sie unter diese Seite.

Wenn sich der Status einer Sendung ändert, sendet der Server HTTP-POST-Anforderungen an die von Ihnen angegebene URL. Der Content-Type für die Anfrage ist application/json. Die Daten der Anfrage sind ein JSON-Objekt der folgenden Form:

{
  "id": "1748b707-0a81-464c-9759-c46ad10d3734",
  "sessionId": "2_MX4xMDBfjE0Mzc2NzY1NDgwMTJ-TjMzfn4",
  "applicationId": 100,
  "createdAt": 1437676551000,
  "updatedAt": 1437676551000,
  "event": "broadcast",
  "group": "status",
  "resolution": "640x480",
  "streamMode" : "auto",
  "streams" : [],
  "broadcastUrls": {
    "hls" : "http://server/fakepath/playlist.m3u8",
    "hlsStatus": "live",
    "rtmp": {
      "foo": {
        "serverUrl": "rtmps://myfooserver:443/myfooapp",
        "streamName": "myfoostream",
        "status": "live"
      },
      "bar": {
        "serverUrl": "rtmp://mybarserver:443/mybarapp",
        "streamName": "mybarstream",
        "status": "live"
      }
    }
  },
  "settings": {
    "hls": {
      "dvr": false,
      "lowLatency": false
    }
  },
  "status": "started"
}

Das JSON-Objekt enthält die folgenden Eigenschaften:

id - Die eindeutige ID für die Sendung.
sessionId - Die Video API Sitzungs-ID.
applicationId - Ihre Video API-Projekt-ID.
group - Diese ist eingestellt auf "broadcast".
event - Diese ist eingestellt auf "status".
createdAt - Der Zeitpunkt des Beginns der Übertragung, ausgedrückt in Millisekunden seit der Unix-Epoche (1. Januar 1970, 00:00:00 UTC).
updatedAt - Bei dieser GET-Methode stimmt dieser Zeitstempel mit dem Zeitstempel createdAt überein.
resolution - Die Auflösung der Sendung (entweder "640x480", "1280x720", "1920x1080", "480x640", "720x1280", oder "1080x1920").
status - Der Status der Sendung: entweder "started", "stopped", oder "failed". Für eine "failed" Status, prüfen Sie die reason Eigenschaft des Ereignisses für Details.
reason - Bei einer Sendung mit dem status eingestellt auf "failed"enthält diese Eigenschaft "Internal server failure".
broadcastUrls - Einzelheiten zu den HLS- und RTMP-Übertragungsströmen.

Bei einem HLS-Stream wird die URL als hls Eigentum. Siehe die Vonage Live-Streaming Entwicklerhandbuch für weitere Informationen über die Verwendung dieser URL. Die hlsStatus auf eine der folgenden Eigenschaften eingestellt ist:
- "connecting" - Der Vonage-Server ist gerade dabei, die Transcoder zu starten. Dies ist der Ausgangszustand.
- "ready" - Der Vonage-Server wurde erfolgreich initialisiert, aber das CDN konsumiert keine Medien.
- "live" - Der Vonage-Server wurde erfolgreich initialisiert und das CDN konsumiert Medien.
- "ended" - Der Quellstream wurde beendet. Wenn DVR aktiviert ist und voraufgezeichnete Medien angefordert werden, wechselt der Status zu "live".
- "error" - Es liegt ein Fehler in der Vonage-Plattform vor.
Für jeden RTMP-Stream werden die URL des RTMP-Servers und der Stream-Name sowie der Status des RTMP-Streams angegeben.
- status - Der Status des RTMP-Streams. Diese Eigenschaft wird auf einen der folgenden Werte gesetzt:
  - connecting - Die Vonage-Plattform stellt gerade eine Verbindung mit dem entfernten RTMP-Server her. Dies ist der anfängliche Status, und es ist der Status, wenn Sie beginnen, wenn keine Streams in der Sitzung veröffentlicht sind. Er wechselt zu "live", wenn es Streams gibt (oder er wechselt zu einem der anderen Zustände).
  - live - Die Vonage-Plattform hat sich erfolgreich mit dem entfernten RTMP-Server verbunden, und die Medien werden gestreamt.
  - offline - Die Vonage Plattform konnte sich nicht mit dem entfernten RTMP-Server verbinden. Dies ist auf einen nicht erreichbaren Server oder einen Fehler im RTMP-Handshake zurückzuführen. Zu den Ursachen gehören abgelehnte RTMP-Verbindungen, nicht vorhandene RTMP-Applikationen, abgelehnte Stream-Namen, Authentifizierungsfehler usw. Überprüfen Sie, ob der Server online ist und ob Sie die richtige Server-URL und den richtigen Streamnamen angegeben haben.
  - error - Es liegt ein Fehler in der Vonage-Plattform vor.
- serverUrl - Die URL des RTMP-Servers.
- streamName - Der Name des RTMP-Streams.
settings - Weitere Einzelheiten zum HLS-Übertragungsstrom. Diese properties Objekt enthält ein hls mit den folgenden Eigenschaften:
- dvr - Ob DVR-Funktionalität ist für diese Sendung aktiviert.
- lowLatency - Ob Low-Latency-Modus für den HLS-Stream aktiviert ist.
multiBroadcastTag - Der eindeutige Tag für gleichzeitige Übertragungen (falls einer festgelegt wurde).
streamMode - ob alle Streams in die Übertragung einbezogen werden ("auto") oder Sie wählen Streams aus, die in die Übertragung einbezogen werden sollen ("manual"). Siehe Auswahl von Streams für eine Live-Streaming-Übertragung.
streams - Ein Array von Objekten, die den Streams entsprechen, die gerade übertragen werden. Dies wird nur für eine Übertragung mit der Option status eingestellt auf "started" und die streamMode eingestellt auf "manual". Jedes Objekt im Array enthält die folgenden Eigenschaften:
- streamId - Die Stream-ID des in der Übertragung enthaltenen Streams.
- hasAudio - Ob der Ton des Streams in der Übertragung enthalten ist.
- hasVideo - Ob das Video des Streams in der Sendung enthalten ist.

Bekannte Probleme mit der Vonage Live-Streaming-Übertragungsfunktion

Bei der Live-Streaming-Übertragungsfunktion gibt es die folgenden bekannten Probleme:

Wenn Sie eine Live-Streaming-Übertragung stoppen, werden die letzten 5 Sekunden (vor dem Stoppen der Übertragung) des Inhalts der Vonage-Sitzung aus dem Übertragungsstrom entfernt.

Navigation