Fehlerbehebung-FAQ

In diesem Dokument werden bewährte Methoden und Tipps zur Fehlerbehebung für Amazon Interactive Video Service (IVS) beschrieben. Bei der Verwendung von IVS kann es zu unerwartetem oder unbeabsichtigtem Verhalten kommen. Diese Verhaltensweisen können an verschiedenen Stellen des Streaming-Prozesses auftreten, von der Übertragung bis zur Wiedergabe von Inhalten:

Informationen zum Support und anderen Amazon-IVS-Ressourcen finden Sie unter Ressourcen und Support.

Broadcasting und Codierung

Die Fragen in diesem Abschnitt beziehen sich auf die Übertragung, die Codierung und die Bedingungen für das Streamen auf der ersten Meile zu IVS. Diese Verhaltensweisen treten auf, bevor der Inhalt die IVS-Server erreicht.

Themen:

• Was ist Stream-Starvation?

• Warum wurde der Stream plötzlich gestoppt?

• Was passiert, wenn ich beim Streamen das Netzwerk wechsle?

• Wie kann ich mit IVS eine regionsübergreifende Redundanz erreichen?

• Wie behebe ich Fehler bei einer IVS-Web-Broadcast-SDK-Sitzung?

• Wie verwende ich die WebRTC-Internals-Metriken von Google Chrome, um eine IVS-Web-Broadcast-SDK-Sitzung auszuwerten?

Was ist Stream-Starvation?

„Stream Starvation“ ist eine Verzögerung oder ein Stopp der Bereitstellung von Inhaltspaketen, wenn Sie Inhalte an IVS senden, d. h. wenn Inhalte von IVS aufgenommen werden. Wenn IVS beim Erfassen nicht die erwartete Menge an Bits erhält, die das Verschlüsselungsgerät angekündigt hat, innerhalb eines bestimmten Zeitrahmens zu senden, wird dies als Starvation-Ereignis betrachtet. Häufig werden Starvation-Ereignisse durch den Encoder des Senders, die lokalen Netzwerkbedingungen und/oder durch die Übertragung über das öffentliche Internet zwischen dem Codierungsgerät und dem IVS verursacht.

Aus der Sicht des Betrachters können Starvation-Ereignisse als Video erscheinen, das hinterherhinkt, puffert oder einfriert. Stream-Starvation-Ereignisse können kurz (weniger als 5 Sekunden) oder lang (mehrere Minuten) sein, abhängig von der Art des Starvation-Ereignisses.

Um die Überwachung von Starvation-Ereignissen zu ermöglichen, sendet IVS Starvation-Ereignisse als Amazon- EventBridge Ereignisse; siehe Beispiele: Stream Health Change in Using Amazon EventBridge with Amazon IVS . Diese werden gesendet, wenn ein Stream in einen Starvation-Zustand eintritt oder ihn verlässt. Je nach Anwendungsfall können Sie geeignete Maßnahmen ergreifen, z. B. den Sender und die Zuschauer über intermittierende Streambedingungen informieren.

Weitere Tools zur Überwachung von Starvation finden Sie unter Überwachen von Amazon-IVS-Streaming mit niedriger Latenz, des IVS-ListStreamsAPI-Endpunkts (Filterung nach Zustand) und des IVS-GetStreamEndpunkts (zur Analyse eines einzelnen Streams). Lesen Sie auch den Abschnitt Wie überwache ich Stream-Starvation-Ereignisse?

Warum wurde der Stream plötzlich gestoppt?

Im Folgenden sind die häufigsten Gründe aufgeführt, warum ein Stream abrupt beendet werden kann (d. h. die Stream-Sitzung wird beendet):

