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.

Diese Seite enthält die folgenden Abschnitte:

Es können mehr Clients gleichzeitig einen HLS-Stream ansehen als einen OpenTok – interaktive Live-Videositzung. Beispielsweise können Sie einem Client einen HLS-Stream bereitstellen, wenn die OpenTok-Sitzung das Limit von 15.000 Verbindungen für interaktive Live-Übertragungen mit OpenTok erreicht hat. HLS-Streams unterstützen eine unbegrenzte Anzahl von Zuschauern. RTMP-Streams sind durch die Anzahl der vom RTMP-Anbieter unterstützten Zuschauer begrenzt.

Mit der RTMP-Streaming-Funktion können Sie einen Videostream an eine Plattform übertragen, die RTMP-Streams unterstützt, wie beispielsweise 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 umfassen (sowie bis zu 50 Audiostreams). Wenn die Sitzung mehr als 16 Videostreams gleichzeitig umfasst, werden die zusätzlichen Streams nicht in die Übertragung einbezogen.

Ein HLS-Stream hat in der OpenTok-Sitzung eine Verzögerung von 15 bis 20 Sekunden gegenüber den Live-Streams; Low-Latency-HLS (LL-HLS) hat eine Verzögerung von 4 bis 6 Sekunden gegenüber den Live-Streams. Während der anfänglichen Verzögerung ist der Broadcast-Stream nicht verfügbar. Geben Sie die Broadcast-URL erst dann an Clients weiter, wenn der HLS- oder RTMP-Stream verfügbar ist.

Eine EXT-X-ENDLIST Das Tag wird am Ende einer HLS-Übertragung in die Medien-Wiedergabelisten eingefügt (damit Player-Applications das Ende des Streams erkennen können).

Bei einem RTMP-Stream verursacht die OpenTok-Plattform eine Latenz von etwa 5 Sekunden. Allerdings fügt jede RTMP-Auslieferungsplattform (wie beispielsweise YouTube Live oder Facebook) zusätzliche Latenz hinzu, die sich aus der Verarbeitung des Videos vor dessen Veröffentlichung ergibt.

Die HLS- und RTMP-Streaming-Funktion ist nur für geroutete Sitzungen verfügbar (Sitzungen, die den OpenTok Media Router verwenden). Weitere Informationen finden Sie unter Der OpenTok Media Router und die Medien- Modi.

Die HLS-Wiedergabe wird von den meisten modernen Browsern nativ unterstützt. Für Umgebungen, die keine native Unterstützung bieten, können Plugins wie Flowplayer kann verwendet werden, um die Kompatibilität mit anderen Browsern zu gewährleisten.

OpenTok-RTMP-Streams weisen die folgenden Spezifikationen auf:

  • 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 (FHD-Hochformat), bei 25 Bildern pro Sekunde
  • Video-Bitrate
    • 2 Mbit/s konstante Bitrate (CBR) bis zu einer HD-Auflösung (720p) mit einem Keyframe-Intervall von 2 Sekunden
    • 4 Mbit/s konstante Bitrate (CBR) für eine Auflösung von FHD (1080p) mit einem Keyframe-Intervall von 2 Sekunden
  • 1-Kanal-AAC-Audio mit 128 kbit/s und einer Abtastrate von 48 kHz

Sie können die maximale Bitrate für die Übertragung begrenzen, indem Sie die maxBitrate Eigenschaft beim Aufruf der REST-Methode „start broadcast“.

OpenTok-HLS-Streams weisen die folgenden Spezifikationen auf:

  • 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

  • Qualitätsstufen:
    Auflösung Qualitätsstufen Audio-Bitrate HLS-Max-Layer-Bitrate
    VGA 3 128 kbit/s 1 Mbit/s
    HD (720p) 4 128 kbit/s 2 Mbit/s
    FHD (1080p) 5 128 kbit/s 4 Mbit/s

  • 1-Kanal-AAC-Audio mit 128 kbit/s und einer Abtastrate von 48 kHz

