Microsoft Stream (klassisch) Videobereitstellung und Netzwerkübersicht

  • Artikel

Warnung

Microsoft Stream (klassisch) wird eingestellt und durch Stream (auf SharePoint) und Microsoft Teams-Liveereignisse ersetzt. Es wird empfohlen, Stream (auf SharePoint) zu verwenden, indem Sie Videos in SharePoint, Teams, Viva Engage oder OneDrive hochladen und Ihre Liveereignisse über Teams und Viva Engage ausführen.

Die Funktionalität in Stream (klassisch) wird vor dem Ausmusterungsdatum geändert und entfernt. Erfahren Sie mehr über Stream (auf SharePoint)...

Streaming mit adaptiver Bitrate

Es gibt viele unterstützte Videoformate, die in Microsoft Stream hochgeladen werden können. Jede Videodatei wird dann in ein Standardformat mit verschiedenen Videoqualitäten und -größen für die Wiedergabe codiert. Stream (klassisch) verwendet HTTPS Unicast Adaptive Bitrate Streaming (ABR), um die beste Videowiedergabequalität basierend auf der verfügbaren Netzwerkbandbreite und Größe des Videoplayers dynamisch auszuwählen.

Während der Wiedergabe passt sich der Player an Schwankungen der Netzwerkbedingungen und der Größe des Players an. Wenn die verfügbare Bandbreite hoch ist, streamt der Player eine qualitativ hochwertige Version des Videos. Wenn die Bandbreite sinkt, streamt der Player eine version mit niedriger Qualität des Videos. Die Qualität und Auflösung des Videos ist auch proportional zur Größe des Players. Wenn ein Zuschauer auf einem kleineren Bildschirm schaut, erhält er immer eine kleinere Version des Videos.

Das Streaming mit adaptiver Bitrate führt all dies im Hintergrund aus, während das Video mit der geringsten Unterbrechung oder Pufferung wiedergegeben wird. Während der Videowiedergabe kann der Videoplayer die automatische Wiedergabequalität manuell überschreiben, um eine bestimmte Videowiedergabequalität auszuwählen.

Intelligente Codierung hochgeladener Videos für das Streaming mit adaptiver Bitrate

Stream (klassisch) verwendet einige Smarts, um zu bestimmen, wie die verschiedenen Videoqualitäten und -größen aus dem ursprünglich hochgeladenen Video für das Streaming mit adaptiver Bitrate erstellt werden.

Zunächst bestimmt Stream (klassisch), wie viele verschiedene Videoqualitäten oder Wiedergaben für das hochgeladene Video erstellt werden sollen. Stream (klassisch) berücksichtigt die ursprüngliche Auflösung des Videos. Wenn es sich beispielsweise um ein Video mit 1080p oder höher handelt, werden mehr Qualitätsstufen (etwa 6) erstellt, um auf die Version mit der niedrigsten Qualität zu wechseln. Wenn das hochgeladene Video stattdessen 480p ist, werden weniger Qualitätsstufen (etwa 3) erzeugt, um auf die Version mit der niedrigsten Qualität zu gelangen. Stream (klassisch) generiert keine Auflösung des Videos, die die Auflösung des ursprünglich hochgeladenen Videos überschreitet.

Nachdem die Anzahl der Videoqualitäten oder Wiedergaben festgelegt wurde, besteht die nächste Phase darin, die Bitrate für jede Wiedergabe zu bestimmen. Je höher die Qualität der Wiedergabe ist, desto mehr Bits sind erforderlich. Allerdings werden nicht alle Videos gleich erstellt, unterschiedliche Arten von Videos erfordern unterschiedliche Bitraten, um eine qualitativ hochwertige Anzeigeerfahrung zu erzielen. Wenn ein Video viel Bewegung hat, muss es mit einer höheren Bitrate bereitgestellt werden, um eine großartige Anzeigeerfahrung zu erzielen. Eine PowerPoint-Präsentation in einem Video mit überwiegend statischem Text kann jedoch bei einer niedrigeren Bitrate immer noch eine hervorragende Anzeigeerfahrung bieten.

Um diese Variabilität bei Videoinhalten zu beheben, misst Stream (klassisch) die Merkmale des hochgeladenen Videos und empfiehlt dann die Bitrate für jede Wiedergabe. Jedes Video, das in Stream (klassisch) hochgeladen wird, hat am Ende einen etwas anderen Satz von Auflösungen und Bitraten, die für das Streaming verwendet werden, um sicherzustellen, dass wir bandbreitenweise und nur bei Bedarf mehr Bits verwenden.