• Fehlende Erfassungsdaten – Wenn die Aufnahme einer Stream-Sitzung 30 Sekunden lang vollständig beendet wird (keine Daten werden in IVS erfasst), beendet der IVS-Erfassungs-Server die IVS-Stream-Sitzung. Der Zeitraum von 30 Sekunden ermöglicht es dem Sender, sich erneut mit dem Erfassungs-Server zu verbinden. In einigen Fällen (z. B. beim Umschalten von Netzwerken) ist eine erneute Verbindung zur bestehenden Stream-Sitzung jedoch möglicherweise nicht möglich, da der TLS-Handshake von RTMPS unterbrochen wurde. Zu den häufigsten Ursachen hierfür gehören Netzwerkprobleme (wie Überlastung zwischen dem Übertragungsgerät und dem IVS), der vollständige Verlust des Internets auf dem Übertragungsgerät oder das Übertragungsgerät, das keine Inhaltssegmente (FLV-Tags) produziert.

  Oft geht eine Stream-Unterbrechung mit einem Stream-Starvation-Ereignis einher. Das Starvation-Ereignis wird ausgelöst, wenn eingehende Daten zum Stillstand kommen. Wenn ein Starvation-Start-Ereignis gesendet wird und dann ein Stream-End-Ereignis gesendet wird (ohne ein Starvation-End-Ereignis), weist dies oft darauf hin, dass der Stream beendet wurde, da keine Daten an IVS gesendet wurden.

• IVS- StopStream Endpunkt – Wenn der StopStream API-Aufruf während einer IVS-Stream-Sitzung erfolgt, wird die IVS-Stream-Sitzung beendet. Der StopStream Endpunkt trennt den eingehenden RTMPS-Stream vom IVS-Erfassungsserver. Abhängig von der verwendeten Codierungssoftware/Hardware kann versucht werden, eine neue Stream-Sitzung zu starten.

• Encoderfehler – Einige Software-/Hardware-Encoder trennen die Stream-Sitzung, wenn während des Codierungsprozesses ein Fehler auftritt. Aus Sicht von IVS erscheinen diese Verbindungsabbrüche als vorsätzliche Verbindungsabbrüche durch den Sender. In den Codierungsprotokollen kann jedoch festgestellt werden, dass der Stream aufgrund eines unbeabsichtigten Fehlers unterbrochen wurde.

Was passiert, wenn ich beim Streamen das Netzwerk wechsle?

Wenn ein Sender das Netzwerk wechselt (z. B. von WiFi zu Mobilfunk), wird eine laufende RTMPS-Verbindung getrennt. Während die Internetverbindung des Senders wahrscheinlich nach 3–4 Sekunden wieder hergestellt ist, hat die neue Verbindung aufgrund des Netzwerkwechsels, der eine neue RTMPS-Verbindung generiert, eine neue IP-Adresse. Während dieses Wechsels wird die vorherige RTMPS-Verbindung nicht sauber getrennt: Der Encoder sendet IVS keine Trenn-Meldung. Infolgedessen wartet IVS 30 Sekunden, bis die vorherige RTMPS-Verbindung wieder hergestellt wird, wodurch verhindert wird, dass der neue RTMPS-Stream im neuen Netzwerk eine Verbindung zu IVS herstellt.

Um einen schnelleren Wechsel zwischen Netzwerken zu ermöglichen, empfehlen wir, den IVS-StopStreamEndpunkt zu verwenden, um die vorherige Stream-Sitzung zu schließen, wenn das Gerät das Netzwerk wechselt. In diesem Szenario könnte das Broadcast-Gerät, wenn es eine Verbindung zum neuen Netzwerk herstellt, den StopStream Endpunkt aufrufen, um den jetzt inaktiven Stream zu beenden. Nach einem erfolgreichen StopStream Anruf könnte das Broadcast-Gerät eine neue Stream-Sitzung im neuen Netzwerk starten, ohne 30 Sekunden zu warten.

Wie kann ich mit IVS eine regionsübergreifende Redundanz erreichen?

Redundanz innerhalb von IVS kann auf verschiedene Weise erreicht werden; siehe Resilienz in IVS Security.

IVS ist in verschiedene Netzwerkebenen unterteilt: Steuerung und Daten.

• Die Steuerebene ist regional (basiert auf AWS-Regionen) und speichert Informationen über IVS-Ressourcen (Kanäle, Stream-Schlüssel, Wiedergabe-Schlüsselpaare und Aufzeichnungskonfigurationen).

• Die Datenebene ist nicht auf eine AWS-Region beschränkt und ist das Netzwerk, das Daten vom Eingang bis zum Ausgang überträgt. Selbst wenn ein Kanal beispielsweise in der Region USA West-2 erstellt wird, wird das Video, das auf diesen Kanal gestreamt wird, möglicherweise nicht über USA West-2 übertragen.

