Generische Stream-Gleichzeitigkeit

In diesem Dokument wird beschrieben, wie die Gleichzeitigkeit von Streams mit einem Heartbeat-Mechanismus und ohne DRM auf die Endbetrachter beschränkt werden kann.

Einleitung

Mit Generic Stream Concurrency können Sie die Anzahl der Videostreams festlegen, die ein bestimmter Benutzer gleichzeitig sehen kann. Durch die Begrenzung der Stream-Gleichzeitigkeit können Sie verhindern, dass Inhalte gestohlen oder durch Diebstahl oder unangemessene Weitergabe von Anmeldeinformationen illegal angesehen werden.

Diese Funktion ist Teil der Wiedergabebeschränkungen und stellt eine Alternative zur Gleichzeitigkeit von Streams mit DRM dar, was eine alternative Lösung ist.

Wann ist GSC zu verwenden?

Brightcove bietet zwei Lösungen für die Verwaltung der Gleichzeitigkeit:

Die nachstehende Tabelle bietet einen Vergleich der beiden Möglichkeiten, um Ihnen die Entscheidung zu erleichtern, welche für Ihre Situation besser geeignet ist.

Stream Concurrency Lösungen
Generische Stream-Gleichzeitigkeit Gleichzeitigkeit der Streams mit DRM
Vorteile:
  • Erfordert kein DRM
  • Aktive Stream-Sitzungen können über die API aufgelistet werden
Vorteile
  • Es gibt keine Möglichkeit, diese Funktion auf der Client-Seite zu deaktivieren
  • Der Erneuerungsmechanismus ist bei benutzerdefinierten Implementierungen transparent
  • Mehr Sicherheit
Nachteile
  • Heartbeat läuft auf der Client-Seite
  • Kundenspezifische Implementierungen erfordern die Integration des Heartbeat-Mechanismus
Nachteile
  • Es erfordert viele DRM-Lizenzen
  • keine Möglichkeit, alle aktiven Sitzungen eines bestimmten Benutzers aufzulisten

So funktioniert es

Herzschlag

Der Heartbeat ist ein Mechanismus, der in regelmäßigen Abständen die aktiven Sitzungen für einen bestimmten Benutzer abfragt, um sicherzustellen, dass es sich um eine gültige Sitzung während der gesamten Wiedergabe handelt. Der Heartbeat kann für den Brightcove-Webplayer und die nativen SDK-Player aktiviert werden.

Die Häufigkeit des Heartbeats legt fest, wie oft der Player in der Mitte des Streams überprüft, ob die Bedingungen für die Wiedergabe noch erfüllt sind. Standardmäßig ist die Häufigkeit auf 1 Minute eingestellt, dies kann jedoch geändert werden.

Blockieren von Strömen

Wenn die maximale Anzahl gleichzeitiger Streams erreicht ist und der Zuschauer oder jemand mit seinen Zugangsdaten versucht, einen weiteren Stream zu öffnen, wird jeder neue Stream dieses Nutzers, der als anderer Streaming-Standort identifiziert wurde, blockiert.

Kennung des Korrelators

Ein Korrelator-Identifikator wird verwendet, um die Standorte der Zuschauerströme zu definieren. Die Merkmale dieses Identifikators sind:

  • Sie sollte spezifisch genug sein, um alle Anfragen desselben Betrachters miteinander in Beziehung zu setzen. Wenn der Korrelator zu allgemein ist, werden mehrere Betrachter mit der gleichen Betrachter-ID zusammengefasst und in den gleichen Slot eingeordnet.
  • Sie sollte für alle Videoansichten desselben Betrachters einheitlich sein.

Wenn der "Korrelator" anders ist, wird er versuchen, einen "Slot" für die Betrachter-ID zu füllen, d. h., wenn sich dieser Wert während der gleichen Betrachtung ändert, wird er wie ein anderer Betrachter behandelt und die Wiedergabe verhindert.

Der Korrelator wird in der JWT anhand des sid Claims festgelegt

Implementierung