Siehe die OpenTok-Preisseite Weitere Informationen zu den Preisen für HLS- und RTMP-Streaming.

Starten und Beenden von Live-Streaming-Übertragungen

Verwenden Sie die OpenTok-REST-API, um Start und stoppen Live-Übertragung einer Sitzung sowie den Status prüfen einer Live-Streaming-Übertragung.

Die HLS- und RTMP-Streams werden automatisch 60 Sekunden nach der Trennung des letzten Clients von der Sitzung beendet. Außerdem gilt für jeden HLS- und RTMP-Stream eine standardmäßige maximale Dauer von 4 Stunden (14.400 Sekunden) (die Live-Übertragung wird automatisch beendet, sobald diese Dauer erreicht ist). Sie können die maximale Dauer der Übertragung ändern, indem Sie die maxDuration Eigenschaft beim Aufruf der Startsendung REST-Methode. Sie können die maximale Dauer auf 60 Sekunden bis 10 Stunden (36.000 Sekunden) festlegen.

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.

Konfiguration des Video-Layouts für OpenTok-Live-Streaming-Übertragungen

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

Standardmäßig ordnet die OpenTok-Live-Streaming-Funktion die Videos aus der OpenTok-Sitzung in einem Kachel-Layout im zusammengesetzten HLS- oder RTMP-Video an. Das Layout richtet sich nach der Anzahl der Videos in der Sitzung. Die folgende Abbildung veranschaulicht beispielsweise das Layout bei 1, 2, 4 oder 5 Streams in einer Sitzung:

Dies wird als „Best-Fit“-Layout bezeichnet. Alternativ können Sie aus einer Reihe weiterer vordefinierter Layouts wählen. Bei den anderen Layouts weisen Sie jedem OpenTok-Videostream einen Klassennamen zu, um festzulegen, wie er im Layout dargestellt werden soll. (Siehe Vordefinierte Layouttypen.)

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

Standardmäßig hat das Broadcast-Video eine Auflösung von 640 × 480 Pixel (SD im Querformat, Seitenverhältnis 4:3). Die einzelnen OpenTok-Videos werden in rechteckigen Containern innerhalb des zusammengesetzten Videos angeordnet. Standardmäßig wird das Video mit dem CSS-Befehl object-fit Eigenschaft eingestellt auf contain. Die folgende Abbildung zeigt beispielsweise ein optimal angepasstes Layout mit zwei SD-Videos im Querformat (4:3) (1 und 4) und zwei HD-Videos im Querformat (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 im Hochformat, Seitenverhältnis 3:4), 1280x720 (HD im Querformat, Seitenverhältnis 16:9), 720×1280 (HD im Hochformat, Seitenverhältnis 9:16), 1920×1080 (FHD im Querformat, Seitenverhältnis 16:9) oder 1080×1920 (FHD im Hochformat, Seitenverhältnis 9:16) verwenden soll, wenn Sie die Startsendung Methode der OpenTok REST-API. Für Übertragungen, die Videostreams von Mobilgeräten enthalten (die häufig das Hochformat verwenden), empfiehlt es sich, das Hochformat zu verwenden.

Festlegen des anfänglichen Layouttyps

Wenn Sie die Live-Übertragung einer Sitzung starten, Mithilfe der OpenTok-REST-API können Sie optional den anfänglichen Layout-Typ festlegen.

Setzen Sie die Content-Type zu "application/json" und legen Sie den Layouttyp als Eigenschaft der JSON-Daten fest, die in der POST-Anfrage gesendet werden.

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

Wenn Sie ein benutzerdefiniertes Layout verwenden (siehe Definieren von benutzerdefinierten Layouts), stelle die type Eigenschaft zu "custom" und das Stylesheet als zusätzliche Eigenschaft übergeben — stylesheet:

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