Sehen Sie auch unter Globale Lösung, regionale Kontrolle. Stellen Sie sich diese beiden Szenarien vor:

• Wenn nur eine Steuerungsebenenregion (z. B. us-east-1) verwendet wird – Wenn in einer bestimmten AWS-Kontrollregion eine Verschlechterung oder ein Ausfall auftritt, kann es in der IVS-Steuerebene zu Latenzen oder Fehlern kommen, wenn folgende Elemente erstellt, gelesen, aktualisiert oder gelöscht werden: Kanäle, Streamschlüssel, Wiedergabeschlüsselpaare oder Aufzeichnungskonfigurationen. Der Versuch, während eines Ausfalls einen neuen Stream zu starten, kann zu mehr Latenz oder Fehlern beim Initiieren einer Stream-Sitzung führen. Je nach Schweregrad der Beeinträchtigung kann es möglich sein, die Übertragung auf einen Kanal mit einem bereits laufenden Stream fortzusetzen.

  Wenn die Wiedergabeautorisierung aktiviert ist, können aktuelle Zuschauer die Wiedergabe laufender Streams wahrscheinlich fortsetzen. Neue Zuschauer können jedoch möglicherweise nicht mit der Wiedergabe beginnen, wenn Probleme mit der Autorisierung des Wiedergabeschlüsselpaars auftreten. Wenn die Wiedergabeautorisierung nicht aktiviert ist, sollten sowohl aktuelle als auch neue Zuschauer den laufenden Stream sehen können.

  Das IVS-Feature „Automatische Aufzeichnung in S3“ kann im Falle eines Ausfalls unterbrochen werden.

  Die IVS-Steuerebene führt im Falle eines regionalen Ausfalls nicht automatisch ein Failover zu einer anderen AWS-Region durch.

• Wenn zwei Steuerebenenregionen (z. B. USA West-1 und USA West-2) verwendet werden und die zweite Region ein Failover ist, wenn die primäre Region nicht verfügbar ist, unterstützt IVS von Haus aus kein regionales Failover auf der Steuerebene. Wenn also in einer Steuerebenenregion Probleme auftreten, können beim Starten neuer Streams oder bei Anrufen an die Steuerebene Probleme auftreten. Die Datenebene wäre jedoch wahrscheinlich nicht betroffen, sodass die laufenden Streams für den Bereich der Steuerebene problemlos fortgesetzt würden. Das Verschieben der Steuerebene in eine sekundäre (Failover)-Region müsste auf der Anwendungsseite erfolgen. Sie können eine benutzerdefinierte Implementierungslogik schreiben, um den Failover auf der Steuerebene zu handhaben. Wir haben keine offiziellen Richtlinien zur Verwaltung eines regionalen Channel-Failovers.

  Durch die Trennung der Videodatenebene und der regionalen Steuerebene erhöht die IVS-Architektur die Widerstandsfähigkeit: Laufende Live-Streams sollten im Falle eines Ausfalls der regionalen Steuerebene kaum bis gar nicht unterbrochen werden. IVS hat ein SLA von 99,9 % Verfügbarkeit und verpflichtet sich, die Stabilität seiner Infrastruktur für seine Kunden zu gewährleisten (siehe unser SLA).

Wie behebe ich Fehler bei einer IVS-Web-Broadcast-SDK-Sitzung?

Das IVS Web Broadcast SDK funktioniert etwas anders als eine normale IVS-RTMPS-Ingest-Sitzung. Das Web Broadcast SDK nutzt das WebRTC-Protokoll, um zu einem IVS-Endpunkt zu streamen. Sobald der Inhalt den IVS-Endpunkt erreicht hat, wird er verarbeitet und zur Anzeige in der HLS-Ausgabe erneut gemischt/transkodiert.

Aufgrund der Funktionsweise des Web Broadcast SDK sollten Sie die folgenden Tipps zur Fehlerbehebung beim Codierungsverhalten beachten:

• Schließen Sie alle Registerkarten/Programme auf dem Übertragungsgerät, die während der Übertragungssitzung nicht geöffnet sein müssen. Überflüssige Registerkarten/Programme können Rechenressourcen (wie CPU, RAM und Netzressourcen) beanspruchen, was zu einer schlechten Leistung der übertragenden Anwendung führen kann. Stellen Sie bei Registerkarten/Programmen, die nicht geschlossen werden können, sicher, dass sie keine unnötigen Mengen an Rechenressourcen verbrauchen.

• Stellen Sie sicher, dass die Upload-Geschwindigkeit des Geräts 200 Kbit/s überschreitet. (Dies ist in einem der bekannten Probleme für das Web Broadcast SDK vermerkt.) Um die Upload-Geschwindigkeit zu bewerten, öffnen Sie den Aufgabenmanager des Übertragungsgeräts, um das beim Streaming verfügbare Netzwerk zu analysieren. Wenn die Upload-Geschwindigkeit/Bitrate niedriger als erwartet oder gewünscht ist, überprüfen Sie andere Registerkarten/Prozesse, die möglicherweise Bandbreite verbrauchen. Schauen Sie sich auch andere Computer im lokalen Netzwerk an, die möglicherweise viel Bandbreite verbrauchen.

• Wenn es willkürliche Spitzen in der CPU-Auslastung gibt, sehen Sie sich den Aufgabenmanager des Rechners an, um herauszufinden, welche Prozesse möglicherweise CPU verbrauchen. Ein häufiger Dienst, der die CPU-Auslastung unregelmäßig belastet, ist Anti-Virus-Software, die regelmäßige Scans auf dem Rechner durchführt.

• Versuchen Sie, über https://stream.ivs.rocks/ zu streamen, um Umgebungen zu isolieren und sicherzustellen, dass nicht die Anwendungslogik das unerwünschte Verhalten verursacht. Diese Website wird von IVS betrieben und ist eine zuverlässige Testumgebung, um festzustellen, ob Teile der Integration mit dem Web Broadcast SDK die Hauptursache für das unerwünschte Verhalten sind.

• Versuchen Sie, die WebRTC-Internals von Google Chrome zu verwenden (siehe unten).

Wie verwende ich die WebRTC-Internals-Metriken von Google Chrome, um eine IVS-Web-Broadcast-SDK-Sitzung auszuwerten?

Beim Streamen über das IVS Web Broadcast SDK können beim Codieren und Senden der Übertragung verschiedene Verhaltensweisen auftreten. Gehen Sie wie folgt vor, um Fehler zu beheben oder Informationen über die Sitzung auf dem Übertragungsgerät zu sammeln:

1. Öffnen Sie in Google Chrome die übertragende Webseite.

2. Öffnen Sie eine neue Registerkarte in Chrome und gehen Sie zu chrome://webrtc-internals/ (kopieren Sie exakt das).

3. Starten Sie auf der Registerkarte der ursprünglich übertragenden Webseite die Web-Broadcasting-SDK-Sitzung und lassen Sie die Sitzung laufen, bis das Verhalten beobachtet wird.

4. Sobald das Verhalten beobachtet wurde, wechseln Sie zur Registerkarte chrome://webrtc-internals/ (beenden Sie die Übertragungssitzung nicht) und stellen Sie sicher, dass die richtige Webseite angezeigt wird:

   

5. Öffnen Sie den erweiterbaren Bereich Create Dump ganz oben auf dem Bildschirm.

6. Wählen Sie oben auf dem Bildschirm (Rechts unter Create Dump ) die Option PeerConnection Updates und Statistikdaten herunterladen aus, um die .txt Datei aus der entsprechenden Sitzung herunterzuladen.

7. Nach dem Herunterladen zeigt die Datei eine Verlaufsansicht der WebRTC-Verbindung. Sie können dies in verschiedenen Tools einsehen oder zur weiteren Analyse an das Team von AWS Support senden.

Überwachung und Ereignisse

Die Fragen in diesem Abschnitt beziehen sich auf IVS-Überwachung, Metriken und Ereignisse.

Themen:

• Wie überwache ich Stream-Starvation-Ereignisse?

• Wie verwende ich Amazon CloudWatch zur Überwachung von IVS-Servicekontingenten?