Beim Anzeigen eines Videos in Stream können die verschiedenen Darstellungen, die für das Streaming mit adaptiver Bitrate erstellt wurden, im Player angezeigt werden:

  • Klicken Sie im Stream (klassisch) Player auf das Zahnradsymbol, und wählen Sie dann Qualität aus.
Beispiel Beschreibung Player
Teams-Besprechungsaufzeichnungen Teams-Besprechungsaufzeichnungen werden mit einer einzelnen Videowiedergabe mit einer Auflösung von 1080p codiert. 1080p – 574 KBit/s
Video-on-Demand (ohne Besprechungsaufzeichnungen) Nicht-Teams-Video-on-Demand wird mit einer inhaltsfähigen Voreinstellung codiert, die intelligent bis zu 6 Videodarstellungen auswählt, wie in diesem Beispiel gezeigt. Inhalte mit höherer Komplexität mit einem hohen Grad an Farb- und Bewegungsvarianz werden mit mehr Videodarstellungen codiert, und inhalte mit geringerer Komplexität werden mit weniger codiert. 1080p – 3 MBit/s
720p – 1,6 MBit/s
540p – 989 KBit/s
360p – 460 KBit/s
270p – 327 KBit/s
180p – 193 KBit/s

Codierungsprofil für Liveereignisse

Die oben aufgeführte intelligente Codierung gilt nur für Videos, die in Stream hochgeladen wurden.

Liveereignisse, die in Stream (klassisch) oder "Externe App oder Gerät" erstellt wurden, erhalten von Yammer oder Microsoft Teams ein festes Codierungsprofil:

  • 720p – 1,7 MBit/s
  • 540p – 850 KBit/s
  • 360p - 350 KBit/s
  • 240p – 140 KBit/s

Hinweis

Wenn die Videoauflösung des Encoders 720p oder höher beträgt, erhalten Sie das oben genannte Profil. Wenn Sie die Videoauflösung der Eingabe vom Encoder auf unter 720p festlegen, erhalten Sie nur Ausgabebitraten aus Der Eingabeauflösung und nach unten. Wenn Sie beispielsweise eine Auflösung von 540p von Ihrem Encoder senden, können Viewer mit der höchsten Bitrate die Version 540p bis 850 KBit/s abrufen. Stream (klassisch) das oben genannte Livecodierungsprofil nicht basierend auf der Eingabebitrate des Encoders ändert, schneidet es nur Qualitätsstufen basierend auf der Eingabeauflösung ab.

Bandbreitenanforderungen für die Videowiedergabe

Die Videowiedergabe in Stream (klassisch) ist Unicast, was bedeutet, dass jeder Zuschauer seinen eigenen Videostream aus dem Internet erhält. Basierend auf der intelligenten Codierung und dem Streaming mit adaptiver Bitrate, die von Stream verwendet werden, ist die Bandbreitenanforderung für die Videowiedergabe keine statische Zahl. Die Wiedergabe eines Videos kann je nach hochgeladener Video unterschiedlich viel Internetbandbreite beanspruchen:

  • ursprüngliche Auflösung, Bitrate und Inhalt
  • Verfügbare Bandbreite des Benutzers
  • Größe des Spielers

Wenn Sie Einige Bandbreitenschätzungen entwickeln möchten, müssen Sie einige Videos hochladen, die die typischen Inhalte darstellen, die Ihre organization mit Stream (klassisch) verwenden, und watch die Videos auf Bildschirmgrößen, von denen Sie glauben, dass sie von Ihren Benutzern verwendet werden. Anschließend können Sie einige Bandbreitenmessungen und Stichprobenentnahmen durchführen. Sie können diese Näherungen dann verwenden, um einige allgemeine Berechnungen und Schätzungen darüber durchzuführen, wie viel Bandbreite Ihre Benutzer verbrauchen werden, basierend darauf, wie viele Videos Ihrer Meinung nach gleichzeitig watch werden.

Optimieren der Videozustellung in meinem lokalen Netzwerk

Stream (klassisch) nutzt die intelligente Codierung und das Streaming mit adaptiver Bitrate, um den Netzwerk- und Internetdatenverkehr der Videowiedergabe zu reduzieren. Die Wiedergabe ist jedoch ein Unicaststream. Bei Liveereignissen oder Videos, die an große Teile Ihrer Organisation gesendet werden, kann ein beträchtlicher Anteil der Internetbandbreite von den Zuschauern in Anspruch genommen werden.