Verwendung von Brightcove-Web- oder SDK-Playern

  1. Wenn Sie die Herzschlagfrequenz von der Standardeinstellung (1 Minute) abweichen möchten, wenden Sie sich an den Support.
  2. Erstellen Sie ein JWT für Wiedergabebeschränkungen.

    Die folgenden Angaben sind erforderlich:

    • climit- Das Limit für die gleichzeitige Nutzung gibt an, wie viele Zuschauer oder Streams gleichzeitig spielen können
    • uid- Die Viewer-ID wird verwendet, um mehrere Sessions zu korrelieren, um die Stream-Parallelität zu erzwingen
    • sid- Die Korrelator-ID definiert die Streaming-Standorte für einen Zuschauer.

      Beispiele:
      • Chrom MAC (Kadmium) HTML 5 - 1112223334
      • Apple iPad 7. Generation 10.2 (WLAN) - 2223334444
      • Apple Apple TV TBD Apple TV - 3334445555
      • Android DefaultWidevineL3Phone Android Telefon - 1112224567
      • Firefox MAC (Kadmium) HTML 5 - 1112226754
      • Google Chromecast Streaming-Stick - 1112346677
  3. Registrieren Sie den öffentlichen Schlüssel für das JWT bei Brightcove. Weitere Informationen finden Sie unter Verwenden von Authentifizierungs-APIs.
  4. Generische Stream-Gleichzeitigkeit auf Client-Playern aktivieren: siehe Implementierung in Playern unten
Beispiel für Ansprüche JSON Web Token(JWT)
{
// account id: JWT is only valid for this account
"accid":"4590388311111",
// limit of concurrent users
"climit": 3,
// user id
"uid": "108.26.184.3_1634052241",
// correlator identifier
"sid": "Firefox MAC (Cadmium) HTML 5 - 1112346677"
}
}

Anmerkungen

  • Wenn die maximale Anzahl von Sitzungen für einen Betrachter überschritten wird, wird eine Sitzung beendet. Es kann so lange wie die Herzschlagfrequenz dauern, bis die Sitzung beendet wird.
  • Wenn der Client-Spieler keine Verbindung zum Server herstellen kann, versucht er es dreimal erneut. Wenn immer noch keine Verbindung hergestellt werden kann, wird die Wiedergabe angehalten.

Umsetzung bei den Akteuren

Voraussetzungen

  • Für die generische Streamgleichzeitigkeit ist der Brightcove-Webplayer 6.63.2 oder höher erforderlich.
  • Für die generische Streamgleichzeitigkeit ist der Brightcove iOS SDK-Player 6.10.1 oder höher erforderlich.
  • Für die generische Streamgleichzeitigkeit ist der Brightcove Android SDK-Player 6.17.2 oder höher erforderlich.

Brightcove-Webplayer

Die generische Parallelität von Streams im Brightcove Player kann mithilfe der video_cloud.stream_concurrency Player-Konfiguration aktiviert werden.

Zurzeit gibt es in Studio keine spezielle Benutzeroberfläche für diese Funktion, so dass der JSON-Editor verwendet werden muss. Die Konfiguration sieht dann etwa so aus:

"stream_concurrency" : true
...
  "video_cloud": {
    "stream_concurrency": true,
    "policy_key": "BCpk..."
  },
  "player": {
    "template": {
      "name": "single-video-template",
      "version": "6.63.1"
    }
  },
...

Wenn dieses Schlüssel/Wert-Paar in JSON nicht vorhanden ist oder der Wert falsch ist, wird die GSC-Funktion für den Player nicht aktiviert.

Einstellung des JWT zur Laufzeit

Ähnlich wie die Funktion zur Begrenzung der Stream-Gleichzeitigkeit des EPA hängt die generische Stream-Gleichzeitigkeit von einem JSON-Web-Token ab.

Nachdem der Player wie oben beschrieben für die allgemeine Streamgleichzeitigkeit konfiguriert wurde, besteht der verbleibende Schritt darin, dem Player zur Laufzeit ein JWT bereitzustellen. Dies ist das gleiche Verfahren wie bei der Verwendung von EPA:

player.catalog.setBcovAuthToken('');
Beispiel

Nach dem Hinzufügen eines JWT-Tokens besteht der letzte Schritt darin, Daten von der Wiedergabe-API anzufordern und sie in den Player zu laden. Dieses Beispiel zeigt den Abruf eines einzelnen Videos:

// Set the authorization token.
  player.catalog.setBcovAuthToken('');
  
  // Initiate a catalog request. API selection will occur each time this
  // is called.
  player.catalog.get({id: '1', type: 'video'}).
    then(function(data) {
  
      // When the request is complete, you must load the returned metadata
      // and sources into the player.
      player.catalog.load(data);
    }).
    catch(function(error) {
      throw new Error(error);
    });