• Wie diagnostiziere ich Stream-Instabilität mit IVS Stream Health?

Wie überwache ich Stream-Starvation-Ereignisse?

Wir empfehlen die folgenden Methoden zur Überwachung von Stream-Starvation-Ereignissen:

• Amazon EventBridge mit Amazon IVS – Wenn ein Stream-Starvation-Ereignis beginnt oder endet, erzeugt IVS ein EventBridge Stream-Zustandsänderungsereignis. Mithilfe von Amazon- EventBridge Zielen und -Regeln können Sie dieses Stream-Starvation-Ereignis verwenden, um Warnungen zu erhalten, wenn Stream-Starvation auftritt. Weitere Informationen zu Zielen und Regeln finden Sie im Amazon- EventBridge Benutzerhandbuch.

• Überwachen von Amazon-IVS-Streaming mit niedriger Latenz – Während einer Live-Stream-Sitzung werden Daten aufgezeichnet und sind dann über IVS-Stream-Zustand-Analyse verfügbar. Dazu gehören Informationen zur Encoder-Konfiguration, Erfassungsmetriken und Stream-Sitzungsereignissen. Dies ist vorteilhaft, wenn ein laufender Stream überwacht oder ein Stream rückwirkend bewertet wird. Sie können die IVS-Konsole oder API verwenden, um Streams zu identifizieren, bei denen es zu Starvation gekommen ist. Stream-Sitzungsdaten sind 60 Tage lang verfügbar, auch nachdem ein Kanal gelöscht wurde. Dies kann nützlich sein, um vergangene Streams mit Starvation-Ereignissen zu identifizieren.

• Streams nach Zustand filtern – Mit der IVS-Konsole oder dem IVSListStreams-API-Endpunkt können Sie den health Filter verwenden, um Stream-Sitzungen zu finden, die sich im STARVING Status befinden. Außerdem ConcurrentStreams enthält die IVS- CloudWatch Metrik für eine Health Dimension, mit der Sie eine Gesamtzahl von Streams erfassen können, die sich im Stream-Starvation-Status befinden. Siehe Überwachen von Amazon-IVS-Streaming mit niedriger Latenz.

• Sie können den IVS-GetStreamEndpunkt verwenden, um einen einzelnen Stream zu analysieren.

Lesen Sie auch den Abschnitt Was ist Stream-Starvation?

Wie verwende ich Amazon CloudWatch zur Überwachung von IVS-Servicekontingenten?

Sie können Amazon verwenden CloudWatch , um IVS-Servicekontingente proaktiv zu überwachen/zu verwalten. Siehe Service Quotas von IVS. Diese Dokumentation enthält Informationen zum Erstellen von CloudWatch Alarmen für Nutzungsmetriken.

Wir empfehlen, ein geeignetes SNS-Thema einzurichten, um die richtigen Personen/Gruppen zu benachrichtigen, wenn ein Alarm ausgelöst wird. Wenn der Alarm ausgelöst wird und das Kontingent anpassbar ist, sollten Sie eine Erhöhung des Servicekontingents um einen neuen Wert beantragen. Informationen zur Beantragung einer Erhöhung finden Sie unter Service Quotas von IVS.

Wie diagnostiziere ich Stream-Instabilität mit IVS Stream Health?

Wir empfehlen Ihnen, die Stream-Instabilität mithilfe des IVS-Stream-Health-Dashboards zu bewerten. Anleitungen finden Sie in Überwachen von Amazon-IVS-Streaming mit niedriger Latenz.

Das Dashboard enthält Zeitreihendiagramme für Videobitrate, Bildrate und Audiobitrate. Beispiele finden Sie unten. Außerdem können Sie auf Anzeigen in CloudWatch klicken, um die Daten in Amazon anzuzeigen CloudWatch.

Im Folgenden werden mehrere Szenarien diskutiert.

Niedrige Internetbandbreite oder Internetüberlastung