Sie können außerdem einen Layouttyp festlegen, der verwendet werden soll, wenn in der Sitzung ein Bildschirmfreigabe-Stream vorliegt, indem Sie die screenshareType Eigenschaft der layout Eigenschaft (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.

Sie können den anfänglichen Layout-Typ auch beim Starten einer Übertragung mithilfe der OpenTok-Server-SDKs festlegen:

Wenn Sie keinen anfänglichen Layout-Typ angeben, verwendet der HLS- oder RTMP-Stream den am besten geeigneten Layout-Typ. Wenn Sie einen anderen Layout-Typ angeben, stellen Sie sicher, dass Sie die entsprechenden Layout-Klassen für die Streams in der OpenTok-Sitzung anwenden (siehe Zuordnung von Layout-Klassen zu OpenTok- Streams).

Siehe Vordefinierte Layouttypen.

Dynamische Änderung des Layout-Typs während einer Live-Streaming-Übertragung

Sie können den Layouttyp dynamisch ändern, indem Sie die OpenTok-Funktion aufrufen. /broadcast/layout REST-API.

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

{
  "type": "pip"
}

Wenn Sie ein benutzerdefiniertes Layout verwenden (siehe Definieren von benutzerdefinierten 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 außerdem einen Layouttyp festlegen, der verwendet werden soll, wenn in der Sitzung ein Bildschirmfreigabe-Stream vorliegt, indem Sie die screenshareType Eigenschaft (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.

Sie können den Layout-Typ auch mithilfe der OpenTok-Server-SDKs ändern:

Wenn Sie einen anderen Layouttyp als den Standardtyp „Best Fit“ festlegen, achten Sie darauf, die entsprechenden Layoutklassen für die Streams in der OpenTok-Sitzung anzuwenden (siehe Zuordnung von Layout-Klassen zu OpenTok-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 auswählen, welche Streams in die Übertragung einbezogen werden sollen. Sie können während der Übertragung Streams hinzufügen oder entfernen. Außerdem können Sie festlegen, ob die Übertragung den Audio- oder den Videostream (oder beides) eines Streams enthalten soll. Siehe Eine Live-Streaming-Übertragung starten und Auswahl von Streams für eine Live-Streaming-Übertragung.

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

HLS-Übertragungen unterstützen die DVR-Funktion, mit der Nutzer die Übertragungen zurückspulen, anhalten und fortsetzen können (in Playern, die DVR unterstützen). Sie können die dvr Option zu true wenn Start einer Live-Streaming-Übertragung.

Wenn DVR aktiviert ist, wird die HLS-URL um den Abfrageparameter „?DVR“ am Ende ergänzt.

Die DVR-Funktion bietet ein Zeitfenster von zwei Stunden für die Wiedergabe von Sendungsinhalten. Während der Sendung können Sie jeden beliebigen Zeitpunkt der Sendung bis zu zwei Stunden vor dem aktuellen Zeitpunkt wiedergeben (und zurückspulen). Die DVR-Aufzeichnung 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 Echtzeit-Startzeitpunkts der Aufzeichnung des Streaming-Segments gesetzt ist. Dies ist definiert in der Spezifikation für HTTP-Live-Streaming. Dies ist auf einen ISO 8601:2004 Datums-/Zeitwert 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-Applications synchronisieren, um die Verzögerung im HLS-Stream zu berücksichtigen. Wenn Sie beispielsweise einem Client ein Ereignis senden möchten, um ein Emoji zu einem bestimmten Zeitpunkt im Videostream anzuzeigen, 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, legen Sie die multiBroadcastTag Option, wenn zu Beginn jeder Live-Übertragung. Sie müssen hierfür für jede gleichzeitige Übertragung einer laufenden Sitzung eine eindeutige Zeichenfolge festlegen.

Obwohl Sie beim Starten einer Live-Streaming-Übertragung mehrere RTMP-Streams angeben können, werden für alle dieselben Optionen verwendet (z. B. die zugewiesenen Streams und das Layout). Wenn Sie jedoch gleichzeitige Übertragungen starten (indem Sie die REST-Methode mehrmals aufrufen, mit dem multiBroadcastTag (Optionen-Set) können Sie verschiedene Layouts verwenden und jeder gleichzeitigen Übertragung unterschiedliche Streams zuweisen.

Reine Audio- und Videoübertragungen

Wenn Sie eine Live-Übertragung über die 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: Reine Audioübertragungen enthalten in RTMP-Streams Videobilder mit schwarzen Rahmen im Format 160×120. Einige Endpunkte, wie beispielsweise YouTube und Facebook, lehnen reine Audio-RTMP-Streams ab.

Informationen über Live-Streaming-Sendungen erhalten

Verwenden Sie die OpenTok-REST-API, um Informationen einholen über eine Live-Streaming-Übertragung oder um Liste Live-Streaming-Übertragungen. Oder nutzen Sie die OpenTok-Server-SDKs:

Ü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:

  1. Melden Sie sich bei Ihrem Vonage Video API Account.

  2. Wählen Sie im linken Menü den gewünschten Account aus (wenn Sie mehrere Accounts haben).

  3. Wählen Sie im Menü auf der linken Seite das Projekt aus, für das Sie einen sicheren Callback registrieren möchten.

  4. Suchen Sie die Überwachung von Rundfunkübertragungen Abschnitt und klicken Sie auf den Konfigurieren Sie Taste.

  5. 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",
  "projectId": 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.

  • projectId - 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 — Für eine Sendung mit dem status eingestellt auf "failed", enthält diese Eigenschaft den Wert „Interner Serverfehler“.

  • broadcastUrls - Einzelheiten zu den HLS- und RTMP-Übertragungsströmen.

    Bei einem HLS-Stream wird die URL als hls Eigentum. Siehe die OpenTok-Entwicklerhandbuch für Live-Streaming für weitere Informationen über die Verwendung dieser URL. Die hlsStatus auf eine der folgenden Eigenschaften eingestellt ist:

  • "connecting" — Der OpenTok-Server ist gerade dabei, die Transcoder zu starten. Dies ist der Ausgangszustand.
  • "ready" — Der OpenTok-Server wurde erfolgreich initialisiert, aber das CDN ruft keine Medien ab.
  • "live" — Der OpenTok-Server wurde erfolgreich initialisiert, und das CDN ruft Medien ab.
  • "ended" - Der Quellstream wurde beendet. Wenn DVR aktiviert ist und voraufgezeichnete Medien angefordert werden, wechselt der Status zu "live".
  • "error" — Auf der OpenTok-Plattform ist ein Fehler aufgetreten.

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 OpenTok-Plattform stellt gerade eine Verbindung zum externen RTMP-Server her. Dies ist der Ausgangszustand, der angezeigt wird, wenn Sie die Sitzung starten und noch keine Streams veröffentlicht wurden. Der Status wechselt zu „live“, sobald Streams vorhanden sind (oder zu einem der anderen Zustände).
    • live — Die OpenTok-Plattform hat erfolgreich eine Verbindung zum externen RTMP-Server hergestellt, und die Medien werden gestreamt.
    • offline — Die OpenTok-Plattform konnte keine Verbindung zum entfernten RTMP-Server herstellen. Dies liegt an einem nicht erreichbaren Server oder einem Fehler beim RTMP-Handshake. Mögliche Ursachen sind abgelehnte RTMP-Verbindungen, nicht vorhandene RTMP-Applications, abgelehnte Stream-Namen, Authentifizierungsfehler usw. Überprüfen Sie, ob der Server online ist und ob Sie die richtige Server-URL und den richtigen Stream-Namen angegeben haben.
    • error — Auf der OpenTok-Plattform ist ein Fehler aufgetreten.

  • 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:
  • 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 Live-Streaming-Funktion von OpenTok

Die Live-Streaming-Funktion weist das folgende bekannte Problem auf:

  • Wenn Sie eine Live-Streaming-Übertragung beenden, werden die letzten 5 Sekunden (vor Beendigung der Übertragung) des Inhalts aus der OpenTok-Sitzung aus dem Übertragungsstream ausgelassen.