iOS

Um die Funktion Generic Stream Concurrency für iOS SDK zu aktivieren, müssen Sie die Option streamConcurrencyEnabled in Ihrem playbackController. Optional können Sie den Wert für senden sid. Wenn der leer sid ist, wird dieser Wert nicht als Header gesendet.

Ziel c

self.playbackController.streamConcurrencyEnabled = YES;
// Optional. Set custom sid
self.playbackController.options ■ (?{ kBCOVAuthHeartbeatPropertyKeySessionld: G'sessionld" };

Schnell

self.playbackController.streamConcurrencyEnabled ■ true
// Optional. Set custom sid
self.playbackController.options = [ kBCOVAuthHeartbeatPropertyKeySessionld: "sessionld" ]

Weitere Einzelheiten finden Sie in der Referenz für den nativen Brightcove-Player für iOS.

Android

Fügen Sie in der onCreate-Methode der Playeraktivität die folgende Zeile hinzu:

brightcoveVideoView.setStreamConcurrencyEnabled(true);

Fügen Sie in der onCreate Methode einen Event-Listener für das DID_SET_VIDEO Ereignis hinzu. Verwenden Sie diesen Code, um Heartbeat-Header festzulegen. Beachten Sie, dass dasselbe JWT, das für den Abruf des Videos verwendet wurde, hier verwendet wird und einen uid Anspruch (und optional einen sid Anspruch) enthalten sollte:

Map<String, String> requestHeaders = new HashMap<>();
requestHeaders.put(ConcurrencyClient.HEARTBEAT_VIDEO_HEADER_KEY, video.getId());
requestHeaders.put(ConcurrencyClient.HEARTBEAT_ACCOUNTID_HEADER_KEY, accountId);
requestHeaders.put(BrightcoveTokenAuthorizer.BRIGHTCOVE_AUTHORIZATION_HEADER_KEY, jwtToken);
brightcoveVideoView.setStreamConcurrencyRequestHeaders(requestHeaders);

Weitere Einzelheiten finden Sie unter Generic Stream Concurrency (GSC) mit dem Native SDK für Android dokumentieren.

Implementierung über API

Dieses Feature kann über die Gleichzeitigkeitsservice-API implementiert werden, ohne den Brightcove-Webplayer oder SDK-Player zu verwenden. Weitere Informationen finden Sie in der API-Referenz.

Die Basis-URL für die Gleichzeitigkeitsdienst-API lautet:

https://edge-gsc.api.brightcove.com

Die Autorisierungsmethode erfolgt über das JWT, das in einem Authorization Header gesendet wird:

Authorization: Bearer code translate="No">{token}

Die grundlegende Logik, die Ihr Player/Ihre Anwendung ausführen muss, ist im folgenden Diagramm dargestellt:

Logik für Gleichzeitigkeit
Logik für Gleichzeitigkeit

Die API-Endpunkte

Sitzung
Dieser Endpunkt wird verwendet, um neue Streaming-Sitzungen mit einem Heartbeat für die Gleichzeitigkeitsverwaltung zu erstellen:
/api/v1/accounts/{account_id}/sessions

Methode: POST

Körper der Anfrage:

{
  "video": "the_video_id"
}
Aktive Sitzungen
Dieser Endpunkt ermöglicht es Ihnen, Streaming-Sitzungen aufzulisten, um sie zu verfolgen. Dies ist vor allem dann nützlich, wenn Sie eine Logik implementieren, um zu entscheiden, welche Sitzung gestoppt werden soll, wenn die Gleichzeitigkeitsgrenze erreicht ist:
/api/v1/accounts/{account_id}/sessions

Methode: POST

Sitzungen anhalten
Dieser Endpunkt ermöglicht es Ihnen, eine Streaming-Sitzung zu stoppen - Sie würden dies verwenden, wenn Sie eine Logik implementieren, um zu entscheiden, welche Sitzung zu stoppen ist, wenn eine neue Wiedergabeanforderung die Gleichzeitigkeitsgrenze überschreitet. Dieser Endpunkt ist hauptsächlich für die Verwendung im Backend gedacht, um Sitzungen nach Abschluss zu entfernen:
/api/v1/accounts/{account_id}/sessions

Methode: DELETE