In diesem Fall ist der Stream relativ instabil, selbst wenn die Bitraten gesenkt werden. Entweder ist nicht genügend Bandbreite zwischen dem Sender und dem ISP oder zwischen dem ISP und IVS vorhanden, oder im Netzwerkpfad zu IVS stimmt etwas nicht. Um dieses Problem zu beheben, überprüfen Sie, ob kein anderer Netzwerkprozess Bandbreite beansprucht, oder wenden Sie sich für eine Netzwerkdiagnose an den ISP.

Dashboard von IVS Stream Health:

CloudWatch:

Übermäßig hohe Bitrate

Eine höhere Bitrate bedeutet nicht unbedingt eine bessere Qualität; hier führt eine hohe Bitrate zu Instabilität. In vielen Fällen führen hohe Bitraten aufgrund von Netzwerküberlastung zu einer Instabilität des Streams während einer Übertragung. Halten Sie sich an die in Auflösung/Bitrate/FPS aufgeführten maximalen Bitraten.

Dashboard von IVS Stream Health:

CloudWatch:

Netzwerk- oder Hardwareprobleme

Die Videocodierung beansprucht eine Menge Rechenressourcen, und manchmal kann die Maschine, die die Videocodierung durchführt, mit der Last nicht Schritt halten. Stellen Sie in diesem Fall sicher, dass die Maschine nicht überlastet ist (es werden zu viele Dinge gleichzeitig ausgeführt) und dass der Encoder auf dem neuesten Stand ist. Erwägen Sie, zu einer Codierungsvorgabe zu wechseln, die weniger CPU verbraucht.

Dashboard von IVS Stream Health:

CloudWatch:

Bitratenspitzen und -einbrüche

Manchmal versuchen Streaming-Encoder, zu intelligent zu sein und die Bitrate zu optimieren, was oft von der Komplexität des zu komprimierenden Frames abhängt. Wenn die Bitrate schnell schwankt, kann es bei Zuschauern zu Puffern kommen, wenn sie versuchen, zu viele Daten zu laden. Stellen Sie sicher, dass Constant Bitrate (CBR) aktiviert ist, da dadurch unabhängig von der Frame-Komplexität eine gleichbleibende Bitrate im gesamten Stream aufrechterhalten wird. Beachten Sie, dass auch Einbrüche auftreten können. Dies kann ein Zeichen dafür sein, dass Ihr Computer nicht über genügend CPU-Leistung verfügt, um den Encoder zum Komprimieren von Videos zu verwenden.

Dashboard von IVS Stream Health:

CloudWatch:

Unterbrechung der Internetverbindung

Wenn bei einem Übertragungsgerät ein Internetproblem auftritt, prüfen die IVS-Server in einem Zeitraum von 30 Sekunden, ob dieselbe Verbindung wieder hergestellt wurde. Wenn dieselbe Verbindung nicht wiederhergestellt wird, beendet der IVS-Server die Stream-Sitzung. Einige Encoder versuchen, sich erneut mit der Broadcast-Sitzung zu verbinden, wenn die Internetverbindung unterbrochen wird. In diesem Fall kann nach dem Ende des ersten Streams eine neue Stream-Sitzung gestartet werden.

Dashboard von IVS Stream Health:

CloudWatch:

Stream-Wiedergabe

Die meisten Informationen in diesem Abschnitt beziehen sich spezifisch auf das IVS-Player-SDK und gelten möglicherweise nicht für andere Player. Weitere Informationen finden Sie unter Amazon-IVS-Player.

Themen:

• Wie debugge ich das Verhalten von IVS-Playern?

• Warum wurde die Wiedergabe für alle Zuschauer eingefroren/gestoppt?

• Was führt dazu, dass der IVS-Player zwischengespeichert wird?

Wie debugge ich das Verhalten von IVS-Playern?

Verwenden Sie die setLogLevel-Player-Methode, um die ausführliche Protokollierung zu aktivieren, um das Debuggen des IVS-Players zu unterstützen. Ändern Sie die Protokollebene des Players, um das DEBUG-Argument zu verwenden. Dann erstellt der IVS-Player eine ausführliche Protokollierung des Zustands und der Logik des IVS-Players.

Verwenden Sie die Testseite https://debug.ivsdemos.com/, um schnell mit dem IVS-Player zu testen, mit oder ohne aktivierten DEBUG-Protokollen. Wenn DEBUG-Protokolle über das Einstellungsmenü aktiviert sind, können Sie die Protokolle in der Browser-Konsolenansicht anzeigen.