Für Organisationen, die diesen Internetdatenverkehr für Liveereignisse und beliebte Videos reduzieren möchten, gibt es zwei Möglichkeiten:

  1. Nutzen vorhandener Cacheproxys in Ihrem Netzwerk

    Das Ansehen von Videos von Stream (klassisch) erfolgt über HTTPS. Daher können normale Webcacheproxys so konfiguriert werden, dass der Datenverkehr für die Videowiedergabe zwischengespeichert wird. Möglicherweise müssen Sie eine benutzerdefinierte SSL-Zertifizierung konfigurieren, um dies mit HTTPS zu ermöglichen. Wenn Sie sich jedoch bei der Wiedergabe eines Videos eine Netzwerkablaufverfolgung ansehen, können Sie die URLs sehen, die Stream (klassisch) zum Streamen des Videos für Ihre organization verwendet (URLs können je nach Stream (klassisch) Mandanten variieren). Wenn Sie diese URLs über Ihren Cacheproxy weiterleiten, kann er den Videodatenverkehr zwischenspeichern und den Internetdatenverkehr für häufig wiedergegebene Videos reduzieren.

  2. Verwenden einer eCDN-Videobereitstellungslösung eines Drittanbieters, die für Stream (klassisch)

    Mehrere eCDN-Lösungen für die Videobereitstellung sind bereits integriert und können für die Verwendung mit Stream eingerichtet werden. Diese eCDN-Plattformen ermöglichen Es Organisationen, die Netzwerkbandbreite zu optimieren, ohne die Anzeigeerfahrung für Endbenutzer zu beeinträchtigen. Unsere Partner können ihnen dabei helfen, eine skalierbarere und effizientere Videoverteilung in Ihrem Unternehmensnetzwerk zu ermöglichen. Weitere Informationen finden Sie unter Skalieren der Videoübermittlung mit eCDN-Anbietern von Drittanbietern .

Endpunkte, die von Benutzern innerhalb Ihres Netzwerks erreichbar sein müssen

Allgemeine Microsoft Stream (klassisch)-Endpunkte

Microsoft Stream (klassisch) erfordert eine Internetverbindung. Alle Endpunkte, die auf Office 365 Endpunkten für Microsoft Stream aufgeführt sind, müssen für Benutzer von Microsoft Stream (klassisch) im Netzwerk Ihrer organization erreichbar sein.

Von einer externen App oder einem Gerät erzeugte Liveereignisse (früher externer Encoder) – RMTP-Erfassungsendpunkte

Um einen Videofeed für eine externe App oder ein vom Gerät erzeugtes Liveereignis von Ihrem Encoder an Microsoft Stream (klassisch) zu senden, benötigen Sie die folgenden IP-Bereiche und Ports, die in der Firewall Ihres Netzwerks geöffnet sind:

  • Domänen: *.channel.media.azure.net
  • Ports: 1935/2935/1936/2936 (für RTMP und RTMPS)

Wenn Ihre spezifische Netzwerkeinrichtung es Ihnen nicht ermöglicht (oder sie nicht möchten), den oben genannten Domänenbereich zu öffnen, besteht derzeit die einzige Option zum Abrufen bestimmter IP-Adressen für die RTMP/RTMPS-Erfassung darin, die rotierenden IP-Adressbereiche für das Azure-Rechenzentrum abzurufen, mit dem Ihr Microsoft Stream (klassisch) Mandant verbunden ist.

Die folgenden JSON-Dateien werden aktualisiert, wenn sich die IP-Adressen für Azure-Rechenzentren ändern und nach Region und markierten Diensten getrennt werden.

Diese Dateien werden wöchentlich aktualisiert und enthalten versionsverwaltung sowohl für die vollständige Datei als auch für jedes einzelne Diensttag in dieser Datei.

So suchen Sie das Azure-Rechenzentrum für Ihren Stream (klassisch) Mandanten:

  1. Klicken Sie in Stream in der oberen rechten Ecke auf ? .

  2. Wählen Sie Info Microsoft Stream aus.

  3. Zeigen Sie die Informationen unter Ihre Daten sind gespeichert in an.

Nachdem Sie das Azure-Rechenzentrum für Ihren Stream (klassisch) Mandanten ermittelt haben, suchen Sie die entsprechenden IP-Adressbereiche in der xml-Datei oben, und aktualisieren Sie dann Ihre Firewall/Ihren Proxy mit den spezifischen IP-Adressbereichen für Ihr Rechenzentrum. Wenn sich die XML-Datei ändert, müssen Sie auch Ihre Firewall-/Proxyeinstellungen aktualisieren.

Beispiel:

  • Wenn About Microsoft Stream sagt, dass Ihre Daten in "USA, Osten 2" gespeichert sind

  • In der XML-Datei würden Sie nach einem Knoten mit der Bezeichnung <Region Name="useast2" suchen.>

  • Unter diesem Knoten Region würden mehrere Einträge für alle IP-Adressbereiche vorhanden sein (<IpRange Subnet="13.68.0.0/17">).

  • Sie müssen Ihre Firewall/Ihren Proxy so konfigurieren, dass alle diese IP-Adressbereiche zulässig sind, und sie regelmäßig ändern, wenn sich die XML-Datei ändert.