Warum wurde die Wiedergabe für alle Zuschauer eingefroren/gestoppt?

Wenn die Wiedergabe innerhalb des Inhalts für alle Zuschauer gleichzeitig einfriert oder stoppt, ist dies wahrscheinlich das Ergebnis eines Upstream-Verhaltens. Oft ist die Ursache der Broadcast-Encoder.

Ein Stream-Starvation oder ein negatives Verhalten des Broadcast-Encoder können sich auf alle Zuschauer gleichzeitig auswirken. Wenn die Broadcasting-Codierung unterbrochen wird und eine neue Stream-Sitzung gestartet wird, hören alle Zuschauer gleichzeitig auf, Inhalte zu empfangen. Wenn Sie dieses Verhalten evaluieren, empfehlen wir Ihnen, die Stream-Sitzung mit Überwachen von Amazon-IVS-Streaming mit niedriger Latenz auszuwerten.

Was führt dazu, dass der IVS-Player zwischengespeichert wird?

Im Zusammenhang mit der Wiedergabe von Live-Streaming-Video und Audio bedeutet „Pufferung“, dass das Wiedergabegerät den Inhalt nicht herunterladen kann, bevor der Inhalt abgespielt werden soll. Die Pufferung kann sich auf verschiedene Arten manifestieren: Inhalte können nach dem Zufallsprinzip anhalten und beginnen (auch als Stottern bezeichnet), Inhalte können für längere Zeit anhalten (auch bekannt als Einfrieren), oder der Player kann in einen BUFFERING-Zustand wechseln.

Es gibt viele Ursachen für Pufferung, die wir in drei Hauptkategorien einteilen können:

• Eine Pufferung auf der Zuschauerseite tritt häufig auf, wenn ein einzelner Zuschauer oder eine kleine Gruppe von Zuschauern von einem Pufferereignis betroffen ist. Die Hauptursache für diese Pufferereignisse ist häufig ein Problem mit dem lokalen Netzwerk (LAN) oder dem Wiedergabegerät. Im Falle eines langsamen lokalen Netzwerk- oder Geräteproblems kann die Pufferung behoben werden, indem sichergestellt wird, dass die adaptive Bitratenwiedergabe (ABR) aktiviert ist, manuell eine niedrigere Qualität ausgewählt oder die von anderen Programmen und Geräten genutzte Bandbreite reduziert wird.

• Pufferung auf Netzwerkebene – Zwischen dem lokalen Netzwerk und dem IVS-Verteilungsserver, auch bekannt als ISP-Ebene, können Probleme auftreten. Pufferverhalten, das auf ISP-Ebene auftritt, kann schwierig zu beheben sein, da ein vollständiger Einblick in den ISP möglicherweise nicht möglich ist. Verhaltensweisen wie Latenz und Netzwerkbelastung (z. B. kann der ISP den gesamten eingehenden/ausgehenden Verkehr nicht bewältigen) können zu Verzögerungen bei der Bereitstellung von Inhalten für den Betrachter führen.

• Pufferung auf der Broadcast-Seite – Probleme auf der Übertragungsseite der Live-Stream-Sitzung können zu großen Pufferproblemen bei den Zuschauern führen. Wenn beispielsweise ein Broadcasting-Gerät keine Daten mehr an IVS sendet, hat IVS keinen Inhalt, der an den Player übermittelt werden kann, und der IVS-Player geht in einen Pufferzustand über, wenn kein Inhalt heruntergeladen wird. In vielen Fällen führt ein Pufferereignis auf der Sendeseite dazu, dass die meisten, wenn nicht sogar alle Zuschauer gleichzeitig betroffen sind.

Automatische Aufnahme auf Amazon S3

Weitere Informationen finden Sie unter Automatische Aufnahme in Amazon S3 speichern.

Themen:

• Warum fehlen einige Aufnahmeinhalte?

• Kann die KMS-S3-Verschlüsselung mit der automatischen Aufzeichnung in S3 verwendet werden?

Warum fehlen einige Aufnahmeinhalte?

Es gibt verschiedene Gründe, warum aufgezeichnete Inhalte fehlen können. Wir empfehlen die folgenden Schritte, um den fehlenden Inhalt zu beheben:

1. Vergewissern Sie sich, dass die automatische Aufzeichnung in S3 für den gewünschten IVS-Kanal aktiviert ist:

   1. Konsole – Vergewissern Sie sich auf der Detailseite des betreffenden Kanals unter Allgemeine Einstellungen, dass Automatische Aufzeichnung in S3 Enabled ist. Wenn sie aktiviert ist, überprüfen Sie die Aufzeichnungskonfiguration, um sicherzustellen, dass sowohl das Speicher- als auch das Aufzeichnungspräfix korrekt sind.

   2. CLI – Führen Sie get-channel für den gewünschten IVS-Kanal-ARN aus und übergeben Sie ihn:

      aws ivs get-channel --arn "arn:aws:ivs:us-west-2:123456789012:channel/abcdABCDefgh"

      Prüfen Sie, ob ein recordingConfigurationArn zurückgegeben wird.

2. Suchen Sie im angegebenen S3-Bucket nach den Aufzeichnungsinhalten für die spezifische Stream-Sitzung (siehe S3-Präfix ). Das S3-Schlüsselpräfix für eine aufgezeichnete Sitzung befindet sich im Ereignis „Amazon EventBridge -Aufzeichnungsstatusänderung“. Hinweis: Wenn das Feature Fragmentierte Streams zusammenführen aktiviert ist, handelt es sich bei einigen Inhalten möglicherweise um eine weitere aufgezeichnete Sitzung.

3. Wenn die Gesamtdauer des Streams weniger als 10 Sekunden betrug oder der Inhalt des Streams fehlte (d. h. es ist Stream Starvation aufgetreten), fehlen möglicherweise aufgezeichnete Inhalte, da nichts generiert wurde.

Kann die KMS-S3-Verschlüsselung mit der automatischen Aufzeichnung in S3 verwendet werden?

Die IVS-Funktion zur automatischen Aufzeichnung in Amazon S3 unterstützt keine KMS-S3-Verschlüsselung. Wenn Sie versuchen, die KMS-S3-Verschlüsselung zu verwenden, schlägt der Aufzeichnungsstart fehl und es wird ein EventBridge Ereignis für einen Fehler beim Aufzeichnungsstart ausgegeben. Die empfohlene Problemumgehung besteht darin, die unterstützte SSE-S3-Verschlüsselung zu verwenden, die standardmäßig für alle auf Amazon S3 hochgeladenen Objekte aktiviert ist.

Sonstige Themen

Die Fragen in diesem Abschnitt beziehen sich auf Themen, die nicht anderweitig kategorisiert werden können.

Themen:

• Was bedeutet der Fehler „Überprüfung ausstehend“?

• Kann ich die IVS-Kosten schätzen?

Was bedeutet der Fehler „Überprüfung ausstehend“?

Bei der Verwendung von IVS kann ein Fehler auftreten, der besagt: „Die Überprüfung Ihres Kontos steht aus. Bis die Überprüfung abgeschlossen ist, können Sie möglicherweise keine Anforderungen mit diesem Konto durchführen. Bei Fragen wenden Sie sich an den AWS Support.“

Dies bedeutet, dass das von Ihnen verwendete AWS-Konto bei AWS verifiziert werden muss, bevor Sie IVS verwenden können. (Ihr Konto funktioniert möglicherweise mit anderen AWS-Services, IVS verwendet jedoch eine erweiterte Überprüfungsmethode.)

Um Ihr AWS-Konto zu verifizieren, wenden Sie sich – mit der Fehlermeldung, die Sie erhalten – vom AWS Support Center aus an den AWS-Kontosupport: https://support.console.aws.amazon.com/support/home?#/

Kann ich die IVS-Kosten schätzen?

Die genauen Kosten der IVS-Nutzung können zwar nicht vor einer Stream-Sitzung ermittelt werden, eine grobe Kostenschätzung finden Sie jedoch unter: https://ivs.rocks/calculator. Weitere Preisinformationen finden Sie unter: https://aws.amazon.com/ivs/pricing/.