Benutzer in der Community haben Code geschrieben, der nach einem Zeitplan die oben genannte XML-Datei verwendet und die Daten in eine API konvertiert, die abgefragt werden kann. Ihre organization können möglicherweise aus der Ausführung dieses Open Source Projekts lernen und eine eigene ähnliche Lösung erstellen, um Ihre Firewall-/Proxyeinstellungen regelmäßig zu aktualisieren.

Für die Wiedergabe von Videos verwendetes CDN

Liveereignisse von Stream (klassisch) und externen App- oder Geräte-Liveereignissen aus Yammer/Teams sowie On-Demand-Videos verwenden automatisch Azure CDN.

In Stream hochgeladene On-Demand-Videos sowie Liveereignisaufzeichnungen verwenden bei Bedarf auch Azure CDN für die Wiedergabe. Wenn Azure CDN für diese Videos nicht erforderlich ist, werden sie von den Azure Media Services-Ursprungsservern wiedergegeben, die der geografischen Region des Mandanten zugeordnet sind.

Wenn mehrere Personen aus demselben organization innerhalb desselben geografischen Standorts dieselben Videos streamen, speichern CDNs eine Kopie dieser Videos an einem Ort, der sich in der Nähe dieser geografischen Region befindet. Wenn das Video am nächstgelegenen Ort gespeichert oder zwischengespeichert wird, streamt jede Person das Video von dem Standort, der ihnen am nächsten ist, anstelle eines weiter entfernten Speicherorts. Stream (klassisch) verwendet Azure Media Services, um zu verwalten, was und wie lange in den Azure CDNs zwischengespeichert wird. Azure Media Services kann jeden der Azure CDN-Speicherorte verwenden, um Videofragmente und Manifeste für einige Tage zwischenzuspeichern. Wenn Personen in Ihrem organization die zwischengespeicherten Videos weiterhin watch, bleiben sie im Cache. Wenn mehrere Tage lang niemand auf das Video zugreift, wird das Video schließlich aus dem Cache gelöscht. Wenn jemand das nächste Mal versucht, das Video zu watch, wird es erneut am nächstgelegenen CDN-Speicherort zwischengespeichert.

Jeder, der versucht, das Video zu watch, während der Inhalt in einem cdN in der Nähe zwischengespeichert wird, profitiert davon, dass das Video näher und in den meisten Fällen weniger Hops entfernt ist. Dadurch wird die Videowiedergabegeschwindigkeit verbessert. die Netzwerkanforderung für die Wiedergabe des Videos wird jedoch nicht geändert.

Verschlüsselung und Wiedergabefluss auf Videoebene

Stream (klassisch) weiß, wie wichtig es ist, Ihre Daten sicher und privat zu halten. Das Microsoft Trust Center beschreibt unser Engagement für den Datenschutz und die Sicherheit Ihrer Inhalte. Bei der Videowiedergabe ist die Geschwindigkeit wichtig für eine gute Erfahrung. Wir gefährden jedoch nicht Ihre Sicherheit oder Ihren Datenschutz im Austausch für geschwindigkeit. Hier erfahren Sie, wie Wir Geschwindigkeit, Sicherheit und Datenschutz berücksichtigen.

Wenn Sie oder eine Person in Ihrem organization ein neues Video hochlädt oder ein Liveereignis erstellt, wird dieses Video transcodiert, mit AES-128-Verschlüsselung verschlüsselt und in Azure Media Services gespeichert. Dies bedeutet, dass die Videos sowohl während der Übertragung als auch im Ruhezustand verschlüsselt werden.

Wenn jemand in Ihrem organization versucht, ein Video zu watch, führt er die folgenden Schritte aus:

  1. Stream (klassisch) bestimmt, ob der Zuschauer Zugriff auf das Video hat, indem die für das Video in Azure SQL Datenbank festgelegten Berechtigungen auf Stream (klassisch) und Informationen in Microsoft Entra ID zum Benutzer überprüft werden.

  2. Wenn der Benutzer das Video anzeigen darf, wird der Entschlüsselungsschlüssel von Azure Media Services abgerufen und an den Stream (klassisch) Videoplayer übergeben.

  3. Der Stream (klassisch) Videoplayer verwendet dann den Entschlüsselungsschlüssel, um das Video während der Wiedergabe des Videos zu entschlüsseln.

Siehe auch

Skalieren der Videoübermittlung mit eCDN-Anbietern von Drittanbietern